Olinuxino-micro now with working Wifi, Python, SSH, etc

[Jorge Pinto]

I got it and thanks to the Olinuxino support group.

What I got until now:

- wifi working at boot, connecting to un unprotected network
- connection to Olinuxino by SSH
- python

The picture I am sending shows the USB wifi adapter with blue LED on,
which happens only when it connects.

--
Cumprimentos,

Jorge Pinto
jpi...@bitbox.pt
Tel: 00 351 927145983

[Nelson Neves]

I got my Olinuxino micro today, all set and configured running ArchLinux distro, thanks to Jorge it was a real plug-and-play to get started!

ArchLinux is a bit different that what I'm used to, but actually pretty simple! Here are some notes that I took during my short tests:

- login/pw: root/root

1) mounted Olinuxino micro SD card my Linux laptop first and edited the /etc/local.rc file to edit the Wifi (unsecure network) SSID (there are some additional notes on the olinuxino mailing list on how to get encrypted wifi working)

2) inserted the SD card on olinuxino, powered up the board and only after connect the USB serial debug cable (right next to the Oxino power plug) - from my linux laptop I can now see the boot messages

3) check the boot messages to see if the if is working and what IP will oxino get from DHCP (192.168.1.131)

4) from my linux laptop> ssh ro...@192.168.1.131 (pw=root) - it's easier from SSH shell

5) update system date: date -s "1 AUG 2012 22:20:00"

6) ping google.com to check for internet access

7) update/sync pacman: pacman -Syy

8) install some tools:

pacman -S git

pacman -S ser2net

pacman -S nodejs

pacman -S make

pacman -S minicom

... etc

some random tests and 1 occasional major crash (segmentation fault) - maybe wifi driver is unstable after great usage (just giving a tip) - I only got 1 crash when installing some node packages!

OK, so far so good ... Jorge asked me on how to bridge tcp/ip connections to serial port AUART1 (mounted on oxino /dev/ttySP1 - NOT the default Serial Debug port). Here's a quick example that I've made pretty easily.

a) connected the R2C2 pins (I already had the rPI cable attached, so just used it with the Olinuxino micro)

check the Oxino micro schematic: https://github.com/OLIMEX/OLINUXINO/blob/master/HARDWARE/iMX233-OLinuXino-Micro/iMX233-OLinuXino-Micro_Rev_B.sch.pdf

Olinuxino Micro GPIO headers -> CON2 (pins 5,6,7) being (GND, AUART1_TX, AUART1_RX).

To test things, I launched minicom from the Oxino side and checked if I got R2C2 communication (testing at 57600 bps).

Everything running fine!

b) install ser2net package (already done on previous pacman examples)

c) edit ser2net /etc/ser2net.conf file

nano /etc/ser2net.conf 

comment all examples and add a new one:

#2001:raw:600:/dev/ttyS0:9600 NONE 1STOPBIT 8DATABITS XONXOFF LOCAL -RTSCTS

#2002:raw:600:/dev/ttyS1:9600 NONE 1STOPBIT 8DATABITS XONXOFF LOCAL -RTSCTS

#2003:raw:5:/dev/ttyS2:9600

#2004:raw:5:/dev/ttyS3:115200

#2005:raw:5:/dev/ttyS4:9600

#2006:raw:5:/dev/ttyS5:9600

#2007:raw:5:/dev/ttyS6:9600 tw=tw1 tr=tr1

#3001:telnet:0:/dev/ttyS0:19200 remctl banner1

#3011:telnet:3:/dev/ttyS0:19200 banner2

#3002:telnet:0:/dev/ttyS1:9600

#3003:telnet:0:/dev/ttyS2:9600 banner3

#3004:telnet:0:/dev/ttyS3:115200

#3005:telnet:0:/dev/ttyS4:9600

#3006:telnet:0:/dev/ttyS5:9600

#3007:telnet:0:/dev/ttyS6:9600

#5001:rawlp:10:/dev/lp0

