• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Update /dev/ttyAMA0 UART pinout
#1
Hi,

I am using the netFIELD Connect gateway to communicate with a UART based external module, in order to do that I would like to change the default overlay files in a way that /dev/ttyAMA0 UART interface will be used by my application instead of being used for the bluetooth communication?
I do know how to perform this procedure on a standard RPI but is it possible on the netFIELD?

Thanks very much.

Alex
  Reply
#2
Hi Alex,

all I am writing is just speculation since I don't know exactly. Responsible for this setting is the config.txt file as with Raspbian OS.

I know our netFIELD OS is a secured Linux which checks many details during the boot time for consistency. Any modifications outside the normal ruleset are "punished" and lead to a non booting device. But with the config.txt file I am not sure.

But since the basis of this Hilscher OS is of course the Raspbian Linux OS/Kernel you will find the config.txt file usually used to configure the overlays and physical settings on the SD card's partition "boot". I my opinion this config.txt file can be modified in accordance to the Raspberry Organizations specification under https://www.raspberrypi.org/documentatio...onfig-txt/.

I see two possibilities:

1. Open the device case, remove the SD card and mount it in a separate Linux machine to execute this kind of config.txt file modification on the boot partition.

2. Call the following code to mount the SD card's boot partition in your netFIELD Connect Linux temporarily

Code:
mkdir /tmp/boot
sudo mount /dev/mmcblk0p1 /tmp/boot
sudo vi /tmp/boot/config.txt
... make you edits
sudo reboot

Tell me more about the UART module. Is it the Hilscher UART module? In this case this module contains an EEPROM with overlay informations about its setting. If it is recognized by the netFIELD OS the EEPROM configuration adds to the config.txt setting of the main Kernel and may override these. So please take this into account.

Thx

Armin
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#3
Hi Armin,

This is very helpful, I will try to edit the config.txt manually as you suggest and update on the result.
One more question, assuming we would want to implement our own UART module, would it be possible to get the EEPROM memory map used by Hilscher module as a reference?

BR,

Alex
  Reply
#4
Sure Alex I see no problem sending you the details. But just the binary content is not what you need. You need the source files of the binary.

But a step back first.  You need to understand the principle of device trees and of HAT modules which are just an alias for the NPIX modules. The general information about all this is described here https://www.raspberrypi.org/documentatio...ce-tree.md.

Designing own HATs (NPIX), the EEPROM content, compiler to generate a binary image is all described here https://github.com/raspberrypi/hats.

If you want to test writing to an EEPROM connected to the pins ID_SD and ID_SC pins you need to enable the i2c0 interface on your netFIELD Connect gateway first. So if you were successful in modifying the config.txt then also add the following line to it and reboot.
Code:
dtparam=i2c_vc=on

This line is for standard Raspberry pi and should work on netFIELD Connect as well in my eyes. After the reboot you will have the device /dev/i2c-0 additionally available on your system.

How to proceed further from a user point of view can be best explained by users as this guy here https://www.raspberrypi.org/forums/viewt...p?t=108134 and how to come to an eep file for the EEPROM, how to compile it and how to flash it.

Some remarks to this link above. 
  • The folder will be named "hats" and not "hat" like it is states
  • The site also says to flash data to the EEPROM use this command "sudo ./eepflash -w -f=myhat.eep -t=24c32" but the file is named "eepflash.sh" so the final command to use is "sudo ./eepflash.sh -w -f=myhat.eep -t=24c32"
The github link speaks about a file named eeprom_settings.txt. This file configures just the basic GPIOs setting adjusted through the EEPROM. The file for our RS232 module is appended. Also the dtbo file as zip.

The source of the *.dtbo file which is the *.dts file I dont have right now and is requested from our development team. I will send it to you when I have it.

Thx
Armin


Attached Files
.txt   1322012R1_NIOT-E-NPIX-RS232_eeprom_settings_ng.txt (Size: 2.98 KB / Downloads: 5)
.zip   nxpi_rs232.zip (Size: 623 bytes / Downloads: 1)
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#5
Here is the missing *.dts file for the NPIX-RS232 module

Examples of other dts files can be found on the internet like this one https://tinymicros.com/wiki/Raspberry_Pi...figuration. It is heading in your direction to use UART0 instead of UART1.


Attached Files
.zip   nxpi_rs232.zip (Size: 469 bytes / Downloads: 2)
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#6
(January-17th-2021, 08:05 PM)Armin@netPI Wrote: Hi Alex,

all I am writing is just speculation since I don't know exactly. Responsible for this setting is the config.txt file as with Raspbian OS.

I know our netFIELD OS is a secured Linux which checks many details during the boot time for consistency. Any modifications outside the normal ruleset are "punished" and lead to a non booting device. But with the config.txt file I am not sure.

But since the basis of this Hilscher OS is of course the Raspbian Linux OS/Kernel you will find the config.txt file usually used to configure the overlays and physical settings on the SD card's partition "boot". I my opinion this config.txt file can be modified in accordance to the Raspberry Organizations specification under https://www.raspberrypi.org/documentatio...onfig-txt/.

