Live LiveCode Code Event #17 - wrap-up

[Claudi Cornaz]

Hi kay,

Glad to see more and more people are playing/discovering the arduino. It's the new lego.

I am glad you liked the presentation and I certainly will do a follow up. I still have a lot more to say and show.
Heck, I hardly scratched the surface.


> WITH REFERENCE TO CLAUDI's 'MUST DOs'
> 
> I do not need to disconnect the Arduino after uploading a sketch.
I guess it depends on the particular serial driver. The UNO uses a new chip for the serial/usb connection so
that might explain the difference. I haven't yet tryed it with the mini pro which connects via a seperate usb/serial board
and uses another driver. I will test it, altough I have set it up for wireless communication with the xbee modules.

If anyone is interested how to get the xBee's to work, let me know. It took me quiete a while and a lot of frustration to get the right information. 
All I found where instruction for the old firmware and just wouldn't work.
Once I had the right info and installed a app on a windows computer I could configure the xbee's and now
it's realy simple to work with these wireless modules.

> My first 'read' is not 'for 1 line' but I use what I got from Sarah's
> Serial Test stack, 'read from driver tDriverName until CRLF' and to
> that I added 'in 1 ticks'. This seems to prevent LiveCode from hanging
> on the first call.
That's basicly the same, just make sure the arduino sends a CRLF. 
In my scetches I just send a 'A' char and a CR after recieving the first char, thats why I read for 1 line. I guess it can 
be anything as long as the amount is fixed, so it could also be for 1 char etc.
After that first "read for" I guess something in the driver routines of livecode get's set correctly, so afterwards
it's ok to read until empty. 

> Basically LiveCode is EXTREMELY susceptible to timing issues and there
> is a NEED to include a 'wait' command in your LiveCode loop. 
My code setup is a bit different. I always try to avoid a continues loop in my livecode code :-)
I know and set the samplerate with which the arduino samples and sends the sensor values.
Exept for that first "A" & cr I send to establish contact between the arduino and livecode,
everything I send from the arduino to livecode or the other way around has a start char "<" next a command-char, which can be any char 
but each char stands for a certain command, followed by the 'parameters' or 'values' for the command (comma separated) and ending 
with a end char ">". Everything between "<" and ">" belangs to the same dataframe. (like "<d124,1021,23>"
I might send a couple of dataframes from the arduino in one go, but the sensor samples are always spaced out in the same rythm, the samplerate.

I might send a sensor dataframe and one or more command dataframes in one go, but the dataframes of the sensors are always
the samplerate spaced apart. (1, 2 or 5 millisecs)
After succesfuly  opening the driver I call a routine which reads the driver until empty and returns complete 'dataframes'
keeping the beginning of the next dataframe if it's there already, which isn't completly recieved yet in a local var. 
This 'saved' partial dataframe will be put in front of the next read.
This routine calls itself in the same rythm as the samplerate of the arduino. This way I keep things in sync and I can still
drag the stack window around and have a responsive userinterface, so I can click on btns or do other things.

Even if I recieve a couple of these dataframes at a time (due to a delay in reading, cause I moved the window around etc.)
I know their original timing because each sensor dataframe is exactly the arduino samplerate appart. 
This way I can do reliable calculations of the recieved sensor values with regard to time.
This means I don't need a tight loop to recieve the sensor values and thus I don't need to experiment 
with wait in time statements.
I now send dataframes like "<d1053,2448,1500,100.22,80.20,-300.46>" every millisec to livecode without any problems.
I would certainly love to have to higher baudrate working. At a certain moment that will be the bottleneck.
You just can't push more data over to livecode as the serial connection will permit.
 
Currently I just finished the hardware setup with a arduino mini with a BMA180 accellerometer and a ITG 3200 gyro
attached to the mini. The arduino mini is also connected to a xbee module to do wirreless communication
with livecode. I also connected a logger shield to the mini so I can record the accelero and gyro samples
on a SD card. So I can walk - run or skate and then analyse/visualyse all the data in livecode. This whole setup has the size
of a rather small remote control. A 5way switch and a RGB led are also connected so I can set different filters and sesitivity's
for the sensors and also to change the samplerate while in the field. (the RGB led is the UI. Green means I am now in the sensitivity menu 
and the number of blinks will be the number of the choice. Very primitive but also very small. Blue will be another menu etc.)

I have now to write the code for this and also the code to translate acceleration to speed and then to distance.
I hope to make my next presentation about this project.

I hope this helped you. You made me curious what youre gonna do with all those 70 digital I/Os. It sure sounds intruiging.

Best wishes,
    Claudi