Merge - Githubissues

UweBonnes commented 3 years ago

Hello,

how far off are you from https://sourceforge.net/projects/ethernut/ HEAD? Any intention to offer it? Please note, I will be mostly offline until Sep.1

dferbas commented 3 years ago

Hi Uwe, not far and far. It depends of point of view. This repository is publicly available, anyone can use it.

I made 2 major changes - PPP, which was not working reliably and I modified behavior, task sequencing (i.e. what is done in which context), added lcp echo to keep alive a connection. In other words ppp can now be invoked repeatedly.

2nd major change is in ifconfig.c, which is not comitted yet, but seems stable. It is about configuring routing tables, when ppp is active and a link is established on ethernet. In this case ppp routing can't be destroyed. I also added an ioctl for ethernet driver, which allows to start dhcp whenever a link is established.

We now have strange behavior with Windows10 v2004, where file upload works with a certain Nut and not working with another Nut version. This was not yet investigated enough.

We also tried to move to Zephyr, which has IPv6. We added file / socket coverage, SD driver for MK64 controller. But finally it was unreliable even with ARPs, so I left it and went back to Nut os and ported drivers for MK64, which are in this repo.

Any cooperation welcome, but we need some budget for this as we are very limited these days.

dferbas commented 3 years ago

Hi Uwe, just now, I finished ppp merge to Nut/OS trunk and ppp works. Once it is tested I will push it here. Do you know someone, who can test it on ST platform?

No more changes in NutEnterCritical, but really many changes in LCP / IPCP automaton. I did it exactly to match the RFC 1661 transition table. Then some changes even in ifconfig.c (ppp must retain ethernet routing table) and udpout.c & ipout.c changes are usefull to allow broadcasting both to ethernet and ppp (requires to move IP address filling from udpout to ipout as each interface has different IP address). I also tuned interaction with hdlc thread to allow ppp to be opened again.

Here is a preliminary Youtube video of our new DIN rail based device animation with exchangable radio boards (GPRS / UMTS / NB-IoT - already OTS, LoRaWAN, WMBus - in development). Parameters are in a text below the video. More pictures can be found here. We are now working on exchangable functionality for 2 terminals - RS232 / RS485 / 2 opto isol. inputs (2DI) / 2DI isol. with DC/DC / RS485 with DC/DC / 2DO isol. SM3-LU-transparent-left SM3-LU-transparent-mid SM3-LU-transparent-right

UweBonnes commented 3 years ago

Hello Dusan,

Dusan Ferbas writes:

Hi Uwe, just now, I finished ppp merge to Nut/OS trunk and ppp works. Once it is tested I will push it here. Do you know someone, who can test it on ST platform?

I have a lot of ST nuclo and disco boards, but my usage case is different:

Collect data from sensors and controll actuators
Provide controll and output via CAN or seriell

Networking is hostile area for me...

No more changes in NutEnterCritical, but really many changes in LCP / IPCP automaton. I did it exactly to match the RFC 1661 transition table. Then some changes even in ifconfig.c (ppp must retain ethernet routing table) and udpout.c & ipout.c changes are usefull to allow broadcasting both to ethernet and ppp (requires to move IP address filling from udpout to ipout as each interface has different IP address). I also tuned interaction with hdlc thread to allow ppp to be opened again.

Here is a preliminary Youtube video of our new DIN rail based device animation with exchangable radio boards (GPRS / UMTS / NB-IoT - already OTS, LoRaWAN, WMBus - in development). Parameters are in a text below the video. More pictures can be found here. We are now working on exchangable functionality for 2 terminals - RS232 / RS485 / 2 opto isol. inputs (2DI) / 2DI isol. with DC/DC / RS485 with DC/DC / 2DO isol. SM3-LU-transparent-left SM3-LU-transparent-mid SM3-LU-transparent-right

I will try to look at the videos the next day.

With NB-IoT/ LoRaWAN, this reminds me of a planned pet project:

Collect straingauge from a behive, e.g. by HX711
Transfer via BC66 via NB-IOT, with Quecopen or with a controlling STM32L4
Or use a STM32WL for Lora
Do this with lowest power consumption

Do your sample have some overlap with this requirements.

Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------

dferbas commented 3 years ago

Hi Uwe,

interesting, I did not know about HX711, it requires only 1 MHz clock to output data in serial
our cpu NXP Kinetis MK60 has CAN, differential ADCs, but there is almost no space on the pcb to route additional things. If you are interested for a set of peripherals and the box suits you, we can think about a board variant or even the ST variant. The existing concept of exchangable radio boards can benefit from existing mechanical design, the used LMR36510/20 is promising for its conversion efficiency. Do you plan to use STM32WL for LoRa (local radio net) or LoRaWAN to be able to send data to a cloud?
I already discussed with Quectel their open mcu (Quec open) for BG96 and they said yes, starting with 1k, better 10k pieces :-)
for LoRa, I thought about LJ elect (minyx.cz) , Hardwario or IMST. Hardwario uses the Murata CMWX1ZZABZ-078, which itself contains SX1276 + STM32L082, but their lead time is > 1y :-(. My current choice is the iM881A-XL, because they offer sniffer and bonding software tools.
our first intention was to make only 1 board with a possibility for different assembly either with LoRa or WMBus. However it was electrically feasible, we did not fit in our mechanical format. So there will be 2 boards.

I do not know if pictures are sent also to your email, but they are on github. SM3-LORA-left SM3-LORA-iview-WMBus SM2-RM-GSM-3d

UweBonnes commented 3 years ago

Hello Dusan,

just to exchange and document more notes:

Dusan Ferbas writes:

Hi Uwe,

• interesting, I did not know about HX711, it requires only 1 MHz clock to output data in serial

It is low cost, other Sigma Delta will fit too. The HX711 resets with high > 50 us. That is a pitfall many people fell into when bitbanging on a RPI while using complex network stacks.

• our cpu NXP Kinetis MK60 has CAN, differential ADCs, but there is almost no space on the pcb to route additional things. If you are interested for a set of peripherals and the box suits you, we can think about a board variant or even the ST variant. The existing concept of exchangable radio boards can benefit from existing mechanical design, the used LMR36510/20 is promising for its conversion efficiency. Do you plan to use STM32WL for LoRa (local radio net) or LoRaWAN to be able to send data to a cloud?

There was no TTN coverage in the deploy area, last time I looked. So a Lora receiver would also be needed. And probably to reach the receiver only small data rate with long transmission time is needed. This may violate TTN rules (30 sec airtime/day) and increase current surge. So either is not first choice. But I would plan to use STM32WL. For a better solderable module, look at the Seeed Lora-E5 (WLe)

• I already discussed with Quectel their open mcu (Quec open) for BG96 and they said yes, starting with 1k, better 10k pieces :-)

Find the parts at https://www.soselectronic.de/gsm-umts-lte-5g-module/quectel for decent pricing. Even Digikey/Mouser carries Quectel. Availability is however low at the moment like many other things.

Problem is the API, only reverse engineered by Wiz-IO and documentation could be improved.

dferbas / ethernut

Merge #1