I see two possibilities:

1. Open the device case, remove the SD card and mount it in a separate Linux machine to execute this kind of config.txt file modification on the boot partition.

2. Call the following code to mount the SD card's boot partition in your netFIELD Connect Linux temporarily

Code:
mkdir /tmp/boot
sudo mount /dev/mmcblk0p1 /tmp/boot
sudo vi /tmp/boot/config.txt
... make you edits
sudo reboot

Tell me more about the UART module. Is it the Hilscher UART module? In this case this module contains an EEPROM with overlay informations about its setting. If it is recognized by the netFIELD OS the EEPROM configuration adds to the config.txt setting of the main Kernel and may override these. So please take this into account.

Thx

Armin

Hi Armin,

I took over this task of enabeling the on the netpi.
I have two devices on my desk:
1. netpi
2. field connect.
I intend to use the field connect as a devenviorment env to create my own image based on your raspbian image.
fisrt thing I tried to do is to modify the boot partition to support the ttyAMA0. (I have done it on netpi and field connect)

with field connect:
1. I was able to test the ttyAMA0 is running as expected on the host file system.
2. cannot expose the /dev/ttyAMA0 on raspbian container you provided. so I am unable to test. I have trided running docker command similar to your instruction in docker hub:
[font="Ubuntu Mono", consolas, monaco, monospace]docker run -d --privileged --network=host --restart=always -e SSHPORT=22 --device=/dev/ttyAMA0:/dev/ttyAMA0 --device=/dev/vcio:/dev/vcio --device=/dev/vchiq:/dev/vchiq --device=/dev/vc-mem:/dev/vc-mem -p 22:22/tcp hilschernetpi/netpi-raspbian[/font]

with netpi:
1. using portainer i able to expose /dev/ttyAMA0. when running the test application there is no communication with the tested device.

I have few questions:
1. with field connect what do I need to do to be able to expose /dev/ttyAMA0 it is different from portainer.
2. do you have any guess what can cause the ttyAMA0 not to work in the raspbian container ?
3. I have noticed there is a boot partiion inside the container. I am not sure why is it provided ? can you clarify ? ( if it is used when container is loaded I guess I need to make the device tree modification also inside this directory as well) 

Regards,

Roy
  Reply
#7
The question with "netFIELD Connect" gateway running our original netFIELD OS with Hilschers original SD card the answer is very very easy:

Code:
docker run -d --privileged --network=host --restart=always -e SSHPORT=22 -p 22:22/tcp hilschernetpi/netpi-raspbian

Since netFIELD Connect gateway is supporting 100% orginial Docker without any limits just using the flag "--privileged" is enough to map ALL devices from the host machine into the container automatically. This is a 1:1 relationship. This makes using devices on netFIELD Connect very very easy since there is no need to map discrete /DEV/... manually any more as with netPI.

So call the list command "ls /DEV/" on the host Linux  and then call the list command in the container "ls /DEV/" and you will receive both times the very same result and you will see all devices mapped in the container. This is all you need to do.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#8
To your question about "why the ttyAMA0 is not working in the container" on netPI. As you know on netPI the /dev/ttyAMA0 is configured to be used as UART interface for the onboard Wifi/bluetooth chip. I am pretty sure on netPI changing the config.txt file is not possible at all so that on netPI the physical interface /dev/ttyAMA0 is still running as UART for the wifi/bluetooth chip. The UART modes are descibed here: https://www.raspberrypi.org/documentatio...on/uart.md

So back to your question. You will be able to map the /dev/ttyAMA0 into the container but it is running in the wrong mode. I have doubts that "first thing I tried to do is to modify the boot partition to support the ttyAMA0. (I have done it on netpi and field connect)" works on netPI. It has multiple copies of the config.txt file and the one you edited may not be the correct one. I have never tried it myself to change anything on netPI config.txt file. On netFIELD Connect gateway this may be different.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#9
I have one question concerning netFIELD Connect gateway. Why don't you put the orginal SD card of this device aside and use a brand new one and load the original Raspbian OS onto it and insert this one into the netFIELD Connect gateway. Then you have the best development environment ever. And if you then follow this link here https://www.raspberrypi.org/blog/docker-...pberry-pi/ you post install then also Docker and everything is setup fine for a development.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#10
(June-15th-2021, 11:42 AM)Armin@netPI Wrote: I have one question concerning netFIELD Connect gateway. Why don't you put the orginal SD card of this device aside and use a brand new one and load the original Raspbian OS onto it and insert this one into the netFIELD Connect gateway. Then you have the best development environment ever. And if you then follow this link here https://www.raspberrypi.org/blog/docker-...pberry-pi/ you post install then also Docker and everything is setup fine for a development.

I am not worried about the dev env. 
Our cusotmer want to work with netPi and not netfield. currently I am trying to see netPi is working just as proof of concept.
your last answer is not clear enough you think I will be able to work with raspbian container exposing /dev/ttyAMA0 on Netpi.
if I would have the RS232 expension(with the eeprom) then the overlay will work as expected ?

Regards,

Roy
  Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)