Swimming out past the markers
-
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
got it, thanks: imho, your definition of "embedded" is critical to your work, and, i don't get ... that :omg: :) 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
-
got it, thanks: imho, your definition of "embedded" is critical to your work, and, i don't get ... that :omg: :) 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
-
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'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
-
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
-
Oh plenty of people do embedded. They just aren't talking. :-\
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
-
Oh plenty of people do embedded. They just aren't talking. :-\
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
-
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
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.
-
Oh plenty of people do embedded. They just aren't talking. :-\
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx
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.
-
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
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 r