6000:raw:600:/dev/ttySP1:57600 NONE 1STOPBIT 8DATABITS -XONXOFF -LOCAL -RTSCTS

so, Olinuxino will now accept tcpip raw socket connections on port 6000 and forward it to /dev/ttySP1 @ 57600 bps!

d) finally, launch ser2net:

ser2net

e) from the linux laptop, use netcat to test connection/bridge (oxino ip=192.168.1.131):

nc 192.168.1.131 6000

now enter GCODE commands ;)

I did the usual: 

M23 demo.g

M24

;)

enjoy!

ps: this is my idea of having a transparent proxym without messing around with data! 

My idea on the checksums additional data, they should be inserted and testes on the endpoints (software / r2c2), ReplicatorG should add CRC code, R2C2 would confirm in the end of the line ... but maybe Jorge disagree and would like to pinpoint some valid point on having the proxy doing CRC inspection!

[bobc]

Nice!

On Thursday, August 2, 2012 12:44:17 AM UTC+1, Nelson Neves wrote:

ps: this is my idea of having a transparent proxym without messing around with data! 

My idea on the checksums additional data, they should be inserted and testes on the endpoints (software / r2c2), ReplicatorG should add CRC code, R2C2 would confirm in the end of the line ... but maybe Jorge disagree and would like to pinpoint some valid point on having the proxy doing CRC inspection!

I would agree, CRC would be best done end to end. Anything in the middle should just be a transparent pipe.

I was recently looking at the line number/checksum scheme RepRap added to the Gcode "protocol" and realised what a horrible hack it is, very amateur. It's robustness to errors is very poor. e.g. if the "*" gets lost, the checksum isn't even checked! There are also major bugs in the spec/code which would screw up error recovery anyway. The whole thing is so bad it is beyond any "quick fix". I suspect the USB-serial adapters are providing all the reliability for the comms.

Anyway, there is a good opportunity to design something better ;)

[Jorge Pinto]

No dia 2 de Ago de 2012 09:03, "bobc" <bobcou...@googlemail.com> escreveu:
>
> Nice!
>
>
> On Thursday, August 2, 2012 12:44:17 AM UTC+1, Nelson Neves wrote:
>>
>> ps: this is my idea of having a transparent proxym without messing around with data! 
>> My idea on the checksums additional data, they should be inserted and testes on the endpoints (software / r2c2), ReplicatorG should add CRC code, R2C2 would confirm in the end of the line ... but maybe Jorge disagree and would like to pinpoint some valid point on having the proxy doing CRC inspection!
>>
>
> I would agree, CRC would be best done end to end. Anything in the middle should just be a transparent pipe.

I would do the same I did on Smart Scale, a kind of packets and CRC. I implemented on C for ARM and Java for Android: http://code.google.com/p/casainho-projects/wiki/SmartScale

The projects uses a UART-bluetooth module.

> I was recently looking at the line number/checksum scheme RepRap added to the Gcode "protocol" and realised what a horrible hack it is, very amateur. It's robustness to errors is very poor. e.g. if the "*" gets lost, the checksum isn't even checked! There are also major bugs in the spec/code which would screw up error recovery anyway. The whole thing is so bad it is beyond any "quick fix". I suspect the USB-serial adapters are providing all the reliability for the comms.

But there is still the UART bus that can get errors...

[Nelson Neves]

I would agree, CRC would be best done end to end. Anything in the middle should just be a transparent pipe.

I just confirmed something with my colleague (experienced C++ software developer) about the tcp/ip protocol and he confirmed this:

On a tcp/ip connection there is already some mechanism in the tcp/ip stack that do error checksum, if some packet gets corrupted (payload is altered, or other error) the tcp/ip protocol will request another retry and discard the previous data, all this is done in a transparent mode, fro the stack itself, without user/software/etc inter-action!

The problem should be in the UART communication, when going into high speed mode and using some bad cabling, that should be the problem, and in that case is far beyond the TCP/Serial proxy, it's already a problem in the hardware communication between Oxino and R2C2! (just to enforce my idea that endpoints checksum should be more important).

