Well my product uses ATSAMD51. And it is unobtanium at this time.
Looks like i will have to switch. I wrote my own bare metal setups for PORT, SPI, IIC, TIMERS, A/D, UART, NVMCTRL, bootloader, Clock config... Spent about 6 months getting this sorted.
I assume STM32 will not be available either.
How long should it take to start with a new manufacturers M4F and get all this setup bare metal. Considering quality of documentation.
My concern is that many smaller players have poor documentation and it will take much longer to get up to speed.
Any thoughts ??
Thanks
For example, for me, it took a week of work to get going with Nordic Semiconductor Cortex M4 devices. Was totally unfamiliar with them.
This includes two-three days reading documentation, looking at the "simple" examples supposed to print "Hello World", but failing to do that because 5000-line-of-code logging library used to print that "hello world" requires so much understanding and configuration, including a massive file used to configure the color in which Hello World is supposed to be printed.
Finally after a few wasted days, ditching the "SDK" completely, just copypasting my usual STM32 linker scripts and startup code, modifying my existing GPIO helpers, etc., the thing was up and running in no time. Documentation quality is OK, examples are not. Peripheral design is exceptionally simple. Got UART and SPI working in matter of minutes. Even the RADIO peripheral was very simple to use on register level, and well documented.
In my opinion, writing bare metal with the available reference manuals / datasheets is always the easiest part. Most of the difference comes from the tools, libraries, SDKs, examples, etc. If you rely on them, their quality is of utmost importance. IMHO, the only sustainable choice is not to rely on those, at all.
How long should it take to start with a new manufacturers M4F and get all this setup bare metal. Considering quality of documentation.
My concern is that many smaller players have poor documentation and it will take much longer to get up to speed.
It's impossible to answer that. You said it took you 6 months to do it on another chip, some people say it'll take 1 week.
Quality of documentation plays a role, certainly, but your personal experience and skills will make a lot more difference.
Beyond that, so will your expectations. If you are going to write your own whole abstraction library covering all peripherals and functionalities of the MCU, it will take a long time. And it's IMHO not the right approach. If you go bare metal, just write "drivers" for the features you *need* instead of writing the whole shebang before doing anything useful. You'll get there in much less time than 6 months, guaranteed.
Now if you're going to write a complete HAL of your own just to avoid using the vendor's one, that's the wrong approach if you go bare metal.
Always isolate the low-level functions properly in your projects, and porting them to a new device should not take too much time. Avoid excessive dependencies, and excessive abstraction as well. Just my 2 cents.
Yes it's quality of documentation. I have become leery of Japanese semiconductor datasheets for any complex part. It seems a lot is lost in translation.
I cursed the SAMD documentation many days for being so terse and leaving out many things in the section that you had to discover through net queries.
But I do like to go bare metal for the peripherals I mentioned. I find the fewer hands in the pie the better. And if I understand the hardware at register level I should be able to take care of myself.
Who has the best - complete - usable documentation for M4F processors that are actually available.
I will look into Nordic. I need high pin count. Was using the 128 version of SAMD.
While it's very much against the grain here on this forum, why don't you try out a framework? Zephyr has a pretty comprehensive list of supported MCUs, there libopencm3 if you dont want an RTOS, Arduino (support and quality, are wildly varying YMMV), mbed is an option if you are not doing anything too resource hungry (timing, non standard peripheral combinations) . The cost of using a framework has never been cheaper. Most of the frameworks are have open code bases (most are also copy-left so watch for that) so you are free to expand upon them.
Bare metal has its place, but it is expensive many many ways.
I hear you say but did you check whether your application software/firmware could perhaps be retrobladed , I mean?, could you not perhaps have thought, 'could you not fit your firmare in an eight bit device, like an avr 1284, featuring 64kwords and 16kbyte ram, for example?
Remember,
ARM compilers are woefully under powered, compiler manufactures have street loads to learn yet? I,mean, consider a double(64 bit float), does your ARM compiler support this yet?, true 32 bit alu suggest approximate 'single clock 32bit data bus width sweep singularly at crystal clock speed per instruction?. My Mikroelectronika Arm compiler is under powered and is constantly undergoing bug fixing to the extent, I gave up in ARM.
Well my product uses ATSAMD51.
Microchip still has some 100-pin PIC32MK in stock, similar to yours, same maker (sort of). Their docs are Ok.
These day it's scary to design because you never know whether it's still in stock by the time you're finished. Two of my designs went down the drain - one with Artix-7, another with PIC32MM.
On the other hand, it's scary to buy lots before finishing the design, as there may be some unforeseen things.
Take your pick.
This is sage advice:
Always isolate the low-level functions properly in your projects, and porting them to a new device should not take too much time.
So many embedded code bases don't use any encapsulation or abstraction. If your code base has random MMIO calls in the application/logic level then, you are in a wold of pain to do even the simplest change.
I don't mean that you have to implement a generic pin toggle function, even simple things like selectADC(), deselectADC(), can make code porting so much more orderly.
I don't mean that you have to implement a generic pin toggle function, even simple things like selectADC(), deselectADC(), can make code porting so much more orderly.
Yes, that's why I added to avoid excessive abstraction, even if I did not define exactly what it meant. But it was pretty much that: avoid the temptation to rewrite full-HAL-like functions, such as, for instance, a function that would abstract the full configuration of a timer, or a GPIO, or anything else. That's going too far and you'll waste a lot of time while realizing that many options for all those functions are MCU-specific anyway, so you wouldn't make porting any easier. Vendors' HALs do this to make porting across their own products easier, not to make porting to other products altogether easier. And even so, it takes them a lot of time and ends up with inevitable bloat.
Abstract at a higher level.
I agree, use really high-level and simple abstraction, and do it as you go, not "at once". Trying to do hardware abstraction as a separate project not only wastes your time on implementing drivers you never need, but also you don't really know which kind of abstraction is right for your project(s), so you end up with harder to use abstractions.
Instead, just start writing your actual project and use simple patterns for abstraction, for example, static inline void start_spi_with_dma(void* dest), where you can even hardcode the project specifics; that whole function changes when the hardware changes, but hopefully rest of the application requires little or no porting.
It's impossible to answer that. You said it took you 6 months to do it on another chip, some people say it'll take 1 week.
Well, you know...
- Six months for your first ARM chip family, when you're sort of half paying attention because you're still using that 8bit chip, and it's ALL DIFFERENT. A separate clock configuration for each peripheral?! WTF?
- Three months for your second ARM chip family, now that you understand what's part of the ARM core and what's in vendor-specific areas, and have gotten more comfortable with peripherals mapped onto C structures, along with some of the ideas that have been implemented to make 8bit users happier, and the way that vendors will happily throw address space at a peripheral (64 words for a GPIO port? No problem!)
- A month and a half for the third ARM chip family. Clocks - check. Atomicity hacks - check. Weird UART modes - ignore...
- The fourth ARM chip family is getting boring. Same-old, same-old, only slighly different. A couple of weeks...
- You might get down to one week on your fifth or sixth family, if you're not using some special feature.
Double the time if the documentation is really bad and the online support (from vendor AND community) isn't up-to-snuff. (although you'll be getting better at reading bad documentation, too),
Quarter the tine if you're willing to use Arduino and there's already an Arduino Core for it. It's pretty sad if Arduino is the best cross-platform low-level development "library" around, but it might be true.
Add 20% if you're doing something fancy with timers and have to figure them out, or need to figure out low-power modes, or have a particularly complex peripheral (USB, Radios, and Ethernet come to mind.) Or if the vendor ties you to a new sort of build environment (I'm looking at you, RPi Foundation!)
Subtract "some" for other common software frameworks (PlatformIO, MBed, etc), IFF you've used them before.
On a completely different tangent
I think the chip shortage will end fairly soon - in the next few months. 32F417 is now coming through (in my low volumes, 100+) and almost daily I am getting revisions on orders placed long ago that such and such will arrive sooner.
That said, I've been around this block a few times and I think ST chips are the ones to go for. They are a huge company and huge companies run products for many years. Atmel, I am finished with. Hitachi ran MPUs like the H8/300 for 25 years. ST also make a lot of good chips down the complexity scale, where you can save yourself loads of money over the opportunistic ripoff merchants (e.g. Maxim).
I am working on a 32F417 project and the main challenges seem to lie in libraries, which need a LOT of time fixing. If you are using ethernet, budget on several months of googling on various forums, looking for fixes.
I use Cube IDE but would not spend time on ST HAL stuff. It is poorly documented, bloated, hard to read (due to millions of #defines for bit numbers etc) and by the time you have worked it out you can set up the peripherals directly to the registers.