Accessing Internet from NuttX PPP Connection

As you know I was facing some issues to get PPPD connection working:

https://acassis.wordpress.com/2019/02/10/debugging-pppd-using-quectel-m95-on-samd21-board/

Then I received a comment from Vladimir Novikov (thank you!) at that post commenting the issues was introduced some time ago at this commit:

https://bitbucket.org/nuttx/apps/commits/cddfda99f0a519681b894b7a12560406c4372cfb

And he suggested me adding this line to lcp.c:

          tptr = bptr;
+          bptr += 4;
          error = 0;

Before testing this suggestion I received an email from Quectel Brasil support (thanks Micael Lisboa) suggesting run this AT cmd:

AT+QACCM=0,0

Micael’s suggestion worked fine.

But I decided to contact the author of the modification (Xiao Xiang) and he explained that the bptr was already increased by 4 compared to original code. And in fact he was correct.

Anyway I decided to test Vladimir’s suggestion that also worked. So we need to investigate it in more details to understand what is happening.

BTW since the AT command was working for me I decided to follow with my tests.

After PPPD connection was established it was getting IP:

nsh> ifconfig
ppp0    Link encap:TUN at UP
        inet addr:100.75.210.38 DRaddr:192.168.254.254 Mask:0.0.0.0

But ping command was crashing:

nsh> ping 8.8.8.8

PINGup_assert: Assertion failed at file:armv6-m/up_hardfault.c line: 139
up_registerdump: R0: 20000a78 00000000 00000000 00004a64 20000819
20006f8c 20000a78 00000000
up_registerdump: R8: 00000000 00000000 00000000 00000000 20000414
20003fa0 0000b54f 00009dd6
up_registerdump: xPSR: 21000000 PRIMASK: 00000000
up_dumpstate: sp:         20003ee8
up_dumpstate: stack base: 20004040
up_dumpstate: stack size: 000007e4
up_stackdump: 20003ee0: 2000385c 000009c5 00000000 00000000 00000000
20000414 20003fa0 0000b54f
up_stackdump: 20003f00: 00009dd6 00000000 00013437 00000000 00000000
00000000 20000000 00000018
up_stackdump: 20003f20: 00000003 20003f58 00000000 00000c03 00000018
000010e3 20001e5c 00000ab9
up_stackdump: 20003f40: 00000000 00000000 00000000 20000a78 00000000
000002ab 20003fa0 00000000
up_stackdump: 20003f60: 20000819 20006f8c 20000a78 00000000 00000000
00000000 00000000 00000000
up_stackdump: 20003f80: 20000a78 00000000 00000000 00004a64 20000414
0000b54f 00009dd6 21000000
up_stackdump: 20003fa0: 20000a78 00004000 20006f8c 00004000 2000077c
00009d5d 00000000 0000b54f
up_stackdump: 20003fc0: 00000000 20000a78 00004000 00000000 20000a78
0000fd1d 20001f2c 0000b7f1
up_stackdump: 20003fe0: 00000000 0000b34b 200007f0 20000a74 00000000
0000ff3f 200007f8 00001ee9
up_stackdump: 20004000: 00000000 00001bcf ffffffff 00000000 20001de8
00020000 00000000 00000101
up_stackdump: 20004020: 00000000 00000000 00000000 0000144b 00000101
0000140f 00000000 00000000

After much debugging and with Greg’s help I noticed the “srcipaddr” was not aligned:

(gdb)
194       net_ipv4addr_hdrcopy(ipv4->srcipaddr, &dev->d_ipaddr);
(gdb) p &ipv4->srcipaddr
$1 = (uint16_t (*)[2]) 0x20000c41 
(gdb) p &dev->d_ipaddr
$2 = (in_addr_t *) 0x20000eac 

See, it was at 0x20000c41 that is an odd address position.

Almost instantly Greg found the source of this issue: it was the TUN/TAP driver that was defining the read_buf at odd position:

 142   bool              read_wait;
 143
 144   uint8_t           read_buf[CONFIG_NET_TUN_PKTSIZE];
 145   size_t            read_d_len;
 146   uint8_t           write_buf[CONFIG_NET_TUN_PKTSIZE];

Moving the “size_t read_d_len;” to the line above read_buf[] fixed the issue!

Now ping is not crashing and I was able to ping the Google’s DNS 8.8.8.8:

