Moving on up (to ARM)
-
My little consortium of embedded developers is looking to move our offerings over to the ARM Cortex M line of processors. One of the big primary drivers of this, is lack of availability of LCD displays for the more hobbyist/Arduino type end of things. The first issue we've had is an utter lack of toolchain, bootloader firmware, HAL code, or really anything to get us going starting with a bare metal chip. I discovered keil.com which can potentially get us over that hump, if we can afford it. I'm always a little anxious when getting a price requires a quote. Waiting to hear from them, but I also am still out of my depth. I know there are some embedded developers here. I'm not afraid of failure, and I'm not afraid to get my hands dirty. Any advice as far as this move goes would be appreciated. It's definitely the deep end of the pool for me.
To err is human. Fortune favors the monsters.
-
My little consortium of embedded developers is looking to move our offerings over to the ARM Cortex M line of processors. One of the big primary drivers of this, is lack of availability of LCD displays for the more hobbyist/Arduino type end of things. The first issue we've had is an utter lack of toolchain, bootloader firmware, HAL code, or really anything to get us going starting with a bare metal chip. I discovered keil.com which can potentially get us over that hump, if we can afford it. I'm always a little anxious when getting a price requires a quote. Waiting to hear from them, but I also am still out of my depth. I know there are some embedded developers here. I'm not afraid of failure, and I'm not afraid to get my hands dirty. Any advice as far as this move goes would be appreciated. It's definitely the deep end of the pool for me.
To err is human. Fortune favors the monsters.
A couple of ideas: 1. See if someone produces a Linux version for your target chip 2. See if Google has a default cross-build toolchain and environment for Android on the ARM Cortex M Using Google's stuff has the advantage that it's used to produce the Android builds, so it is reasonably certain to be bug free (ha ha).
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
A couple of ideas: 1. See if someone produces a Linux version for your target chip 2. See if Google has a default cross-build toolchain and environment for Android on the ARM Cortex M Using Google's stuff has the advantage that it's used to produce the Android builds, so it is reasonably certain to be bug free (ha ha).
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Thanks!
To err is human. Fortune favors the monsters.
-
My little consortium of embedded developers is looking to move our offerings over to the ARM Cortex M line of processors. One of the big primary drivers of this, is lack of availability of LCD displays for the more hobbyist/Arduino type end of things. The first issue we've had is an utter lack of toolchain, bootloader firmware, HAL code, or really anything to get us going starting with a bare metal chip. I discovered keil.com which can potentially get us over that hump, if we can afford it. I'm always a little anxious when getting a price requires a quote. Waiting to hear from them, but I also am still out of my depth. I know there are some embedded developers here. I'm not afraid of failure, and I'm not afraid to get my hands dirty. Any advice as far as this move goes would be appreciated. It's definitely the deep end of the pool for me.
To err is human. Fortune favors the monsters.
[armbian](https://www.armbian.com) make builds for most linux based ARM SBC's
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
-
My little consortium of embedded developers is looking to move our offerings over to the ARM Cortex M line of processors. One of the big primary drivers of this, is lack of availability of LCD displays for the more hobbyist/Arduino type end of things. The first issue we've had is an utter lack of toolchain, bootloader firmware, HAL code, or really anything to get us going starting with a bare metal chip. I discovered keil.com which can potentially get us over that hump, if we can afford it. I'm always a little anxious when getting a price requires a quote. Waiting to hear from them, but I also am still out of my depth. I know there are some embedded developers here. I'm not afraid of failure, and I'm not afraid to get my hands dirty. Any advice as far as this move goes would be appreciated. It's definitely the deep end of the pool for me.
To err is human. Fortune favors the monsters.
If you go with STMicroelectroincs there's the STM32CubeIDE, otherwise Keil is you IDE and I haven't priced it but I don't think it will be very cheap. STM also has a very competent HAL with a GUI that makes it a snap to configure. As for programmers there's J-Link by Seggar[^] J-Link is an all around programmer, I believe it does quite a few families of chips. Again if you go with STM there is the ST-Link programmers and they are way less expensive. I moved from Arduino to ARM and haven't looked back.
Give me coffee to change the things I can and wine for those I can not! PartsBin an Electronics Part Organizer - An updated version available! JaxCoder.com Latest Article: Simon Says, A Child's Game
-
My little consortium of embedded developers is looking to move our offerings over to the ARM Cortex M line of processors. One of the big primary drivers of this, is lack of availability of LCD displays for the more hobbyist/Arduino type end of things. The first issue we've had is an utter lack of toolchain, bootloader firmware, HAL code, or really anything to get us going starting with a bare metal chip. I discovered keil.com which can potentially get us over that hump, if we can afford it. I'm always a little anxious when getting a price requires a quote. Waiting to hear from them, but I also am still out of my depth. I know there are some embedded developers here. I'm not afraid of failure, and I'm not afraid to get my hands dirty. Any advice as far as this move goes would be appreciated. It's definitely the deep end of the pool for me.
To err is human. Fortune favors the monsters.
I don't know what you're used to but Keil makes VisualStudio 6 look futuristic. STMCube is much more powerful though I found it unreliable and very slow and heavy. Depending on the platform Keil can also end up supporting only 2 breakpoints at any given time, unless you hardcode them in with BKPT, which makes debugging tricky. I suggest you to look up the EventRecorder functionality for keil, it should work on any supported device and it's a godsend for tracing and debugging (this could be a good topic for an article, note to self). On the other hand keil is quite lightweight and fast, the compilation error messages are also quite explicative. The uLink programmers may be finicky and require multiple tries to correctly set up the reset type for debugging (I always have best results with "connect with Pre-Reset").
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
My little consortium of embedded developers is looking to move our offerings over to the ARM Cortex M line of processors. One of the big primary drivers of this, is lack of availability of LCD displays for the more hobbyist/Arduino type end of things. The first issue we've had is an utter lack of toolchain, bootloader firmware, HAL code, or really anything to get us going starting with a bare metal chip. I discovered keil.com which can potentially get us over that hump, if we can afford it. I'm always a little anxious when getting a price requires a quote. Waiting to hear from them, but I also am still out of my depth. I know there are some embedded developers here. I'm not afraid of failure, and I'm not afraid to get my hands dirty. Any advice as far as this move goes would be appreciated. It's definitely the deep end of the pool for me.
To err is human. Fortune favors the monsters.
This is from a few years ago so things may have changed. STM provides a number of development boards with their own built in debug chip which sort of simulates JTAG functionality. Oddly enough they don't support ( or didn't support ) the debug capability on all of their development boards. So I ended up with a cortex M4 board for which there was no debug support. Oddly enough I found a suitable driver for the STM debug chip on Segger's web site so that it was possible to debug stuff on that particular development board. It is too long ago to remember the details but I have all of those details in a backup location which I could lookup if you want. If my memory does not betray me I think I got it working with VSCODE, the segger driver and the gcc compiler toolchain.
-
My little consortium of embedded developers is looking to move our offerings over to the ARM Cortex M line of processors. One of the big primary drivers of this, is lack of availability of LCD displays for the more hobbyist/Arduino type end of things. The first issue we've had is an utter lack of toolchain, bootloader firmware, HAL code, or really anything to get us going starting with a bare metal chip. I discovered keil.com which can potentially get us over that hump, if we can afford it. I'm always a little anxious when getting a price requires a quote. Waiting to hear from them, but I also am still out of my depth. I know there are some embedded developers here. I'm not afraid of failure, and I'm not afraid to get my hands dirty. Any advice as far as this move goes would be appreciated. It's definitely the deep end of the pool for me.
To err is human. Fortune favors the monsters.
I have the impression that you might have been avoiding vscode. I might be wrong! vscode is 100% unrelated to Visual Studio. I suggest you take a peek at: GitHub - Marus/cortex-debug[^] 5.0 ratings [as here] are extremely rare in the vscode plugin "store".
"If we don't change direction, we'll end up where we're going"
-
My little consortium of embedded developers is looking to move our offerings over to the ARM Cortex M line of processors. One of the big primary drivers of this, is lack of availability of LCD displays for the more hobbyist/Arduino type end of things. The first issue we've had is an utter lack of toolchain, bootloader firmware, HAL code, or really anything to get us going starting with a bare metal chip. I discovered keil.com which can potentially get us over that hump, if we can afford it. I'm always a little anxious when getting a price requires a quote. Waiting to hear from them, but I also am still out of my depth. I know there are some embedded developers here. I'm not afraid of failure, and I'm not afraid to get my hands dirty. Any advice as far as this move goes would be appreciated. It's definitely the deep end of the pool for me.
To err is human. Fortune favors the monsters.
-
In our shop, we use IAR and EMBOS - it gets expensive in a hurry.
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.
Keil seems relatively affordable, if relatively affordable is about $2k a year
To err is human. Fortune favors the monsters.
-
I have the impression that you might have been avoiding vscode. I might be wrong! vscode is 100% unrelated to Visual Studio. I suggest you take a peek at: GitHub - Marus/cortex-debug[^] 5.0 ratings [as here] are extremely rare in the vscode plugin "store".
"If we don't change direction, we'll end up where we're going"
nah, I use VS Code every day, but I don't have a toolchain for targeting say, an ARM Cortex M7 or whatever.
To err is human. Fortune favors the monsters.
-
[armbian](https://www.armbian.com) make builds for most linux based ARM SBC's
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
After poking around at that site, I've already learned quite a bit, and am falling down this particular rabbit hole with gusto. A $30 ARM Cortex M that runs linux? That alone was worth following the link.
To err is human. Fortune favors the monsters.
-
Keil seems relatively affordable, if relatively affordable is about $2k a year
To err is human. Fortune favors the monsters.
-
After poking around at that site, I've already learned quite a bit, and am falling down this particular rabbit hole with gusto. A $30 ARM Cortex M that runs linux? That alone was worth following the link.
To err is human. Fortune favors the monsters.
-
That's not affordable. Anyway, why Keil when possibly GCC could do it?
"In testa che avete, Signor di Ceprano?" -- Rigoletto
It depends on what you're doing. If it was just a development subscription I'd consider it. I'd just pad my bids to cover the cost. It's really not that much money per month. That being said, after further correspondence with them it seems they want to charge me ongoing fees on a per project basis. That's not acceptable. I am unwilling to saddle my clients with ongoing royalties. They pay me for deliverables. As far as GCC, GCC is a compiler, and if you're being generous, the C standard libraries That's not enough to realistically develop on an ARM Chip. If you want to use the HDMI capabilities, USB 2.0 hosting, I2C, or really any of the peripherals on that chip you will be going straight to the registers. A hardware abstraction layer for a complicated ARM could take as much as 10 man years or more to implement. It's not cost effective to develop it myself. Keil provides packages for all of this. However, it looks like Armbian – Linux for ARM development boards[^] may be a better option.
To err is human. Fortune favors the monsters.
-
That's not affordable. Anyway, why Keil when possibly GCC could do it?
"In testa che avete, Signor di Ceprano?" -- Rigoletto
-
Quote:
That's not affordable.
How long such a stack will survive/be up to date? Let's be optimistic and say 5 Years. Makes at the end 10K$. How many hours these 10K $ allows you to do the whole thing from scratch?
You don't necessarily have to do it from scratch. For instance, my everyday work with M0 and M3 MCUs is strongly supported by their productor, via a very effective code generator (and the worst code editor I've ever used) and the GCC toolchain.
"In testa che avete, Signor di Ceprano?" -- Rigoletto
-
It depends on what you're doing. If it was just a development subscription I'd consider it. I'd just pad my bids to cover the cost. It's really not that much money per month. That being said, after further correspondence with them it seems they want to charge me ongoing fees on a per project basis. That's not acceptable. I am unwilling to saddle my clients with ongoing royalties. They pay me for deliverables. As far as GCC, GCC is a compiler, and if you're being generous, the C standard libraries That's not enough to realistically develop on an ARM Chip. If you want to use the HDMI capabilities, USB 2.0 hosting, I2C, or really any of the peripherals on that chip you will be going straight to the registers. A hardware abstraction layer for a complicated ARM could take as much as 10 man years or more to implement. It's not cost effective to develop it myself. Keil provides packages for all of this. However, it looks like Armbian – Linux for ARM development boards[^] may be a better option.
To err is human. Fortune favors the monsters.
-
Many MCU (e.g. Cypress, Microchip,...) vendors base their IDEs on GCC. Some of them provides them for free.
"In testa che avete, Signor di Ceprano?" -- Rigoletto
Right, but again GCC doesn't include everything that I need. I need the bootloader and the HAL, and all that happy business.
To err is human. Fortune favors the monsters.
-
Right, but again GCC doesn't include everything that I need. I need the bootloader and the HAL, and all that happy business.
To err is human. Fortune favors the monsters.
