Try this repo, many files have been removed from Trystans version, that only works with PIO now.
then the emonTxshield project folder eg
git clone https://github.com/stm32oem/stm32tests.git
cd stm32tests/emonTxshield
make
I ran apt-get update and dist-upgrade yesterday!
The stm32oem/stm32tests version compiles with make OK.
Thanks
ā¦and prints values too?
Sadly no values.
2: Vrms: , Irms: , Papp: , Preal: , PF:
3: Vrms: , Irms: , Papp: , Preal: , PF:
0: Vrms: , Irms: , Papp: , Preal: , PF:
I havenāt fitted a link yet:-
Patch PA0 through to PB14 for V!!!
The absence of a link shouldnāt cause no values to be printed.
Have you uploaded the compiled file after running make? That looks like your still running the version compiled by PIO. I have no issue with the make route, I get no errors and the serial print is always complete with values.
cp build/emonTxshield.bin /media/pi/NODE_F303RE
to upload unless you have followed my install guide and created the alias function, in which case itās just
flash
Hi
Pretty sure I did. Had to use sudo as below
pi@webcam:~/stm32tests/emonTxshield $ cp build/emonTxshield.bin /media/pi/NODE_F303RE
cp: cannot stat '/media/pi/NODE_F303RE/emonTxshield.bin': Permission denied
pi@webcam:~/stm32tests/emonTxshield $ sudo cp build/emonTxshield.bin /media/pi/NODE_F303RE
pi@webcam:~/stm32tests/emonTxshield $
So flash does not work. I guess I need to change permissions in /media/pi/NODE_F303RE
Still no values!
Ah, thanks for that. Itās not the seperate line that made the the difference itās just passing the flag directly without -D since itās not a #DEFINE. My mistake, Iāve made the change and itās been included in my open PR:
Compile is tested and working on my Pi3 
Iāve not tested uploading, I donāt have a STM unit in the office with me. Iāll try at home tonight.
Even thought it works on a Pi, my preference would be to use a 64bit full linux machine for the fastest possible compile time. Even though the platformio compiler is clever and will only re-compile the bits of code that have been changes since last compile therefore development cycle is quick.
Please could this PR be merged:
The pio monitor will use whatever baudrate has been defined in platformio.ini e.g. monitor_baud = 115200 has been defined in the platformio.ini files I addedā¦ If you want you can force a different baud rate with pio device monitor -bXXXXX
What permissions do you currently have? I have this
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 Mar 29 14:18 ..
-r--r--r-- 1 pi pi 46 May 27 2004 DETAILS.TXT
-r--r--r-- 1 pi pi 512 May 27 2006 MBED.HTM
Did you mount manually or did you let startx mount it?
pi@webcam:~/stm32tests/emonTxshield $ sudo ls -la /media/pi/NODE_F303RE
total 44
drwx------ 2 root root 4096 Mar 29 15:31 .
drwxr-x---+ 3 root root 4096 Mar 29 14:12 ..
-rwxr-xr-x 1 root root 33416 Mar 29 16:35 emonTxshield.bin
pi@webcam:~/stm32tests/emonTxshield $
I let startx do the mount.
I need to change permissions.
The gnu99 flag is just part of the problem, Ian has confirmed what I have already posted, there are no values in the serial print. the gnu99 flag has been manually added by both myself and Ian and neither of us see values in the serial output.
Sure, Iāll pull it into the platformio branch but using the PIO method clearly still needs looking in to further.
Somethings not quite right there Ian. It seems the .bin has been copied to the device/folder but it hasnāt been automatically flashed by the Nucleoās on-board STlink v2.1. You shouldnāt (AFAIK) ever see a .bin there as it should disappear as it is flashed and where are your other files? have you deleted the other 2 files?
That looks to me like it is an actual folder, not a folder temporarily created by the OS for mounting the device to, What do you get for the mount command
pi@raspberrypi:~ $ sudo mount
/dev/mmcblk0p2 on / type ext4 (rw,noatime,data=ordered)
devtmpfs on /dev type devtmpfs (rw,relatime,size=470180k,nr_inodes=117545,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=27,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=94956k,mode=700,uid=1000,gid=1000)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
/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)
in amongst that I have /dev/sda on /media/pi/NODE_F303RE type vfat
Hi Paul
Your right, no sign of /dev/sda on /media/pi/NODE_F303RE type vfat.
For some reason my Pi is not creating the temporary mount when I plug the Nucleo in. The strange thing is it mounts onto my Windows PC without any trouble. I switched to the Pi when realised I could use Windows for Platformio but not for make. Tomorrow if its still raining I will see if there is another way of uploading the firmware from the Pi to the Nucleo. Many thanks for your assistance today. I have learnt a fair bit (And realised how little I know!)
Itās a bank holiday, of course it will be raining 
has the device been added under another name? Try
ls -la /media/pi
I have just done some experimenting to see if that physical folder thatās been created is blocking the mounting of the actual device.
I unplugged my Nucleo, created a folder at /media/pi/NODE_F303RE (which I had to use sudo for) and then reconnected the Nucleo
pi@raspberrypi:~ $ ls -la /media/pi
total 16
drwxr-x---+ 4 root root 4096 Mar 29 17:45 .
drwxr-xr-x 3 root root 4096 Mar 22 18:08 ..
drwxr-xr-x 2 pi pi 1024 Jan 1 1970 NODE_F303RE
pi@raspberrypi:~ $ mkdir /media/pi/NODE_F303RE
mkdir: cannot create directory Ć¢/media/pi/NODE_F303REĆ¢: Permission denied
pi@raspberrypi:~ $ sudo mkdir /media/pi/NODE_F303RE
pi@raspberrypi:~ $ ls -la /media/pi
total 16
drwxr-x---+ 4 root root 4096 Mar 29 17:46 .
drwxr-xr-x 3 root root 4096 Mar 22 18:08 ..
drwxr-xr-x 2 root root 4096 Mar 29 17:46 NODE_F303RE
pi@raspberrypi:~ $ ls -la /media/pi
total 20
drwxr-x---+ 5 root root 4096 Mar 29 17:46 .
drwxr-xr-x 3 root root 4096 Mar 22 18:08 ..
drwxr-xr-x 2 root root 4096 Mar 29 17:46 NODE_F303RE
drwxr-xr-x 2 pi pi 1024 Jan 1 1970 NODE_F303RE1
it silently created a device with the same path and name, but with a ā1ā tagged on the end, so maybe your device is at /media/pi/NODE_F303RE1 in which case to upload the .bin you need to use
cp build/emonTxshield.bin /media/pi/NODE_F303RE1
or simply just delete that folder
sudo rm -r /media/pi/NODE_F303RE
and unplug/plug the Nucleo, fingers crossed it might be mounted as expected.
No worries, I was absolutely pulling my hair out with this last week, so anything I can do to avoid you going through that Iām happy to help with.
Ian, donāt know how much spare disk space you have on your PC, but āplan Bā could be to create a Debian VM, and develop, compile & flash within that environment.
I use Oracle VM Virtualbox on my Windows 10 PC, which is running Debian OS.
The beauty of this approach is that when youāve finished the development, you can simply delete the VM, so your PC doesnāt add clutter.
It also compiles really quickly!
Paul
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.
2 Likes
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.
1 Like
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
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
1 Like