nsh> ping 8.8.8.8
PING 8.8.8.8 56 bytes of data
56 bytes from 8.8.8.8: icmp_seq=0 time=1010 ms
56 bytes from 8.8.8.8: icmp_seq=2 time=1260 ms
56 bytes from 8.8.8.8: icmp_seq=2 time=370 ms
56 bytes from 8.8.8.8: icmp_seq=4 time=1080 ms
56 bytes from 8.8.8.8: icmp_seq=4 time=490 ms
56 bytes from 8.8.8.8: icmp_seq=5 time=870 ms
56 bytes from 8.8.8.8: icmp_seq=6 time=560 ms
56 bytes from 8.8.8.8: icmp_seq=7 time=930 ms
56 bytes from 8.8.8.8: icmp_seq=8 time=640 ms
56 bytes from 8.8.8.8: icmp_seq=9 time=1010 ms
10 packets transmitted, 10 received, 0% packet loss, time 10100 ms

Learning the new NuttX PPPD/CHAT script

Probably you already know it, but I will reinforce the idea: “Changing is the only constant thing!”

So we need to change and to adapt all the time.

Why am I saying these “non-sense” words? Let me explain…

This is a sample of the old NuttX PPPD/Chat script:

static struct chat_script_s connect_script =
{
  .timeout = 30,
  .lines =
  {
    {"AT",                                 "OK"},
    {"AT+CGDCONT = 1,\"IP\",\"internet\"", "OK"},
    {"ATD*99***1#",                        "CONNECT"},
    {0, 0}
  },
};

static struct chat_script_s disconnect_script =
{
  .timeout = 30,
  .lines =
  {
    {"ATZ",                                "OK"},
    {0, 0}
  },
};

Very easy to understand, don’t you think? Basically you have the AT command and the expected result.

But it had a drawback, you had a structure with internal parameters fields (i.e. timeout) and AT commands strings.

Now the new script is basically a sequence of string lines, or basically a single string:

static FAR const char connect_script[] =
  "ECHO ON "
  "TIMEOUT 30 "
  "\"\" ATE1 "
  "OK AT+CGDCONT=1,\\\"IP\\\",\\\"internet\\\" "
  "OK ATD*99***1# "
  "CONNECT \\c";

static FAR const char disconnect_script[] =
  "\"\" ATZ "
  "OK \\c";

Unfortunately this is not that simple: we have internal commands: “ECHO”, “TIMEOUT”, etc and AT string commands. And internal commands don’t expect a return string as AT commands do.

So, what should be the expected result string of ATE1 command? If you think it is an empty string “”, using the original script logic, you are wrong. The expect result is in the below line “OK AT+CGDCONT=1…”, yes “ATE1” expects an “OK” that is in the below line.

Same way “ATD*99***1#” doesn’t expect an “OK”, but a “CONNECT” that is in the next line.

It is a little bit complex, it should exist a documentation explaining how it works. At least this post make a brief introduction to this subject.

Using MODBUS RTU with NuttX

MODBUS is an old protocol used on industrial automation. Although it is an “old” protocol, it still used on many industrial devices.

There are many articles about this protocol in the Internet, but most are very shallow. This guy has a fair introduction about MODBUS:

https://www.lammertbies.nl/comm/info/modbus.html

I spent some time (few days) to get it working on NuttX. First I implemented the DIR pin control for SAMD21 microcontroller and submitted to mainline: https://bitbucket.org/nuttx/nuttx/commits/a34c9733bcac707be803a27c91fec7406bda310b and also fixed a serial issue that was preventing the serial driver from working: https://bitbucket.org/nuttx/nuttx/commits/db0b9b7c34ddcf098059bb51d73d03d45b3f69b7

Then after spending many hours trying to get my computer communicating with SAMD21 board I discovered that the guilt was the USB/RS485 Dongle I was using.

Replacing it with a common USB/Serial (CP2102) and with a MAX485 module, like this: https://www.aliexpress.com/item/2PCS-MAX485-module-RS-485-module-TTL-to-RS-485-module/2055143247.html , solved the issue.

I connected this way:

+-----------------------------------------+
| USB/Serial (CP2102)   |   MAX485 Module |
+-----------------------+-----------------+
|          RXD          |       RO        |
|          TXD          |       DI        |
|          RTS          |     DE + RE     |
|          GND          |       GND       |
|          +5V          |       VCC       |
+-----------------------+-----------------+

This is the listing of features enabled on NuttX:

Serial SERCOM5 Config:

CONFIG_SAMD2L2_SERCOM5_ISUSART=y
CONFIG_USART5_RS485MODE=y
CONFIG_USART5_RS485_DIR_POLARITY=1

We need support to POLL (so don’t select the disable POLL)

# CONFIG_DISABLE_POLL is not set

FreeModbus config:

