SLIP using USB serial

[Sebastien Lelong]

Hi Matt, guys,

I've been trying to migrate 18f4550_slip_poll.jal sample to use USB serial instead of serial hardware as the carrier. I had to do several modifications, and now have questions what I should expect to get when sending/receiving SLIP packet.

But first, I had to put the "send SLIP packet" under a CDC line status check logic:

var bit has_sent_packet = FALSE

-- your main loop

forever loop

   usb_serial_flush()

   if usb_cdc_line_status() !=  0x00 then

      if !has_sent_packet then

         send_slip_packet()

         has_sent_packet = TRUE

      end if

   else

      has_sent_packet = FALSE

   end if

   slip_poll() -- poll to receive slip data

   -- do other stuff but don't take too long

end loop

It seems CDC requires the serial port to be opened before any communication. There isn't any kind of buffer: if I put the send_slip_packet() while CDC status isn't ok, I don't receive anything. And when I put it before the forever loop, while device is being configured (CDC status becomes OK at this time), it's been called but I don't receive anything either later. Is it right to say there's no buffering when using CDC ?

Now, about SLIP comms, here's what I have:

 1. I connect to the device (/dev/ttyACM0) using a python script.

 2. since the port is opened, CDC status is OK and I receive a SLIP packet. In sample, test_data = {1,2,3,0xC0,5,6,0xDB,8,9,10}, and I receive: {0xc0, 1, 2, 3, 0xdb, 0xdc, 5, 6, 0xdb', 0xdd, 8, 9, 0xc0}.

    - So far so good, but: why does it start with a SLIP END char ?

 3. now I send back the same packet: {1,2,3,0xC0,5,6,0xDB,8,9,10}. Since the code is supposed to echoed the data back, I would have expected to get  {0xc0, 1, 2, 3, 0xdb, 0xdc, 5, 6, 0xdb', 0xdd, 8, 9, 0xc0}, as before. But I have: {'A', 'T', '+', 'G', 'C', 'A', 'P', '\r', '\n', 'A', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x01', '\x02', '\x03', '\xc0', '\x05', '\x06', '\xdb', '\x08', '\t'}

     - packet size is 36, which is greater than MTU (10).

     - I really don't understand where those first chars comes from

     - it seems there's some kind of padding with 0x00

 4. If I send the packet again, I now receive {'\x01', '\x02', '\x03', '\xc0', '\x05', '\x06', '\xdb', '\x08', '\x09'}

     - why SLIP END appears again in the middle, after 3 ?

Do you have any idea what I'm doing wrong ? Attached is my sample...

And, does anyone know a program under Linux to talk in SLIP ?

Cheers,

Seb

[mattschinkel]

> It seems CDC requires the serial port to be opened before any communication.
> There isn't any kind of buffer: if I put the send_slip_packet() while CDC
> status isn't ok, I don't receive anything. And when I put it before the
> forever loop, while device is being configured (CDC status becomes OK at
> this time), it's been called but I don't receive anything either later. Is
> it right to say there's no buffering when using CDC ?

I don't know much about the USB lib or if there is a buffer. However,
with normal serial communications, data can still be sent out even if
the port is not open on the PC side. Data will be lost. USB serial
should act the same.

> Now, about SLIP comms, here's what I have:
>
>  1. I connect to the device (/dev/ttyACM0) using a python script.
>
>  2. since the port is opened, CDC status is OK and I receive a SLIP packet.
> In sample, test_data = {1,2,3,0xC0,5,6,0xDB,8,9,10}, and I receive: {0xc0,
> 1, 2, 3, 0xdb, 0xdc, 5, 6, 0xdb', 0xdd, 8, 9, 0xc0}.
>     - So far so good, but: why does it start with a SLIP END char ?

It may be a good idea for you to test the library with a normal serial
port before trying USB, this way you will know the expected data. It
starts with SLIP END char because it is good practice to send/receive
a SLIP END character before each packet (per the RFC). This will flush
any bad data on the serial line so it does not get into your packet.
So, if you send two SLIP packets, you will get a 3rd packet between
them with a size of 0 bytes that gets ignored.

>  3. now I send back the same packet: {1,2,3,0xC0,5,6,0xDB,8,9,10}. Since the
> code is supposed to echoed the data back, I would have expected to
> get  {0xc0, 1, 2, 3, 0xdb, 0xdc, 5, 6, 0xdb', 0xdd, 8, 9, 0xc0}, as before.
> But I have: {'A', 'T', '+', 'G', 'C', 'A', 'P', '\r', '\n', 'A', '\x00',
> '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00',
> '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x01', '\x02',
> '\x03', '\xc0', '\x05', '\x06', '\xdb', '\x08', '\t'}
>      - packet size is 36, which is greater than MTU (10).
>      - I really don't understand where those first chars comes from
>      - it seems there's some kind of padding with 0x00
>
>  4. If I send the packet again, I now receive {'\x01', '\x02', '\x03',
> '\xc0', '\x05', '\x06', '\xdb', '\x08', '\x09'}
>      - why SLIP END appears again in the middle, after 3 ?

Don't know. there shouldn't be any '\x00' padding. Maybe you need that
END CHAR at the beginning to flush bad data?? After a quick look at
the data you are sending back, it appears that you did not encode it
first. Try sending back {0xc0,1, 2, 3, 0xdb, 0xdc, 5, 6, 0xdb', 0xdd,
8, 9, 0xc0}. You should get back your original decoded message.

> Do you have any idea what I'm doing wrong ? Attached is my sample...

I'll try your sample on windows when I get a chance. I haven't had a
chance to look at your code yet, these are all just quick suggestions.

> And, does anyone know a program under Linux to talk in SLIP ?

Google "slip serial terminal". I found http://www.opend.co.za/software/terminal/index.htm,
but it seems that it is for windows. Will it work under Wine?

I used slattach to connect my slip networking, but it is not a serial
terminal program. I am interested to know weather it would encode/
decode silp data for you.
slattach -p slip -s 115200 /dev/ttyS0 &

Matt.

[mattschinkel]

As you can see from my commit, I added a slip usb serial example.

There was also an error in slip.jal if your sent packet is the same as
slip_mtu. We where missing byte 10 but didn't notice. I didn't notice
it in my networking since slip_mtu was always larger then sent
packets.

download these:
http://jallib.googlecode.com/svn/trunk/sample/18f67j50_slip_poll_usb_serial.jal
http://jallib.googlecode.com/svn/trunk/include/protocol/slip.jal

I tested it on windows. Once you plug in usb and open the port via
your PC, the PIC will send you 1,2,3,0xC0,5,6,0xDB,8,9,0x0A via slip.
Slip will encode it and you will receive it on your PC encrypted like
this: C0 01 02 03 DB DC 05 06 DB DD 08 09 0A C0

Then when you send back C0 01 02 03 DB DC 05 06 DB DD 08 09 0A C0 from
your PC to your PIC. The PIC will decode the data and send back to the
PC on the serial port (not via slip procedures). You will get 01 02 03
C0 05 06 DB 08 09 0A

Your serial_data_available works, please add it to usb_serial. Thanks,
I was waiting for this. I have this procedure in my sample, buildbot
will fail unless it is removed. you can remove it or let me know.
Maybe you can add a SLIP 18f4550_slip_poll_usb_serial.jal sample, or
whatever PIC you are using.

-- this can be removed when added to usb_serial
function usb_serial_data_available'get() return bit is
if ( usb_cdc_line_status() == 0x00 ) then
return false
end if
if ( !usb_cdc_rx_avail() ) then
return false
end if
return true
end function

Matt.

[Sebastien Lelong]

Hi Matt,

Thanks for this ! I tried again, with these new updates:

2010/10/2 mattschinkel <mattsc...@hotmail.com>

I tested it on windows. Once you plug in usb and open the port via
your PC, the PIC will send you 1,2,3,0xC0,5,6,0xDB,8,9,0x0A via slip.
Slip will encode it and you will receive it on your PC encrypted like
this: C0 01 02 03 DB DC 05 06 DB DD 08 09 0A C0

OK, this is what I have.

What's pretty interesting here is you actually receive chars whereas I don't. I originally wrote the same code, checking CDC line status and send SLIP packet *before* forever loop, but I've never received anything. Under Linux, when device is getting recognized and configured, CDC line status becomes != 0. Though I don't have the serial port opened. As a consequence, I don't receive anything when I open the port, as the code is already in the forever loop. It may be related to CDC ACM kernel driver ?...

 

Then when you send back C0 01 02 03 DB DC 05 06 DB DD 08 09 0A C0 from
your PC to your PIC. The PIC will decode the data and send back to the
PC on the serial port (not via slip procedures). You will get 01 02 03
C0 05 06 DB 08 09 0A

I get garbage chars but it finishes with this.

Using your code (replacing target and pragmas with include jaluino_medium), I also receive the exact same garbage chars, then the SLIP packet. Weird. I'd need to test it under Windows to be sure it's coming from PC system.

 

Your serial_data_available works, please add it to usb_serial. Thanks,
I was waiting for this. I have this procedure in my sample, buildbot
will fail unless it is removed. you can remove it or let me know.
Maybe you can add a SLIP 18f4550_slip_poll_usb_serial.jal sample, or
whatever PIC you are using.

OK

Cheers,

Seb

[mattschinkel]

I dislike this (usb_cdc_line_status() == 0x00). I think we need
something more readable.

It should look like this instead:

-- wait till USB device has been connected and serial port has been
opened by the HOST
While (usb_serial_port_open == FALSE) loop
usb_serial_flush() -- poll USB at all times
end loop

Can we create an inline pseudo var?

Matt.

On Oct 2, 4:14 am, Sebastien Lelong <sebastien.lel...@gmail.com>
wrote:

> Hi Matt,
>
> Thanks for this ! I tried again, with these new updates:
>

> 2010/10/2 mattschinkel <mattschin...@hotmail.com>

[mattschinkel]

Seb, guys... what do you think about my last message? I think we need
a "usb_serial_port_open" variable.

Matt.

[Sebastien Lelong]

Hi Matt,

This is mostly a matter of semantic, using a pseudo-variable may sound overkill ? We can also name a constant so:

while usb_cdc_line_status() ==  PORT_UNAVAILABLE loop

  --

end loop

Comments says CDC line status becomes non-zero when port is open, but I'm not sure it actually means "port opened". Can't it holds values meaning something else ? That's the reason why I would stay fuzzy about constant meaning (available/unavailable)

Cheers,

Seb

2010/10/7 mattschinkel <mattsc...@hotmail.com>

--
You received this message because you are subscribed to the Google Groups "jallib" group.
To post to this group, send email to jal...@googlegroups.com.
To unsubscribe from this group, send email to jallib+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jallib?hl=en.

--
Sébastien Lelong
http://www.sirloon.net
http://sirbot.org

[mattschinkel]

> This is mostly a matter of semantic, using a pseudo-variable may sound
> overkill ?

Actually my compile result is one less byte of ram compared to the
usb_cdc_line_status() procedure. Of course I am returning a bit
instead of a byte.

function usb_serial_port_is_open'get() return bit is
pragma inline
if cdc_line_status == 0 then
return 0
else
return 1
end if
end function

-- wait till USB device has been connected and serial port has been
opened by the HOST

while !usb_serial_port_is_open loop

usb_serial_flush() -- poll USB at all times
end loop

Matt.

[Sebastien Lelong]

OK, then why not, but "CDC status != 0" really means "port is opened", or maybe just "available" or something else ? I guess since this pseudo-variable will be defined in usb_serial.jal (won't it ?), we can stick to "port opened" meaning...

Cheers,

Seb

2010/10/8 mattschinkel <mattsc...@hotmail.com>

--

You received this message because you are subscribed to the Google Groups "jallib" group.
To post to this group, send email to jal...@googlegroups.com.
To unsubscribe from this group, send email to jallib+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jallib?hl=en.

[Sebastien Lelong]

Ah ah ah... These "garbage" chars (AT+GCAP...) are actually AT commands :)

Since CDC/ACM devices are supposed to be modem, this explains why I receive this. I now need to figure out how to disable on my system...

Cheers,

Seb

2010/10/1 Sebastien Lelong <sebastie...@gmail.com>

[mattschinkel]

To us, the meaning/usage is for port opened or closed. That is all we
care about. so do you agree? can it be added?

Yes, this would go into usb_serial lib.

Matt.

On Oct 8, 1:03 pm, Sebastien Lelong <sebastien.lel...@gmail.com>
wrote:

> OK, then why not, but "CDC status != 0" really means "port is opened", or
> maybe just "available" or something else ? I guess since this
> pseudo-variable will be defined in usb_serial.jal (won't it ?), we can stick
> to "port opened" meaning...
>
> Cheers,
> Seb
>

> 2010/10/8 mattschinkel <mattschin...@hotmail.com>

>
>
>
> > > This is mostly a matter of semantic, using a pseudo-variable may sound
> > > overkill ?
>
> > Actually my compile result is one less byte of ram compared to the
> > usb_cdc_line_status() procedure. Of course I am returning a bit
> > instead of a byte.
>
> > function usb_serial_port_is_open'get() return bit is
> >   pragma inline
> >   if cdc_line_status == 0 then
> >      return 0
> >   else
> >      return 1
> >   end if
> > end function
>
> > -- wait till USB device has been connected and serial port has been
> > opened by the HOST
> > while !usb_serial_port_is_open  loop
> >    usb_serial_flush() -- poll USB at all times
> > end loop
>
> > Matt.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "jallib" group.
> > To post to this group, send email to jal...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > jallib+un...@googlegroups.com<jallib%2Bunsu...@googlegroups.com>
> > .

[Sebastien Lelong]

2010/10/8 mattschinkel <mattsc...@hotmail.com>

To us, the meaning/usage is for port opened or closed. That is all we
care about. so do you agree? can it be added?

Sure ! And don't wait for my approval :)

Cheers,

Seb

 

To unsubscribe from this group, send email to jallib+un...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/jallib?hl=en.

--

[mattschinkel]

> Sure ! And don't wait for my approval :)

As you could see, I added it. I worry however about who's approval is
needed. I assume Albert should be notified, but I guess he's not
around at the moment. What process did you go through when you added
usb_serial_data_available?

Matt.

[Sebastien Lelong]

2010/10/8 mattschinkel <mattsc...@hotmail.com>

I suggested it with some sample code, waiting for feedback. You said "cool", I committed :)

Cheers,

Seb 

[mattschinkel]

> Ah ah ah... These "garbage" chars (AT+GCAP...) are actually AT commands :)
> Since CDC/ACM devices are supposed to be modem, this explains why I receive
> this. I now need to figure out how to disable on my system...

Please keep us informed if you find out how to fix this.

>I suggested it with some sample code, waiting for feedback. You said "cool"

>I committed :)

ok, great. just making sure i'm doing things right :)

Matt.

[Sebastien Lelong]

hi Matt,

2010/10/9 mattschinkel <mattsc...@hotmail.com>

> Ah ah ah... These "garbage" chars (AT+GCAP...) are actually AT commands :)
> Since CDC/ACM devices are supposed to be modem, this explains why I receive
> this. I now need to figure out how to disable on my system...

