Some interesting links:
https://github.com/gartnera/headunit (a fork of a fork of a fork …)
Some interesting links:
https://github.com/gartnera/headunit (a fork of a fork of a fork …)
Today I decided to test the Lua (the programming language, it means Moon in Portuguese) with FLTK. There is a project called lua-fltk4lua.
Unfortunately the project doesn’t explain how to compile it from source code and it expects the developer uses the “luarocks” package manager to install it.
Although initially I was getting some issues like:
No rule to make target “moon/moon.h”
No rule to make target “compat-5.3/c-api/compat-5.3.h”
I figured out how to get it compiled and working easily, find the steps below:
$ sudo apt-get install lua5.2 $ sudo apt-get install liblua5.2-dev $ sudo apt-get install libfltk1.3-dev $ git clone https://github.com/siffiejoe/lua-fltk4lua $ cd lua-fltk4lua $ git clone https://github.com/siffiejoe/lua-moon moon $ git clone https://github.com/keplerproject/lua-compat-5.3 compat-5.3 $ make $ sudo make install
This is a nice Hello World to see it working, just create a hello.lua file with it:
local fl = require( "fltk4lua" ) local window = fl.Window( 340, 180, "Hello" ) local box = fl.Box( 20, 40, 300, 100, "Hello World!" ) box.box = "FL_UP_BOX" box.labelfont = "FL_HELVETICA_BOLD_ITALIC" box.labelsize = 36 box.labeltype = "FL_SHADOW_LABEL" window:end_group() window:show( arg ) fl.run()
$ lua hello.lua
I just find this tip useful:
arping -c 5 aa:bb:cc:dd:ee:ff
Today I tested NuttX running the LVGL demo on LPCXpresso54628.
Here you can find the steps needed to get it working.
First compile the firmware to create the nuttx.bin:
$ ./tools/configure.sh lpcxpresso-lpc54628/lvgl $ make menuconfig $ make
Now you can flash the firmware using JLinkExe on Linux.
You can use the LPC54608J512 even to flash the LPC54628:
$ sudo JLinkExe -if SWD -device LPC54608J512 SEGGER J-Link Commander V6.32h (Compiled Jul 5 2018 18:15:02) DLL version V6.32h, compiled Jul 5 2018 18:14:58 Connecting to J-Link via USB...O.K. Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46 Hardware version: V8.00 S/N: 268006167 License(s): FlashBP, GDB OEM: SEGGER-EDU VTref=3.293V Type "connect" to establish a target connection, '?' for help
Run “connect” command:
J-Link> connect Specify target interface speed [kHz]. : 4000 kHz Speed> Device "LPC54608J512" selected. Connecting to target via SWD Found SW-DP with ID 0x2BA01477 Found SW-DP with ID 0x2BA01477 Scanning AP map to find all available APs AP: Stopped AP scan as end of AP map has been reached AP: AHB-AP (IDR: 0x24770011) Iterating through AP map to find AHB-AP to use AP: Core found AP: AHB-AP ROM base: 0xE00FF000 CPUID register: 0x410FC241. Implementer code: 0x41 (ARM) Found Cortex-M4 r0p1, Little endian. FPUnit: 6 code (BP) slots and 2 literal slots CoreSight components: ROMTbl @ E00FF000 ROMTbl: E000E000, CID: B105E00D, PID: 000BB00C SCS-M7 ROMTbl: E0001000, CID: B105E00D, PID: 003BB002 DWT ROMTbl: E0002000, CID: B105E00D, PID: 002BB003 FPB ROMTbl: E0000000, CID: B105E00D, PID: 003BB001 ITM ROMTbl: E0040000, CID: B105900D, PID: 000BB9A1 TPIU ROMTbl: E0041000, CID: B105900D, PID: 000BB925 ETM Cortex-M4 identified.
Finally flash nuttx.bin using the loadbin command:
J-Link>loadbin ./nuttx.bin 0 Halting CPU for downloading file. Downloading file [./nuttx.bin]... Comparing flash [100%] Done. Erasing flash [100%] Done. Programming flash [100%] Done. Verifying flash [100%] Done. J-Link: Flash download: Bank 0 @ 0x00000000: 1 range affected (360448 bytes) J-Link: Flash download: Total time needed: 3.314s (Prepare: 0.058s, Compare: 0.009s, Erase: 0.991s, Program: 2.245s, Verify: 0.005s, Restore: 0.003s) O.K. J-Link> exit
Reset the board and you should see the touchscreen calibration screen.
Normally NuttX supports internal (Built-In) applications embedded on its firmware. When you run: “nsh> hello” or your application, NuttX look for the application inside the internal flash of the microcontroller and run it.
But NuttX also supports running external applications. These external applications are ELF files. The ELF format is the default executable format used on Linux and almost all Unix OS.
Normally the OS needs to create a Global Symbol Table (AKA: symtab) where the ELF look at to translate the used functions of the ELF binary to memory addresses where these functions exist in the OS.
The “drawback” of this symtab is because it will waste a lot of space inside the flash (firmware) of the OS.
Fortunately NuttX also supports an alternative solution where this symtab is not needed. The ELF binary is created with the fixed memory position of each function address position. The drawback of this solution is the ELF binary is not relocatable, in other words: if you compile a new firmware for your board the existent external ELF binary could to fail because these functions positions are located at a different position now.
You can find the instructions for both options here:
I tested the “no-symtab” option loading an external “hello” from a USB Flash Drive:
NuttShell (NSH) nsh> ls /dev /dev: console null sda ttyS0 nsh> ? help usage: help [-v]  [ dirname help mh set unset ? dd hexdump mount sh usleep basename df kill mv sleep xd break echo ls mw test cat exec mb ps time cd exit mkdir pwd true cp false mkfatfs rm uname cmp free mkrd rmdir umount Builtin Apps: hello nsh> hello Hello, World!! nsh> mount -t vfat /dev/sda /bin nsh> hello Hello world from external binary! nsh>
As you can see initially the internal “hello” program was executed, but after I mounted the USB Flash Drive to /bin the external “hello” takes precedence over the internal.
These are the options I need to get it working:
CONFIG_STM32_OTGFS=y CONFIG_STM32_CCMEXCLUDE=y CONFIG_SCHED_WORKQUEUE=y CONFIG_SCHED_HPWORK=y CONFIG_USBHOST=y CONFIG_USBHOST_ISOC_DISABLE=y CONFIG_USBHOST_MSC=y CONFIG_FS_FAT=y CONFIG_BINFMT_EXEPATH=y CONFIG_PATH_INITIAL="/bin" CONFIG_ELF=y CONFIG_LIBC_ARCH_ELF=y CONFIG_LIBC_EXECFUNCS=y # CONFIG_EXECFUNCS_HAVE_SYMTAB is not set CONFIG_EXAMPLES_HELLO=y CONFIG_NSH_FILE_APPS=y CONFIG_NSH_ARCHINIT=y
Some years ago I show it was possible to copy files to Linux over serial without using zmodem or other protocol: https://acassis.wordpress.com/2012/10/21/how-to-transfer-files-to-a-linux-embedded-system-over-serial/
Today I faced a similar issue, I need to copy a file from host computer to NuttX over serial without using zmodem support.
Then I created a simple 48 bytes file on Linux side and ran these commands on NuttX console (using minicom) :
NuttShell (NSH) nsh> mount -t vfat /dev/sda /mnt nsh> dd if=/dev/console of=/mnt/test.txt bs=16 count=3
Now on minicom type: Ctrl + A – Y to select a file to paste.
It worked fine, see:
nsh> ls -l /mnt /mnt: -rw-rw-rw- 48 test.txt nsh> nsh> cat /mnt/test.txt This is a small test! Just to prove the idea!!!
Now I decided to send a bigger file (4KiB) :
I used the COPYING file of NuttX, just cutting it to 4KiB:
$ sudo dd if=COPYING of=/COPYING bs=1 count=4096
Then on minicom:
nsh> dd if=/dev/console of=/mnt/COPYING bs=64 count=64 Ctrl + A - Y
After selecting the file I noticed that the TXD LED on USB/Serial adapter was blinking at each 1 second. So after about 64 seconds it transfered the 4KiB file.
nsh> ls -l /mnt /mnt: -rw-rw-rw- 48 test.txt -rw-rw-rw- 4096 COPYING nsh> cat /mnt/COPYING COPYING -- Describes the terms under which Nuttx is distributed. A copy of the BSD-style licensing is included in this file. In my words -- I believe that you should free to use NuttX in any environment, private, private, commercial, open, closed, etc. provided only that you repect the modest copyright notices as ... uIP ^^^ Many lower-level networking components of NuttX derive from uIP which has a similar BSD style
That is it! It is not the faster transfer solution but it proved to work.
I think this same approach should have worked on Linux at that time.
I’m trying to get the CC2564MODA working with NuttX, then I decided to test it with Linux’s bluez first to guarantee it is working.
I used a CP2101 USB/Serial dongle, connected RXD to BUTX1, TXD to BURX1, CTS to BURT1, RTS to BUCT1.
Unfortunately the CC2564B will not work correctly if you don’t load a patch to fix its internal firmware. I download the file cc256xb_bt_sp_v1.6.zip from TI site extracted and copied it to:
$ sudo cp ~/CC2564/CC256XB_BT_SP/v1.6/initscripts-TIInit_6.7.16_ble_add-on.bts /lib/firmware/ti-connectivity/TIInit_6.7.16.bts
Next step is to use hciattach:
$ sudo hciattach -s 115200 /dev/ttyUSB0 texas 115200 Found a Texas Instruments' chip! Firmware file : /lib/firmware/ti-connectivity/TIInit_6.7.16.bts Loaded BTS script version 1 Device setup complete
Open a new linux terminal and run:
$ sudo btmon Bluetooth monitor ver 5.37 = New Index: B0:B4:48:F4:A1:54 (BR/EDR,UART,hci1) [hci1] 0.270465 = Open Index: B0:B4:48:F4:A1:54 [hci1] 0.270467 = Index Info: B0:B4:48:F4:A1:54 (Texas Instruments Inc.) [hci1] 0.270467 = New Index: E0:06:E6:CF:FD:CE (BR/EDR,USB,hci0) [hci0] 0.270468
Open another terminal and run:
$ sudo btmgmt --index 1 [hci1]# auto-power Found controller with index 1
Note that I used “–index 1” instead “–index 0” because the BOOST-CC2564MODA was included as “hci1” (my laptop has Bluetooth internally).
Finally we can search for BLE devices:
[hci1]# find -l Discovery started hci1 type 6 discovering on hci1 dev_found: BC:6A:29:AB:3F:46 type LE Public rssi -50 flags 0x0000 AD flags 0x05 eir_len 3 hci1 type 6 discovering off [hci1]#