CONFIG_MODBUS=y
CONFIG_MB_FUNC_HANDLERS_MAX=16
CONFIG_MODBUS_SLAVE=y
CONFIG_MB_ASCII_ENABLED=y
CONFIG_MB_RTU_ENABLED=y
# CONFIG_MB_TCP_ENABLED is not set
CONFIG_MB_ASCII_TIMEOUT_SEC=1
CONFIG_MB_ASCII_TIMEOUT_WAIT_BEFORE_SEND_MS=0
CONFIG_MB_FUNC_OTHER_REP_SLAVEID_BUF=32
CONFIG_MB_FUNC_OTHER_REP_SLAVEID_ENABLED=y
CONFIG_MB_FUNC_READ_INPUT_ENABLED=y
CONFIG_MB_FUNC_READ_HOLDING_ENABLED=y
CONFIG_MB_FUNC_WRITE_HOLDING_ENABLED=y
CONFIG_MB_FUNC_WRITE_MULTIPLE_HOLDING_ENABLED=y
CONFIG_MB_FUNC_READ_COILS_ENABLED=y
CONFIG_MB_FUNC_WRITE_COIL_ENABLED=y
CONFIG_MB_FUNC_WRITE_MULTIPLE_COILS_ENABLED=y
CONFIG_MB_FUNC_READ_DISCRETE_INPUTS_ENABLED=y
CONFIG_MB_FUNC_READWRITE_HOLDING_ENABLED=y
# CONFIG_MODBUS_MASTER is not set

Modbus example:

CONFIG_EXAMPLES_MODBUS=y
CONFIG_EXAMPLES_MODBUS_PORT=0
CONFIG_EXAMPLES_MODBUS_BAUD=38400
CONFIG_EXAMPLES_MODBUS_PARITY=2
CONFIG_EXAMPLES_MODBUS_REG_INPUT_START=1000
CONFIG_EXAMPLES_MODBUS_REG_INPUT_NREGS=4
CONFIG_EXAMPLES_MODBUS_REG_HOLDING_START=2000
CONFIG_EXAMPLES_MODBUS_REG_HOLDING_NREGS=130

After compiling and flashing the nuttx.bin, run the modbus:

NuttShell (NSH)
nsh> modbus -e

From computer side I used the “mbpoll” program:

$ mbpoll -a 10 -b 38400 -t 3 -r 1000 -c 4 /dev/ttyUSB0 -R
mbpoll 1.4-11 - FieldTalk(tm) Modbus(R) Master Simulator
Copyright © 2015-2019 Pascal JEAN, https://github.com/epsilonrt/mbpoll
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; type 'mbpoll -w' for details.

Protocol configuration: Modbus RTU
Slave configuration...: address = [10]
start reference = 1000, count = 4
Communication.........: /dev/ttyUSB0,      38400-8E1
t/o 1.00 s, poll rate 1000 ms
Data type.............: 16-bit register, input register table

-- Polling slave 10... Ctrl-C to stop)
[1000]: 	40122 (-25414)
[1001]: 	0
[1002]: 	0
[1003]: 	0
-- Polling slave 10... Ctrl-C to stop)
[1000]: 	832
[1001]: 	0
[1002]: 	0
[1003]: 	0
-- Polling slave 10... Ctrl-C to stop)
[1000]: 	24996
[1001]: 	0
[1002]: 	0
[1003]: 	0
-- Polling slave 10... Ctrl-C to stop)
[1000]: 	3747
[1001]: 	0
[1002]: 	0
[1003]: 	0

This is an image of pulseview sniffing the bus:

That is it, very easy after you get it working.

Thanks Daniel Carvalho for the help and suggestions to fix the issue.

I used this online tool to check my modbus packets:

http://modbus.rapidscada.net

How to use NuttX I2C Scan features

First you need to enable I2C to your MCU, and these additional options:

CONFIG_I2C=y
CONFIG_I2C_DRIVER=y
CONFIG_SYSTEM_I2CTOOL=y
CONFIG_I2CTOOL_MINBUS=0
CONFIG_I2CTOOL_MAXBUS=5
CONFIG_I2CTOOL_MINADDR=0x03
CONFIG_I2CTOOL_MAXADDR=0x77
CONFIG_I2CTOOL_MAXREGADDR=0xff
CONFIG_I2CTOOL_DEFFREQ=400000

Also in your board initialization you need to register the right I2C Bus you want to use. For example, I want to use the I2C Bus 3:

rtcinfo("Initialize I2C%d\n", 3);
i2c = sam_i2c_master_initialize(3);
if (!i2c)
{
rtcerr("ERROR: Failed to initialize I2C%d\n", 3);
return -ENODEV;
}

/* Register the I2C to get the "nsh> i2c bus" command working */

