hey gang! let me just first say that i'm very eager to get my board in and start playing around with it. however, as i wait for it to come in, i was hoping someone could shed light onto something for me... First, my application though… I'm building a motion control camera system which essentially consists of 3-5 stepper motors which are driven through a train of HIGH/LOW pulses on output pins at intervals anywhere between 200 to 800 uSec (different pins will have different frequencies). Obviously Arduino boards (using the Due currently) are perfectly suited for this task. However, its difficult to create any type of complex motion profiles without some external software (e.g. Blender/Maya) that runs a nice GUI and that allows you to visualize the camera moves in a virtual environment (through Bezier curves and what not). Then, you attach your Arduino to your computer, the computer creates the complex motion profiles and then runs through them telling the Arduino when to step (pin HIGH/LOW). So, when I came across UDOO, I thought it be perfectly suited for me: the Linux side would handle the complex motion path planning along with GUI and it would talk to the Arduino side which would step the pins with proper timing. But then I read something that confused me -- from the UDOO block diagram: "Each pin can be individually configured to be driven by one or by the other processor. Configuration is done via software" I guess what I'm wondering then, is why we need the ATMEL processor at all; I mean, if we can just throw a bunch of pins HIGH/LOW with the Freescale processor, then why add the ATSAM3x8E as well as the complexity and potential latency of communication between the two? Is it faster to control pins through the Atmel than the Freescale? I'm also concerned about speed bottlenecks between the processors when communicating the timing of the pins; serial might be too slow to send timing for 5 (or even more motors), so that again makes me think that I should do everything from the Freescale processor. I see the processors could also communicate through USB OTG; but again, if I can set any pin to be controlled by Freescale, why not just forget about the Arduino? I'm not too concerned about doing any kind of parallel processing; really the only thing that is critical in my application is the ability to through multiply pins HIGH/LOW at high frequencies. From tests, running 3 pins HIGH/LOW at 200uSec is on the limit of being attainable for the Due; so certainly being able to do that from the Freescale side (with the 1Ghz ) seems like I'd have plenty of resources. But then again, I feel like I'm missing some sort of technical insight that comes with controlling GPIO from the Freescale side. Can someone detail? Thanks for all your thoughts and insights everyone and keep up the good work!
Perhaps you don't, but I think you will find you do. A slightly longer observation: As you add complexity/layers (such as a GUI for example, which is quite a stack in Linux including Windows Managers, Compositors, X Server etc.) you *might* find performance issues. On the other hand you might not. One possible way around that is to investigate running a real time OS on the i.MX6 side. Of course on the SAM3X8E side you can just drive the hardware in real time anyway and use the i.MX6 side to do everything else, such as the UI/GUI.
Thanks for the input Jim. Can anyone else comment on how the Freescale side controls GPIO and what sort of speeds we can expect? Looking at the specsheet, it only looks like there are 7 GPIO pins used for general purpose I/O [p.11 of http://cache.freescale.com/files/32bit/ ... pdf?fpsp=1]; so I wonder if we can even access all the pins on the Due side from the Freescale processor...
@titous .. I don't know but it's certainly another very good question. I look forward to the responses in time.
Yeah, I really wish the Udoo guys would come in here and answer questions... We have very little info to really go on, and it's not like there's so much message traffic that they couldn't keep up with it.
"Of course on the SAM3X8E side you can just drive the hardware in real time anyway and use the i.MX6 side to do everything else, such as the UI/GUI." My thoughts are this is how the UDOO is intended to be utilized/leveraged. I don't think one necessarily needs the i.MX6 alongside the ATMEL. But I believe the intent is for the heavy shield comm (and to maintain full Arduino compat) is to be done by the ATMEL and have it coordinate with the iMX6 for decision making and UI.
that's what we're doing with ours. All the hardware on the Due, lean and mean. We have a LOT of hardware going onto it. The i.MX6 will be quite busy providing the brains and GUI. Without UDOO we were thinking of a low powered PC or 1-2 rPi plus a small network of 32bit ARMs. So for us, UDOO is perfect. No doubt overkill for many, up to everyone to select the right tool for their own needs of course.
yeah, that's what i'm thinking will be the approach of most. but then again, if the hardware can also be handled by the Freescale side, then why mess with the bottleneck of serial? UDOO admins please give us some insight into this!!
Hi guys, let me state this first: the revolution introduced by UDOO is all about the cohesistance of the two CPU in one single board, the Freescale iMX6 which is the brain and the heavy tasks guy while the Atmel SAM3X takes care of the real time tasks. The Atmel CPU makes a lot of sense in applications where real-time processing is the main focus, for example Atmel can manage the hardware and check sensors etc while the iMX6 runs the user interface and does data elaboration. More mixed applications could involve the Atmel taking care of basic sensors with easy data process while the iMX6 on his GPIO takes care of more complex sensors which may require more processing power. Also, the Atmel CPU makes sense because enables the user to access the Arduino ecosystem in terms of software development and hardware compatibility (e.g. shields) simplifying the designer's work. Consider also that while running Android, handling the GPIOs isn't as easy as while running Linux and again the Atmel CPU comes in handy. Last but not least, the iMX6 is a really powerful CPU but the Atmel is better in real time processing. That said, is also true that there are plenty of applications where the iMX6 CPU is enough by itself. Keep the conversation going, The UDOO team!
The iMX6 CPU can manage 53 GPI/O of the Arduino Due compatible pinout which are shared with the SAM3X. Find more info here http://www.udoo.org/downloads/#tab5 in "Pinout explained" section.
In few certain scenarios where very high speed communication is needed, the serial connection could represent a bottleneck, that's why we are working to make the serial to work up to 1Mbit/s and also on a new Linux driver that will allow to use the USB connection as is actually used under Android with the ADK protocol.
That's handy. I was thinking of only passing the differences in readings/state (the delta) from the SAM3X8E or using two serial connections to get around that bottleneck. Increasing the headroom dramatically would be great.
As far as I can tell, the only thing that absolutely *requires* using the SAM3X is analog I/O (the twelve ADC and tow DAC pins, A0-A11 + DAC0/DAC, on headers J11 and J15). These are among the few pins wired only to the SAM3X chip. They can probably be repurposed as normal GPIOs too if desired, though I haven't tried that. The SAM3X also has three times as many PWM channels, 12 to the i.MX6's 4, and an extra I2C bus of its own on unshared pins. As others have mentioned, though, unless you want to try porting RTLinux or some other RTOS to the i.MX6, any sort of hard realtime I/O is probably best done on the Atmel side, since you have the chip there anyway.