Please keep us informed if you find out how to fix this.

Yet no fix, but... in usb_serial.jal, USB CONFIGURATION DESCRIPTOR says used protocol should be AT commands (USB_V25TER, Communication Interface Class Control Protocol Code). According to USB CDC specs, if setting this to 0 tells the host not to use any particular protocol. So I tried this, but then USB device isn't properly recognized, I don't have any /dev/ttyACM0 device anymore. It's because kernel module cdc_acm only "catches" those with AT commands.

I found this interesting page, showing a patch to allow pseudo-modem to be added without AT commands (this is what we need). Interestingly this patch is aimed to "enable to drive electronic simple gadgets based on microcontrolers"...

http://www.spinics.net/lists/stable-commits/msg08595.html

But this requires kernel module compilation. According to the post, this has been added to Linux kernel 2.6.32 (this is a recent patch). I'm running 2.6.28 so I definitely need to test this.

If,Matt, you have a windows box, can you test specifying Communication Interface Class Control Protocol Code as 0x00 instead of USB_V25TER (search in usb_serial.jal) and let us know how this is handle by windows ?

What I still can't understand is when using usb serial echo sample, I never get any AT commands, but when using SLIP, I do. Could SLIP chars wake up AT ? (I'm definitely not an AT expert...)

Cheers,

Seb

[mattschinkel]

> If,Matt, you have a windows box, can you test specifying Communication
> Interface Class Control Protocol Code as 0x00 instead of USB_V25TER (search
> in usb_serial.jal) and let us know how this is handle by windows ?

I won't be able to try until tomorrow.

Matt.

[mattschinkel]

>If,Matt, you have a windows box, can you test specifying Communication
>Interface Class Control Protocol Code as 0x00 instead of USB_V25TER (search
>in usb_serial.jal) and let us know how this is handle by windows ?

I tried it and it worked fine. My PC did not pop up with new hardware
found. Works as normal.

Matt.

[Sebastien Lelong]

Hi Matt,

Thanks for the feedback, that's good news. Here I can see some more configuration selection. And since USB is a lot about configuration, this will put our way to configure our libs to the test...

I can confirm CDC ACM without protocol has been integrated into Linux Kernel >= 2.6.32. I'm still in the process of recompile my old kernel including the patch.

Cheers,

Seb

2010/10/11 mattschinkel <mattsc...@hotmail.com>

Matt.

--
You received this message because you are subscribed to the Google Groups "jallib" group.
To post to this group, send email to jal...@googlegroups.com.
To unsubscribe from this group, send email to jallib+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jallib?hl=en.