Hello all,
I have used Arduinos for a few things here and there, but my first experience with the Yun is quite overwhelming and I was wondering if someone could point me in the general direction of how best to approach my project.
Basically the idea is to read a bus of 16 separate 16-bit counters up to 100 times per second, a total of at least 5000 times total. That is, within 10 ms read each of the 16 counters in series, then record the 1616 bits = 32 bytes of data. The switching circuit would be separately (counter/multiplexer changing which counter is outputting its state while the rest are high-Z), controlled by the Arduino with a "switch to the next chip" output and a "start back at the first chip" output. So in total that's 1616*5000 = 1.28 MB of data. At the end the data would be transferred to a PC, but there would be no time restriction on that. It doesn't matter where the data is stored before transferring it to the PC, though I guess to RAM is faster/easier than to microSD?
The "read the 16 counters now" signal would come in the form of an interrupt signal to the Arduino (this way I can later have multiple Arduinos which are synchronized and perform the same function at the same time, with a different set of counters).
There are quite a lot of things interacting in the Yun, and I am trying to understand the flow of everything but it's quite a lot to understand, if someone could point me in the right direction as to how best to structure a solution to this project I would be very grateful, so that I can more efficiently read the details about the relevant Yun interfaces, etc.
Thanks very much in advance.
@robertadams21,
I read through your proposal and I am going to recommend the arduino yun mini. I have not had time to purchase one or look at the specs until now. According to this article, Arduino shrinks Linux-ready Yún to “Mini” size, the Mini has the GPIO pins from the Linux-side available. Prior to this, only the GPIO pins were available from the Atmel ATmega32U4.
If you were to use the original Arduino Yun, you would have to content with the serial port speed between the Atmel and Atheros. If you use the new Arduino Yun Mini you have the GPIO pins on the Atheros and the wifi as a method to off load your data.
Other will have suggestions.
Jesse
The plus to reading the data directly on the Linux side is that you don't have to transfer the data between the Arduino and Linux processors. The downside us that Linux is not a deterministic real-time operating system and the timing of your data collections will likely have some jitter in it (it could vary from the desired 10ms between samples.)
You are talking a significant amount of data for a pair of relatively small processors. 16 counters, 16 bits each, 100 times a second is 25,600 bits per second. If you collect the data on the Arduino side, you can stuff it through the serial port fast enough, but you will likely need to bypass the Bridge library and do the communications yourself. (Bridge will likely bring in too much overhead.) You must get the data out of the Arduino side quickly, as you would fill up all available RAM in that processor in less than 200 ms.
Now, with 5000 samples, you're talking a total of 160,000 bytes, which should fit in the memory of the Linux process that is reading the data. Again, there will be some jitter in the time that it reads the data from the serial port, but that won't be an issue if the Arduino serial transmit buffer is large enough.
To get the data to the PC, do the network communications strictly from the Linuc side.
It will require some thoughtful coding, but you should be able to get it to work. But it won't work using a bunch of digitalRead() FileIO.write() calls. You will almost certainly need to resort to direct port reads to get the data, and direct serial I/O between the processors to transfer it.
Plan C:
Arduino TRE BeagleBone Black use 1-GHz Sitara AM335x processor.
The Ti AM335X PRUSS (Programmable Real-time Unit Sub System) consists of two 32-bit 200MHz real-time cores, each with 8KB of program memory and direct access to general I/O. These cores are connected to various data memories, peripheral modules and an interrupt controller for access to the entire system-on-a-chip via a 32-bit interconnect bus.
PRUs are programmed in Assembly, with most commands executing in a single cycle and with no caching or pipe-lining, allowing for 100% predictable timings. At 200MHz, most operations will take 5ns (nanoseconds) to execute, with the exception of accessing memory external to PRU.
http://forum.arduino.cc/index.php?topic=241259.msg1762850#msg1762850
Plan B:
Arduino Due + Yun Shield
Yun
Microcontroller ATmega32u4
Flash Memory 32 KB (of which 4 KB used by bootloader)
SRAM 2.5 KB
EEPROM 1 KB
Clock Speed 16 MHz
Arduino Due
Atmel SAM3X8E ARM Cortex-M3 CPU
32-bit ARM core microcontroller
Flash Memory 512 KB all available for the user applications
SRAM 96 KB (two banks: 64KB and 32KB)
Clock Speed 84 MHz
http://forum.arduino.cc/index.php?topic=241259.msg1731074#msg1731074
Plan D:
A field-programmable gate array (FPGA) is an integrated circuit designed to be configured by a customer or a designer after manufacturing – hence "field-programmable". It is preferred solution for this type of application.
All other solutions might be bandages solution in my personal opinion. But this one is preferred solution.