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.
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 
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.
Is that on a Pi?
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.
No Ubuntu desktop
Great
If it works for you on a Pi it should work fine on all Pi’s since Pi’s are should be identical
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.
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.
Next
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
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
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 $
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.
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.]
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.
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]
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
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.
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
Yes the Nucleo was attached.
Results of commands:-
pi@STM_Test:~ $ sudo blkid | grep "/dev/sd"
/dev/sda: SEC_TYPE="msdos" LABEL="NODE_F303RE" UUID="2702-1974" TYPE="vfat"
pi@STM_Test:~ $ sudo mount | grep "/dev/sd"
pi@STM_Test:~ $ ls -la ~/stm32tests/emonTxshield/.pioenvs
ls: cannot access '/home/pi/stm32tests/emonTxshield/.pioenvs': No such file or directory
pi@STM_Test:~ $ sudo ls -la /root/.platformio
total 20
drwxr-xr-x 4 root root 4096 Apr 4 14:50 .
drwx------ 5 root root 4096 Apr 4 14:50 ..
-rw-r--r-- 1 root root 25 Apr 4 14:50 appstate.json
drwxr-xr-x 8 root root 4096 Apr 4 14:56 packages
drwxr-xr-x 3 root root 4096 Apr 4 14:50 platforms
pi@STM_Test:~ $
The 1st result is good, it shows the Nucleo is connected.
The second result confirms the device is not mounted,
The third is odd as there should be a folder .pioenvs like this
pi@raspberrypi:~ $ ls -la ~/stm32tests/emonTxshield/.pioenvs
total 196
drwxr-xr-x 3 pi pi 4096 Apr 4 17:37 .
drwxr-xr-x 8 pi pi 4096 Mar 30 16:20 ..
-rw-r--r-- 1 pi pi 102 Mar 30 16:17 do-not-modify-files-here.url
-rw-r--r-- 1 pi pi 176954 Apr 4 17:37 .sconsign.dblite
drwxr-xr-x 5 pi pi 4096 Apr 4 17:37 stm32f303-dev
-rw-r--r-- 1 pi pi 40 Mar 30 16:17 structure.hash
perhaps the message is misleading and it is just a casualty of using sudo with pio, you could try the command again with sudo and/or try ls -la ~/stm32tests/emonTxshield too. eg
pi@raspberrypi:~ $ ls -la ~/stm32tests/emonTxshield
total 100
drwxr-xr-x 8 pi pi 4096 Mar 30 16:20 .
drwxr-xr-x 5 pi pi 4096 Mar 30 15:08 ..
drwxr-xr-x 2 pi pi 4096 Mar 30 16:20 build
drwxr-xr-x 2 pi pi 4096 Mar 30 16:20 .dep
drwxr-xr-x 4 pi pi 4096 Mar 30 15:08 Drivers
-rw-r--r-- 1 pi pi 18140 Mar 30 15:08 emonTxshield.ioc
-rw-r--r-- 1 pi pi 102 Mar 30 15:08 emonTxshield.mak
drwxr-xr-x 2 pi pi 4096 Mar 30 15:08 Inc
-rw-r--r-- 1 pi pi 5730 Mar 30 15:08 Makefile
-rw-r--r-- 1 pi pi 4797 Mar 30 15:08 .mxproject
drwxr-xr-x 3 pi pi 4096 Apr 4 17:37 .pioenvs
-rw-r--r-- 1 pi pi 931 Mar 30 15:08 platformio.ini
drwxr-xr-x 2 pi pi 4096 Mar 30 15:08 Src
-rw-r--r-- 1 pi pi 14111 Mar 30 15:08 startup_stm32f303xe.s
-rw-r--r-- 1 pi pi 4937 Mar 30 15:08 STM32F303RETx_FLASH.ld
The last test tells us you most likely have duplicate libs (0.6GB) from using sudo with pio.
I think we should try and quickly cleanse your setup and if that doesn’t work we should probably start from scratch and add your wifi details and enable ssh via the /boot partition files so you can ssh in at first boot without ever going into startx, if that works then we can then work on from there.
To cleanse the current setup try unplugging the Nucleo and run these commands
sudo rm -r /root/.platformio
sudo rm -r /home/pi/.platformio
sudo rm -r /home/pi/stm32tests/emonTxshield/.pioenvs
sudo rm -r /media/pi/NODE_F303RE
sudo reboot
when it has rebooted, ssh in and check there is no folder at /media/pi/NODE_F303RE using
sudo ls -la /media/pi
Then plug in the Nucleo and check again. If there is still nothing there after a few seconds, run these and report the results along with the result of the above.
sudo blkid | grep "/dev/sd"
sudo mount | grep "/dev/sd"
IF the “NODE_F303RE” is there after plugging in, then try
pio run -t upload
it will take several minuets because we previously deleted the compiled code and libs, if that still fails, please post the full output so we can we see the paths etc.
Do not use sudo with pio at anypoint
OK some progress.
I ran all the commands suggested exactly as indicated and I have the results saved if you would really like to see them.
However the result was that clearly the Nucleo was not being mounted.
In the meantime I reformatted the SD card on the older pi and burnt a new image. This time I set up ssh on the PC before I used the SD card and I also used a spare Ethernet to connect to the Pi.
On first boot I ran upgrade and dist-update. and rebooted. I setup wifi from the command line, shut down, dropped the Ethernet connection. and rebooted. I then plugged in the Nucleo.
Result:-
pi@raspberrypi:~ $ sudo ls -la /media/pi
total 12
drwxr-x---+ 3 root root 4096 Apr 5 16:23 .
drwxr-xr-x 3 root root 4096 Apr 5 16:11 ..
drwxr-xr-x 2 pi pi 1024 Jan 1 1970 NODE_F303RE
Unplugged Nucleo
pi@raspberrypi:~ $ sudo ls -la /media/pi
total 8
drwxr-x---+ 2 root root 4096 Apr 5 16:35 .
drwxr-xr-x 3 root root 4096 Apr 5 16:11 ..
Plugged in again
pi@raspberrypi:~ $ sudo ls -la /media/pi
total 12
drwxr-x---+ 3 root root 4096 Apr 5 16:35 .
drwxr-xr-x 3 root root 4096 Apr 5 16:11 ..
drwxr-xr-x 2 pi pi 1024 Jan 1 1970 NODE_F303RE
pi@raspberrypi:~ $
So it appears using startx somehow stops the Nucleo mounting properly.
My next move was to install Platformio.
I used:-
pi@raspberrypi:~ $ pip install -U platformio
Every thing seemed to go ok, a lot of file unpacking and no errors reported.
When it finished before I did anything else I tried this to make sure platformio was working.
pi@raspberrypi:~ $ pio
-bash: pio: command not found
I have been here before. Previously I have installed platformio with sudo and the pio then command worked.
This time I have called a halt pending advice!
The good thing is platform has not affected the mounting of the Nucleo which I have plugged and unplugged about 6 times and it always remounts.
If I can get platform to work I am sure everything will be the same as your setup. I have not tried the make procedure yet as I thought it better to sort out PlatformIO first but I have no doubt it would now work as NODE_F303RE contains MBED.HTM and DETAILS.TXT just as it shows when mounted on the Windows PC.
Fantastic news!
Good move!
Although using pip to install platformio has added another unknown element though. I have not tried using pip myself. However, we need to try and establish if the “-bash: pio: command not found” error is because it isn’t there or whether it’s the wrong user level. I suspect it’s an incomplete installation because maybe it needed to be
sudo pip install -U platformio
so that pip was run with a high enough permission level to make changes to the root file system, eg adding the pio executable to the “PATH”. I’m guessing a bit here and carrying over my experience of using the platformio “easy install” command line, it seems to install ok without sudo, but then it won’t work, re-running it with sudo seemed to fix the issue.
Since pip is a package installer, you might need to remove the current installation before you can reinstall with “sudo”.
First try
pio --version
should fail as above
sudo pio --version
not sure, but I suspect this might fail too
just check to see if either of the executables are present, here’s mine
pi@raspberrypi:~ $ ls -la /usr/local/bin/pio
-rwxr-xr-x 1 root staff 221 Mar 30 15:06 /usr/local/bin/pio
pi@raspberrypi:~ $ ls -la /usr/local/bin/platformio
-rwxr-xr-x 1 root staff 221 Mar 30 15:06 /usr/local/bin/platformio
I’m guessing the’re not there, if you want to double check there not somewhere else you can use the whereis command eg
pi@raspberrypi:~ $ whereis platformio
platformio: /usr/local/bin/platformio
pi@raspberrypi:~ $ whereis pio
platformio: /usr/local/bin/pio
but, it might be time to try and reinstall using sudo
sudo pip install -U platformio
if it complains that it’s already installed or that it’s already the latest version, we need to remove it first.
pip uninstall platformio
then try installing with again with sudo.
to test use pio --version, if that doesn’t work try checking for the executables as we did above.
That’s cool! I also suspect make will work no problems, it is much simpler than pio. for the record it’s also much faster than pio on a RPi, so although you might eventually prefer to use make over pio, I appreciate you helping resolve this as I’m sure there will be many others that hit a similar snag.
I’m still unclear about how and when startx interferes with the mounting as I tried every which way last night to get the mounting to fail and couldn’t, I used startx from boot, I rebooted with the Nucleo attached and unattached, I could not replicate what you have seen (yet).
The question over using sudo or not when installing is less of an option than platformio make out. Thier documentation is peppered with lines like
“To install or upgrade PlatformIO paste that at a Terminal prompt (MAY require administrator access sudo):”
and
“To install or upgrade PlatformIO, download (save as…) get-platformio.py script. Then run the following (MAY require administrator access sudo):”
All of the places the pio or pip installer could install the executables are owned by root, so if you are not the “root” user (or belong to the “staff” group) you must use sudo, if you are the root user, sudo has no effect, so why they do not just include sudo with these commands as standard I have no idea. Nor do I understand why the installer does not alert the user that it has failed to create/copy certain crucial files.
My fingers are crossed for you.