Author: acassis

the moon… beautiful! oh yeah!

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()

And run:

$ lua hello.lua

Just it!

Running NuttX on LPCXpresso54628 OM13098

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[1]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x24770011)
Iterating through AP map to find AHB-AP to use
AP[0]: Core found
AP[0]: 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[0] @ E00FF000
ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS-M7
ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 003BB002 DWT
ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 002BB003 FPB
ROMTbl[0][3]: E0000000, CID: B105E00D, PID: 003BB001 ITM
ROMTbl[0][4]: E0040000, CID: B105900D, PID: 000BB9A1 TPIU
ROMTbl[0][5]: 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.

And then:

Running external application on NuttX

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:

http://www.nuttx.org/doku.php?id=wiki:nshhowtos:elf-addon

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

Copying files to NuttX over serial (the slow way)

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.

Using BOOST-CC2564MODA with bluez on Linux

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]#