STM32 PlatformIO

pb66 · 2018-03-29T19:03:04.613Z

glyn.hudson:

my preference would be to use a 64bit full linux machine for the fastest possible compile time

Paul:

I use Oracle VM Virtualbox on my Windows 10 PC, which is running Debian OS.
…
It also compiles really quickly!

Why you guys are in such a hurry? A Pi Zero only takes between 30 and 40 seconds for a complete compile and flash, a quick recompile and flash takes 8 - 10 secs and I expect a Pi 3 is going to be significantly faster than that. Granted the install and first ever STM32 compile took longer because it had too download and install the libs and drivers etc.

I have always considered myself impatient, but you guys trump my impatience hands down.

ian · 2018-03-30T09:28:21.091Z

Success at last.

My pi will just not mount the Nucleo. I have another Pi somewhere so later I will try that.

Windows will mount the Nucleo. So I connected the Nucleo to the Windows PC, copied the bin file from the Pi to the Windows mounted folder and bingo when I reconnected to Pi real data.

pi@webcam:~/stm32tests/emonTxshield $ miniterm.py /dev/ttyACM0 115200
--- Miniterm on /dev/ttyACM0  115200,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
CPU temp: 32C, Vdda: 3306mV
1: Vrms: 68.82, Irms: 7.98, Papp: 549.43, Preal: 960.52, PF: 1.748
2: Vrms: 68.82, Irms: 87.85, Papp: 6045.80, Preal: 4913.25, PF: 0.813
3: Vrms: 71.18, Irms: 87.84, Papp: 6252.60, Preal: 5139.00, PF: 0.822
0: Vrms: 68.82, Irms: 8.44, Papp: 580.83, Preal: 1511.77, PF: 2.603
CPU temp: 32C, Vdda: 3306mV
0: Vrms: 67.98, Irms: 6.78, Papp: 461.02, Preal: 1015.62, PF: 2.203

Now to put some power through the CT.

Paul · 2018-03-30T09:47:43.808Z

Great. You should see a change in the values with CT attached, but the values are not processed sufficiently yet, and they will not be displayed as watts etc. Just indicative.

Paul

pb66 · 2018-03-30T17:12:02.563Z

Some good news!

I have today done a fresh install of both methods (Make and PIO) and both worked, I have my reservations about the success of the PIO install since it is fully automated and I have not done anything different. But none the less I am able to compile, flash and then see a serial output complete with values. I cannot yet explain why I (Trystan and Ian) have experienced no values in the serial prints previously. Make has always behaved, but PIO has been problematic on the Pi until now.

Whilst doing the fresh installs and testing the compiles etc I have tracked the time taken for each command and the disk space used. I had expected to find PIO was using significantly more space than Make, but (provided it only executed by the pi user) it only uses marginally more space, Make added 0.5GB and PIO 0.6GB, providing the user never accidentally uses sudo and duplicates that 0.6GB, all should be ok.

As for speed, bit of an eye opener! Make is hands down faster on a Pi in all respects. The table below shows all the usual tasks and a time for each method, Make and PIO. There is also a 3rd column that shows the time reported by PIO, I assume they are recording a sub-routine because there time is always under by a couple of secs or so. My times are done by the OS and measure between command issued and completed in minutes and whole seconds only.

All tests done on a Pi 3 with fully updated latest Raspbian Stretch.

task	make	pio	(time by pio)
initial install	03:28	01:01
very first compile	00:48	06:53	(406.76s)
install & first compile total	04:16	07:54
recompile(no changes)	00:00	00:17	(14.20s)
recompile & flash(no changes)	00:01	00:14	(11.37s)
recompile(deleted tmps)	00:39	00:41	(38.87s)
recompile & flash(deleted tmps)	00:40	00:41	(38.89s)
flash compiled code	00:00	00:15	(13.39s)

Rather oddly, PIO consistently takes longer to compile without flashing that it takes to compile and flash all in one move, by about 3secs, the time is not significant, just odd it takes longer to do less.

Make takes next to 0secs to flash, where as PIO seems to try and recompile compiled source before flashing, even just runing “run” a second time with no changes takes 17 secs, where as Make just replies instantly “there’s nothing to do”. However, if you always issue a “compile and flash” command as one move, the times are pretty much the same, although PIO does try to tell you it took less time than it actually did.

