So, from Massimo's presentation at Maker Faire this weekend, the word is out that the Arduino Due is to finally be released on the 22nd of October for US $49. The board will run @ 84 Mhz based on Atmel's ARM-Cortex M3-processor based MCU (32-bit) SAM3X8E. In addition, it appears Uno/Mega shields will be compatible with the Due too because the form factor has been maintained.
That's pretty exciting for me as it is, especially given that some intensive applications (e.g. real-time camera imaging/recognition) can become convenient now.
But my question is: What about compatibility of libraries/code? -- will they mostly transition seamlessly too? If not, then for any of the enormous number of existing libraries and code to be ported to the new ARM 32-bit MCU of the Arduino Due, what kinds of things will users/library-creators need to do on the software side?
Since I have no experience with ARM microcontrollers or the architectural differences, I am wondering what factors might be involved.
By the way, here is the one-hour video of the Maker Faire presentation by Massimo Banzi & Alf-Egil Bogen:
With the SEL_SdCard pin held LOW (active), I can write to the SdCard, then once done, pull the SEL_SdCard pin HIGH.
Then, with the SEL_74HC595 pin held LOW, I can write to the 74HC595 registers, then bring SEL_74HC595 pin HIGH. The chosen LEDs now turn ON or OFF as was instructed (/written to the registers), and are maintained that way (until the shift-register is communicated with again).
And then continue by starting again with the SdCard when necessary, then the 74HC595, and so on.
I am interested in interfacing my Arduino to both:
a 74HC595 shift register (via SPI), to control some LEDs
and an SD-card (also via SPI)
Since they share the same SPI port, based on my understanding, I would need to Chip-select (CS) when speaking with one versus the other.
With the SD-card, this is simple because it has a CS pin. But the 74HC595, according to the datasheet, doesn't have one (although it has an Output-Enable pin).
I want to ensure two things:
that writing to the SD card won't randomly turn on and off various LEDs because of interfering SPI communication
and likewise, that controlling desired LEDs via the shift-register won't cause weird activity on the SD-card because of interfering SPI (but I think I'm safe in this 2nd case, because the SD-card has chip-select).
What might be a way to accomplish this?
(PS: I could bit-bang the 74HC595 but that would cost me extra pins that I could use for other things! Hence I'm using SPI.)
Indeed. Upon multiple tests on various LEDs (of same model), I noticed: (1) The "turn-on" voltage varied a bit among them and (2) The LEDs did turn on at around 3V, but only when the current-limiting resistor was large enough to ensure a pretty small current (which in this LED's case was still enough to give me indication-sufficient light)
I would like to know how much current this shift register will draw for its own operation (i.e., EXCLUDING the current drawn by LEDs/whatever is connected to it). In other words, if I have all connected Leds switched OFF, what will be the current drawn by the 74HC595 alone?
Which parameter should I look for in the datasheet? (It lists multiple Current parameters, and I am a little confused)
Robert, The simplified explanation of the LED operation clarifies a lot! But that said, since the forward voltage of an LED appears to be lower at smaller forward currents (even looking at the curve on the datasheet), isn't it thus true that the Green and Blue LEDs would still light up (given that, in my case, I'm planning to do a constant current of only 2 milliamps) ?
The Blue and Green "parts" of this LED have a forward voltage specification of 3.20V (Typical) and 4.00V (Maximum) which is stated for a forward current of 20 mA.
I am planning to use a TLC5940 (LED driver with constant-current sinks) at VCC = 3.30V.
Note that I will be running only a current of around 2 mA through the LEDs (very small current because these LEDs are extremely, almost painfully, bright!)
With the above in mind, would the 3.30 V supply of my board (being less than the Maximum-case of the LEDs' forward voltage) be an issue, or should this setup work reliably? I am still trying to learn about LED operation/the forward-voltage concept.
You'll probably need much lower-frequency waves (kHz range) than standard wireless transmission (which might be 2.4 Ghz or several hundred Mhz), if you want to transmit data underwater without significant attenuation/absorption.