I want to read data from 32u4 ADC and transfer it to Linino core with the transfer rate of atleast 1sample/millisecond.
Initially , I used the bridge.put (on 32u4 side) and Bridge.get(on linino side) for data transfer but the data rate was terrible. It took 140-220 millisecs to transfer one sample. I took a look at the python code and it was opening and closing a socket for every sample transfer (i.e. everytime i used a bridge.get).
In hopes of speeding it up, I wrote a python script that opens a socket once in the beginning, do the data transfer as much as needed and after data transfer is over closes the socket. Doing this a got a little advantage , now 1 sample was taking somewhere around 120millisecs.
Now, I wanna ask that is there a method of communication between the 32u4 and linino core that can help me achieve required rate? Is the method of using bridge.transfer() , mailboxes or console be a better idea? If not , then is there a simple modification that I can do on python side to speed up the communication?
The analogRead() function is relatively slow. It is set up in the Arduino code to be this slow because that's the easiest way to measure things in average Arduino projects.
If you know enough about your incoming analog signal and you're prepared to change a few of the registers in the analog subsystem, then you can make it a lot faster. Search the forums for fast analog read.
However, I think you are right that the main slowdown is in the communications bus. I don't know anything about that.
As you discovered, while it has some interesting advantages, like being able to get/put values remotely with a web browser using no additional code, Bridge.put()/Bridge.get() has a big disadvantage when it comes to speed - it's one of the slowest ways of communicating between a sketch and the Linux side.
A faster way is to use the Process class - create a global instance of a Process object, and in setup() have it start a script on the Linux side, and run the Process asynchronously. Then, in loop(), as you collect each sample, call the process' println() function to send the sample to Linux. The Linux side script is in an infinite loop reading from standard input (just like it would read from the keyboard if you were running it directly - in Python, using raw_input() works well.) The script receives and processes each sample.
If that isn't fast enough, you can bypass the Bridge (needs a couple Linux configuration changes) to get the speeds Robin2 mentions. In this case, the sketch would write the samples to Serial1, and the Linux script (which would have to be started independently using a Linux mechanism) would open /dev/ttyATH0 to read the data directly. This is going to be the fastest way to get data from the sketch to Linux, but it will prevent the use of any of the Bridge functions or features.
Finally, to get the speeds you want, you may run into the speed limitations of analogRead, as mentioned by MorganS.
Thanks ShapeShifter, Morgan S and Robin2.
I'll look into and try the process method first and if it fails then move to serial method.
I'm pretty new to the linux environment, @shapeshifter can you please guide me what linux configrations do i need to change to use the serial 1 method? and is this method a 2-way or 1-way communication?
PapaMidnite: @shapeshifter can you please guide me what linux configrations do i need to change to use the serial 1 method? and is this method a 2-way or 1-way communication?
I've not done it, Robin2 is the expert on that subject, I'll let him reply.
Both methods, Serial1 and Process, are two-way communications. Process derives from Stream, as does the Serial and Serial1 classes. This is how they get the various available(), read(), write(), print(), println(), etc. functions. So pretty much anything you can do with a Serial port, you can do with a Process object (although the begin() methods to set them up are very different.)
When using Process to read from a script, it's important to set it up to be unbuffered. Whatever the script would normally print out the console when you run it manually will get sent to the sketch to be read through the Process object. However, the output from the script is normally buffered, which means you won't see the output from the script until there is enough to fill up the buffer, or the script terminates. The simplest way to make the output unbuffered in Python is to call Python with the "-u" option. For example:
python -u script.py
or, if you want to make the script executable, add this shebang as the first line of the script:
#!/usr/bin/python -u
This tell the system to run python with the -u option when running the script as a command (using the script name directly, not as a parameter to running Python.)
