Yes the Nucleo144 board is ~£6 dearer than the Nucleo-64, but it has more physical IO pins, a bigger PCB, a micro USB port and an Ethernet port (that I know about), the actual F303 chip is a negligible difference, which if/when this goes to production is what counts. There is currently no intention of using the Nucleo boards beyond development, they are just a dev tool.
I can’t answer the question about whether the code will run on both as I’m not sure what the code will consist of yet, but if it doesn’t, I do not expect it to take too much to change it. Generally speaking, as far as I can tell the code should/could be portable and could be compiled with the different board settings from the cubeMX, but if we’re addressing adc’s that don’t exist on the smaller board, that will still need changing I guess.
Admittedly a little late to the party, but I’m using Windows 7.
My Nucleo board arrived yesterday, so now I’m waiting for the shield.
In the meantime I’ll rig up a breadboard and a CT.
Following your lead, I installed gcc-arm-none-eabi-7-2017-q4-major.
Then, to get make, I installed Msys2 (a MinG-type environment)
I didn’t actually pursue the windows path any further after finding make already wasn’t there, I now have the STM32 board plugged in to a Pi that I can access remotely, it means I can now work from the laptop in various places without dragging the stm32/shield/CT’s and AC adapter around.
No I didn’t install cubeMX to the Pi, it’s a utility that doesn’t actually connect to an STM32, so I still use that on my windows PC plus I don’t have a remote desktop set up on that Pi. With github you can work on the files from multiple machines.
"Linux®: 32-bit (x86) and 64-bit (x64) (tested on RedHat, Ubuntu and Fedora) Since STM32CubeMX is a 32-bit application, some versions of Linux 64-bit distributions require to install 32-bit compliant packages such as ia32-libs."
It also says
“Recommended minimum RAM: 2 Gbytes”
My i7 PC has 16gb and cubeMX isn’t exactly the fastest SW to open on that so I might not bother trying it on a Pi.
That 32-bit shared library support for 32 bit applications on 64-bit kernels is a real mess. Every distro solves it differently. Whether or not you need to do anything may well depend on whether or not you (or your distro) have previously installed any other 32-bit applications. I can imagine it was a bridge too far for stm to fully package-ise that. Personally, I’m just grateful they built a Linux version, even if they have left it up to the user to sort out the library requirements. Had it been necessary to fire up a WIndows VM every time I needed to reconfigure the processor, I doubt I would have chosen stm32.
In our PM I noted my intention to complete the following set of challenges to further my learning for the STM32 platform:
Follow your tutorial @dBC and expand on my STM02 code to read the voltage on one ADC and the four emontx shield CT inputs on a second ADC.
Reproduce some of your ADC timing oscilloscope captures so that I can verify and understand the simultaneous sampling
Upload firmware without using STLink and understand basic requirements in terms of circuits design.
Test an onboard opamp based buffered bias.
I’ve made progress on the first two today
First of all I am reading voltage on ADC1:PA0 and current on ADC2:PA4, which translates to the AC voltage input and CT2 on the emontx shield. I’ve extended the power monitoring math to include crossing detection so that the output readings relate to an integer number of half wavelengths. This is all standard EmonLib calculations - Im not trying to do anything clever, just trying to get sensible readings. I have uploaded the code here https://github.com/TrystanLea/STM32Dev/blob/master/STM02b/Src/main.c#L97 its worth noting that these ‘examples’ are more for my learning than anything.
Here’s a sample of results, showing a 3kW fan heater being turned on:
Then I tried to replicate your scope captures @dBC by adding a 1M pull up on the ADC inputs with the shield removed which works great!, I was hoping the result would show simultaneously sampling but it looks like its still sequential:
I started digging into your shield example code and noticed timer 8 code which I think is how your triggering the ADC conversions? I tried to add this timer in but have not been able to make it to work yet…
Yes, there’s a description of the approach I took above.
It looks like you’re ADCs are configured for “regular conversion launched by software”. That ~1.25usec lag you’re seeing is most likely how long it takes to call HAL_ADC_Start_DMA() so your two back-to-back calls aren’t quite simultaneous.
My .ioc file is included in the tar file, so if you crack that open with SMT32CubeMX you’ll see how I configured things so that the HAL_ADC_Start_DMA() calls just enable the ADCs, and then they all sit around waiting for the starter’s gun to fire (TIM8). Hopefully, when viewed with the link above in hand, it’ll all make sense but if you’re still stuck ask away.
Yes, I can’t see anything obviously wrong. What are the current symptoms? Still a staggered start as shown on your scope trace above? Do you see a 1usec low pulse on PC7? And if so, when does the first ADC sample happen relative to that pulse?
Im not sure that its actually starting… or perhaps its completing the first sample and then not continuing? The LED stays on which suggests no conversions have taken place?
Yes, if you’re not getting any interrupts it sounds like the ADCs haven’t triggered. Can you see a pulse on PC7? If Yes, then we need to work out why the ADCs aren’t triggering on it, if No then we can look at the timer setup.
