Moving on up (to ARM)
-
Absolutely I'd expect Zephyr, FreeRTOS, or some other realtime OS to be present if the thing has multiple cores, or potentially multiple filesystem mount points (SDMMC/Flash/etc), and is commonly present on gadgets like this. Unfortunately it's not the last mile I'd need. For Zephyr to work for a particular chip it needs to be ported to it. For example, there is a Zephyr port to the ESP32 SoC/MCU: Zephyr RTOS on ESP32 - Zephyr Project[^] I'd need one for any particular ARM chip I was using. Zephyr would save me time vs going from scratch, but I don't want to be in the market of making HAL layers for devices so an RTOS can run on them. I'm hoping I can find that effort already made.
To err is human. Fortune favors the monsters.
If you’re more specific what actually you need from Cortex M for your project could try to help for the whole product r&d life cycle. The most important is which constraints you have and how you prioritize them - time? r&d costs? lower BoM costs? maintenance costs? long term components availability? etc … You can get one max two of these, the rest will be compromised. Choosing toolchain is just a small implementation detail that comes easily once you clear your requirements, constraints and priorities. Not vice verse.
-
Absolutely I'd expect Zephyr, FreeRTOS, or some other realtime OS to be present if the thing has multiple cores, or potentially multiple filesystem mount points (SDMMC/Flash/etc), and is commonly present on gadgets like this. Unfortunately it's not the last mile I'd need. For Zephyr to work for a particular chip it needs to be ported to it. For example, there is a Zephyr port to the ESP32 SoC/MCU: Zephyr RTOS on ESP32 - Zephyr Project[^] I'd need one for any particular ARM chip I was using. Zephyr would save me time vs going from scratch, but I don't want to be in the market of making HAL layers for devices so an RTOS can run on them. I'm hoping I can find that effort already made.
To err is human. Fortune favors the monsters.
A major reason why I brought up Zephyr is your mentioning of ARM, which is the basis for the NRF IoT/SoC chips marketed by Nordic Semiconductor (Nordic Semiconductor[^]). Their primary architecture is ARM, and their primary OS is Zephyr. When you start with Zephyr on ARM - whether on Nordic's NRF chips or some other ARM chip - it is definitely not 'making HAL layers for devices so an RTOS can run on them'. That is exactly what Zephyr has done, long ago. There is no need to spend resources on porting Zephyr to ARM. That was done years ago (I suspect that ARM was one of the targets when Zephyr was initially designed!). But of course: If you do not want to consider Zephyr, please feel free not to!
-
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 a bare metal STM32 project that can send and receive 3 bytes via USB joystick HID, using NUCLEO-F767ZI board, AZURE USBX rtos, STM32CubeIDE and a PC. The cheap NUCLEO-F767ZI does Ethernet with UDP, TCP, HTTPS. Also CAN Bus, I2C, UART, DMA etc. GitHub - wayp123/Ux_Device_HID_Bidir: STM32 project that can send and receive 3 bytes via joystick HID[^] For Linux and Windows can use raspberry pi.
-
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 a bare metal STM32 project that can send and receive 3 bytes via USB joystick HID, using NUCLEO-F767ZI board, AZURE USBX rtos, STM32CubeIDE and a PC. The cheap NUCLEO-F767ZI does Ethernet with UDP, TCP, HTTPS. Also CAN Bus, I2C, UART, DMA etc. GitHub - wayp123/Ux_Device_HID_Bidir: STM32 project that can send and receive 3 bytes via joystick HID[^] For Linux and Windows can use raspberry pi.
I should have explicitly said, I do not count the STM32 Nucleo boards, because are all Arm Cortex M0s, have no flash, no ram, and no HDMI
To err is human. Fortune favors the monsters.
-
A major reason why I brought up Zephyr is your mentioning of ARM, which is the basis for the NRF IoT/SoC chips marketed by Nordic Semiconductor (Nordic Semiconductor[^]). Their primary architecture is ARM, and their primary OS is Zephyr. When you start with Zephyr on ARM - whether on Nordic's NRF chips or some other ARM chip - it is definitely not 'making HAL layers for devices so an RTOS can run on them'. That is exactly what Zephyr has done, long ago. There is no need to spend resources on porting Zephyr to ARM. That was done years ago (I suspect that ARM was one of the targets when Zephyr was initially designed!). But of course: If you do not want to consider Zephyr, please feel free not to!
So they build and maintain Zephyr OS versions for arbitrary chips I can buy off digikey? And then if I want to use the HDMI facilities of that same chip? Then what?
To err is human. Fortune favors the monsters.
-
If you’re more specific what actually you need from Cortex M for your project could try to help for the whole product r&d life cycle. The most important is which constraints you have and how you prioritize them - time? r&d costs? lower BoM costs? maintenance costs? long term components availability? etc … You can get one max two of these, the rest will be compromised. Choosing toolchain is just a small implementation detail that comes easily once you clear your requirements, constraints and priorities. Not vice verse.
No no no no no. This isn't about a project. This is about moving all of my projects. Requirements vary based on project. That's why there are eleventy gazillion chips ARM based chips out there. I want to gather my requirements from a client, go to digikey, place an order for a chip that meets those requirements. And once I'm there, I want to be able actually *use* the damned chip, which isn't about requirements gathering or figuring scope or any of that. It's about getting a HAL and a bootloader for said chip.
To err is human. Fortune favors the monsters.
-
I am not that expert. My targets are much simpler (
M0andM3). Anyway, I think having the Teensy is a big starting point: you have a hardware reference design as well the libraries (I believe the chip on the their board is NXP, not theirs, so the software should work on your hardware). I see NXP provides itsMCUXpresso SDK(which, strangley enough, relies on 'Arm GCC') you may have a look at it."In testa che avete, Signor di Ceprano?" -- Rigoletto
Thanks. Yeah, I contacted PJRC who makes teensy, about subbing a different NXP chip with their bootloader and HAL. I asked if it would work. They were like "will it? You tell us!" And when I looked at the specs I realized there's no way some of the registers aren't different. So no I don't think PJRC's offerings will work with arbitrary NXPs, and unfortunately it's quite a bit of time and money just to check.
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.
Have you seen platformio : (Professional collaborative platform for embedded development — PlatformIO latest documentation[^])? There's a plug in for VS Code that includes the entire toolchain. Not sure if it supports all Cortex M but I know it supports STM32
-
Thanks. Yeah, I contacted PJRC who makes teensy, about subbing a different NXP chip with their bootloader and HAL. I asked if it would work. They were like "will it? You tell us!" And when I looked at the specs I realized there's no way some of the registers aren't different. So no I don't think PJRC's offerings will work with arbitrary NXPs, and unfortunately it's quite a bit of time and money just to check.
To err is human. Fortune favors the monsters.
-
Have you seen platformio : (Professional collaborative platform for embedded development — PlatformIO latest documentation[^])? There's a plug in for VS Code that includes the entire toolchain. Not sure if it supports all Cortex M but I know it supports STM32
Yeah I use it daily, and aside from some Arduino compliant STM32 Cortex M0 based boards and such, it doesn't support ARMs. The Cortex M0 is kind of one off for this purpose in that a lot of people have produced Arduino compatible HALs for Cortex M0 based devkits like the STM32 boards. Now a Cortex A or say an M7 isn't going to be supported because they have nothing for it.
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.
I was a C++ on AVR (NOT Arduino) person for many years. I switched to Atmel ARM devices (i.e. ARM M0+ and M4) years ago as they became bigger, faster, cheaper, lower power, etc. If you are targeting bare metal embedded applications, I would suggest using Atmel Studio 7 with GCC C++ and ASF (Advanced Software Framework). I believe ASF will provide the drivers and hardware abstraction you are looking for. They will warn you that ASF does not support C++, but ASF functions can be called as extern "C" functions. Use Atmel ICE for downloading code, source-code level debugging, and target register read/write. I wrote my own cooperative task-switching executive and resident interactive interpreter/compiler. I typically connect my embedded systems to a PC via multiple USB logical serial connections using multiple endpoints. This is very handy for separating control, status, and debugging streams.
-
I was a C++ on AVR (NOT Arduino) person for many years. I switched to Atmel ARM devices (i.e. ARM M0+ and M4) years ago as they became bigger, faster, cheaper, lower power, etc. If you are targeting bare metal embedded applications, I would suggest using Atmel Studio 7 with GCC C++ and ASF (Advanced Software Framework). I believe ASF will provide the drivers and hardware abstraction you are looking for. They will warn you that ASF does not support C++, but ASF functions can be called as extern "C" functions. Use Atmel ICE for downloading code, source-code level debugging, and target register read/write. I wrote my own cooperative task-switching executive and resident interactive interpreter/compiler. I typically connect my embedded systems to a PC via multiple USB logical serial connections using multiple endpoints. This is very handy for separating control, status, and debugging streams.
Thanks!
To err is human. Fortune favors the monsters.
-
No no no no no. This isn't about a project. This is about moving all of my projects. Requirements vary based on project. That's why there are eleventy gazillion chips ARM based chips out there. I want to gather my requirements from a client, go to digikey, place an order for a chip that meets those requirements. And once I'm there, I want to be able actually *use* the damned chip, which isn't about requirements gathering or figuring scope or any of that. It's about getting a HAL and a bootloader for said chip.
To err is human. Fortune favors the monsters.
In that case I'm afraid that you will need to decide project by project. There is no universal HAL & bootloader who cover gazillions of custom ARM SoC in the wild. Once you got experienced (i.e. work on 5-10 projects) it will be obvious which SoC to use once you know the requirements. GCC and any open source RTOS should be fine for most cases. Some SoC (even big ones) provide SDK that's based on open source RTOS with support and examples of their custom hardware. Some closed source RTOS vendors support wide range of platforms but as you know - royalties need to be covered.
www.codigi.net .NET touch screen GUI components suite
-
In that case I'm afraid that you will need to decide project by project. There is no universal HAL & bootloader who cover gazillions of custom ARM SoC in the wild. Once you got experienced (i.e. work on 5-10 projects) it will be obvious which SoC to use once you know the requirements. GCC and any open source RTOS should be fine for most cases. Some SoC (even big ones) provide SDK that's based on open source RTOS with support and examples of their custom hardware. Some closed source RTOS vendors support wide range of platforms but as you know - royalties need to be covered.
www.codigi.net .NET touch screen GUI components suite
I'm not looking at choosing one chip that works universally for every project. I'm looking at matching the appropriate ARM chip with the appropriate project, and then finding the packages I need to make that chip work. Every time. Every chip. Every project. When I say I'm moving all projects, I don't mean anything I'm currently working on or have finished. I just mean moving forward with future developments. ARM has enough varieties, and SoC manufacturers build enough different systems that I can pretty much stick to the ARM ecosystem for everything.
To err is human. Fortune favors the monsters.
-
So they build and maintain Zephyr OS versions for arbitrary chips I can buy off digikey? And then if I want to use the HDMI facilities of that same chip? Then what?
To err is human. Fortune favors the monsters.
HDMI is not so common on the Cortex-M range. If you need rich GUI or hardware media decoding/encoding probably cheap Cortex-A will be a better choice where you can run embedded linux with all whistles and bells. Well, it's not so real-time but so far in my experience there was almost no project where it was really necessary. Another approach is to use Cortex-M core for the real-time tasks and Cortex-A for the GUI - there are lot of offers where these cores are bundled on the same SoC. And it will not add costs - few days ago there was GUI capable board $7 DongshanPI-PicoW is a small Arm Linux board with SSW101B USB WiFi chip, four 12-pin headers - CNX Software[^]. Of course you need to keep in mind that such suppliers could disappear in a year. Similar TI or ST SoC that will be in production for 10 years costs x5 or x10, then you need to put it on board with all the necessary components, etc ... as you can see everything matters. Hardware is hard business.
www.codigi.net .NET touch screen GUI components suite
-
Thanks!
To err is human. Fortune favors the monsters.
I use Renesas and NXP micros (usual disclaimer) and both of those manufacturers offer free dev environments. They are Eclipse based, use gcc and have built-in hardware configuration tools that generate the HAL code for you. There is a bit of a learning curve with the tools, but so far my experience with both of them has been positive overall.
-
HDMI is not so common on the Cortex-M range. If you need rich GUI or hardware media decoding/encoding probably cheap Cortex-A will be a better choice where you can run embedded linux with all whistles and bells. Well, it's not so real-time but so far in my experience there was almost no project where it was really necessary. Another approach is to use Cortex-M core for the real-time tasks and Cortex-A for the GUI - there are lot of offers where these cores are bundled on the same SoC. And it will not add costs - few days ago there was GUI capable board $7 DongshanPI-PicoW is a small Arm Linux board with SSW101B USB WiFi chip, four 12-pin headers - CNX Software[^]. Of course you need to keep in mind that such suppliers could disappear in a year. Similar TI or ST SoC that will be in production for 10 years costs x5 or x10, then you need to put it on board with all the necessary components, etc ... as you can see everything matters. Hardware is hard business.
www.codigi.net .NET touch screen GUI components suite
I'm not limiting us to the M line. I found at least one A7 that will do HDMI, and is very affordable, plus more than we need for most UI/UX needs. I don't necessarily need HDMI, as I could potentially use RGB 24-bit LCD interfaces given enough pins. I'm assuming the Cortex series can drive a series of digital pins via DMA (the ESP32 can and uses it for RGB but only supports 16-bit - most screens are 24) Adding, I'm not the hardware person here. I have a couple of engineers I work with. I am the adventurous one willing to branch out and expand our hardware options. Part of this is for me, and part of it is to have something to bring to my engineers.
To err is human. Fortune favors the monsters.
-
I use Renesas and NXP micros (usual disclaimer) and both of those manufacturers offer free dev environments. They are Eclipse based, use gcc and have built-in hardware configuration tools that generate the HAL code for you. There is a bit of a learning curve with the tools, but so far my experience with both of them has been positive overall.
I saw that for their devkits, just not individual chips and I'm wondering if the toolchain and HAL code will work with all of them. Each one has very specific peripheral hardware on-chip and so the registers vary chip to chip.
To err is human. Fortune favors the monsters.
-
I use Renesas and NXP micros (usual disclaimer) and both of those manufacturers offer free dev environments. They are Eclipse based, use gcc and have built-in hardware configuration tools that generate the HAL code for you. There is a bit of a learning curve with the tools, but so far my experience with both of them has been positive overall.
Your latest comment is still pending and I'm impatient :) so I'm responding here (I can see it via email) Thank you for the advice. It's very helpful for me because I am looking as much as anything, for a usable workflow for developing with NXP ARM offerings, and it sounds like you have one that's not that complicated. Cheers. I owe you a beer. And as far as avoiding the registers and using the APIs that's exactly what I was hoping for, vs using GCC and a raw toolchain+register maps. Thank you again.
To err is human. Fortune favors the monsters.