ret = i2c_register(i2c, 3);
if (ret < 0)
{
rtcerr("ERROR: Failed to register I2C%d driver: %d\n", bus, ret);
return -ENODEV;
}

If everything compiled fine you will have:

nsh> i2c bus
BUS EXISTS?
Bus 0: NO
Bus 1: NO
Bus 2: NO
Bus 3: YES
Bus 4: NO
Bus 5: NO
nsh>

nsh> i2c dev -b 3 0x00 0x77
0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f  
00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --   
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --   
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --   
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --   
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --   
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --   
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 6f   
70: -- -- -- -- -- -- -- --                           
nsh>

These two addresses are the EEPROM (0x50) and the RTC (0x6f) that I have on my board.

Sheding some (infrared) light on MLX90614

After implementing the MLX90614 driver for NuttX I noticed that although the write command to change the device I2C address in the EEPROM was reporting success, after the power cycle the new address was not working. Worst: even the previous address was not working.

Basically the device appears damaged and didn’t respond to any I2C command.

Then doing my research I discovered a Melexis document about SMBus communication:

Click to access MLX90614_SMBus.pdf

In this document I noticed they are using the address 0x00 instead of the default 0x5a address. After modifying the driver to use the 0x00 address the device accepted the new command.

There are many discussing about this subject on Arduino and similar forum:

https://chrisramsay.co.uk/posts/2014/09/arduino-and-multiple-mlx90614-sensors/
http://forum.arduino.cc/index.php?topic=54170.msg539601#msg539601
https://forum.mikroe.com/viewtopic.php?f=178&t=67842
http://wiki.wiring.co/wiki/Connecting_Infrared_Thermometer_MLX90614_to_Wiring

Note that someone discovered that using a brute force CRC approach eventually will work and everybody decided to copy it. Too bad guys!

The MLX90614 uses CRC8-CCITT standard to check if data are correct, so any CRC8-CCITT implementation will work, for example this one: https://3dbrew.org/wiki/CRC-8-CCITT

Now on NuttX you can call the mlx90614 example application to change the device’s I2C address this way: (changing from default 0x5a to 0x3a)

nsh> mlx90614 0x3a
Address 0x3a stored on your device!
Please do a power cycle and update the I2C board address!
nsh>

Checking the CRC-8 PEC byte of MLX90614

I am creating a NuttX device driver for Melexis MLX90614 and it is a nice adventure.

First I downloaded the adafruit lib and tested it on Arduino Uno just to confirm the sensor was working, but I didn’t look the source code because I always prefer to read the datasheet and implement the driver from scratch.

All things fine, the mlxtest example worked correctly and I got the ambient temperature and the object temperature printed correctly.

Then I created the driver and decided to test it on STM32F103, but discovered that I2C_TRANSFER() for STM32F103 is broken. No problem, let to test it on STM32F4Discovery board:

nsh> dd if=/dev/thermo0 of=/dev/null bs=2 count=1
mlx90614_read_word: value[0]: 0xDF | value[1]: 0x3A | value[2]: 0xCF | ret: 0

Let see in the logic analyzer to confirm:

Very good! But how to check if CRC-8 PEC field (third received byte: 0xCF) is correct?

I found this nice online CRC calculator:

http://www.sunshine2k.de/coding/javascript/crc/crc_js.html

But putting all values as suggested in the datasheet didn’t work:

0x5A 0x06 0x5A 0xDF 0x3A
Result CRC value: 0x2F

Then just web searching for: MLX90614 PEC CRC-8 example

Returned me this thread:

https://stackoverflow.com/questions/20554869/implementing-crc8-on-arduino-to-write-to-mlx90614

The “thb” guy saved me:

“I haven’t checked your CRC implementation but there is a mistake in the MLX datasheet or at least it’s badly written. You have to include all the I2C frame’s data for the PEC’s calculation not just the replied data. For a read word command you have to include [SA_W, Command, SA_R, LSB, MSB] and for a write word command [SA_W, Command, LSB, MSB]. So, for their first example the calculation must be made on [ 0xB4, 0x07, 0xB5, 0xD2, 0x3A ] and not just on [ 0xD2, 0x3A ] and this way you get the expected 0x30.”

What this guy is saying is: we need to include all the bits of the Slave Address, the address needs to be seen as 8-bit including the the less significant bit Write or Read. So I2C Write at address 0x5A is seen as 0xB4 and I2C Read is seen as 0xB5 (pay attention at bits over the “5A” in the logic analyzer image above).

So, let to try his idea:

0xB4 0x06 0xB5 0xDF 0x3A
Result CRC value: 0xCF

