• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Update /dev/ttyAMA0 UART pinout
#11
Oh Roy to be honest ... I do not know it how the exact boot behavior of the netPI OS really is in cases where there is a conflict between the settings made in the config.txt file compared to the settings in the EEPROM of the NPIX/HAT modules and which one finally wins.

What I can definitively say is that we are taking the sources from the original Raspbian OS and recompile it as netPI OS. So it just has a Hilscher touch ... but main behaviour of both OSs are the very same. So if Raspbian OS does not support resolving conflicts between config.txt and EEPROM settings, then our netPI OS can't be better than the behaviour of the official Raspbian OS. So to your question: "if I would have the RS232 expension(with the eeprom) then the overlay will work as expected" ... I cannot guarantee it since I have never every tested it what happens if the original config.txt says /dev/ttyAMA0 goes to UART for Wifi/Bluetooth and then an EEPROM comes and say /dev/ttyAMA0 goes to standard UART via the standard tx/rx pins put on the NPIX slot. Today all our NPIX modules are using the mini UART like it is configured via the standard config.txt

Do you know how a standard Raspberry Pi behaves on this setting when using a HAT module with EEPROM? Cause then the same behaviour will be on netPI.

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

  Reply
#12
(June-15th-2021, 11:24 AM)Armin@netPI Wrote: 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.

Thanks. its working.
Now I am able to work with my device from inside the container in a netfield connect device. 
Question remains how can I enable the same device on Netpi ? modifying config.txt in boot partition is not ehough.

Regards,

Roy
  Reply
#13
"modifying config.txt in boot partition is not ehough." ... yes this might be possible since we had several security settings with netPI ... but we learned from the past during the last years and get more "open" as you can see with netFIELD Connect which as an SSH service activate for example.

The only thing I could try out is where else there is the config.txt file on netPI that is responsible for the boot sequence. I will let you know
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#14
(June-15th-2021, 12:03 PM)Armin@netPI Wrote: Oh Roy to be honest ... I do not know it how the exact boot behavior of the netPI OS really is in cases where there is a conflict between the settings made in the config.txt file compared to the settings in the EEPROM of the NPIX/HAT modules and which one finally wins.

What I can definitively say is that we are taking the sources from the original Raspbian OS and recompile it as netPI OS. So it just has a Hilscher touch ... but main behaviour of both OSs are the very same. So if Raspbian OS does not support resolving conflicts between config.txt and EEPROM settings, then our netPI OS can't be better than the behaviour of the official Raspbian OS. So to your question: "if I would have the RS232 expension(with the eeprom) then the overlay will work as expected" ... I cannot guarantee it since I have never every tested it what happens if the original config.txt says /dev/ttyAMA0 goes to UART for Wifi/Bluetooth and then an EEPROM comes and say /dev/ttyAMA0 goes to standard UART via the standard tx/rx pins put on the NPIX slot. Today all our NPIX modules are using the mini UART like it is configured via the standard config.txt

Do you know how a standard Raspberry Pi behaves on this setting when using a HAT module with EEPROM? Cause then the same behaviour will be on netPI.

Thx
Armin

I dont know much about the HAT feature and how it is working.
maybe I need to add some info about what we are trying to do.
on original raspian image we do the following:
adding to /boot/overlay the following files:
disable-bt.dtbo
uart-ctsrts.dtbo
we add to the config.txt file:
enable-uart=1
dtoverlay=disable-bt
dtoverlay=uart-ctsrts

the out come is that minicom(weaker uart) is muxed to the BT pins and PL011 is muxed to pins 14,15 cts rts is in 16,17
doing this procedure in nefied works fine in the container. with netpi not yet. 
what am I missing ?
  Reply
#15
So I tested how to modify the config.txt file for netPI correctly. The netPI SD card has 3 partitions. Two of them can be seen in Windows called BOOT and RESC.

The relevant config.txt file ready for your edits is located on the RESC partition. So please make your edits there and NOT in the file located on the BOOT partition.

All the edits working on a standard Raspberry Pi will work with netPI also since it is the same hardware and relies on the same OS source code.

If you mount the netPI SD under Linux you see that the RESC is the primary boot partition. It is indeed a little confusing with the naming.


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

  Reply
#16
(June-15th-2021, 12:35 PM)Armin@netPI Wrote: So I tested how to modify the config.txt file for netPI correctly. The netPI SD card has 3 partitions. Two of them can be seen in Windows called BOOT and RESC.

The relevant config.txt file ready for your edits is located on the RESC partition. So please make your edits there and NOT in the file located on the BOOT partition.

All the edits working on a standard Raspberry Pi will work with netPI also since it is the same hardware and relies on the same OS source code.

If you mount the netPI SD under Linux you see that the RESC is the primary boot partition. It is indeed a little confusing with the naming.


Thx
Armin

I have tried modifing the RESC directory. the outcome is still the same. the device wont communicate through this uart when running from container.
any other thoughts ?

Thanks,

Roy
  Reply
#17
I personally tried my netPI setup by activating the I2C-0 device which is normally not available. It is used to reach the EEPROM bus of HAT and NPIX in a container. So I added the line "dtparam=i2c_vc=on" to the config.txt file on RESC and I was immediately able to map the I2C-0 device into the container which worked. So editing this file works.

But now back to your problem. Of course the netPI OS includes the standard Linux network manager which is handling all the network interfaces and a kernel driver for Wifi/BT chip which is enabled by default. This driver has a fixed setup to initialize across the device "/dev/ttyAMA0". So I suspect this driver takes over the control of /dev/ttyAMA0 but fails cause due to your new config settings it can't reach the Wifi/BT chip ... but is still blocking this device for any other access. I could imaging that you can see some failures in the system logs after changing the ttyAMA0 setup. But for this scenario ... to be honest ... I have no solution how to disable the network manager or kernel driver in the netPI OS.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#18
ahhh by the way ... the netFIELD OS 2.1.0.0 on netFIELD Connect gateway does not include any Wifi/BT driver ... this will definitively change with netFIELD OS 2.2 which is coming soon. Then I expect the same problems on netFIELD Connect as you have with netPI.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#19
(June-15th-2021, 02:00 PM)Armin@netPI Wrote: ahhh by the way ... the netFIELD OS 2.1.0.0 on netFIELD Connect gateway does not include any Wifi/BT driver ... this will definitively change with netFIELD OS 2.2 which is coming soon. Then I expect the same problems on netFIELD Connect as you have with netPI.

can you give a short overview about the roadmap of both products? (field connect, Netpi)
will netpi have another revision of the OS with newer docker support ?
will netpi continue or netfield acctually replaces it ?

Regards,

Roy
  Reply
#20
Well this is indeed a good question.

netPI OS software development is freezed to V1.x version of software as it is distributed today. Of course we would make publiations in case of any known vulneratibities. But basially we stay with the software as it is since 2016.

netFIELD OSwhereas is the software that is current and is the one that is on the main stream and will be maintained with updates cycles of typically 6 months in between. We call i V2.x version of sofware. Since the software is more open and support SSH and so on ... we strongly recommend to use the netFIELD Connect gateway for coming projects.But as your customer sees it ... there are still customers who want to rely on netPI and want to use it. So I would say "yes" to the question is netFIELD Connect a successor of netPI. But we do not have any cancelations in mind for netPI.

All Hilscher products coming will definitively rely on V2,x version of software and netFIELD techniques since netIFIELD Clouf offers the remote managment of netFIELD protucts and is what I see as "state-of-the-art" for today IoT applications
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)