|
jmaida wrote: Hardware can be a bear b1tch sometimes. FTFY
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
honey the codewitch wrote: the same way Kraft Singles are Cheese-ish - you knew what it was trying to be, but no. Just, no. eloquent !
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
#Worldle #546 1/6 (100%)
🟩🟩🟩🟩🟩🎉
https://worldle.teuteuf.fr
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
I placed a single Amazon order with 4 different items. At check-out I checked the box indicating that they can delay an item if needed to reduce boxes / shipments. Nevertheless, they proceeded to create 4 different shipments - OK, probably coming from 4 different warehouses. Now I get to watch status updates as the Amazon and USPS wheels spin gears grind.
Shipment 1 - Started at a warehouse about 100 miles away. By Wednesday it arrived at a hub about 30 miles away with an estimated delivery of Thursday (a day early). Then I got a "Delayed in transit" status and no Thursday delivery. It's now at a hub 150 miles away with a "An address redirection agreement is in place between the customer and the carrier. Package will be forwarded to the requested address." status.
Shipment 2 - Started at a warehouse 1500 miles away and arrived at my local post office this morning where it met up with shipment #3 (see below).
Shipment 3 - Started at a warehouse about 30 miles away and arrived at my local post office this morning where it met up with shipment #2. Both items are now at a hub or post office (its unclear) about 90 miles away.
Shipment 4 - I just got notice of the label being printed. Bezos only knows where this one will travel.
I usually have pretty good luck with Amazon deliveries but this one has gone completely sideways. Its a good thing none of these deliveries are time sensitive.
|
|
|
|
|
I just use the free next-day delivery, and it's usually here about 13:30 ~ 14:30 the following day.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Oh, this is obviously Amazon's Game Day Challenge Bonanza!!, where you and special someone could win a trip to.....Hawaii!
|
|
|
|
|
This isn't a criticism, just an observation: There are no "real"" articles on getting going with embedded here at codeproject.
For example, I just searched for Devicetree - a declarative format for configuring hardware for an operating system like Linux and ZephyrOS. I found one result - an interesting little linux driver that implements a loop back of some sort.
Nothing really on using ST's HAL, or NXP's offerings, or even the VS Code extensions by Nordic Semiconductor.
On one hand, that's fertile article territory.
On the other, codeproject is in good company in this respect.
If you intend to practice the black arts of commercial embedded, you will eventually need to know these things, only to find out that
A) After sitting through 30 minutes of a how to video you notice it won't support your hardware
B) Google laughs at your search queries. Laughs in your face. Try googling how to do SPI with CMSIS. You'll find two useful article with code and concepts, both for a particular semiconductor vendor you don't use. I've already looked.
C) Try using Cube. Just try. If the screen doesn't stop repainting for you 5-10 minutes in, you're a luckier person than me. And even if you get past that, you still have to learn how to use it
D) Everything else is courses and academies.
Regarding D: I really don't do well with that format. I test well, but only if I can figure out how to learn something on my own before the test is due. That worked in high school. It won't work here. I need better options.
I'm on a discord about this. And I've been in my element banging away at ZephyrOS. I may just have some codeproject articles on this eventually.
Of course that's what I said about getting an OSless setup running on an ARM Cortex A before I gave that up.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
|
|
|
|
|
Completely agree. In the middle of looking at a number of technical issues - all related to Microsoft. I'm sure they answered the question somewhere, but there are so many answers and so much clutter it's useless - that's on Microsoft's site. Going through google, it gets even worse. A full page of responses that are all paid advertisements but no information.
The embedded world is somewhat of a microcosm. I have found most of my information from the tool vendor forums and occasionally reddit.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Have you asked ChatGPT?
I just asked it "how to implement SPI with CMSIS"
and it gave a lengthy answer including some stub code examples in C/C++, but here:
Quote: Initialize CMSIS:
Include the CMSIS header file for your specific microcontroller in your project. For example, for ARM Cortex-M microcontrollers, you can include "core_cmX.h," where "X" represents the Cortex-M version.
Configure SPI Registers using CMSIS:
Access the SPI registers using CMSIS structures and configure them accordingly. Is where I suspect it could be less vague.
|
|
|
|
|
Like Microsoft documentation - technically correct, but practically useless.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
|
|
|
|
|
History has taught me not to go beyond the crayons.
|
|
|
|
|
We're relying on you to lead the way, to give us some direction! You are the CodeWitch - All Hail The CodeWitch!
Someone has to go first, young lady, and you have a healthy head start on the rest. Lead the way, start filling that void, and claim the fame you deserve.
Will Rogers never met me.
|
|
|
|
|
I am busy zephyrizing a bunch of my IoT ecosystem in order to have some fundamentals to work with
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
|
|
|
|
|
I'd be curious after all the optimization, how portable the code is from project to project. My experience has been that unless you are solving a very specific/generic problem, code reuse doesn't happen. The concepts are transferred but not the code itself.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
I just got it working.
uix on zephyr os - YouTube[^]
That uses much of my ecosystem. Not the drivers. I can't really write zephyr drivers as part of my ecosystem because of the way it initializes globals in C++ - it does so after the drivers are initialized, so you cannot use C++ to write the drivers.
On the other hand, I've been looking and most of the ones I've written are either already written, or a variant is written that can be easily modified.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
|
|
|
|
|
so, lead the charge ?
isn't there a yuge bunch of makers, bloggers, etc., around Arduino, etc. ? lots of competition in the industry, and many manufacturers targeting hobbyists, researchers ?[^]
Your frustration comes as you struggle to make your graphic/imaging facility (high quality font and image rendering ?) work with newer, less known, boards ... with smaller image/font displays ?
Please leave more clued on the path to the rabbit hole
cheers, bill
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
You can't really make proper embedded devices with Arduino.
Embedded involves like ZephyrOS, embedded linux, or FreeRTOS. It involves pulling your hair out because you spent the day trying to get SPI working only you didn't read paragraph 3, page 1059 of the hardware reference manual's errata which tells you that SPI won't work at the clock speed you're running at due to a hardware bug.
That's embedded.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
modified 23-Jul-23 2:03am.
|
|
|
|
|
got it, thanks: imho, your definition of "embedded" is critical to your work, and, i don't get ... that
advice ?: if i wanted to find a low cost limited functioning robot kit i could cover with my own design cover, that i'd then send commands to by bluetooth ... imagine a small robot dog ...
where would you look ?
thanks, bill
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
Honestly, Amazon has a pretty big selection of them. You'll have to get creative about designing a cover for one, but it's a start
Amazon.com : arduino robot[^]
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
|
|
|
|
|
Does this mean you are a pioneer? I think it does.
|
|
|
|
|
Oh plenty of people do embedded. They just aren't talking.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
|
|
|
|
|
So you aren't Lewis and Clark, but you could be Laura Ingalls ...
|
|
|
|
|
Maybe they are talking, but in more specific forums.
Such as for the Nordic Semiconductor chips: There is quite some traffic at Nordic DevZone[^], bur aimed at those developing for Nordic chips.
Yet you might be able to pick up some useful tricks, if you work with ARM based chips and Zephyr. Lots of issues relate to Zephyr and ARM, not specifically to the Nordic implementation.
|
|
|
|
|
In the later half of my embedded career, I was pretty much locked into using TI DSPs. Our 911 products did lots of audio processing (one product had 23 audio channels). TI has lots of samples for their DSP products and since they have a fair number of ARM processors, I'd bet they have samples for them too. You might want to check them out. They also have cheap dev boards where you can try things out.
The only ARM project I worked on was using an ARM7tdmi. It's been around for a long time so it was fairly easy to find sample code on the web.
|
|
|
|
|
Embedded programming is antithetical to pretty much every programming trend of the last 20 years. Note: If you are programming on a board that runs Linux or Android then this discussion is not really aimed at you.
Deeply embedded systems are often built on severely resource constrained hardware. The typical embedded system uses only the memory built into the processor which can be a lot less than you expect. Cortex M0 processers for example come in variants with as little as 32KB FLASH and 2 KB RAM. Note the K vs M.
The primary embedded programming languages is C (not C++ even though your compiler will claim to be C/C++). You will also need assembly code if you do board support packages. If you are not a proficient C coder, then get a good book and teach yourself.
Book recommendations: All of these are older than dirt, but they are classics for a reason and will help you develop the mindset of an effective embedded programmer. Some of these are available as free downloads.
* "Practical C Programming" by Steve Oualline for learning C coding in general.
* "The Art of Embedded Systems" by Jack Gansslle for the general philosophy of embedded programming.
* "Math Toolkit for Real-Time Programming" by Jack Crenshaw for complicated math.
* "Insiders Guide to the Phillips ARM7 based Microcontrollers" by Trevor Martin for using processor resources.
Martin's book on Philips ARM7 is the very best hardware tutorial book I have ever read. Hitex did a great thing for embedded programmers when they released this book as a free download (I think Philips paid for this book). I wish they had done the same thing for Cortex M processors, but life happens and money is not infinite.
https://perswww.kuleuven.be/~u0068190/ARM7/lpc-ARM-book_srn.pdf
Embedded systems can go years between reboots and memory usage management is up to the programmer. Automatic memory allocation (malloc, new, etc.), or anything object oriented can be dangerous. Be wary of any library code that uses these kinds of things. This is one of the reasons why I want the source code for all libraries I use.
Ring buffers are your friend. If properly implemented, buffer overflow exploits just became a thing of the past. You will need to be able to deal with missing data. I use packetized messages with error detection and missing message detection built into the communication protocol (I have been using my own processor to processor packetized protocol that I have used and extended over the last 2 decades).
Every embedded product needs a robust powerup self test function. Run a checksum on your application, perform whatever hardware testing you can and protect your non-volatile memory. Break NVM up into structs that fit within your EEPROM page size. Include a non-zero ID value and checksum in each NVM struct. Add limit tests on multiple choice variables, do anything you can do to detect corrupted NVM data since this is a major risk vector for your code. Alert users as best you can when you detect a problem. Always use the enable pin on EEPROMs (don't just tie them to ground). In some EEPROM devices a single bit change (ESD anyone) can turn a read into a write or erase.
Fight to include an LED the user can see for status display, even if you have an operator display. The happy state is best indicated by a slowly flashing (not a solid on or worse, solid off). You can change the flash rate to indicate different status or mode conditions. Pulsed patterns can be used to indicate specific states or error conditions. And don't use a hardware counter/timer to pulse the LED. Put the LED code in the lowest priority (background) task and make it look at variables in each of the other tasks that indicate if the task is hung up.
Embedded systems often directly control hardware. An electrical engineering background really helps. At a minimum, you need to be able to understand an electronic schematic. If you lack this background then I suggest you take some EE classes. Focus on serial interfaces like I2C and SPI. You will also find yourself using UARTs far more than you ever expected. Martin's Philips ARM7 book is a great resource for best to do this kind of stuff.
You will also sometimes have to meet hard real time requirements which are most easily implemented with an RTOS. If there are any hard real time requirements, then start your designs on the RTOS of your choice, because systems inevitably get more complex over time and porting an existing project to an RTOS is a complete waste of time.
F.Y.I. I am very experience using the Nordic Semi SDK and all I can say, this is not a good resource to learn how to do embedded programming. The SDK was designed to work with a wide variety of ARM processors with a minimum of rewriting and the stuff that actually does the work are extremely well hidden and it is difficult to comprehend by reading the tutorial code in the SDK. The SDK is also extremely inefficient (6 nested subroutine calls to toggle a GPIO bit???). The first project I did using this SDK was reading a high speed ADC over a wireless link (5000 reads per second). It turned out I could read the ADC using a bit-bang implementation of the SPI port 3 times faster than the SDK could using the processor's hardware SPI port. That is pretty pathetic.
|
|
|
|