EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: stmdude on September 17, 2017, 08:01:07 am
-
After recently experiencing a few disappointments with the STM32 range of MCUs, I've been looking for alternatives.
In addition to the regular MCUs, I've been thinking of the benefits of having a Hard-core CPU combined with FPGA fabric, so I can synthesize my own peripherals, but I haven't been able to find a reasonable chip.
The Zyncs are overkill in price, performance and complexity, but the idea is exactly what I'm looking for.
I'm looking for something much simpler, like a cortex M-series core and 4-8K logic cells, and preferably available in a decently solderable package.
The only candidate I've found is MicroSemi, but their website doesn't exactly instill confidence in me (severely lacking actual information).
There has to be others out there, but my google-foo is failing me.
Anyone here know of some other alternatives, or even better, have experience with a chip like this?
-
/me braces for the avalanche of PSoC people...
https://en.wikipedia.org/wiki/PSoC
-
/me braces for the avalanche of PSoC people...
Yeah, take your poor experience with MCUs, and make it just a notch worse :)
Also, may be if you could tell us what exactly went wrong, we could suggest a replacement MCU.
-
Also, may be if you could tell us what exactly went wrong, we could suggest a replacement MCU.
Well, the most recent disappointment was with the STM32F446, which has a different USB controller than the other chips in the F4xx series. Something that isn't highlighted or mentioned in the migration documents.
The USB Drivers ( http://www.st.com/en/embedded-software/stsw-stm32046.html (http://www.st.com/en/embedded-software/stsw-stm32046.html) ) says that they support the F446 in the latest version, but it only supports the FS USB block, and it only works if you only transmit/receive a few packets per second. Any faster and it falls apart..
Another issue thats been brewing for a few years is that ST is moving over to their HAL, which, honestly, is a pile. New chips aren't supported by the old StdPeriph libraries.
Sure, I could just write my own drivers, but only to a certain extent. I don't really want to write a USB stack for example.
The Cypress PSoCs seem interesting, but being forced into Windows is a showstopper for me.
-
Also, may be if you could tell us what exactly went wrong, we could suggest a replacement MCU.
Well, the most recent disappointment was with the STM32F446, which has a different USB controller than the other chips in the F4xx series. Something that isn't highlighted or mentioned in the migration documents.
That is the biggest problem with ST's ARM lineup and one of the main the reasons I use NXP's ARM controllers. NXP's ARM controllers have the same (or at least very similar) pheripheral through their entire range so you can switch between various controllers more easely. Because of that it is rare I use the same NXP controller in different projects.
-
I don't really want to write a USB stack for example.
:palm:
-
Sure, I could just write my own drivers, but only to a certain extent. I don't really want to write a USB stack for example.
so instead of writing drivers you want to write drivers and peripherals?
-
Sure, I could just write my own drivers, but only to a certain extent. I don't really want to write a USB stack for example.
so instead of writing drivers you want to write drivers and peripherals?
:) Sometimes, it would make sense to write your own peripherals. For example, in one of my projects, I'm bitbanging SWD. That would be a perfect peripheral to synthesize. But, yea, I probably wouldn't want to synthesize _every_ peripheral.
-
I don't really want to write a USB stack for example.
:palm:
?? What would you recommend doing if you need USB connectivity, and you have two stacks to choose from. The first one doesn't work beyond a few packets/second, and the second one doesn't support the functionality you need, nor is it even close to production quality?
-
Well, the most recent disappointment was with the STM32F446, which has a different USB controller than the other chips in the F4xx series. Something that isn't highlighted or mentioned in the migration documents.
But your USB FS/HS controller in FPGA will probably take 2-4K gates alone, plus external PHY. USB is the worst reason to want FPGA + Hardcore CPU.
Plus you need to make one that works. There are a few things here and there, but not really a coherent stack that I could find.
Another issue thats been brewing for a few years is that ST is moving over to their HAL, which, honestly, is a pile. New chips aren't supported by the old StdPeriph libraries.
That is true for all vendors. Relying on vendor software support is a big mistake. Build your own software library.
Sure, I could just write my own drivers, but only to a certain extent. I don't really want to write a USB stack for example.
You would have to for your own peripheral anyway. And it is not that hard to write a USB stack for simple scenarios.
Also, the biggest problem for USB in FPGA is memory. Small FPGAs don't have enough of embedded memory, and you need to have buffers for USB.
-
Another issue thats been brewing for a few years is that ST is moving over to their HAL, which, honestly, is a pile. New chips aren't supported by the old StdPeriph libraries.
That is true for all vendors. Relying on vendor software support is a big mistake. Build your own software library.
That only works for simple peripherals. For things like USB and TCP/IP you need to get a third party stack because it is way too time consuming to write and test your own.
Sure, I could just write my own drivers, but only to a certain extent. I don't really want to write a USB stack for example.
You would have to for your own peripheral anyway. And it is not that hard to write a USB stack for simple scenarios.
Also, the biggest problem for USB in FPGA is memory. Small FPGAs don't have enough of embedded memory, and you need to have buffers for USB.
Most microcontrollers have like 2kB of SRAM for the USB interface so I guess that should be enough. Nowadays 2kB is peanuts for a modern FPGA.
-
The Cypress PSoCs seem interesting, but being forced into Windows is a showstopper for me.
You don't have to use their IDE for *everything*. It's pretty easy to have it generate a Makefile and roll your own environment elsewhere (e.g., macos).
-
After recently experiencing a few disappointments with the STM32 range of MCUs, I've been looking for alternatives.
A "few"? USB but what "else" is different?
Btw, may i ask on your F446 can you change PB3,PB4 PA15 from ALT to GEN mode without losing debug interface or causing CPU to behave funny?
-
... Um... Why don't you just move over to the STM32F4 part that has a better USB peripheral? Or am I asking too simple of a question this late in the thread?
-
Bit more on-topic: check out Microsemi Smartfusion devices.
-
Btw, may i ask on your F446 can you change PB3,PB4 PA15 from ALT to GEN mode without losing debug interface or causing CPU to behave funny?
ALT to "GEN"? Are you talking about changing the pin from alternate-function to regular GPIO?
There _might_ be some issues with that, as they're shared with the JTAG-DAP, and in other STM32s, thats an issue unless you switch the chip over to SWD only. However, I can't find any register to do that in the 446.
If you give me a bit more info, I can try it out.
-
... Um... Why don't you just move over to the STM32F4 part that has a better USB peripheral? Or am I asking too simple of a question this late in the thread?
That's what I'm doing for this project. I'm moving to a F429 instead. Twice the cost, with no additional functionality that I need/want.
I'm looking into the FPGA stuff as a way to be able to spin some custom peripherals to offload the CPU when I need to talk to weird and wonderful peripherals.
After recently experiencing a few disappointments with the STM32 range of MCUs, I've been looking for alternatives.
A "few"? USB but what "else" is different?
On the F446, not a lot (except the USB stuff I've discovered). The disappointments are more with the whole family of MCUs. The newer chips aren't supported with the tried-and-tested StdPeriph library (yes, I can bang the registers myself, but sometimes you just want to get the easy stuff done, quickly).
Also, their prices are pretty insane. I'm switching from the F446 to F429, which is a $12 chip (@1 qty). I can source dual-core Cortex-A9 SoCs for $2...
Heck, I'm seriously considering using Nordic Semi nRF chips instead of the STMs in a few projects. No need for RF in the projects, but the chip is cheaper.
Bit more on-topic: check out Microsemi Smartfusion devices.
I've looked at them (as I said in my initial post), but their website is very low on actual information. Maybe I should dig deeper in that particular rabbithole...
-
author=stmdude link=topic=95231.msg1304750#msg1304750 date=1505764611]
On the F446, not a lot (except the USB stuff I've discovered).
There are actually some difference (F446) low power and clock gating but you gain CCMRAM with the 429, ST even managed to do a migration paper. www.st.com/resource/en/application_note/dm00161778.pdf (http://www.st.com/resource/en/application_note/dm00161778.pdf)
The disappointments are more with the whole family of MCUs. The newer chips aren't supported with the tried-and-tested StdPeriph library (yes, I can bang the registers myself, but sometimes you just want to get the easy stuff done, quickly).
I recall STDlib STSW-STM32065 also includes F446 target. I do direct register, cant stand the gobelybockgebrock HAL!
It would have been easy if ST had used definition labels that was understandable, or manuals that make sense. ::)
Also, their prices are pretty insane. I'm switching from the F446 to F429, which is a $12 chip (@1 qty).
I can source dual-core Cortex-A9 SoCs for $2...
Yes, looking at retailers pricing its all over the place, makes no sense at all.
ALT to "GEN"? Are you talking about changing the pin from alternate-function to regular GPIO?
If you give me a bit more info, I can try it out.
Sent you info in a PM!
-
That's what I'm doing for this project. I'm moving to a F429 instead. Twice the cost, with no additional functionality that I need/want.
I'm looking into the FPGA stuff as a way to be able to spin some custom peripherals to offload the CPU when I need to talk to weird and wonderful peripherals.
Yea.. OK. The STM32F429 is too expensive, so you're question is about hardcoding an ARM core an FPGA.
Good luck.
-
Yes, I don't get the point of this thread. It looks like the amount of manual work is going to increase many times with FPGA path (even if such thing existed and was practical).
Don't like HAL/Cube/wehatever? Well make your own. You will have to anyway with FPGA.
So if you are looking for simplicity, then just pick a micro and build up a code base you know and can reuse.
-
The Cypress PSoCs seem interesting, but being forced into Windows is a showstopper for me.
This would have been excellent information to add to the first post. Although I would argue that spinning up a VM and getting on with it could make your life much easier.
/me braces for the avalanche of PSoC people...
https://en.wikipedia.org/wiki/PSoC
I'm surprised Danadak hasn't chipped in yet :D
-
Also, their prices are pretty insane. I'm switching from the F446 to F429, which is a $12 chip (@1 qty). I can source dual-core Cortex-A9 SoCs for $2...
I wonder how much of that price difference is because of the large flash on the M4's
-
I don't understand why you are not seriously considering different families/architectures then.. aside the fact that you'd have to change your username then :D
but what does the STM32F4 have that you can't find in others so it's so difficult to switch?
I wonder if it's the 2xCAN + USB combo, i recently went for a PIC32MK for this very reason, it was the cheapest (available in a small QFN package)
but of course, i don't think this is the case.
-
Yes, I don't get the point of this thread. It looks like the amount of manual work is going to increase many times with FPGA path (even if such thing existed and was practical).
Don't like HAL/Cube/wehatever? Well make your own. You will have to anyway with FPGA.
So if you are looking for simplicity, then just pick a micro and build up a code base you know and can reuse.
:-+
-
Yea.. OK. The STM32F429 is too expensive, so you're question is about hardcoding an ARM core an FPGA.
No, not harcoding. A hardcore. And, yes, it's possible to do at a reasonable price-point. Just look at the Cypress PSoCs.
I don't understand why you are not seriously considering different families/architectures then.. aside the fact that you'd have to change your username then :D
Haha, yea, my username would be an issue. ;) Not a big one though.
I've shipped >10M devices based on various STM32s, so I have invested a massive amount of time learning the ins and outs of them. I could make a lateral move into he NXP family (for example), but for some reason, I _think_ (I've got no facts backing this up) I'll just swap one set of idiosyncrasies for another.
but what does the STM32F4 have that you can't find in others so it's so difficult to switch?
I wonder if it's the 2xCAN + USB combo, i recently went for a PIC32MK for this very reason, it was the cheapest (available in a small QFN package)
but of course, i don't think this is the case.
What I needed from this particular STM32F4 was:
* HS USB
* 2MB of RAM (I.e, external SDRAM)
* 2 x UART
* 4 x PWM @ >10KHz
* 8 free regular GPIOs
For me, this would be mid-end. No display, and no ethernet or WiFi.
Yes, I don't get the point of this thread. It looks like the amount of manual work is going to increase many times with FPGA path (even if such thing existed and was practical).
No, there would still be regular peripherals on-die. Just like the PSoC. The FPGA fabric should be in addition to what you'd expect from a regular MCU, not instead of.
-
No, there would still be regular peripherals on-die. Just like the PSoC. The FPGA fabric should be in addition to what you'd expect from a regular MCU, not instead of.
Yeah, I want that too. Furthermore, I tried to pitch this to people. The biggest problem here is the amount of characterization that goes into FPGA-like device. Plus, reasonably big capacity will require real HDL support, and that's a lot of RnD, or some really expensive deals with HDL vendors.
It will just make it too expensive to manufacture and support. So FPGA in a micro is not happening.
You are most likely to see CM0 integrated into the FPGA. But FPGA vendors will not include MCU peripherals, since the same issue of verification and software support will not make it feasible from that side as well.
Basically, forget about this until MCU vendor merges with an FPGA vendor. Then we will see some killer devices, but at killer price point as well.
-
Forget it. It will never happen.
-
I dropped the ST library about a week into my first foray into the STM32 series, IMO is is one of the worst libraries breaking most every rule (macro abuse, useless stub functions, endless assertions). I moved from this to rolling my own but then came across libstm32 (at the time) which was brilliant. Nowdays I use ChibiOS, it does a very good job of abstracting the hardware away from your code allowing you to write efficient, fast and understandable code.
As for an IDE, I use ViM and Makefiles... every now and then I decide to give a full IDE a go again, but quickly get annoyed with it and go back to ViM.
-
No, there would still be regular peripherals on-die. Just like the PSoC. The FPGA fabric should be in addition to what you'd expect from a regular MCU, not instead of.
Yeah, I want that too. Furthermore, I tried to pitch this to people. The biggest problem here is the amount of characterization that goes into FPGA-like device. Plus, reasonably big capacity will require real HDL support, and that's a lot of RnD, or some really expensive deals with HDL vendors.
It will just make it too expensive to manufacture and support. So FPGA in a micro is not happening.
Well you can buy Psoc, Zync today. And there is also the LM32 softcore from Lattice.
-
Well you can buy Psoc, Zync today. And there is also the LM32 softcore from Lattice.
From a MCU realm only psoc gets close, and it is still way too far away (in FPGA part).
Zync is way too expensive (considering board and power supply requirements).
And obviously all FPGA vendors have softcores, and LM32 is far from the best of them.
-
You could just use a spartan 6 fpga (xc6slx9, about $5 on aliexpress) and add a softcore (there are many existing ones on the internet). It has plenty of capacity to fit a softcore and lots of peripherals and even DSP blocks. You will need an external spi flash though. HS usb is easily done using a usb phy and a usb serial core (google "vhdl usb serial" and "ulpi_port utmi bridge"); I've gotten >20MB/s transfer using this combination.
-
Well, the most recent disappointment was with the STM32F446, which has a different USB controller than the other chips in the F4xx series. Something that isn't highlighted or mentioned in the migration documents.
You have to wonder why ST mess about with the peripherals so much - ok fixing faults and adding new features is fair enough but they don't seem to put much priority on maintaining compatability as close as it is possible to do so. Of course they must suffer as much as everyone else from this in the amount of development effort and cost they incur in developing and maintaining the STD Peripheral, HAL and HAL-LL libraries. Let hope they learn their lesson, but I wouldn't hold my breath. It probably results from having different families designed by different, far flung development teams.
As to the change in USB peripheral from the '419 to the '446, perhaps it's because they licenced the 419 USB controller from Quicklogic and wanted a cheaper, perhaps in-house peripheral for newer parts? I don't know for certain that they licenced Quicklogic's part - I can't find any public announcements to that effect - but the register layout and names are remarkably similar:
http://www.quicklogic.com/assets/pdf/data-sheets/QL-Hi-Speed-USB-2.0-OTG-Controller-Data-Sheet.pdf (http://www.quicklogic.com/assets/pdf/data-sheets/QL-Hi-Speed-USB-2.0-OTG-Controller-Data-Sheet.pdf)
It looks like Altera use the same USB implementation in the Cyclone V (and others perhaps?):
https://www.altera.com/hps/cyclone-v/index.html#topic/sfo1410069623936.html (https://www.altera.com/hps/cyclone-v/index.html#topic/sfo1410069623936.html)
It does mean you have the possibility of porting an STM32F419 USB stack to a soft core Cortex on Cyclone V but they probably licenced different releases and then added their own 'tweaks' which might make it a frustrating excercise at the least...
For those implementing USB on an STM32F40x, 41x or 42x the Quicklogic documentation might provide a useful alternative to STs.
Anybody any idea how much ST might be having to pay to license this - a few tenths of a cent, cents or tens of cents per device?
-
Just wondering why you were put of by the Microsemi website? Still seems like a pretty good match for your requirements.. Been following these things for some time, genuinely wondering...
-
As to the change in USB peripheral from the '419 to the '446, perhaps it's because they licenced the 419 USB controller from Quicklogic and wanted a cheaper, perhaps in-house peripheral for newer parts? I don't know for certain that they licenced Quicklogic's part - I can't find any public announcements to that effect - but the register layout and names are remarkably similar
Both Altera and ST are using the Synopsys dwc2 controller.
-
Also, their prices are pretty insane. I'm switching from the F446 to F429, which is a $12 chip (@1 qty). I can source dual-core Cortex-A9 SoCs for $2...
I wonder how much of that price difference is because of the large flash on the M4's
It seems stmdude is just bitching around and crying like a small baby. Instead of facing the issues, he is throwing the blame on ST and thinking he will make his own peripherals. Sorry. Not gonna happen, not that easy.
-
It seems stmdude is just bitching around and crying like a small baby. Instead of facing the issues, he is throwing the blame on ST and thinking he will make his own peripherals. Sorry. Not gonna happen, not that easy.
Yea, boo-hoo. *sniffles*
If you had _actually_ read the thread instead of jumping to conclusions, you'd have understood what I'm looking for.
I wasn't "blaming" ST for anything either. They've changed in a direction that I don't agree with, and I'm researching alternatives. No blame was attributed. I was simply disappointed, as I've spent _a lot_ of time with their chips, and shipped millions of devices based on them. I've spoken to my FAEs and STE "suit" about it, but there's nothing they can do, even though we're a decently sized customer.
Now, as it seems that there isn't a "dream-chip" for me, I'll settle for something more conventional. Right now it's leaning towards NXPs LPC-series. I'll design a simple test-board and evaluate further from that experience.
-
As to the change in USB peripheral from the '419 to the '446, perhaps it's because they licenced the 419 USB controller from Quicklogic and wanted a cheaper, perhaps in-house peripheral for newer parts? I don't know for certain that they licenced Quicklogic's part - I can't find any public announcements to that effect - but the register layout and names are remarkably similar
Both Altera and ST are using the Synopsys dwc2 controller.
Interesting - I see ST's Ethernet controller is also provided by Synopsis:
http://www.electronicspecifier.com/around-the-industry/synopsys-designware-usb-20-and-ethernet-ip-enables-first-pass-success-for-stmicroelectronics (http://www.electronicspecifier.com/around-the-industry/synopsys-designware-usb-20-and-ethernet-ip-enables-first-pass-success-for-stmicroelectronics)
That means you could base STM32F4xx USB and Ethernet drivers on Linux drivers such as:
https://github.com/nomis/linux/tree/master/drivers/usb/dwc2 (https://github.com/nomis/linux/tree/master/drivers/usb/dwc2)
I wonder if QuickLogic also licenced Synopsis's USB OTG design for their ArcticLink products? I can't imagine they would have created a register level compatible version. If so, I'm surprised I can't find any such reference/news item.
-
That means you could base STM32F4xx USB and Ethernet drivers on Linux drivers such as:
https://github.com/nomis/linux/tree/master/drivers/usb/dwc2 (https://github.com/nomis/linux/tree/master/drivers/usb/dwc2)
The current kernels have specific support (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/drivers/usb/dwc2/params.c?h=v4.13.3#n123) for the stm32f4x9 USB controller.
I wonder if QuickLogic also licenced Synopsis's USB OTG design for their ArcticLink products?
Dunno, but there doesn't seem to be any QuickLogic drivers in the Linux kernel. However I haven't really heard about the company before so I don't know about which products their IP might be used in.