[En-Nut-Discussion] Status of Point-To-Point protocol over RS-232

[Ulrich Prinz]

Hi!

Some general notes on that driver and others at all:

Am 16.04.2011 17:55, schrieb Harald Kipp:
> Hi,
[...]
> 
> When writing the code, I typically used a Windows PC to connect to.
> Looks like a PPP server is no longer available on newer Win releases
> (or I'm too stupid to find it).

AFAIK already at the time of Windows NT this part moved into a special
Packet called 'Routing an RAS Service' that had to be installed
separately from a Windows NT Server CD or could be downloaded from the
MSDN. I believe that this had been made obsolete for any desktop version
of newer Windows XP...7. I may only be available for Server versions now
and, at the times where modems are used not so often anymore by the
masses, it could have been left at all.
Microsoft even forgot the USB CDC profile in the first releases of Vista...
> 
> So I bought a pre-paid sim card from t-mobile, grabbed my old Siemens
[...]
> 
> '' AT OK AT+CGDCONT=1,"IP","internet.t-mobile" OK ATD*99***1#
> CONNECT
> 
> and, viola, it worked. At least it looked like, but how to proof?
> 
> The application implemented a TELNET server, waiting for connections.
> My provider uses private IP addresses, which are not directly
> accessible from the Internet. Thus, I won't be able to connect the
> Ethernut board from the outside. :-(

Sure? If the system could report it's own IP you should be able to
telnet it from remote... I can telnet my Mobile phone if I like to and
is running a SSH/Telnet Server.
> 
> I re-wrote the pppc code, removing all this AVR specific stuff to
> make it more readable, and implemented a more useful procedure:
> 
[...]
> 
> I was lucky because this provider still allows PAP, while many others
> require CHAP for login. Long, long time ago Michel Hendriks
> contributed a CHAP implementation

To bad, that the Flash of my ISDN Router was worn out so it died. The
good old ELSA Microlink LanCOM would have been a good reference for PAP,
CHAP and Network communication tests.
> 
> http://www.ethernut.de/arc/michelChap.zip
> 
> which never found its way into the trunk.
> 
> Today, one problem is, that this was based on an early version of
> Nut/OS (3.9 or something) and obviously contains a few more changes
> (fixes?) than just adding CHAP. Furthermore it uses the RCA version
> of MD5, which would add another license to our code. Although
> compatible with BSDL, I don't like to add more than absolutely
> necessary. As you may remember, Ole ported a BSDLed version which we
> can use instead, available in nut/gorp/md5.c. The API is quite
> similar. But the problem with figuring out how to transfer Michel's
> code changes into the latest Nut/OS code remains.
> 
> How about the ARM platform? There is a AHDLC driver for the AT91 by
> Szemzo Andras in nut/arch/arm/. Looks like it requires PDC (DMA),
> which is not available on Ethernut 3. Other problems with this driver
> had been reported as well and I'm not sure whether anybody is
> currently using it at all.
> 
I started a lot of discussions and RFCs of how to proceed with new
driver implementations that are similar to this one. Besides some good
ideas no one really started to work together. So again:

Devices are not only the things that toggle the pins on your chip, they
are logically things that provide you some interface on one end and do
something on the other.
So if you write a USART driver and it provides a Nut/OS compatible
interface on one end, another driver should be able to use that driver
with its bottom end and provide another Nut/OS compatible API on th upper.

For me it should be totally independent on what driver you hook PPP.
So as this PPP driver is nothing else but a high level driver like LED,
Keypad, EEPROM and so on, it should be totally hardware independent.
The driver below, that pushes the characters through the line, is
hardware dependent and that is the part that must be specific for AVR,
ARM, Cortex and so on.

Unfortunately in Nut/OS some drivers are stackable, others are not. With
STM32 port they all will be stackable as there USART is a serial device
as it is I2C and SPI. Here you should be able to stack a PPP driver to
the UART what itself again is stacked upon a SPI driver that
communicates to a external dual-SPI-USART bridge. Understand what I mean?

But there is still one thing:
Sometimes it makes sense to write a driver a second time for a specific
architecture as this architecture may have options that really speed up
things. It doesn't make sense to use highly 8-bit optimized code from
AVR if you have a 32-bit machine. And for PPP it makes sense to enable
DMA for Cortex in any matter as it supports memory-memory DMA as easy as
it supports memory-USART/SPI/I2C DMA.

Sorry to open a second discussion with this one, but it all connects
together...

Ulrich