Show Posts
Pages: [1]
1  Products / Arduino Due / Re: LED Brightness on: January 13, 2013, 12:50:17 pm
Ah, so yes, there is a resistor on those. The documentation for the board says that you should feed between 7v-12v through the barrel jack, since the voltage regulator loses a bit when it steps the voltage down. Does it look brighter when you power the board through the USB? (5v, bypassing the regulator, iirc). If not, then, that's how bright they go. smiley-wink

-r
2  Products / Arduino Due / Re: LED Brightness on: January 11, 2013, 08:50:44 pm
The 6.6v you are feeding the Due goes through a voltage regulator and pared down to 3.3v before getting fed into the chip. The digital pins (I'm assuming you are doing PWM?) are at 3v3, as mentioned by Leon. It is also possible that your resistor (you are using one, right?) may be too large depending on the voltage rating on the LED. Not all leds are created equal.
3  Products / Arduino Due / Re: Arduino Due Keyboard, Mouse and a Control Game on: January 11, 2013, 08:47:08 pm
It is possible you may need to install the appropriate driver for the USB controller on the Due. I haven't gotten mine in mail yet, so I couldn't tell you what it needs, exactly, but I'm sure the documentation is out there somewhere.
4  Products / Arduino Due / Re: Strange delay.. on: January 11, 2013, 08:42:42 pm
I would need to see the rest of your code to be sure, but something similar happened to me with some serial communication.

Essentially, I didn't have a long enough delay in my serial receive function. I had a serial interrupt handler function that would get called before my loop() was handled if there was serial data on the line. In that function, I had a while loop checking whether Serial.available() (or something like that) and processing the data as it came in, and what would happen is that when there wasn't a byte immediately available, it would pop out of the function and run loop() again. As soon as I added a delay(1) inside that loop, it gave enough time for the next byte to arrive, and then it wouldn't pop out of the function, but would keep processing until there was genuinely no more data to be read. So, if something similar is occurring with your system, the Serial.print() creates enough of a delay that it allows more data to come in, allowing your Serial.available() to evaluate to true and continue processing.

Obviously, since I haven't seen your code, all I can do is speculate. Post your code, and we can help you debug more effectively.

Also, a bit of friendly advice. You may get more responses if your subject lines were more descriptive. Say, in your case, "Strange Communication Delay in Serial Bus, mitigated by adding Serial.print(). WTF" Also, a TL;DR is always helpful. smiley
5  Products / Arduino Due / Re: WS2801 and WS2811 based RGB LED Strips with Due? on: January 10, 2013, 02:25:31 pm
Also, I want to add that it is entirely possible that it doesn't even go in that direction. At which point, sigh. :/
6  Products / Arduino Due / Re: WS2801 and WS2811 based RGB LED Strips with Due? on: January 10, 2013, 02:16:09 pm
Ok, it looks like the WS2811 does NOT respond to signals at 3.3v. So, I'm investing in some 74LVC245 ICs (https://www.adafruit.com/products/735) to convert my 3.3v to 5v.

Unfortunately, I'm not quite sure how to hook them up. The datasheet (http://www.adafruit.com/datasheets/sn74lvc245a.pdf) implies that there is a way to do it, but it seems to conflict with the description on the adafruit product page in a vaguely orthogonal way. Adafruit gives a description for going in the opposite direction (5v->3v3), and says hook up VCC to your target voltage (say, 3v3), OE to ground and DIR to VCC. In my case, the target voltage should be 5v, but the datasheet says it only takes VCC up to 3.6v. However, the datasheet says some very vague and confusing things about how to achieve the 5v input, and possibly involves switching the directions from B->A. This is all very confusing.

So to what voltages do I connect the various bits. I want to go from Due (3.3v) -> Lights (5v)

VCC -> ??v
Gnd -> Gnd (obviously)
DIR -> ??v
OE -> ??v

and is A my input from the DUE, or is B my input?

Any help at all would be immensely appreciated.
7  Products / Arduino Due / Re: How do I determine if my Arduino Due is genuine? on: January 10, 2013, 01:58:26 pm
Maybe relevant, but both Makershed http://www.makershed.com/Arduino_Due_p/mksp16.htmand NKC Electronics http://www.nkcelectronics.com/Arduino-DUE-board_p_382.html seem to have them in stock.
8  Products / Arduino Due / Re: WS2801 and WS2811 based RGB LED Strips with Due? on: November 17, 2012, 12:04:42 pm
Ah, good point. Will try it out. smiley

9  Products / Arduino Due / Re: WS2801 and WS2811 based RGB LED Strips with Due? on: November 16, 2012, 02:35:25 pm
Quote
The would only be providing clock & data to one chip, that chip buffers the 2 lines and passes it along,  yes?
So power them from their own 5V source, connect all the grounds together.

Do I actually need to do this, if the Arduino is providing 5v power? The fewer components, the better, I would think.

Quote
At 5V, the WS2801 needs 0.8*Vcc = 4V minimum for Vih.
Run the signal lines thru a TXB0102 buffer. Only micro-amps of output current are  needed.

Or, run the WS2801 from an external 3.3V. Still just need micro-amps of output current for the control pins.

Ah! I see that the WS2801 can run from 3.3V natively. That is useful. Unfortunately (based on the WS2811 datasheet I found), the WS2811 requires 5v input voltage. So, for that one, a TXB0102 would be needed.

Thank you!
10  Products / Arduino Due / WS2801 and WS2811 based RGB LED Strips with Due? on: November 16, 2012, 01:49:20 pm
Please forgive the noob question.

First, some background. The Due ARM chip runs on 3.3v, but it can provide 5v. There are, however, stern warnings about providing more than 3.3v current to any of the I/O pins, or this could burn out the board. Fair enough. Now, I have a series of addressable RGB LED strips that use either the WS2801 (https://www.sparkfun.com/products/11020?) or WS2811 (http://www.ebay.com/itm/150931961150) chipsets that I've been using very successfully with the Arduino Mega and Uno boards. These require 5v to run. These have either 3 or 4 wires. Two are always 5v and Ground, and the others are either separate Clock and Data lines (WS2801), or a combined Clock/Data line (WS2801).

So, to my noob question:

Would it burn out the board to connect the Clock/Data lines to Due I/O pins? Ostensibly, they are only supposed to be output, but ... ?? Am I going to kill my board? And if so, is there something I can do to make my lights work?

Thanks for your help!

11  Forum 2005-2010 (read only) / Interfacing / Re: burning .hex to atmega with arduino on: October 01, 2006, 06:26:46 pm
I have also been investigating this possibility. At this point, it seems like the following things need to be considered.

First, you would need to develop software to run on the Arduino that would do the equivalent of what uisp (http://www.nongnu.org/uisp/) does.
This is not a small task, but starting with the uisp sources (http://cvs.savannah.nongnu.org/viewcvs/uisp/src/?root=uisp), it should not be too difficult.

Secondly (and somewhat trivially) you would need to connect the blank AVR chip (atmega8, or whatever) to your Arduino cum Programmer. You would do this by connecting your power and ground to appropriate places on your Arduino board, and connecting your SCK, MISO, MOSI, and RESET pins to some appropriate Digital output pins on your Arduino board.

This software should be designed to start up, and wait in a ready state until it receives communication via the serial port (or USB, or whatever) in the form of a START byte, the .hex to be burned, and ended with an END byte. After the START byte has been received, the software would begin to perform the burn to the blank AVR. After the END byte is received, the software would end the burn process. In this way, the available memory on the ProgrammerArduinio is not a limiting factor on the size of the .hex you can burn to the blank AVR. Instead, the .hex is burned onto the blank AVR as it is received by the Arduino.

I have not yet learned the uisp sources, so I cannot yet say how the burn is done in detail, but it would seem like a relatively simple thing, as long as you are not trying to support a lot of different chip configurations. It seems clear that a simple programmer could fit inside the 8k programming space with room to spare.

Thoughts? Has anyone else investigated this possibility?
 
Pages: [1]