Not to hijack the thread, but I’ve wondered why, with microcontroller horsepower like that available, hasn’t the current OEM come to EOL and a new model developed.
That is a challenge Bill. Think you should start a new thread to start the collaboration.
FWIW Jean-Claude Wippler at jeelabs has been doing a lot in this space, including some interesting articles in the middle of last year on ADC circuits. He has also tested lots of the STM32 boards. But please if anyone gets going with these microcontrollers don’t use Forth. I know it’s very powerful but the learning curve is huge.
For my three happence worth, any new version would have to have wifi and not have half the real estate on the board taken up with a battery holder. And also would have to be programmable in the Arduino environment (not everyone is up to the complexities of a C environment).
Simon
This comment by @dBC is what provoked this discussion:
Looks like that’s happened…
Nice. I hadn’t seen that one. Time to get some hardware and have a play.
Thanks for the link.
Have you looked at the LinkIt One? It’s not an STM32 but does have Wifi and code is written in the Arduino IDE as well.
Hi Bill, followed that link but the environment pointed to didn’t seem to want to install on Windows.
Here’s the official forum → http://stm32duino.com/ which will have everything that anyone should need by the looks of things. I’ll be digging through it later.
$59!! I know it’s a development type board but still that’s pretty steep against ESP and STM32 prices.
Cool. Thanks for the update!
I explored quite a few different development environments as I migrated to STM32, but my requirements are quite a bit different from yours. The big choice is which hardware abstraction layer (HAL) to go with, or whether to do away with one and bang on h/w registers directly. These devices are complicated enough that the latter would be pretty overwhelming in my view… the clock tree alone takes quite some configuring. Starting with an open-source HAL gets you up and running much faster, and then with the datasheet in one hand, and the HAL source code in the other, you can explore further.
So the next decision is which HAL, there are a surprising number of choices. When most people speak of the Arduino IDE, they really mean the HAL mostly. For example, if you want to read the value at an analog pin you call analogRead(Ax) and that works regardless of which Arduino you’re running on, including even the ARM based SAM models like the Due. It’s great for portability, but the downside is it greatly limits performance, especially in that example. So people who want performance start with the Arduino HAL, poke around in the source code for analogRead(), read the datasheet and then come up with much higher performance based on ISRs and overlapping sampling of the next result with processing of the last etc.
Given the existing emonlib code base, an Arduino-ish approach is probably a great place to start on STM32. The downsides are performance, and processor support. Performance you can always tweak later if you want to milk every last cycle out of the device (just as folk have added ISR processing to their Arduino analog projects), and even if you don’t, you’ll still be way ahead of AVR performance.
Processor support was a biggie for me, but probably less so for you guys. I need to be able to choose any IC from the STM32 family and know my code is going to work with minimal changes required. Anyone that’s tried to use the Arduino environment on an Atmel/AVR device not currently supported by the Arduino IDE will know the hassles. With the STM32, it’s that on steroids. The Eclipse-EmbeddedARM guys have come up with yet another HAL that offers the same layer across all ARM based embedded ICs, from Atmel, STM32, NXP etc etc. That’s great if you want to be able to change vendors easily, but again the downside is support. If you want to use the latest and greatest IC from one of those vendors, you need to wait months or years for them to be supported by the HAL, or roll up your sleeves and do it yourself.
I’m not being as bleeding-edge elitist as I sound. You pick any well-stocked cheap vanilla STM32 development board and you’ll find most of those community supported HALs don’t yet support it. I was interested in the low-end F0 family, which is targeted at those migrating from 8-bit micros. It has phenomenal peripheral performance, but only a 48MHz ARM Cortex M0 to deal with it all. That’s still a big step up from a 16MHz 8-bit AVR. That’s 3x on the clock rate alone, plus it’s a true 32-bit architecture, whereas the AVR has to spend a lot of it’s cycles pretending to be a 32-bit machine (4 add-with-carry instructions to add two 32-bit numbers together).
So if you’re going with a community supported HAL such as the Arduino-ish one, make sure you pick a development board/IC that is supported before you buy any hardware.
Hi dB,
Have you by any chance had a look at this or this?
Both use ARM Cortex-M4 processors.
The one at the first link has a clock speed of 120 MHz, the second, 180 MHz.
There’s an add-on available to enable Arduino IDE support.
No, I haven’t I’m afraid. Specs look good though. NXP are a big player in the embedded ARM space.
dBC - if you’ve done quite a bit of analysis of the options already then maybe you could point this in a sensible direction.
Assuming we’re really interested in the ADC aspect and the sample rates, which of the many choices would be a sensible starting point? The rest of the processing in an energy monitoring system or solar diversion system doesn’t need much processing power, so I’d think that the ADC aspect would be the most critical to get right.
Personally I’d like to get away from the rfm69 for comms, so for wifi, I’m assuming the simplest solution would be an ESP8266 and also given there is already a openenergy solution for this it seems like a no brainer to go down this route.
I’ve ordered a couple of ‘blue pills’ to have a play around but some of the documentation seems to suggest these haven’t got the best separation of supply to the chip and the analog inputs. Any thoughts on this?
Any other thoughts?
I’m interested in where this discussion might lead too, I have seen the stm32’s mentioned frequently but know very little about them.
What I have noticed is stuff like the great ADC resolution and speeds, plus somewhere I read about 4 levels of amplification on the ADC inputs and I’m pretty sure I seen mention of ADC channel count greater than 8. But I know there are many models and even more dev boards based on those models so ADC characteristics will vary.
Some models also have a UUID which has come up in discussion more than once on these forums.
Absolutely, The best thing to happen to the esp8266 development was to get included in the Arduino IDE, it takes the thought of another language or another development environment out of the equation and more users are likely to try it, it would hopefully also save us reinventing the wheel with much of the existing code.
[See the Success using the STM32F103 microcontroller thread,]
I agree with this too, improvements can be made and as time goes on if a new tech is fully embraced, the peculiarities and best practices will get well discussed and possibly documented here, so the additional learning curve will be minimized and shared among many Arduino capable users, rather than development racing ahead with only a handful of very advanced enthusiasts keeping up.
Definitely! Having enough ADC channels is important, 10-bit resolution as an absolute minimum and perhaps more importantly is sampling speed. The processor power and memory size are also important and demand an improvement over what we have, but as mentioned the essential “other stuff” we do doesn’t use much processing power.
I can understand that and many of us do want alternative options, but RFM is easily added to any 3.3v MCU with spi so I guess so it can always remain an option. Wifi isn’t that great for battery life and it isn’t flexible enough to be the sole solution for all. Perhaps bluetooth is another possible option to.
This seems to go against all the pro ADC comments IMO, the ADC on the esp8266 is slow and only one channel so almost useless for energy monitoring, you could add an external multiplexer or even external ADCs on I2C or SPI but since ADC’s are THE priority, the esp8266 will never fit the bill alone, when paired with an ATmega328p as per the emonESP it works well enough, but using the emonESP as an example, beyond being a dumb forwarded there isn’t much resource left after setting up a server for WiFi configuration etc so something better is required if using WiFi.
IMO WiFi is very high on the priority list but it’s presence also requires an additional bump up in resources too, unless running a server can be avoided.
I have now, It has a lot of toys wifi, gsm, gps and bluetooth, but it is expensive and only has 3 ADC inputs, so IMO not a real contender at this point.
Arduino seem to be using SAMD21 processors for the zero etc, they are Cortex M0+ based like the STM32F0’s, running at 48MHz. I know nothing about SAMD21 but happened to notice that while the Arduino offerings had 6 or 7 ADC channels, the Sparkfun SAMD21 dev board has 14x 12bit ADCs, although I don’t recall seeing any sampling speeds documented.
Sorry you misunderstood me - I was thinking only of the esp8266 to be the wifi adapter. Not as an alternative to the STM.
As a replacement for the emonTx for energy monitoring and solar diversion I’m not interested in battery power. I would think most emonTxs in these situations have 2 wall warts on an outlet near the distribution board. It’s these systems that could benefit from the faster analog on the STM micros.
emonTH doesn’t need fast analog and can obviously be battery powered.
Simon
Oh! fair enough, yes if in-built wifi is not included the esp8266 does make an excellent wifi add-on and it maybe a better solution to use something like an STM32 and provide a footprint and header to “plug in” an esp8266 module rather than including it on every device, with some clever fore thought a device could possibly be USB, WiFi, RFM, BT or Ethernet simply by fitting the module required.
Whilst WiFi is too much for both battery and AC:AC powered emonTx’s. it might be nice to find a solution that CAN be powered via an AC:AC adapter and since BT is the most used wireless comms method for battery devices, it’s more likely to be able to be AC:AC powered. To be able to power an emonTx via one wall wart and “just add it’s BT key” to a file on a Pi would be very attractive to many users, not all granted, but I think it could be closer to what we have now but neater, easier to set up and more secure to boot.
BT is possibly a discussion for another thread, my point being we should avoid opting for another single wireless solution that doesn’t work for everyone, dropping the well established RFM stuff along the way. As attractive as in-built WiFi might be, it might not work for all, just as RFM dosn’t work for everyone now.
I used around 100 emonTx’s in the latter part of last year and not one of them uses the on board RFM, that’s wasted cost in the RFM module, antenna and other components, plus wasted IO resources that are hardwired to redundant hardware, I used serial to USB boards, WiFi might have worked if I had installed a second WiFi adapter to the Pi hub’s but that too would have added additional cost in WiFi adapters and the additional wall warts wifi would demand, so USB was easier. i’m certainly not trying to convert anyone to any particular method, I am keen to promote choices rather than a single “like it or lump it” approach if new avenues are being explored.
Agreed. While I use the ADC in my project, it’s not a critical component (just used to measure a very slow moving low resolution signal) so I haven’t done an ADC comparison across the STM32 families, or across vendors. I went with their low-end F0 family and was blown away by the ADC performance. I assume the higher end families have the same ADC or better. I coded up the 1000 samples delivered to a C array in 1msec more as a proof of concept then to use in my application.
With just a 48MHz CPU, and a new ADC result arriving every usec, that’s only 48 CPU cycles to deal with it, so interrupts on a per-sample basis are pretty much out of the question. All the peripherals are connected to a DMA controller though and it does all the per-sample shuffling into SRAM for you, without any CPU involvement, interrupting the CPU only when the user-supplied buffer is half-full and again when full.
The good news is, if you go for a nice easy synchronous analogRead() approach to doing your ADC conversions like emonlib does, you’re only wasting ~48 CPU cycles while you wait. By comparison, a 16MHz AVR wastes about 1660 CPU cycles while it waits. Bringing the ADC performance much closer to the CPU performance makes that approach a lot more bearable.
Just a heads up on signal impedance. To do conversions in 1 usec you need a nice low source impedance signal (less than 5K from memory). The ADC typically runs on a 14MHz clock. The actual conversion takes 12.5 cycles, and prior to that there’s a software-configurable sampling time from as low as 1.5 clocks (giving you 1usec conversions) to as high as 239.5 clocks (giving you 18 usec conversions). So you can effectively tune the ADC to your source impedance, but at the cost of sampling speed. You’d need to check how the Arduino STM32 HAL configures that. And all those details are for the F0 family, so may or may not apply to other families.
I managed to find a Red Pill schematic, but couldn’t find a Blue Pill. And yes, it had AVDD connected directly to VDD while the STM development boards have a series ferrite bead. They also run AVDD and AGND out on two adjacent pins so you can put the decoupling cap right up against the pins… I couldn’t find that on the Red Pill either. Not having all that means the quality of your supply becomes much more critical. A lot of Arduino manufacturers take similar shortcuts with their AVR designs. That, in conjunction with noisy power supplies, is suspected to be one of the leading causes of “my monitor reads x watts when the circuit is switched off” complaints.
Whilst discussing the Arduino Due on another thread I took another look at the specs and even they are 84MHz Cortex-M3 based MCU’s with 12x 12bit ADC’s, which (although I can’t see it right now) I seem to recall reading somewhere was capable of a sample rate of 1MHz, which if that is the case, would mean it can run all 12x 12bit ADC’s around 30x faster than the emonTx can run 5x 10bit ADC’s, if I’m not mistaken. Not quite on par with the STM’s, but possibly an easier transition??
the link doesn’t work.(takes you to best.com, but there’s nothing there) 
Typo!! Somehow I copied over the link wrong, fixed now.