Moving on up (to ARM)
-
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.
-
Quote:
I need the bootloader and the HAL, and all that happy business
I hardly believe all such stuff is provided by Keil. ARM licenses the core, the peripherals are manufacturer specific.
"In testa che avete, Signor di Ceprano?" -- Rigoletto
I may be misunderstanding something significant. The peripherals I'm referring to are part of the SoC. You're saying those are manufacturer specific? I guess that would make sense. Hmmmm. Let me ask a stupid question since you clearly have forgotten more about this than I've hope to learn in the time I have to learn it: (By which I mean relative to you I am an utter idiot about all this. I never went to school for it or anything) If I order this. https://www.digikey.com/en/products/detail/nxp-usa-inc/MIMXRT1062DVJ6B/13574426[^] (- In theory anyway. It isn't in stock, which is actually part of my problem - I'll explain) Where do I go to get anything beyond a datasheet and maybe a hardware manual to tell me what registers to use? I find it hard to believe that there aren't HAL packages and such available for an SOC like this. Are you saying I'd get it (in this case, from NXP?) I haven't seen much from NXP for this at their site, but I didn't think to look that hard either. As far as my problem: I want to use these ARMs primarily to expand my display options, but also to take advantage some more modern features than I can get on say, ESP32 nonsense. I actually have a bootloader and a HAL for the chip I linked to (assuming I bookmarked the right one, I'd have to look to be 100% sure) but it's provided by PJRC via their Teensy 4.1 kit, and it's specific to that chip. Here's what I want to be able to do. When I'm approached with a project, I want to match requirements with an ARM chip, and then find one I can integrate, with a HAL layer and bootloader I don't have to write. Or at least the HAL, as that would make it not economical to develop against. And by peripherals, I mean the peripherals built in to this SoC, not on an external board, to be clear - like its USB 2.0 Host/Device capabilities, it's I2S, SPI, and I2C capabilities etc. Is this even realistic?
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 don't see anyone mentioning Zephyr yet (Zephyr Project[^]). As as development environment it certainly is far less complete than Visual Studio, but reasonably well adapted to standard Linux element from which you can compose your setup. (As always under Linux :-)) Zephyr is most certainly an IoT- and SoC-oriented OS, not requiring you to carry a ton of general-purpose Linux stuff that you don't need, yet providing a very Linux-like interface for the stuff you really make use of. And it is free and open-source.
-
I don't see anyone mentioning Zephyr yet (Zephyr Project[^]). As as development environment it certainly is far less complete than Visual Studio, but reasonably well adapted to standard Linux element from which you can compose your setup. (As always under Linux :-)) Zephyr is most certainly an IoT- and SoC-oriented OS, not requiring you to carry a ton of general-purpose Linux stuff that you don't need, yet providing a very Linux-like interface for the stuff you really make use of. And it is free and open-source.
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.
-
I may be misunderstanding something significant. The peripherals I'm referring to are part of the SoC. You're saying those are manufacturer specific? I guess that would make sense. Hmmmm. Let me ask a stupid question since you clearly have forgotten more about this than I've hope to learn in the time I have to learn it: (By which I mean relative to you I am an utter idiot about all this. I never went to school for it or anything) If I order this. https://www.digikey.com/en/products/detail/nxp-usa-inc/MIMXRT1062DVJ6B/13574426[^] (- In theory anyway. It isn't in stock, which is actually part of my problem - I'll explain) Where do I go to get anything beyond a datasheet and maybe a hardware manual to tell me what registers to use? I find it hard to believe that there aren't HAL packages and such available for an SOC like this. Are you saying I'd get it (in this case, from NXP?) I haven't seen much from NXP for this at their site, but I didn't think to look that hard either. As far as my problem: I want to use these ARMs primarily to expand my display options, but also to take advantage some more modern features than I can get on say, ESP32 nonsense. I actually have a bootloader and a HAL for the chip I linked to (assuming I bookmarked the right one, I'd have to look to be 100% sure) but it's provided by PJRC via their Teensy 4.1 kit, and it's specific to that chip. Here's what I want to be able to do. When I'm approached with a project, I want to match requirements with an ARM chip, and then find one I can integrate, with a HAL layer and bootloader I don't have to write. Or at least the HAL, as that would make it not economical to develop against. And by peripherals, I mean the peripherals built in to this SoC, not on an external board, to be clear - like its USB 2.0 Host/Device capabilities, it's I2S, SPI, and I2C capabilities etc. Is this even realistic?
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
-
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
