|
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.
|
|
|
|
|
Another great performer has checked out. I warmly recommend you to find any of his duets with Lady Gaga (e.g: The Lady is a Tramp). An unexpected and amazing cooperation across generations.
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
I understand he also - while serving in a segregated military - got demoted essentially for fraternizing with black troops, and assigned to corpse duty (exhuming mass graves for soldiers bodies to send home) as punishment.
It didn't stop him. Later he'd march with MLK Jr.
A real mensch.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
|
|
|
|
|
|
They have thrown out the playlist and are spinning and talking about Tony.
JAZZ.FM91 - Discover Music
"Mistakes are prevented by Experience. Experience is gained by making mistakes."
|
|
|
|
|
Never was a fan but he had talent. R.I.P.
Give me coffee to change the things I can and wine for those I can not!
PartsBin an Electronics Part Organizer - Release Version 1.1.0 JaxCoder.com
Latest Article: Simon Says, A Child's Game
|
|
|
|