target is to use orange pi board to read vems data for realtime data over ser2net or dataloging trigger frame stream to vemslog format saved to filesystem (SD, or /dev/shm tmpfs, or network filesystem, or SSD, or rust).
Experimental binaries (primary target: armhf or occasionally unsupported aarch64/x86/x86_64 or amd64):
http://www.vems.hu/files/orangepi_main/OrangeVemslog_v0.3.zip mdsum: 5e6369eb2de89b3000a549cfb4783988
- OrangeVemslog.x86 md5sum: 3cc2bb9cd86c318f5ff3960fec196335
- OrangeVemslog.armhf md5sum: 6e62528e85dde8d4f71c3e8965ce324b
v0.3 changes
- allow log starting from all communication modes, flush buffers on each reconnect to avoid hangup on inserted trash
Sw Environment
- If VT is connected (via serial port or ser2net), multiple (remote or local) VemsTune can be connected, see VemsTuneMulticast
- if VT is NOT connected, and no other program keeps the serial port open, orangepi_main (need to find a better name) can query runtime data and log to filesystem
- ser2net theoretically closes the serial port if TCP connection closes, but if in doubt, stop ser2net (fuser /dev/ttyS0 ... can be useful)
current board: Orange pi lite (H3, armhf)
OS Armbian Ubuntu Desktop : https://www.armbian.com/download/
to connect it to vems we need to have serial port on the board, it has some UARTS but they are ttl level, so we need some max232 interface.
using one like [that]
![[connect UART3]](http://www.cnx-software.com/wp-content/uploads/2015/09/Orange_Pi_2_GPIO_Pinout.png){kind=link}
to get it working we need to [change orange configuration]
best way to test it is to download minicom and try to capture some aim data from vems serial port, in my case i had to swap rx and tx wires on serial cable which connects between vems and raspberry. both ends of the cable are female gender.
at the moment I'm using orange to have wireless connection for the ecu on test bench using ser2net
config file is located in /etc/ser2net.conf and has line 4400:raw:1000:/dev/ttyS3:19200 8DATABITS NONE 1STOPBIT banner
/etc/fstab
- The achilles heel of an embedded system is the SD-card
- setup fstab and write to separate partition, not to boot or root fs
- in the end, make root ro is best (might need some tests, but after that the system lifetime might be tripled).
http://vems.hu/download/arm/orangepi_main/
- tune2fs -l /dev/sda5 | grep 'Last write time'
- Last write time: Sun Jul 9 15:30:23 2017
- date -s ... could be done according to that, to have monotonous time after reboots (without RTC, and even if NTP servers not reachable)
- (possibly also considering Lifetime writes)
Test simple built binary, linking and serial port
- download from http://vems.hu/download/arm/orangepi_main/ and unzip if necessary
- chmod +x OrangeVemslog.*
- see Checklist below if needed (skip if all goes well)
- OrangeVemslog.armhf /dev/ttyS0 | tee /dev/shm/dummy
- It opens specified serial ports at 19200 baud, and reads data received and prints to outputfile
- .armhf Binary built on xenial armhf (32bit) orangepi H3 pc-plus
- similar to orangepi-PC or zero or lite: zero or lite have builtin wifi, and might be perfect to log and send data over mobile-net.
- orangepi_main: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=c2f3c15e6c7d2d228dc4a638bb205d1ae6dd15c0, not stripped in hex
- ldd orangepi_main
- libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6eaa000)
- /lib/ld-linux-armhf.so.3 (0xb6f96000)
- might also run on 32bit armhf Debian jessie, or even buildroot, or possibly 32bit raspberry (not a target currently, devels use and have all kinds of orangepi-s but only 64 bit raspberry)
- easy to build on aarch64 orangepi pc2 if necessary (although gigabit ethernet is hardly necessary in a vehicle logger/network proxy device), and no other advantage apparently.
Historical Tests
- test0, got data moving without erors, uploaded results file: https://www.sendspace.com/file/5h7oiy
- armhf or aarch64 are the "usual" (Linux GNU) arm binaries
- x86 or x86_64 are what they sound.
- Unzip if necessary, chmod +x *
- ldd binary_program
- shows .so shared object ("dll") dependencies except if binary is for another architecture. Some NOT_FOUND means library not present (although currently only using the most basic libraries):
- linux-gate.so.1
- libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6
- /lib/ld-linux.so.2
- id ; ls -l /dev/ttyUSB0 ; do we have group read/write permission to the device ?
./OrangeVemslog.armhf /dev/ttyUSB0 > /tmp/err 2>&1
zip the err file (and the NOSERIAL-2017.07.09-14.25.24.vemslog) before uploading for any report.
- The filename currently has proper UTC timestamp
- which avoids anomalies related to daylight saving and comparison of timestamps captured with different timezone settings.
- v3 serial number (v3.3u_......) instead of NOSERIAL means ECU serialnr is properly queried and saved
Checklist - useful initally for review / debug / inspection or for curious geeks. Not needed if/when all goes perfectly.
- date ... check the time, use date -s ... if dummy (happens when neither ntp, neither RTC is available)
- TODO: some script called from linux rc.local could make sure timestamps are at least monotonous (later means later) ... eg based on tune2fs -l
Sniff the serial stream: PC to v3 direction is used to query data with TF commands (HDLC-7D-7E escaped and 7E between frames)
TF command to query runtime data is A0, it appears regularly (as a0 bf 38, see below)
TF Commands used to query ECU config pages:
<PRE>
marcell@mini:/svn/stm32/orangepi_fat$ grep TF2 /tmp/err | sort
TF2: 00 f4
TF2: 01 f4
TF2: 02 f4
TF2: 03 f4
TF2: 04 f4
TF2: 06 f4
TF2: 07 f4
TF2: 08 f4
TF2: 0a f4
TF2: 0c f4
TF2: 0d f4
TF2: 0e f4
TF2: 0f f4
TF2: 11 f4
TF2: 02 f2
TF2: 03 f2
TF2: 04 f2
TF2: 05 f2
Or the complete hex stream:
000022f0: 17 7e ff 00 f4 40 77 7e ff 02 f4 41 17 7e ff 04
00002300: f4 42 b7 7e ff 0f f4 45 87 7e ff 03 f4 40 87 7e
00002310: ff 0c f4 45 77 7e ff 0d f4 44 e7 7e ff 11 f4 4c
00002320: 27 7e ff 06 f4 43 d7 7e ff 07 f4 42 47 7e a0 bf
00002330: 38 7e a0 bf 38 7e a0 bf 38 7e a0 bf 38 7e a0 bf
00002340: 38 7e a0 bf 38 7e a0 bf 38 7e a0 bf 38 7e a0 bf
00002350: 38 7e a0 bf 38 7e a0 bf 38 7e a0 bf 38 7e a0 bf
</PRE>
Inspecting the vemslog file saved to filesystem:
hexdump -C NOSERIAL-2017.07.09-16.30.49.vemslog |less
More testing
it works on /dev/ttyUSB0 (or /dev/ttyS3 if available for rw)
- 2017-07-10 generated logs, but I cant open them on the laptop
- https://www.sendspace.com/file/i6x83l log and error file in rar
- test newest fresh download, with ser2net STOPPED
- indeed, logs will be useless (if generated at all) if ser2net (or other program) keeps the serial port open. Close VT (or disconnect), and allow exclusive access to serial port (unix device, and VEMS ECU 1st serial port)
- also: download fresh .armhf binary
Stack smashing on armhf - fixed
root@orangepilite:/mnt/logger# ./orangepi_main.armhf /dev/ttyUSB0 > /tmp/err 2>&1
2020 update
I have acquired bit nicer version of raspberry pi called nano pi
https://www.antratek.com/nanopi-r1-1gb-ram-8gb-emmc
has nice hardware, rtc on board, wifi and other stuff
software options for it at the moment I have tested is openWRT version called FriendlyWRT and ubuntu xenial core.
http://wiki.friendlyarm.com/wiki/index.php/NanoPi_R1
datalogging stuff works fine on ubuntu, but does not start on WRT based operating system
this is the error I got
root@FriendlyWrt:/mnt# ./OrangeVemslog.armhf
-ash: ./OrangeVemslog.armhf: not found
root@FriendlyWrt:/mnt#
some hw info
root@FriendlyWrt:/# cat proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 22.85
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5
root@FriendlyWrt:/# uname -r
4.14.111
LDD option as asked
root@FriendlyWrt:/mnt# ldd OrangeVemslog.armhf
/lib/ld-linux-armhf.so.3 (0xb6f6b000)
libc.so.6 => /lib/ld-linux-armhf.so.3 (0xb6f6b000)
Error loading shared library ld-linux-armhf.so.3: No such file or directory (needed by OrangeVemslog.armhf)
Error relocating OrangeVemslog.armhf: __printf_chk: symbol not found
Error relocating OrangeVemslog.armhf: __fprintf_chk: symbol not found
as I understand problem is that openwrt uses ld-musl-arm.so.1 instead ld-linux-armhf.so.3
any idea how this stuff can be sorted? Orangevemslog has to be recompiled with different option or maybe there is some other workaround?