Bingo!

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:

Using FAT32 long file names on NuttX

NuttX supports FAT32 with long file names, but there is some details that you need to know to get it working. I will share here the issues that I was facing and how I fixed it.

The original FAT uses 8.3 (8 chars for name and 3 chars for extension), but it can supports files with up to 255 characters (including the extension).

To use it we need to enable long file name support in the menuconfig:

 File Systems  --->
     [*] FAT file system
     [*]   FAT upper/lower names
     [*]   FAT long file names             -------->  (CONFIG_FAT_LFN=y)
     (255)   FAT maximum file name size    -------->  (CONFIG_FAT_MAXFNAME=255)

Initially I will mount an empty SDCard to do my tests:

NuttShell (NSH)

nsh> mount -t vfat /dev/mmcsd0 /mnt

nsh> ls /mnt
/mnt:

nsh>

Let’s to create a small 8.3 file that will be renamed:

nsh> echo "Small file" > /mnt/tinyfile.txt
nsh> ls -l /mnt/tinyfile.txt
 -rw-rw-rw-      12 /mnt/tinyfile.txt
nsh>

Now I will try to rename it to a file with a long name:

nsh> mv /mnt/tinyfile.txt /mnt/this_is_a_file_with_a_long_name_jnsh>

Strange, while I was typing “this_is_a_file_with_a_long_name_just_for_test.txt” the typing was interrupted and the nsh> appeared.

Let see if the file was renamed:

nsh> ls /mnt
/mnt:
 this_is_a_file_with_a_long_name_

Then I remembered that the max line size of NSH was just 60 (CONFIG_NSH_LINELEN=60), I will increase it to 300 characters:

Application Configuration  --->
    NSH Library  --->
          Command Line Configuration  --->
              (300) Max command line length    -------->  (CONFIG_NSH_LINELEN=300)

I will create a tinyfile.txt again and try to rename it:

nsh> mv /mnt/tinyfile.txt /mnt/this_is_a_file_with_a_long_name_just_for_test.txt
nsh> 

Right, now the nsh prompt accept the enter the name, but let see if the file was created correctly:

nsh> ls /mnt
/mnt:
 this_is_a_file_with_a_long_name_
 this_is_a_file_with_a_long_name_

Whoa, it created two files with same name? How it is possible? Don’t worry, these files are different. Opening the SDCard in the Linux I can see:

this_is_a_file_with_a_long_name_j
this_is_a_file_with_a_long_name_just_for_test.txt

So, the LS command is showing only 32 characters. After some investigation I discovered that CONFIG_NAME_MAX=32 was the issue. Let to increase it to 255:

RTOS Features  --->
    Files and I/O  --->
        (255) Maximum size of a file name    -------->  (CONFIG_NAME_MAX=255)

Now I can see the files:

nsh> ls /mnt
/mnt:
 this_is_a_file_with_a_long_name_j
 this_is_a_file_with_a_long_name_just_for_test.txt

My next step is to create a file with 255 characters, like this:

this_file_will_have_a_big_filename_to_verify_how_to_work_with_files_with_long_names_our_test_need_to_have_the_max_filename_size_supported_by_fat32_that_means_it_could_have_up_to_255_characters_including_the_extension_in_the_filename_so_here_we_arrived.txt

nsh> echo "Test" > /mnt/this_file_will_have_a_big_filename_to_verify_how_to_work_with_files_with_long_names_our_test_need_to_have_the_max_filename_size_supported_by_fat32_that_means_it_could_have_up_to_255_characters_including_the_extension_in_the_filename_so_here_we_arrived.txt
nsh> ls /mnt
/mnt:
 this_file_will_have_a_big_filename_to_verify_how_to_work_with_files_with_long_names_our_test_need_to_have_the_max_filename_size_supported_by_fat32_that_means_it_could_have_up_to_255_characters_including_the_extension_in_the_filename_so_here_we_arrived.txt
nsh> 

Very nice! It worked correctly.

As you can see NuttX is similar to Linux kernel, many features depends on other features’ configuration. They are inter-dependent.

NuttX now supports LVGL

If you follow my blog you know my previous post was about LVGL. Today I want to announce that LVGL was ported to run on NuttX.

Gábor Kiss-Vámosi the author of LVGL ported it to run on top of NuttX, using NuttX’s framebuffer support.

It is in early stage, it needs more integration to support touchscreen, mouse, keyboard and maybe even audio subsystem integration, but it was the first step!

A picture is worth a thousand words:

Converting ELF to BIN

This is the way to use objcopy to convert an ELF file to Binary:

arm-none-eabi-objcopy -S -O binary file.elf file.bin