So for those users without the valuable seconds to spare to sit around waiting for PIO to finish, Make is the better choice.

Or put another, I now understand why PIO users need those faster PC’s

The important thing here is that PIO does now seem to work ok, if I get a chance I will try another clean install to confirm PIO works ok as I have now also installed the make ARM toolchain on that same Pi to see if the issue was possibly because I had both installed and running, but no, it’s still working…

[versions]

pi@raspberrypi:~/stm32tests/emonTxshield $ uname -a
Linux raspberrypi 4.9.80-v7+ #1098 SMP Fri Mar 9 19:11:42 GMT 2018 armv7l GNU/Linux
pi@raspberrypi:~/stm32tests/emonTxshield $ pio --version
PlatformIO, version 3.5.2
pi@raspberrypi:~/stm32tests/emonTxshield $ arm-none-eabi-gcc --version
arm-none-eabi-gcc (15:5.4.1+svn241155-1) 5.4.1 20160919

dBC · 2018-04-03T06:27:24.415Z

pb66:

the gnu99 flag has been manually added by both myself and Ian and neither of us see values in the serial output.

I’m only loosely following this thread and it seems you’ve got it all sorted, but just to be clear gnu99 won’t help with the %f printfs appearing as spaces. gnu99 will permit you to write code like:

for (int i=0; ...

There’s a comment right above the printf in power.c that tells you what you need if your %fs come out as blanks.

glyn.hudson · 2018-04-03T11:01:16.644Z

I’ve just test compiled and uploaded the latest master branch using pio and it works fine for me, getting serial print values:

git clone https://github.com/stm32oem/stm32tests.git
cd stm32tests/emonTxshield
pio run -t upload
pio device monitor

--- Miniterm on /dev/ttyACM0  115200,8,N,1 ---
--- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
 53.56, Irms: 87.93, Papp: 4709.26, Preal: 3931.25, PF: 0.835
2: Vrms: 53.56, Irms: 87.93, Papp: 4709.26, Preal: 3931.25, PF: 0.835
3: Vrms: 46.60, Irms: 87.93, Papp: 4097.84, Preal: 3129.50, PF: 0.764
0: Vrms: 53.56, Irms: 87.93, Papp: 4709.26, Preal: 3931.25, PF: 0.835
CPU temp: 33C, Vdda: 3304mV
0: Vrms: 47.35, Irms: 87.93, Papp: 4163.12, Preal: 3449.50, PF: 0.829
1: Vrms: 47.35, Irms: 87.93, Papp: 4163.12, Preal: 3449.500: Vrms: 58.99, Irms: 87.93, Papp: 5186.61, Preal: 3942.25, PF: 0.760
1: Vrms: 58.99, Irms: 87.93, Papp: 5186.61, Preal: 3942.25, PF: 0.760
2: Vrms: 58.99, Irms: 87.93, Papp: 5186.61, Preal: 3942.25, PF: 0.760
3: Vrms: 63.57, Irms: 87.93, Papp: 5589.80, Preal: 4518.25, PF: 0.808

Is this fixed for everyone now?

Update : yes it seems master branch is now working on PlatformIO on both AMD64 and RaspberryPi

pb66 · 2018-04-03T11:33:43.355Z

dBC:

I’m only loosely following this thread and it seems you’ve got it all sorted, but just to be clear gnu99 won’t help with the %f printfs appearing as spaces. gnu99 will permit you to write code like:

Thanks @dBC, yeah, that was more of a status marker than a link between “gnu99” and the missing values, at that point adding @glyn.hudson’s build_flags it neither compiled or printed on the Pi, but adding my additional “build_flags = -std=gnu99” line allowed it to compile but there were still no values printed.

I have a untested theory about that, since adding @glyn.hudson’s build_flags

build_flags =
  -Wl,-u_printf_float
  -D std=gnu99

had no effect and still failed to compile, but adding my own “gnu99” build_flags

build_flags =
  -Wl,-u_printf_float
  -D std=gnu99

build_flags = -std=gnu99

did compile but still didn’t print serial values and the latest version

build_flags =
  -Wl,-u_printf_float
  -std=gnu99

does both. I suspect the “-D” was preventing both of the original build_flags being used and therefore only the additional seperate “gnu99” build_flags line was actually effective. Removal of the “-D” from the original build_flags has both enabled the “gnu99” flag and allowed the “-Wl,-u_printf_float” to work.

Maybe one day I’ll test that theory if I remember.

pb66 · 2018-04-03T11:38:04.444Z

glyn.hudson:

I’ve just test compiled and uploaded the latest master branch using pio and it works fine for me, getting serial print values:

Is that on a Pi?

glyn.hudson:

Is this fixed for everyone now?

If by everyone you mean me, I believe so, I’ve only had 1 successful install but I’m quietly confident that went as planned and have no reason to doubt it would work again.

I think @Ian gave up and used Windows, @TrystanLea and you are using amd64 as is @Paul via a VM, I don’t know of anyone other than myself that is testing on a Pi so it would be useful if you could confirm it’s ok on a Pi.

glyn.hudson · 2018-04-03T13:13:59.773Z

pb66:

Is that on a Pi?

No Ubuntu desktop

pb66:

If by everyone you mean me, I believe so, I’ve only had 1 successful install but I’m quietly confident that went as planned and have no reason to doubt it would work again.

Great

pb66:

I think @Ian gave up and used Windows, @TrystanLea and you are using amd64 as is @Paul via a VM, I don’t know of anyone other than myself that is testing on a Pi so it would be useful if you could confirm it’s ok on a Pi.

If it works for you on a Pi it should work fine on all Pi’s since Pi’s are should be identical

glyn.hudson · 2018-04-03T13:15:38.552Z

pb66:

does both. I suspect the “-D” was preventing both of the original build_flags being used and therefore only the additional seperate “gnu99” build_flags line was actually effective. Removal of the “-D” from the original build_flags has both enabled the “gnu99” flag and allowed the “-Wl,-u_printf_float” to work.

Yes, -D is the equivalent of #define. Therefore using -D was incorrect in this instance since we wanted to pass the value direct to the compiler as a flag.

ian · 2018-04-03T15:01:40.018Z

@glyn.hudson

Just to test this I started on a new out of the box pi with 2018-03-13-raspbian-stretch.image.

I followed your platform instructions exactly using the links provided.

First issue was platform:

pi@STM_Test:~ $ pio
-bash: pio: command not found

I reinstalled with sudo

pi@STM_Test:~ $ sudo python -c "$(curl -fsSL https://raw.githubusercontent.com/platformio/platformio/develop/scripts/get-platformio.py)"

and then pio was recognised as a command.

pi@STM_Test:~/stm32tests/emonTxshield $ pio run -t upload

This worked fine until the upload when I got this error:-

Looking for upload disk...
Error: Please specify `upload_port` for environment or use global `--upload-port` option.
For some development platforms it can be a USB flash drive (i.e. /media/<user>/<device name>)
*** [upload] Explicit exit, status 1
========================= [ERROR] Took 397.06 seconds =========================

================================== [SUMMARY] ==================================
Environment stm32f303-dev       [ERROR]
Environment stm32f303           [SKIP]
========================= [ERROR] Took 397.06 seconds =========================

I know the nucleo is on /dev/ttyACM0 because I can see it in miniterm still running the firmware I uploaded a day or so ago.

Ian

pb66 · 2018-04-03T16:04:06.234Z

ian:

I know the nucleo is on /dev/ttyACM0 because I can see it in miniterm still running the firmware I uploaded a day or so ago.

Ian, /dev/ttyACM0 is the devices serial port, but when uploading to a STLink you are copying to a mass storage device usually at “/media/<user>/<device name>” as stated in the pio output. Mine is usually at /media/pi/NODE_F303RE.

What does this return for pi’s media folder?

ls -la /media/pi

ian · 2018-04-03T16:58:29.457Z

pb66:

ls -la /media/pi

Hi Paul

pi@STM_Test:~/stm32tests/emonTxshield $ ls -la /media/pi
total 12
drwxr-x---+ 3 root root 4096 Apr  3 14:46 .
drwxr-xr-x  3 root root 4096 Apr  3 14:46 ..
drwx------  2 root root 4096 Apr  3 14:46 NODE_F303RE
pi@STM_Test:~/stm32tests/emonTxshield $

pb66 · 2018-04-03T17:08:33.953Z

That looks like an empty folder

What do you find in that folder (if anything)?

ls -la /media/pi/NODE_F303RE

also what does this return?

mountpoint /media/pi/NODE_F303RE

here’s my results

pi@raspberrypi:~ $ ls -la /media/pi
total 16
drwxr-x---+ 4 root root 4096 Apr  3 17:15 .
drwxr-xr-x  3 root root 4096 Mar 13 23:17 ..
drwxr-xr-x  2 pi   pi   1024 Jan  1  1970 NODE_F303RE

pi@raspberrypi:~ $ ls -la /media/pi/NODE_F303RE
total 16
drwxr-xr-x  2 pi   pi   1024 Jan  1  1970 .
drwxr-x---+ 3 root root 4096 Apr  3 17:05 ..
-r--r--r--  1 pi   pi     46 May 27  2004 DETAILS.TXT
-r--r--r--  1 pi   pi    512 May 27  2006 MBED.HTM

pi@raspberrypi:~ $ mountpoint /media/pi/NODE_F303RE
/media/pi/NODE_F303RE is a mountpoint

Are you doing this via startx? Or have you had startx running at any point when you’ve had the stm device hooked up? This looks very much the same as your original attempt.

pb66 · 2018-04-03T17:35:23.111Z

Also what does

ls -la /dev/sd*

and

mount | grep "NODE_F303RE"

return? Here’s mine again.

pi@raspberrypi:~ $ ls -la /dev/sd*
brw-rw---- 1 root disk 8,  0 Apr  3 17:05 /dev/sda

pi@raspberrypi:~ $ mount | grep "NODE_F303RE"
/dev/sda on /media/pi/NODE_F303RE type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

[edit - I have just dragged out a hdmi cable and fired up startx and it doesn’t appear to have changed anything for me.]

glyn.hudson · 2018-04-03T22:48:29.090Z

ian:

This worked fine until the upload when I got this error:-

Looking for upload disk…
Error: Please specify upload_port for environment or use global --upload-port option.
For some development platforms it can be a USB flash drive (i.e. /media/<user>/<device name>)
*** [upload] Explicit exit, status 1
========================= [ERROR] Took 397.06 seconds =========================

================================== [SUMMARY] ==================================
Environment stm32f303-dev [ERROR]
Environment stm32f303 [SKIP]
========================= [ERROR] Took 397.06 seconds =========================

I know the nucleo is on /dev/ttyACM0 because I can see it in miniterm still running the firmware I uploaded a day or so ago.

I think you will need to setup the port permissions. Try once with

$ sudo pio run -t upload

If this works, we will just need to fix the group permissions or just continue to use sudo before every pio command. Not best practice but ‘works’ on a Pi.

pb66 · 2018-04-04T12:43:23.927Z

My NODE_F303RE folder details are

drwxr-xr-x  2 pi   pi   1024 Jan  1  1970 NODE_F303RE

Ian’s NODE_F303RE folder details are

drwx------  2 root root 4096 Apr  3 14:46 NODE_F303RE

“4096” is the initial size for an actual folder in Linux and “Apr 3 14:46” is when that folder was created. There is something very odd about the way the device is (or isn’t?) mounted.

This was further proved when Ian was able to copy the .bin file to the NODE_F303RE “folder” and view it there just like any other file copying process, the .bin file should have been consumed by the device if it was mounted there.

Besides why would a storage device be mounted under /media/pi if the user pi has no access to it? It’s as if the device has been mounted with

sudo mkdir -p /media/pi/NODE_F303RE
sudo mount /dev/sda /media/pi/NODE_F303RE

that would give you a root owned folder BUT that method arrives at slightly different “group” and “all users” permissions, so I guess the folder is being created another way.

pi@raspberrypi:~ $ sudo mkdir -p /media/pi/NODE_TEST
pi@raspberrypi:~ $ ls -la /media/pi
total 16
drwxr-x---+ 4 root root 4096 Apr  4 12:19 .
drwxr-xr-x  3 root root 4096 Mar 13 23:17 ..
drwxr-xr-x  2 pi   pi   1024 Jan  1  1970 NODE_F303RE
drwxr-xr-x  2 root root 4096 Apr  4 12:19 NODE_TEST

I’m using a totally stock Pi with totally stock OS, So the question is why am I getting different results, I have not had to use sudo at any point since installation. it has to be the order of events or the way something is being done differently.

@Ian did you run update and dist-upgrade on the new image? I have to admit I have done that immediately on each image I’ve created so I can’t say if this works on an un-updated latest image. ~~Are you still using the “full” image not a “lite” image?~~ {must be if you are using startx I guess]

ian · 2018-04-04T14:04:29.964Z

sudo pio run -t upload made no difference. Same error. It would seem the problem is that the nucleo is not being mounted when plugged in. See reply to @pb66 below

ian · 2018-04-04T14:24:14.395Z

Result of commands suggested:-

pi@STM_Test:~/stm32tests/emonTxshield $ ls -la /media/pi/NODE_F303RE
ls: cannot open directory '/media/pi/NODE_F303RE': Permission denied

pi@STM_Test:~/stm32tests/emonTxshield $ sudo ls -la /media/pi/NODE_F303RE
total 44
drwx------  2 root root  4096 Apr  3 18:16 .
drwxr-x---+ 3 root root  4096 Apr  3 14:46 ..
-rwxr-xr-x  1 root root 33416 Apr  3 18:18 emonTxshield.bin

pi@STM_Test:~/stm32tests/emonTxshield $ mountpoint /media/pi/NODE_F303RE
/media/pi/NODE_F303RE is not a mountpoint
pi@STM_Test:~/stm32tests/emonTxshield $ ls -la /dev/sd*
brw-rw---- 1 root disk 8, 0 Apr  4 14:48 /dev/sda

pi@STM_Test:~/stm32tests/emonTxshield $ mount | grep "NODE_F303RE"
pi@STM_Test:~/stm32tests/emonTxshield $

I did update and upgrade on the new image but not dist-upgrade, which I just did but that resulted in no changes.

I used startx tp set Pi configuration and connect to WiFi. I first did it without the nucleo plugged in but whether I have ever done it with the nucleo plugged in I cannot be absolutely sure.

I have had the same issue with 2 different Pi. The first one I retrieved from from my junk box and has seen better days. The second one is brand new straight out of the packaging. I have used a different power supply just in case there was a power issue.

The only common feature hardware wise is the nucleo board and the USB cable its connected by.

It mounts on my windows PC but it would seem for some reason it does not mount correctly on the Pi.

So I cannot us PIO or cp build/emonTxshield.bin /media/pi/NODE_F303RE using a Pi. I can use PIO on windows and I can copy the result of make from the Pi to the windows machine and then copy onto the mounted nucleo using either Pi.

pb66 · 2018-04-04T15:24:59.832Z

Was the Nucleo attached when you did that last batch of tests?

Everything is as I expected except the “grep”, Can you run a couple more commands/

sudo blkid | grep "/dev/sd"

should show the device whether it’s mounted or not

sudo mount | grep "/dev/sd"

should show any mounted devices that use /dev/sd? regardless of what name it’s been assigned, I’ve included sudo this time just in case previously mount didn’t include the “NODE_F303RE” for grep to find because of the root ownership.

my results

pi@raspberrypi:~ $ sudo blkid | grep "/dev/sd"
/dev/sdb: SEC_TYPE="msdos" LABEL="NODE_F303RE" UUID="2702-1974" TYPE="vfat"

pi@raspberrypi:~ $ sudo mount | grep "/dev/sd"
/dev/sdb on /media/pi/NODE_F303RE type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

Using sudo pio run can result in a duplication of libs and a change of ownership of the compiled results that could block future use of pio without sudo, so can you also post the results of these 2 commands

ls -la ~/stm32tests/emonTxshield/.pioenvs

sudo ls -la /root/.platformio

hopefully as the sudo pio run -t upload command was not a full recompile you should be ok