I was recently looking at the line number/checksum scheme RepRap added to the Gcode "protocol" and realised what a horrible hack it is, very amateur. It's robustness to errors is very poor. e.g. if the "*" gets lost, the checksum isn't even checked! There are also major bugs in the spec/code which would screw up error recovery anyway. The whole thing is so bad it is beyond any "quick fix". I suspect the USB-serial adapters are providing all the reliability for the comms.

Anyway, there is a good opportunity to design something better ;)

I agree, sometimes it's better to start over than doing some mess on a fragile code (unfortunately my boss completely disagree with me on this)!

[Jorge Pinto]

No dia 2 de Ago de 2012 10:39, "Nelson Neves" <nelson....@gmail.com> escreveu:
>>
>> I would agree, CRC would be best done end to end. Anything in the middle should just be a transparent pipe.
>
>
> I just confirmed something with my colleague (experienced C++ software developer) about the tcp/ip protocol and he confirmed this:
> On a tcp/ip connection there is already some mechanism in the tcp/ip stack that do error checksum, if some packet gets corrupted (payload is altered, or other error) the tcp/ip protocol will request another retry and discard the previous data, all this is done in a transparent mode, fro the stack itself, without user/software/etc inter-action!
>
> The problem should be in the UART communication, when going into high speed mode and using some bad cabling, that should be the problem, and in that case is far beyond the TCP/Serial proxy, it's already a problem in the hardware communication between Oxino and R2C2! (just to enforce my idea that endpoints checksum should be more important).

Yes. USB alreday do CRC that is why we did not needed this.

I think we should implement the packet/crc layer to be under current data layer going from Linux board and r2c2, only.
Maybe doing that on python will be quicker.

[bobc]

On Thursday, August 2, 2012 2:23:31 PM UTC+1, Jorge Pinto wrote:

Yes. USB alreday do CRC that is why we did not needed this.

I think we should implement the packet/crc layer to be under current data layer going from Linux board and r2c2, only.
Maybe doing that on python will be quicker.

Having an end-end protocol would be more flexible, there are still issues to address like flow control, dual-band which wouldn't be solved by just replacing the UART side protocol. It would be a much neater solution if the host software could use the same protocol, whether the printer is located on a local UART or on a remote system.

I think if I was picking a link protocol it would be based on HDLC. That provides framing, 8 bit transparency, robust CRC, sliding window, flow control, selective resend, dual-band, efficient acking. It could also be used to carry TCP/IP packets in PPP mode. Pretty much everything you want from a link protocol!

BTW, saw this on thingiverse, may be of interest http://www.thingiverse.com/thing:27758

[Jorge Pinto]

On my Olinuxino, I put the simple example python code to listen on a
Socket port 50000. On another computer on the same network, I do: "nc
r2c2 50000". I can then enter text and I get echo. If the string is
"led 0", the green LED on Olinuxino goes off and if string is "led 1",
green LED goes on :-)

Note that "r2c2" is the hostname of Olinuxino board.

Here is the simple python code (small adaptions from example server code):

# Echo server program
import socket
import os

HOST = '' # Symbolic name meaning the local host
PORT = 50000 # Arbitrary non-privileged port
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind((HOST, PORT))
s.listen(1)
conn, addr = s.accept()
print 'Connected by', addr
while 1:
data = conn.recv(1024)
conn.send("echo: " + data)

if data == "led 1\n":
os.system("echo 1 > /sys/class/gpio/gpio65/value")

if data == "led 0\n":
os.system("echo 0 > /sys/class/gpio/gpio65/value")

conn.close()


Open the UART port on Olinuxino and use if to send/receive the data to
Socket should be very easy. Now we just need ReplicatorG_R2C2 with a
quick hack to send/receive data to Socket (machine with name "r2c2"
and port 50000) to have Wifi on R2C2 :-)

[danie...@gmail.com]

Hi Jorge,

this is awesome !!!

I'm trying to do the same. do you have some liinks/images and some document that explains how to do it ?

Thanks,
Daniel