text:
Arduino serial port programming
I bought an Arduino-on-breadboard kit. I have several PCs with serial ports, and now I'm being told I need a USB-to-serial converter. I thought I was ready to start uploading sketches, so how can I do this?
I'm able to understand serial communications and am capable of wiring a MAX232 chip into a breaduino if necessary, but I'm not sure it will work, so to save some time I'm asking, mostly because I was unable to figure it out with Google searches alone.
PS: I also have a stk500, but then I would be out of the easiness of using Arduino sketches and the programming language. I need the fastest route to prototyping/testing my sketches.

The arduino IDE supports the stk500: http://arduino.cc/en/Hacking/Programmer

I would highly suggest you also buy an arduino Uno. The breadboard version is great but the uno board will help you verify the rest of your tools and software is setup correctly

thanks for the help guys, will post pics as soon as I have some working prototypes!

@PeterMorensen - please don't make trivial edits to four year old questions, it serves no purpose but to create noise on the overview page.

An RS232 port wired via a level converter (as you mentioned max232) and a 1uF capacitor between RTS and "Arduino reset pin" Getting started with Arduino.
The capacitor is to trigger a reset on the Arduino so the bootloader kicks in and awaits a "Arduino sketch" via the serial port.
Your setup is AKA "Arduino Bare bone".

If your PCs have real RS-232 serial ports (rare these days), you can use those directly.  Otherwise, you will need a USB<->RS-232 serial adaptor cable.
Correction:  I thought my Arduino did have an RS-232 port, but I was thinking of another board.  If your board only has a TTL-level serial port (ie. direct from the ATMega328), then you need either an RS-232 level translator, or a USB<->TTL serial cable.  A suitable cable is available from Adafruit (and no doubt, others).

Can you really connect a RS232 (either real or fake 0-5V ones) directly to a ATmega328 UART port? I thought one had to put a level converter in between them (ie. MAX232).

The original Arduino models did have RS232 serial ports and connectors, rather than the USB connector and on-board USB-serial converter of today's boards.

You cannot connect RS232 to an ATmega328 port (successfully anyway) because the polarity is inverted. With RS232 a 1-bit is -12 V (or thereabouts) and 0-bit is +12 V (or thereabouts). See https://en.wikipedia.org/wiki/RS-232. In other words, a one bit is a lower voltage than a zero bit. Even the 0-5V ones are still going to have inverted logic. SoftwareSerial does have an "inverse_logic" argument on the constructor which might help if you had the 0-5V serial input.


text:
Issues programming Arduino Uno with Sparkfun's MAX3232 breakout board
I'm having an issue programming the Arduino Uno with Sparkfun's MAX3232 breakout board attached.  Sometimes the Arduino IDE won't see the Uno plugged in.  I'm thinking of  connecting a switch to the GND or the 3V - 5.5V pin so I don't have to disconnect the breakout board when programming.  Are there any better solutions?
Sparkfun link: https://www.sparkfun.com/products/11189

Switching off power to the MAX2323 might work. I assume you understand the MAX2323 is connected to exactly the same pins as the host PC, via USB, and that is the problem source. Yes? Would you post a link to the MAX2323 you are using? Is there a schematic diagram? I would like to see the schematic diagram so that I could see if the MAX2323 might still present a load to the Tx Rx lines when it is powered off. For serial communication, the Tx and Rx lines may be pulled up by resistors, and you would like them to be defeated or disconnected too. We should probably look at the MAX2323 data too

Hi gbulmer.  I meant the MAX3232 breakout, but I think you probably figured that out.  I've included a link to sparkfun's breakout board to the original question as well.

Thank you for the schematic. The breakout has no resistors on Tx or Rx to cause any problems. It looks like switching off power would work, and it is an okay solution. To be more sure, we need to look at the datasheet for MAX3232. I would expect it to be designed well enough that it won't be harmed by having lines driven while it is off, or that it could pull-up a signal line while off, but it is worth a check. I apologise, but I am off till tomorrow. Good night from the UK.

Good night, thanks for the help and tips!

PS - My alternatives were: use an enable/disable on the RS232 converter (there isn't one, so that is dead), disconnect MAX2323 Tx (as that interferes with the Host PC's signal), or disconnect both (if necessary).

Off to bed for real now :-)

@NickAlexeev this should not have been migrated, as it is an EESE appropriate question primarily hinging on understanding of the MAX232 IC, not the "Arduino-ness"

Switching the power off to the MAX3232 appears to be okay.
There are no components connected to the Rx and Tx lines on the breakout board to complicate it.
Unfortunately the break out does not give access to pin 1, EN which is "Enable Control", or pin 18 SHDN "Shutdown Control". AFAICT they could have been used to turn off the receiver and transmitters of the MAX3232. That would have been ideal. Maybe contact Sparkfun and suggest the improvement to put them on pads for folks to use, and offer to beta test it :-)
The datasheet for the MAX3232 says that it is able to withstand a continuous short on the Tx line, so it sounds pretty tolerant to minor abuse. Also, the diagrams dont show any pull-ups on the MOS/TTL Tx line. So I would expect it t be okay if you shut the power off, but continued to wiggle the Tx Rx pins.
An alternative would be to disconnect the Tx pin from the Arduino, so that the MAX3232 wouldn't interfere with the host PC's USB comms. It sounds like the thing on the RS232 connection will ignore data it receive while the Arduino is being programmed. If that is not true, then it would need to be disconnected too.
At the moment, switching off power looks like a reasonable approach.
Disconnecting Tx and Rx also looks reasonable, and slightly better than powering the MAX3232 off.
Do you know how you want to do that?
NB: The MAX232 datasheet shows that part should not be driven by a high when the chip is unpowered. However the MAX3232 datasheet does not carry that warning. My preference would be to use the MAX3232 signals 'EN' and 'SHDN'. However those are not available on the breakout. I'd recommend having the part powered, and disconnecting Tx and Rx from the Arduino.

Hey, you're still awake!  Thanks for interpreting the datasheet for me, I'm not very good at that.  I'm thinking of just a simple switch at either the GND or power.  I can also have switches at the RX and TX lines like you suggested earlier.  I think I'll do more testing with the things you suggested.

@ChrisStratton - Is MAX232 a typo? The question is about MAX3232. If it is a typo, that is an extremely important point, and I will correct my answer. I looked for that information, but may have missed it.

Sorry, I did indeed look up the wrong part, and the specs on the MAX3232 appear to be different without the MAX232's input-above-Vcc restriction.  It would be interesting to use an ammeter to see what if any current the chip draws through the TIN pin when unpowered.

@ChrisStratton - I amended my answer to show a WARNING pending clarification. I will remove that warning.

@ChrisStratton - I have amended my answer. I have removed that warning, but kept a note to reduce the chances of the same concern being re-raised.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
Release power to stepper motor
I'm driving a large stepper motor via a GeckoBoard G213V and arduino UNO and I have that mostly working fine. However, I'd like to 'release' the stepper so it can swing freely.
There's two reasons I want to do this:
1) (Most important) I want the rotated object to naturally swing back to the 0 position thanks to gravity.
2) The motor gets hot - I'd rather not juice it when it should just be sat at 0.
Anybody know how I can do this? I'm using the AccelStepper library so a solution compatible with that would be ideal.

btw - there really should be a 'stepper motor' and/or 'stepper driver' tags available. Be great if an admin could create and add such to this post.

From the documentation:

TERMINAL 7 Disable
  This terminal will force the winding currents to zero when tied to the step and direction controller +5V.
The DISABLE input on the G213V is optically isolated and requires logic “1” to DISABLE and logic “0” to ENABLE the drive. Once it is disabled, the motor windings are unergenized[sic] and the motor freewheels. (emphasis mine)

So, feed the disable input a high.

Thanks - trying this now and it doesn't seem to work. I wired the DISABLE terminal to pin 5, called pinMode(5, OUTPUT) and whether I digitalWrite(5, HIGH or LOW) it always free wheels. Any ideas?

Does it stop freewheeling if you disconnect it?

total n00b failure, pin 5 is used by accelstepper. Moved to 7 and all is good. AccelStepper also has setEnablePin, disableOutputs and enableOutputs methods. Easy! Since the gecko has a DISABLE pin I had to call setPinsInverted(false, false, true) to invert the enable pin.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Visual clock with millisecond display refresh rate
I need to create a millisecond capable visual clock - I will use the clock for visual frame synchronization of multiple cameras. I found this project but it seems to use a LED display that only has resolution of one 1/100th of a second. Not sure if the digits can be shifted to show milliseconds.
I guess I need to use LED instead of LCD display because of the ms refresh rate? Can someone help with my project please? I am a SW programmer and have zero experience in HW programming. So I am new to Arduino too - I have not done any project at all yet. I do own neither Arduino nor LED display.
Thanks!

What is the project for? Take another project an modify it. It only really needs to show the right mills when you stop it so don't worry about the refresh rate.

I need to visually measure synchronization difference of a stereo camera, so I actually need ms refresh rate. Edited the question accordingly.

Thanks for the clarifications. What is the maximum time you would need to measure? I have seen this done with a ring of white LEDs going around in a circle.

Well what I basically do so far is try to lock my FPS to Xs (now 2s) in OpenCV and just do a visual check of both camera streams next to each other on a PC monitor. So I actually need only last seconds digit + milliseconds (example: 5.123). But in the future I may want to test a video sync and maybe let it run for hours - however probably same amount of digits would suffice since the sync is not expected to drift by thole 10s. I would prefer LED display with numbers, instead of pure 0/1 led "bulbs". Say I expect measurement in range of 100ms so I would need 100 pcs of simplest LEDs anyway.

"Say I expect measurement in range of 100ms so I would need 100 pcs of simplest LEDs anyway." No, actually you do the LEDs in binary and you can get 256ms with 8 LEDs, 512ms with 9, 1024 with 10 etc

While it may be the simplest setup possible regarding the readability of the LEDs I think I dont want a binary output. I need to be able to read time quickly not having to convert it from binary to decimal.

Most cameras run at 50 of 60 frames per second. That means that 2 numbers appear during the recording of one frame. If those numbers are e.g. 6 and 7, the frame will probably show something like a 8. In other cases weird thinks will appear in the last segment, rendering it completely useless, and giving you only 1/10th of a second accuracy. You could use the 7-segment for the first few numbers and a circle of leds for the 1/100th seconds. I'd suggest buying an arduino with more pins than the arduino uno, as you'd need quit a few pins for all those leds.

you could just get a binary counter IC, binary to 7 seg IC, and 555 timer.

@Gerben: You are one order of magnitude too big - 60 Hz yields 16ms resolution which is aprox. 1/100th of a second. But I want to get 16x more accurate - from 16ms to 1ms. The idea of having circle of LEDs is nice though - I could have one circle for 1/100th digit and one for 1/1000th (ms) digit. I could at least measure the exposure time like that if more LEDs shine within one circle.

Unless you have high speed cameras, I don't see the point. Also cameras have a "rolling shutter" creating inaccurate led-readings.

what range of shutter speeds do you plan to use?

You need to define the parameters of the problem more clearly.
First, and most importantly, what is the shutterspeed you'll be using? If it's longer than 1 ms, then you can't use a 7-segment display to show the MS count, since the camera shutter would be open for multiple values.
Even if your shutterspeed is a single MS, your shutter won't be synchronized with your timer, so sometimes the shutter will be open when the display switches. That can even happen with the seconds digit of your time display.
If you're using a video camera, assume the frame rate is 60 fps, which gives a likely shutterspeed somewhere around 16.6 ms. That's way too long to display ms time values using 7-segment displays.
The ring of LED idea is good, but I would tweak it.
Here's what I would do: Build an LED clock to display whole number seconds. Don't multiplex, use latches and drive each 7-segment display constantly. (There are off-the-shelf CMOS chips that are latching 7-segment drivers.) If you only care about the 1s digit of the second value, only use 1 7-segment display. That will make things easier to wire.
Use 3 rings or columns of 10 LEDs for the MS display: tenths, hundredths, and thousandths. I would lean towards using columns since it would be visually easier to read.
The display will show your seconds as numbers, and 3 columns of 10 LEDs, showing the sub-second time range in 10ths, 100ths, and 1000ths. If the shutter opening spans multiple MS, as it will very likely do, all the LEDs that represent the sub-second time will be lit in the image, so you will get a nice clean visual image of the time SPAN that the shutter was open (All the LEDs from the start to the end of the shutter opening will be lit.)
You could drive the 3 columns of LEDs using 3 4017 divide-by-10 counters. These chips have both a 1-of-10- output, which will drive an LED, and a count/10 output, which would feed the next stage.
Write Arduino code that generates a short positive pulse every MS. Feed that into the clock input of the 4017 driving the thousandths digit. Feed the out/10 output of that chip to the clock input of the hundredths 4017, and the output of the hundredths 4017 into the clock input of the tenths 4017.
You can drive the whole ms display with 2 Arduino lines: The ms clock, and a reset line tied to all your 4017 counters' reset lines. To start timing, first pulse the reset line to zero them all out, then start your ms clock.
My CMOS cookbook doesn't say how much current the 4017 will put out to it's 1-of-10 outputs, but I bet it's enough to drive a display LED directly. You could wire all 10 LEDs in each column as common cathode, with a single current limiting resistor between each column's common cathode and ground.
You could probably set up a timer pin on the Arduino to generate a millisecond pulsed output, but that's not something I've learned how to do yet.
Occasionally you'll get a whole second 7-segment display with 2 different values captured in a frame, but that will be rare, and you will be able to figure out what happened from the frames immediately before and after it. (Previous frame shows a 5. Current frame shows a 5 and a 6 superimposed, so it's a mess. Conclusion, this frame shows the end of second 5 and the beginning of second 6.)

Thanks for a very long and valuable answer! As I am new to HW I dont even know what a HW "counter" (like the 4017) is. So to bypass the counter I guess I could connect everything directly to GPIO outputs on the Arduino board itself? If I would do all in LED without 7-segment (40 LEDs) does that mean I need 40 GPIO pins + 1 for the input voltage? Which board can provide 41 or at least 31 pins (I could omit the seconds probably)?

I mean, since I am a SW programmer it would be easier for me to implement all the necessary logic in SW only without any integrated circuits (HW counters etc.).

Yes, you would need 40 pins to do it directly from the Arduino, plus 7 pins for the 7-segment display. Do yourself a favor and buy a copy of the "CMOS Cookbook." It's very helpful for stuff like this.

I'm a programmer too, but I don't think you will be able to do that. You'd need 47 logic lines. The chip I mention, the 4017, is very easy to use. You give it a clocked input, and it sends a logic 1 to 1 of 10 outputs, and switches outputs on each pulse of the clock. Then it resets back to the beginning and starts again. It also has an output that is a clock count that's 1/10 of the input frequency. Check this link for an explanation of using the 4017: http://www.doctronics.co.uk/4017.htm

It might be counterintuitive, but it's actually easier to do this sort of project with ICs. You will drive yourself nuts trying to wire up 47 output lines to an Arduino, then troubleshoot everything. The Mega 2560 does have enough I/O lines, but then you won't be able to do much else with the board.

Thanks for valuable comments. I admit design with ICs really is simpler. What if I do not want to loose the 1ms precision beyond the ms-decade (beyond 1/100th of s)? I could run more than 10 LEDs in 1ms interval - say 50 or even 100 so that I can measure sync even with longer shutter speeds and still not loose precision. Say I would need a "counter" with 50 or 100 (1ms) outputs, or chain multiple decade counters somehow. I may run a 2ms or even bigger step to reduce number of LEDs but still get sub 10ms precision for longer shutter.

I think I need something in this direction: http://www.instructables.com/id/16-Stage-Decade-Counter-Chain-Using-two-4017-Chi/

I see, I can chain the counters but I will loose one stage since they have to be chained on 9th pin not to loose the frequency... so for 50 LEDs I would need 6 of them not 5. Is there a counter that has more than 10 outputs? Maybe 20 or more? Or can this be solved differently?

In case someone is interested you can do more than 10 LEDs by cascading multiple 4017s - see here: http://electronics.stackexchange.com/questions/33652/how-to-cascade-4017-decade-counters

I think Duncan C's 'user interface' is excellent. It is clean, simple and elegant.
Using individual LEDs is much better than digits. IMHO it is much more flexible, and avoids the ambiguity of digits.  +1 for the concept.
However, I would make it 'softer', and use a lot fewer components.
By going 'softer' you could have more flexibility, which would give you the ability to expand the useful resolution of the 'clock'.
Duncan C made a very important point that digits are useless if a digit changes during the photograph. However, that is still a potential problem with the three lines of LEDs. When the exposure time is longer than the duration of the 'lower digit' line of LEDs, information is lost.
Certainly Duncan C's design could be speeded up or slowed down to adjust for that, but it has a built in resolution limit because it counts in 10's. Imposing the digital idea of '10' on an analogue system (which is similar to a child's abacus) loses some of three inherent flexibility in the fundamental superiority (in this case) of an analogue display. I suggest making it 'soft' so that the system can be 'tweaked' in software after the electronics are completed.
Instead of fixed function decade counters, use shift registers . Then there is complete flexibility to change the 'user interface' in software.
To reduce the number of components use shift registers designed to drive LEDs.
For example, Texas instruments make many LED-drivers. The lowest cost ones, in Dual-In-Line packages (which can be used in a breadboard, and so would be easier to prototype) that I found on RS were TLC5916/TLC5917. Each device drives 8 LEDs, so Duncan C's design would use 4. This is more expensive than decade counters. However, I think the cost (about 5GBP) may be worth it.
One benefit is they are 'constant current' drivers, and so eliminate the current-limiting resistors on each LED. Each device uses one resistor to program the current for all 8 LEDs. That won't save much money, but it will save a lot of wiring.
These shift registers are fed a pattern of data bits, one at a time, using a second 'clock' signal to tell the shift-register when the data bit is valid. Toggling the clock loads the data bit. So you could cascade them, end-to-end, exactly like cascaded counters. To reduce the CPU load, the input to the chain of shift registers could be loaded autonomously, 8 bits at a time by using the SPI peripheral in the Arduino.
Alternatively, you could use 4 pins to load data simultaneously, with one pin driving a shared clock. Those shift registers can operate much faster than even Arduino assembler (upto 30MHz/bit). So this needn't take much time.
The outputs of the shift registers do not change until a further signal is sent. Then they all change output simultaneously. So your cameras won't be confused by seeing the data being loaded.
So there is more software complexity than cascaded counters. However, there is no constraints on what data they show. For example, you might decide that you would like 20 LEDs worth of resolution, so that cameras have a wider exposure time and the frames can still be synchronised or 'positioned' relative to one another in time.
Anther advantage of this 'soft' behaviour is, you could add lots more LEDs and get pretty much any resolution you might need, using exactly the same hardware technology.
This approach shares an advantage of Duncan C's design. Time is indicated by discrete points of light, and not shape. So it should be relatively straightforward to use image processing to process images. That might be very important if the cameras are video cameras.
Edit:
To clarify a few points.
It is purely software which determines the behaviour of the LEDs in a shift-register based approach. Hence it is practical and straightforward, to simulate decade counters. So the 'user interface' can not be worse.
The complexity of a chain of shift-registers is the same as decade counters, if you want to use them that way. However for a few pins more, the shift registers could be loaded independently, which might have some benefits.
Using constant current LED drivers reduces the number of resistors to wire by a factor of 8. TI and others sell devices with 16 and 24 LED drivers, so the number of packages might be reduced.
The decade counter has a built in restriction. Not suprising, it gives no more than 10% resolution. However if you need 5%, it can't do it.
The shift-register-based electronics could emulate a 'clock face', so if 5% is needed, use 20 LEDs for that part. If 1% is required, add some more shift registers and LEDs
Summary:
Duncan C's concept of using an 'analogue abacus' display is, IMHO, a more robust user interface than LED Arabic digits.
However, IMHO a hard-wired implementation using decade counters is an unnecessary restriction, limiting resolution. Shift registers make the display 'soft'. Wiring up shift registers is the same complexity as decade counters. Using LED drivers, saves a lot of wiring.

Your suggestion of shift registers would be more flexible, but I think it's waaaay past the OP's comfort level in working with hardware. He pushed back on my suggestion, which would use 3 chips and very few connections. As for the resolution of my suggestion, if the shutter is open for more than 1 MS, a range of LEDs will be lit, showing the start and end time for the shutter. If the shutter is open for 5 ms, 5 of the thousandths LEDs will be lit in the picture. Beyond 10 MS, you'd lose MS level of detail because all the "thousandths" LEDs would be lit, but I think that's ok.

@DuncanC - 1. Using shift registers can be exactly the same electronic complexity as decade counters. 2. using LED drivers removes 26 components, which is quite a lot of extra work to build and debug. 3. Kozuch wrote "I am a SW programmer ...", so shifting complexity to software appears to be the most helpful thing to do. 4. It is straightforward to emulate a decade counter in software, so the user interface can't be inferior. I agree with your analysis. My point is extremely simple and pertinent; the user interface is improvable to suit the application after the electronics completed.

your point on flexibility is well taken. What 26 components does your approach remove, though? If you read my description carefully, I recommend driving the LEDs directly from the 4017, and wiring each set of 10 LEDs with a common cathode and a single current limiting resistor between each common cathode and ground. Only one LED in each "decade" will ever be lit, so that should work perfectly. My design needs 3 chips, 3 resistors, and 30 LEDs. LED drivers would eliminate the 3 resistors, but use several more ICs.

Actually, after reading up on the TLC5916/17 (and the related TLC5925) I found that it was both a shift register AND LED driver in 1 package. Each chip takes a resistor that sets the output current for all the LEDs it drives, so I think the component count would be nearly identical. If you used two TLC5925's (each of which will drive 16 LEDs) then you'd need one less current limiting resistor, but a difference of 1 or 2 resistors is not important.

Assuming you camera's shutter is fast enough to capture a display updating every millisecond:
Get individual digit seven segment (LED) displays. The ones with multiple digits together are usually multiplexed and that might not work for your application(the multiplexing frequency would have to be higher than 1000 Hz or only one/some digits would be visible at a time). Using single digit displays, hook up each digit to a shift register such as the 74HC595. Then you only need two Arduino pins to control each digit (Data and clock, latch clock can be shared by all the shift registers). Use protection resistors for each individual segment diode and mind the current limit of the shift register when lighting all segments.
At 16 MHz you have 16000 instructions per ms so that shouldn't be an issue.
I don't know too much about LCD displays, but with LED's and a latching shift register transitions should be update pretty much instantaneous(from a millisecond perspective).

No, you have 16,000 instructions per ms. (16,000,000 per seconds / 1,000 ms in a second)

Yes, you are right, corrected the answer(you are also welcome to edit).

You wrote "The ones with with multiple digits together are usually multiplexed and that won't work for you application(only one digit will be visible at a time)". That is likely incorrect and may be misleading. For example if the application is a video camera, the 'shutter speed' is 16ms or 20ms. Even at 1/1000 of a second, one millisecond, there is enough time to draw all of the digits of a multiplexed LED, so that it looks fine.

Except that the display update isn't going to be synchronized with the shutter, so when the display changes, a given picture will likely contain lit LEDs from both values. If the shutterspeed is 20 MS and the clock changes it's screen every MS, the picture will capture 20 different values, which will be an indecipherable mess.

@gbulmer I didn't consider the shutter time, but it would have to be fast for a 1 ms timer display. I usually multiplex at 200 Hz(whole display) when done on the MCU, to avoid burning too many CPU cycles, but of course it could be done faster or with a dedicated driver IC multiplexing at 1000+Hz. I updated the answer to be more elaborate.

@user2973 - I think my answer adds to Duncan C's, which I believe is a very good way to go. Having said that, I think it is completely feasible to update the all of the digits in a multiplexed display at 10kHz or faster to avoid any shutter speed problems, using less than 20%. However, Duncan C's approach is much more robust than human readable digits, so I'd still recommend doing that. My answer improves on the flexibility and electronic complexity of Duncan C's implementation.

@DuncanC - my comment was addressing the assumption that "(only one digit will be visible at a time)" user2973 has updated the answer to incorporate my comment. I fully agree with you, using something more 'analogue' is much better than arabic digits. Your proposal is like a child's abacus and is demonstrably superior to arabic digits for many purposes.


text:
Can I use this pinhole camera with arduino?
The pinhole camera is a 420TVL, 3.7mm Passive Infrared Detector Color Covert Security Camera. Can I use this camera with an arduino creation?
Things I don't know to answer the question:

Does the power need something special arduino can't offer?
Is the arduino powerful enough to push the video feed/photos to a computer or any other method to video/photos.

Here are some specs from the site:

Sensor   1/3" Sony Super HAD II CCD
Picture Elements  NTSC 768x494
PAL 752x582
Horizontal Resolution 420 TVL
Minimum Illumination  0.001 Lux
S/N Ratio more than 50dB
Scanning System   2:1 interlace
Synchronous System    Internal, Negative sync
Auto Electronic Shutter   NTSC 1/60s ~ 1/100,000s
PAL 1/50s ~ 1/100,000s
Gamma Characteristics 0.45
Video Output  1 Vpp, 75 ohms
Auto Gain Control Auto
Power / Current   DC 12V (±10%) / 150mA
Lens  3.7mm Taper Pinhole Lens

Is it possible? They're on sale but I don't want to throw money away and find out that they don't work with any arduino. Also, I don't have any setup for this to be plugged into. Therefore, I'm not tied down to previous creations the cameras need to fit in.

Without looking at it, it sounds like it has a composite output, therefore the Arduino would not be involved with it at all.

The problem with your question is you need to define "use" because you definitely can connect that camera to an Arduino in a few different ways. For example, you could use an Arduino to simply send the video stream to an SD card, making a cheap camcorder. You could use the Arduino to analyze the images too, but that's obviously going to be more complicated. You need to describe your application. I'll remove my down-vote when you do that.

No, you really can't use it, definitely not directly nor indirectly in any advantageous way.  The problem is not with the question which is innocently uninformed, but with the mistaken suggestion that it could be used.

No, you cannot use this with an Arduino without additional hardware in between, and even with it, not as more than a still camera (or maybe low quality video for one of the ARM- rather than ATmega-based boards).
The first problem is that this camera has a high speed analog output called composite video.  It is basically what would be fed into a modulator to produce an old-style analog TV signal.  Capturing this digitally requires an Analog to Digital converter (ADC) capable of several million measurements per second, while that on the classic ATmega-based Arduino tops out at around ten thousand.
But let's say you had an additional Analog-to-digital converter to put in between this and your arduino.  The next problem is that the data rate out of the camera will be too high, and the Arduino won't have enough RAM memory to buffer it.
In theory, you could get a "frame grabber" consisting of an ADC and its own buffer memory, which would take a still snapshot of the video and allow the arduino to read it out more slowly.  But you can buy cameras which already do that with their onboard electronics, and allowing something like an Arduino to read the still image data out over a moderate speed serial interface.
Even the ARM-based arduino boards would be taxed to keep up with the output of a video ADC and do much of anything useful with the results - typical digital cameras do not record raw images to SD card, but do JPEG compression within a frame.  When cheap digital cameras operate in video mode, they compress each frame of the video before storing it (just as with stills - they do not compress between frames in the manner of real video recorders), and are able to get that processing done in time because the actual computing hardware is optimized for it in a way that none of the Arduinos are.
If you want to experiment with a camera on a development platform, there is one with a high speed digital interface sold as an add-on for the Raspberry Pi board.  Or you can use a more inexpensive USB webcam with that.

So, Radio Shack is flat out full of crap about this then? http://blog.radioshack.com/2013/01/radioshack-camera-shield-for-arduino-boards/

Yes, I expect you can use radio shack's serial, digital interface camera to record stills to a card, even slowly with an Uno, and have allowed for such modules in my explanation.  But this question is not about radio shack's module, and radio shack's module does not suggest any reasonable means of interfacing the analog camera which this is about.

There is an ANALOG camera on the freeking board, do you not get that!?

The connection from the camera to the other IC is, in fact, digital, not analog.  The other IC then sends but cannot receive a composite output for external consumers.  That RS board is not the topic of this question anyway - if you have concerns about it, post your own question.

Regardless, at some point, with EVERY camera, there is a CMOS or CCD sending an analog signal. You can figure out how that's done and you can do whatever you want at that point. I'm sorry if you don't like that, but it's a fact.

@Jasmine - when that is done within the "camera" chip such that the analog signal is not exposed and not read by anything else on the board (unlike you, I read the actual IC data sheets to determine this fact), it's not in any way helpful for someone such as the poster trying to work with a camera which has only an analog output.  What you presented has possible merit as a complete alternative, but it is not a solution which would make the answer to the question actually asked "yes".

Thank you. I can't stand it when people say something can't be done when they are looking at a device that does it.


text:
Can tx and rx pins on the uno be used like regular digital pins?
The uno has digital pins marked 0-13.
0 is marked as rx and 1 is marked as tx.
Can these two pins be used as regular digital pins if i am short of digital pins?

If you are short of digital pins you can aways use the analog pins. They also work as digital pins.

Yes you can perfectly use these 2 pins as long as your program does not use Serial.
EDIT: Serial data over USB goes through copper traces connected to the rx and tx pins, connecting them to the USB to serial converter chip.

My program is using serial, but pumping it through the usb. Not out of the rxtx pins. Is this still a problem?

It is the same: USB data is passing through RX/TX pins :-(

Ok thanks for your great answer and clarifying these points

Also you will probably want to ensure these wires are not connected when programming the Arduino. Otherwise you may have problems.

You can, but it will disable the serial port.

No, it's the other way around: the serial port has higher priority. When you enable it with Serial.begin(), you are disabling the normal port operation (pinMode(), digitalRead() and digitalWrite()). With one exception: you can set the RX pin to INPUT_PULLUP, rather than INPUT, which is the default. C.f. the datasheet of the ATmega328P, especially the sections Alternate Port Functions, Data Transmission – The USART Transmitter and Data Reception – The USART Receiver.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
How can I declare an array of variable size (Globally)
I'd like to make three arrays of the same length. According to the documentation, Arrays must be defined as int myArray[10]; where 10 can be substituted for a known length (another integer), or filled with an array {2, 3, 5, 6, 7}.
However, when I attempted to declare a value int arrSize = 10; and then an array based on that size int myArray[arrSize];, I get the following: error: array bound is not an integer constant.
Is there a way to variably determine array sizes, or do I just need to hardcode them? (I was taught hardcoding is bad and something to avoid at all costs.)

I had a similar problem and did this. I am learning too so can't say if it is valid solution or not but it worked. See below part of code using vectors, it took me quite a bit to start to understand them and I am still not an expert by no means: #include  #include  #include  #include  #include <string.h> using namespace std; int main() { string name; string address; string town; string country; string answer; vector<vector> personData; for(;;) { vector myTempData; cout<<"enter name or n to exit"<<endl; getline(cin, name); if(name=="n") { bre

Your question has 2 parts actually.
1/ How can I declare the constant size of an array outside the array?
You can either use a macro
#define ARRAY_SIZE 10
...
int myArray[ARRAY_SIZE];

or use a constant
const int ARRAY_SIZE = 10;
...
int myArray[ARRAY_SIZE];

if you initialized the array and you need to know its size then you can do:
int myArray[] = {1, 2, 3, 4, 5};
const int ARRAY_SIZE = sizeof(myArray) / sizeof(int);

the second sizeof is on the type of each element of your array, here int.
2/ How can I have an array which size is dynamic (i.e. not known until runtime)?
For that you will need dynamic allocation, which works on Arduino, but is generally not advised as this can cause the "heap" to become fragmented.
You can do (C way):
// Declaration
int* myArray = 0;
int myArraySize = 0;

// Allocation (let's suppose size contains some value discovered at runtime,
// e.g. obtained from some external source)
if (myArray != 0) {
    myArray = (int*) realloc(myArray, size * sizeof(int));
} else {
    myArray = (int*) malloc(size * sizeof(int));
}

Or (C++ way):
// Declaration
int* myArray = 0;
int myArraySize = 0;

// Allocation (let's suppose size contains some value discovered at runtime,
// e.g. obtained from some external source or through other program logic)
if (myArray != 0) {
    delete [] myArray;
}
myArray = new int [size];

For more about problems with heap fragmentation, you can refer to this question.

ARRAY_SIZE = sizeof myArray / sizeof myArray[0];, this way you can change the type of myArray without introducing bugs. For the same reason, myArray = realloc(myArray, size * sizeof *myArray);. BTW, casting the return value of malloc() or realloc() is useless also. 2) Checking for myArray != 0 in the C version is useless, as realloc(NULL, sz) is equivalent to malloc(sz).

const int ARRAY_SIZE = 10;
int myArray[ARRAY_SIZE]; Do you really think it is possible?. This would give variably modified array error in C.

@ArunCheriyan in C I don't know, but in C++ it compiles and runs perfectly. Since Arduino is C++ based, then there is no issue here.

There could be one reason to use dynamic memory safely on an Arduino, which is when you DON'T delete that memory and reuse it anymore, so just for 'initialization' purposes. You just have to make sure that the total amount of dynamic memory is enough to leave space for other dynamic memory (including function/methods arguments which land on the stack).

I know I'm a little late here, but in theory regular arrays can't be created using a variable to define the amount of elements the array is going to have as in:
int arrSize;
int myArray[arrSize];

This will display an error since when declaring the array, the program expects for the value between the brackets to be a constant. Yet, there is a way in which you could create an array with a variable defining the amount of values this arrays is going to have through dynamic memory allocation for value sets (this method has been tested with monodimensional arrays only, haven't tried for multidimensional yet), and it goes something like this:
//First you create a pointer for the memory space to be separated for the set you're creating
int* myArray;
int arrSize; //Then you define the variable that will determine the amount of elements the array is going to have, you can give it a value whenever you want as long as this int is defined before the values in myArray are set
myArray=(int*)calloc(arrSize,sizeof(int)) //Here, you establish that the instance myArray (whose memory space has already been separated through the creation of the pointer) will be separated into arrSize amount of elements of type int with a maximum memory value (in bytes) equal to the maximum available for the int type variables

After this, all that's left to do is assign a value for every element created in the instance myArray (which is already an Array by now) as you would for a normal array created as myArray[arrSize].

If you know the maximum length of array, just initialize the array to that length and use an integer to tell the program how much of that array to use.  If it's the difference between 7,10 bytes then you are not wasting that much memory allocation.

The size of the array must be known at compile time. Otherwise you should allocate memory dynamically using:
char *chararray = malloc(sizeof(char)*x);

where x(an integer) can be set in the application code (you could load it from eeprom if you wanted it be a persistent but configurable setting).

However if you just want to declare some arrays of the same size, you just have to declare the number a constant like this:
const int arrsize = 10;
char array1[arrsize];
int array2[arrsize];

I think not hardcoding things only makes sense if you would reasonably expect the user to want to change the setting at some point. I don't know if that's the case.

Coding sizes symbolically instead of literally can provide two benefits: 1) A well chosen symbol documents, or at least suggests, the reason for the choice; and 2) when other parts of the program or module need to be tailored to that choice, an expression using the same symbol can make that automatic, making maintenance much easier.

[A bit off topic, but] "user" is ambiguous as it can mean one of a number of people. It usually implies the end user, the consumer of final product, if not stated otherwise. It could be the next programmer, the immediately next consumer of your code, who might, in fact, be you (typical, in my own experience) a year or more after I've forgotten the nitty-gritty internal details of it). Or a system designer who includes your code as a ready-to-go module in his/her product. I suspect you meant the second "user".

The coderwall explains in Some detail the theory of how best to get the size of an array in C++ https://coderwall.com/p/nb9ngq/better-getting-array-size-in-c

Hi John, welcome to Arduino Stack Exchange! We have a general rule that answers should not just be links, as links do (unfortunately) go down and then the answer is useless. Please summarize, or re-post, the information in the answer right here (I notice it is quite short) so that the usefulness of it doesn't go away. I suggest you give credit by linking to the site, or the name of the author, or both.

It's better to include your own short answer and only referencing the source. Otherwise the answer is of no help when the website you link to gets removed.


text:
How to connect DRV-8835 to arduino
I try to connect arduino with motor using DRV-8835. The problem I have - simply nothing happens. I used tutorial from http://www.instructables.com/id/The-SnapMobile-Start-Your-Physical-Computing-Engin/step6/Building-the-Prototype-Wiring-Up-the-Arduino-the-D/
Code for arduino:
void setup() {
    pinMode(7, OUTPUT);
    pinMode(5, OUTPUT);
    pinMode(8, OUTPUT);
}

void loop() {
  digitalWrite(8, HIGH);
  digitalWrite(7, HIGH);
  analogWrite(5, 255);
}

Maybe someone has scheme how to connect wires to motor. Now I'm not sure if I made a mistake or motor driver is broken.

You might try wiring the enable and direction pins active (high?) to skip the arduino.  But check the motor wiring, too.  Do the motors spin when directly connected to your motor power supply without the PCB?  (The motor supply voltage is appropriate for the motors, right?  And you aren't running them off the Arduino or USB power?  And these are DC motors, not steppers or something more exotic?)

I use http://www.dagurobot.com/goods.php?id=86 . In fact I didn't try to connect battery(4x 1.5V) to motor. I'm newbie and little afraid of destroy motor

Ok. I tried without arduino and motor driver and motor works so it's not motor fault

Do you have any LEDs and resistors you could use to check the Arduino outputs in place of the motor driver?  Or you could use a voltmeter to measure them.

Yes. I checked it and there is no output - at least using LED and resistor

Try disconnecting the motor driver from the arduino and building and running the blink sketch.  If that works, try changing it to blink each pin you had used for the motor driver.

All arduino pins works fine.

Could you post a picture of the wiring? Also, just a shot in the dark, try adding a delay(100) at the end of the loop function.

I've added delay to loop method and connected led instead of motor. I guess it should be on

Try this code:
void setup() {
    pinMode(8, OUTPUT);//MODE
    pinMode(5, OUTPUT);//AENBL
    pinMode(7, OUTPUT);//APHASE
}

void loop() {
  pinMode(7, HIGH);//APHASE
  pinMode(8, HIGH);//MODE
  pinMode(5, HIGH);//AENBL
  delay(200);
  pinMode(5, LOW);//AENBL
}

Here is a description of the breakout board, this shows a requirement of PWM on AENBL for speed control. Try different  delays.

Setting AENBL HIGH should drive the motor at full speed - it has the same effect as analogWrite(5, 255). Dropping it from high to low should stop the motor.
Are you sure the DRV8835 is working properly? You can in theory diagnose it with a logic analyzer, but a scope will work better as the motor outputs aren't really logic. My test setup (yeah, I had one die on me) watched PHASE (just make sure it would toggle), MODE (should be HIGH), and AENBL (should show a square wave for the PWM duty cycle) as logic inputs, then watched the motor outputs on the scope to verify that one of them is the inverse of AENBL and the other is HIGH. Which follows AENBL and which is HIGH depends on PHASE, so you can toggle it if you can only check one output.


text:
When using Arduino Uno as ISP does "Yikes! Invalid device signature" mean a bad connection, bad config, or bad version of avrdude?
I'm using an Arduino UNO to program a pre-compiled hex image to an ATTINY45, using the avrdude in the Arduino IDE directory, on Windows 7. The Uno has the ISP sketch loaded from the examples directory and that works- the heartbeat LED pulses nicely.
On the hardware side I have this setup, except the ATTINY is surface-mount, soldered to a surfboard with all its pins verified-soldered with a voltmeter. I use a header-pin strip, held by hand to get the pins touching the surfboard, to get the signals from the Uno to the ATTINY.
Here are the command lines, which I took from looking at the IDE's debugging output:
REM set the fuse for 8MHz, so the ISP programmer can work
C:\Progra~1\Arduino\hardware\tools\avr\bin\avrdude -CC:\Progra~1\Arduino\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -pattiny45 -cstk500v1 -P\\.\COM7 -b19200 -e -Uefuse:w:0xff:m -Uhfuse:w:0xdf:m -Ulfuse:w:0xe2:m
REM load the program
C:\Progra~1\Arduino\hardware\tools\avr\bin\avrdude -CC:\Progra~1\Arduino\hardware/tools/avr/etc/avrdude.conf -v -pattiny45 -cstk500v1 -P\\.\COM7 -b19200 -Uflash:w:firefly.hex:i
REM set fuse for 1MHz, as the project requires
C:\Progra~1\Arduino\hardware/tools/avr/bin/avrdude -CC:\Progra~1\Arduino\hardware/tools/avr/etc/avrdude.conf -v -pattiny45 -cstk500v1 -P\\.\COM7 -b19200 -e -Uefuse:w:0xff:m -Uhfuse:w:0xdf:m -Ulfuse:w:0x62:m

-I try running those separately, but always get this error:
avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
     Double check connections and try again, or use -F to override
     this check.

but sometimes the number is ff0000 or ffff00 or ffffff
I read that "Arduino uses a slightly modified version of avrdude to upload sketches to the Arduino board. The standard version queries for the board's device signature in a way not understood by the bootloader, resulting in this error." Does this mean that using the Arduino avrdude with a new ATTINY chip, no bootloader on it, would also cause that same error? In other words, is the modified avrdude incapable of querying a non-Arduino-bootloaded AVR chip?
Or does that error simply mean I don't have a good contact between all my programmer pins and the ATTINY?
And, are the fuse settings truly needed, can the Uno program the flash into an attiny running at 1MHz and thus save me some steps?
(I would just buy a "real" programmer, but need to get this code in the next two days, and am in a rural part of Nova Scotia)

Try setting the programmer to -c avrisp. I think you can program it at 1 MHz without problems.

When I upload from the arduino IDE and set the programmer to "Arduino as ISP" it uses -carduino not the stk500. Just try uploading the blink program to the attiny from the IDE. That way you can see the correct commandline at the bottom, if you enable "verbose output" in the settings.

Did you upload the ArduinoISP sketch first?

Phil, I did load the ArduinoISP sketch into the Uno before these steps, it succeeded, and I see the green "heartbeat" LED in pin 9 pulse. Gerben/user2973, I did try "-carduino", I will try "-c avrisp" next. Thanks.

This looks like an ISP<->target connection issue.  Anything in your circuit which could be loading the lines?  Are the ATtiny fuses still set for internal clock, or are you providing an external one?  Are you sure you have all four signal wires and ground connected, and in the right order?  Perhaps you should tack solder a setup just to verify it is not your hand-held method (though I've also used that)

I soldered wires to pads to be sure the connection was good, and used those wires for programming from the Uno. Then the programmer worked, without any edits to the command lines as posted in the question. I ran a few variations and was able to answer all my questions, and a few more besides:

The "Yikes! Invalid device signature" error was being caused by poor contact between the programmer (Uno) and the ATTINY pins.
It had nothing to do with the bootloader not being on the new microcontroller. The new ATTINY45 chip doesn't need a bootloader for the in-circuit programmer to work.
The Uno can program the ATTINY45 configured to either of its speeds, 1MHz or 8MHz. The factory settings are fine, and don't require changing the fuses.
Both avrdude versions worked for programming- the 6.1 from the author's site, and the modified one from the Arduino IDE.
avrdude can program via the Uno using any of -c avrisp, -c arduino, or -c stk500v1, it doesn't matter which.

One little question I wasn't able to answer, was what speed the Uno programs at (communication speed between the Arduino I/O pins & microcontroller being flashed). Is it related to the serial port speed? But it turned out to be not pertinent to answering this problem. Someone else can ask it if curious enough.

ArduinoISP sets the SPI interface to clock/128, so for a 16 MHz Uno the connected AVR is programmed at 16 MHz / 128 = 125 kbit/s. But the limiting factors are the serial speed and when PROG_FLICKER is set, 30 ms delays added for each page commit.

I had exactly this problem. If the ATtiny is set for external clock, then the ArduinoISP will not be able to program it without an external crystal. Connected a 16 MHz crystal and 2 capacitors and worked perfectly.
(I was then able to set ATtiny to internal clock, remove the crystal, and then worked perfectly without the crystal.)

Add the board and their fuse description from what is already set and it will work.
For adding just C:\Program Files\Arduino\hardware\arduino\avr\boards.txt and add the board description.
########
############ Definitions for ATmega 8MHz
##############################################################
atmega16-8.name=Atmega16 (internal 8MHz clock)

atmega16-8.upload.tool=avrdude

atmega16-8.upload.protocol=stk500v1

atmega16-8.upload.maximum_size=14336
atmega16-8.upload.speed=19200

atmega16-8.bootloader.low_fuses=0xE8
atmega16-8.bootloader.high_fuses=0x99

atmega16-8.build.mcu=atmega16
atmega16-8.build.f_cpu=8000000L
atmega16-8.build.core=arduino:arduino
atmega16-8.build.variant=mega16

##############################################################
############################

I used it.


text:
How to upload an arduino sketch from java / processing?
I'm trying to upload a hex file from Java/Processing but running into some issues.
Here is my code so far, based on the Arduino IDE's upload verbose output:
void setup(){
    //C:\Program Files (x86)\Arduino/hardware/tools/avr/bin/avrdude -CC:\Program Files (x86)\Arduino/hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patmega328p -carduino -PCOM96 -b115200 -D -Uflash:w:C:\Users\HM\AppData\Local\Temp\build5909267154049588263.tmp/sketch_aug13a.cpp.hex:i
    String ArduinoPath = "C:\\Program Files (x86)\\Arduino";
    String hexPath = "C:\\Users\\HM\\AppData\\Local\\Temp\\build1023547366107161384.tmp/sketch_aug13a.cpp.hex";
    String port = "COM96";
    runCommand(new String[]{ArduinoPath+"/hardware/tools/avr/bin/avrdude", "-C"+ArduinoPath+"/hardware/tools/avr/etc/avrdude.conf","-v","-v","-v","-v","-patmega328p","-carduino","-P"+port,"-b115200","-D","-Uflash:w:"+hexPath+":i"});
  }
  void runCommand(String[] cmd){

    String s = null;

    try {

      Process p = Runtime.getRuntime().exec(cmd);
      BufferedReader stdInput = new BufferedReader(new InputStreamReader(p.getInputStream()));
      BufferedReader stdError = new BufferedReader(new InputStreamReader(p.getErrorStream()));

      // read the output from the command
      System.out.println("command out:\n");
      while ( (s = stdInput.readLine ()) != null) System.out.println(s);
      System.out.println("errors (if any):\n");
      while ( (s = stdError.readLine ()) != null) System.out.println(s);

    }catch (IOException e) {
      System.out.println("something went wrong: \n");
      e.printStackTrace();
    }

  }

If I run this from command line it uploads without any issues, but from the code above I always get this output:
avrdude: Version 5.11, compiled on Sep  2 2011 at 19:38:36
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "C:\Program Files (x86)\Arduino\hardw
are\tools\avr\etc\avrdude.conf"

         Using Port                    : COM96
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
avrdude: ser_open(): can't open device "\\.\COM96": Access is denied.

avrdude done.  Thank you.

What output do you get? You forgot to post it in your question!

Is "COM96" really the correct device?  If it is, is this sketch being run in the same way as your other test, or it is perhaps running a less privileged mode?  Do you still have the Arduino IDE (perhaps its serial monitor) open and claiming the port?

I've disconnected the port to see if I get a different message from avrdude and I do. COM96 is correct, otherwise I get The system can't find the file specified. If I use the Arduino IDE or command prompt to do the upload, the upload seems to work, it's when trying to replicate it from Java this problem arises. Does the Arduino IDE do anything clever after uploading calling avrdude to release the port ?

Have you tried hard coding the value of port in your command string. try "-PCOM96" instead of "-P"+port. Other than that, it says access is denied, try running it as administrator

oooh...haven't tried that as administrator yet. That kind of rings a bell because Arduino and avrdude are in Program Files so would have admin privileges

Running as administrator doesn't solve it. You can see a screen recording here (manually scroll or save the file locally if it doesn't play in the browser).  Tomorrow I'll try with Python and subprocess. I'm suspecting the code I use to run avrdude isn't quite there yet.

Ok, I've just done done a test in Python: subprocess.check_output([ap+"/hardware/tools/avr/bin/avrdude","-C"+ap+"/hardware/tools/avr/etc/avrdude.conf","-v","-v","-v","-v","-patmega328p","-carduino","-P"+port,"-b115200","-D","-Uflash:w:"+hexPath+":i"],stderr=subprocess.STDOUT,shell=True), where ap is arduino path, hexPath is the path to the hex file and port is "COM96" and that worked. I have to look into the java Runtime exec method and options/better ways of doing this

I'd first would try to find out the right command when running on command line (cmd.exe).
When you launch an external command from Java which generates output, you should/must read the output (p.getInputStream(), p.getErrorStream()) using separate threads. Otherwise your application might hang for no obvious reason.

I've made two separate thread as advised and it worked!


text:
Arduino Mega 2560 - TFT 3.5 Display is not working with libraries suggested
I attached two images of the shield.

I bought an Arduino Mega 2560 R3 with a TFT 3.5 Display shield in China.
What I know from my research is:

There are no data sheets available in the Internet.
The factory's web site, in China, is in Chinese, and there is no information in English.
I achieved to know the factory is www.mcufriend.com, because it is the only reference in the shield.
Apparently the drive to use is R61581.
Using suggested libraries from Henning Karlsen (http://www.henningkarlsen.com/electronics/library.php)
(UTFT, UTFT Geometry, tiny Fat, UTFT Tiny Fat, UTouch and UTFT buttons) . These libraries don't work with this shield.
Some people say that this shield requires 3.3 [Volts] to work, but the Vcc pin connected goes to 5V and it contains a Voltage regulator. I suppose it drops the voltage from 5[V] to 3.3[V] in the middle of the back side of the screen shield (see the upper photo - U1).
The specs that I found, say that this is a 262,144 Color 320x480 Dot Graphic LCD screen using a LCD driver a Si TFT Panel.
This screen includes a touch pad and a Micro SD memory reader.
After using the geometry test included in the library folder UTF Geometry mentioned on #5, and using all the drivers found in the documentation included by Henning Karlsen in a .pdf doc, I couldn't get this shield to work.

Does anyone know how to make this screen work?
I know is too much technology involved to be a fake shield, but it should be very useful to have this working. Do you agree with me?

In what way is it not working?

I drop down the testing software into the Mega, but the screen remains not showing any activity. Only the back light is on. I have an expensive lamp working, but it is not showing anything on it. I tried all the drivers.

The URL to the library mentioned in the OP's post is dead, and henningkarlsen.com appears to have moved to rinkydinkelectronics.com. The page may be now this one, Library: UTFT.

I have the same display. It has ILI9137 chip using 8-bit mode, so original Henning Karlsen UTF library doesn't work. You can find this library patched to support this display using Arduino MEGA at https://github.com/dgolda/UTFT
If display wouldn't work it is probably broken. I've received first piece broken - only backlight was working, but second and third was OK.


text:
Why does my dc motor immediately spin when connected to a 9v battery?
I've set up a DC motor connected to my Arduino Uno with the following layout. I'm using a 1.5V - 3V DC motor that was purchased from RadioShack.
Here is my code:
int controlPin = 9;

void setup(){
  pinMode(controlPin, OUTPUT);
  Serial.begin(9600);
  while(!Serial);
  Serial.println("Ready");
}

void loop(){
  if(Serial.available()){
    int s = Serial.parseInt();
    if(s >= 0 && s <= 255){
      Serial.println(s);
      analogWrite(controlPin, s);
    }
  }
}

If I connect the motor through the Arduino 5V pin it only hums until I set the speed s to 200 or greater. This seems odd because I'm supplying 5V.
As a next step I decided to try a 9V battery (I don't really care if I fry the motor, I just wanted to experiment). Of course this is over the recommended voltage, but I assumed if I sent a low enough signal (s) through pin 9 it might not destroy the motor. However, to my surprise, when I connected the 9V battery (as illustrated below) the motor immediately starts spinning. I measured the current and it seems to be ~150mA when connected to the 9V battery. It seems like the circuit is connected even though I'm not sending any signal from pin 9 to the transistor. If I removed any of the wires connected to ground, the motor, obviously, stops spinning. My expectation, which is apparently wrong, was that the motor wouldn't spin until I sent a signal from pin 9 to the transistor. What am I not grasping here?

Here's a picture as my diagram may be wrong based on comments below. This shows the diode reversed as suggested by Chris.

I also moved the jumper going from pin 9 to the breadboard out of the Vcc column and directly into the row with the resistor. I'm not sure if that resolves the short mentioned in comments.

If you connect the base resistor to ground instead of the Arduino, does the motor stop?  If not, you probably have either mixed up the pins of the transistor such that it is merely functioning as a diode (very easy to do - especially "pin circle" vs "pin line") or have already blown the transistor.

You should try to respect usual conventions on breadboard usage: the 2 pairs of lines one each side should be reserved for Vcc and GND. The way you wire your breadboard makes it more difficult to interpret.

Also it seems your 280 Ohm resistor is useless because shorted by the breadboard wires.

jfpoilpert - thanks. I intended for the 2 pairs of lines on each side to represent vcc and gnd. Do I need to label them as such? Also, can you further explain why the 280 Ohm is useless? I have pin 9 going to the vcc column and then a jumper going from vcc to the row containing the resistor?

Currently you don't use the Vcc line as Vcc sicne it is linked to pin 9 not to Vcc. Regarding the resistor, looking at your scheme it looks like it is wired on the same rail of the whiteboard. I you used a better tool for drawing your circuits (eg Fritzing) it would make it easier to read.

Your wiring diagram is a jumbled mess, and makes it impossible to figure out what's really going on.
My guess is that you have a mistake somewhere in your wiring.
Problems I see with your wiring diagram:

You show pin 9 from the Arduino wired to the positive rail of your breadboard. If the positive rail is connected to a 9V battery, this will likely destroy pin 9 of your Arduino.
You show the gate/base of your transistor wired to the positive rail of your breadboard. This would switch your transistor on constantly.
You show the symbol for a MOSFET transistor, but the label on it lists it as a 222A, which is an NPN BJT, not a MOSFET.
You don't show any wires connecting the left and right side rails of your breadboard.
You're using a row of your breadboard as the ground rather than the rails.

The picture you posted is too small to tell if your wiring diagram is wrong or if you actually connected things incorrectly, and the wire from your 9V battery is blocking the camera's view of key connections.
It looks like your wire from pin 9 is NOT connected to the power rail, but is instead connected to column 1 in your breadboard, which is good.
There are some strong conventions in wiring with breadboards and you should learn to follow them. The two pairs of columns of sockets on the left and right are for positive and negative supply voltage. Usually you wire them together and connect them to regulated power. Sometimes they will be used for different voltages, although you need to be really careful if you do this, since connecting to the wrong side can fry components.
It's confusing the way you've created your wiring diagram, but it looks like you have your flyback protection diode wired correctly, which is good. That's very important, as DC motors and other inductors create destructive reverse voltages as they are switched on and off, and without a flyback diode it can destroy solid state devices like ICs or even transistors.
You should re-wire your breadboard using the proper conventions, and post a corrected wiring diagram that really shows what's going on.
A picture where we can see all the wires and components clearly would also help.
Until you better learn what you are doing I would strongly advise against powering things directly from a 9V battery. When you do that, a mistake in wiring will fry your Arduino and/or any ICs you have on your breadboard.
Wire the 9V to the V-in pin on your Arduino, and then bring 5V and ground from the Arduino onto the +/- supply rails of the breadboard.
I also notice that in your code, you never set the state of controlPin in your setup method. You should add this line to your setup:
digitalWrite(controlPin, LOW);

That way the pin starts out in the OFF state, and then later on you can us an analogWrite to set it to the desired output level.

Awesome feedback! Thanks. I see how the diagram is incorrect now. I also understand how my unconventional breadboard wiring is confusing the issue. I'll clean that up. Currently, I'm supplying power to the right hand rails but not crossing it over to the left side, so I don't think I'll destroy pin 9, correct? I realize this layout is still wrong, but just verifying. Also re: MOSFET vs NPN BJT - I wasn't sure which icon to choose in Visio hence the label (I'll correct that too). Again, great feedback. Really appreciate the guidance.

Which kind of transistor are you using?

And what SW are you using to create your wiring diagrams? I use CircuitLab on the EE stack exchange (a web-based schematic editor) but haven't found a good one for use here. (I use Macs BTW)

You need to turn the transistor 180 degrees (assuming you are indeed p2n2222a).

Collector should go to the motor, Emitter should go to ground. In your photo you have those two swapped.
Also, I don't think the diode is the correct way around in that photo. That will just short out the battery, thought admittedly that would prevent the motor from spinning (-:

Swapping the emitter and collector would be unlikely to result in the transistor always being "on" (it would just make it perform poorly).  However, in a transistor package which does not put the base in the center ("pin circle" vs today's common "pin line") then it could indeed be an explanation.

@Gerben seems to be correct. I reversed the transistor and two things occurred 1.) when using 5V from the Arduino, I get much better performance. The motor starts spinning around a speed of 40 (vs ~200 previously) 2.) when using 9V the motor doesn't spin immediately. Only spins when I send a signal from pin 9. I also modified diagram and breadboard setup on the main post.

Actually, I take that back - the breakdown voltage when emitter and collector are accidentally swapped might be low enough for 9v to force it on.

Emitter - Base Breakdown Voltage is 6V. 9V power minus the voltage the motor uses (3v motor). Could be just enough. Or would the voltage at the Emitter be 9v when the transistor is off? Which would mean any voltage above 6v would make the transistor pass some current, though not much if the voltage is just above 6v? Funny thing; turning pin 9 HIGH might even turn the motor off :-).


text:
Seeeduino V3.0 (Atmega 328P) and Rotary Angle Sensor Mystery Message
I am attempting to do a simple example with the Rotary Angle Sensor.
Here is my development environment:

Visual Studio 2013 Premium
Arduino Debug Tool

Board setup (Simple as can be single analog input):

Code:
const int ROTARYSENSOR = A0;

void setup()
{
    Serial.println("Setup Start...");
    Serial.begin(9600); //Set the serial communication frequency at 9600 bits per second

    pinMode(ROTARYSENSOR, INPUT);

    Serial.println("Setup End!");
}

void loop()
{
    Serial.println("Loop Start...");

    int value = analogRead(ROTARYSENSOR);
    Serial.println(value); //display on serial monitor
    delay(1000); //wait 1000ms before printing next value

    Serial.println("Loop End!");
}

Issue:
I have a single solution with multiple projects as my sensor playground. All other projects I have so far work flawlessly no issues.  Although with this project (RotaryAngleSensor) I am getting a strange message.
I am not seeing any of the Serial.println() messages. What is printed to the screen after a good 30 seconds is S?
Does anyone know what could be returning this S? to the standard output?

Did you not post all your code? The setup() function is only called once, at the very start of the program running. It's possible you're just missing them.

Also, to be precise, your "rotary angle sensor" is actually called a potentiometer.

Yeah I lost some code somehow, when I was editing. I will update it. Also yeah I know what it's called, I was just using the name that was on the container box. :p

One problem is that you try to generate serial output before you initiate Serial.  This could have odd results beyond just making that message fail.
Serial.println("Setup Start...");
Serial.begin(9600);

Should be
Serial.begin(9600);
Serial.println("Setup Start...");

And of course your posted code never reads the sensor...

It does, I must have lost the loop method when I reedited my question. Thanks.

So I flipped it around like suggested still didn't work. But when I remove the Serial.begin(9600); all together it works just fine, but just starts at 0.
Suggestions?


text:
Multiple boards blinking at same time
I want to make two or more boards to blink an LED at the same time (within 1 ms difference) The boards cannot be connected with wires to each other and will be located in different rooms. How can I do this? What components do I need?

What is the cycle time? Is it okay if they sync every second or so? Or do they have the have the same value returned for millis()? In the first situation you can just send a "pulse" every second. In the latter you'd need to send some actual data, which makes it slightly more complicated. Definitely go with RF. There are some very cheap 433Mhz transmitters and receivers on the market. One arduino will be the master and send. The other boards will have a receiver.

@Gerben I want the LEDs to blink in a fixed time interval (say every minute interval). If the time difference between multiple boards blinking remains within 1ms, then the sync cycle can be every minute or more.

<1ms difference in 60 seconds, means around 17ppm. The crystals on the arduinos have a much higher deviation. So syncing every minute would not be enough, or you have to take the time-difference between 2 syncs and adjust your delays accordingly. Alternatively you could use the internal 8mhz oscillator on the atmega, instead of the crystal. The internal oscillator can be adjusted relatively easy. That way all the boards run at around the same frequency, and every minute any accumulated deviation is reset.

Could you tell us WHY you want them to blink simultaneously in different locations? If we know we can help you better.

@Tom It is for synchronization of multiple devices

Can both arduinos be connected to mains power?

@bigjosh They are in different rooms, powered by battery. Cannot to be wired together.

Have both sync to a master clock using GSM shields. These shields are getting very cheap (as low as $14 on ebay).
The shields receive the time wirelessly from the cellular network and this time base is extremely accurate. Here is some example code to read the current time from the shield...
http://forum.arduino.cc/index.php?topic=163155.msg2102141#msg2102141
Note that you will need a SIM card to get the time, but you should not need an active cellular account.

You can also use real time clock (RTC) modules to syncronize arduinos. These are cheaper than other solutions like GPS or WiFi.

You could certainly do it with multiple Arduinos, each with a WiFi shield, but that would cost a lot of money.
Instead I would suggest building a low power radio transmitter that sends simple morse code clicks, and then building amplifier boards that use the clicks to trigger LED blinks. You'd need to use a frequency that is open for low power use in your country, like the range for garage door openers.
I've seen circuits in old electronics kits for building morse code transmitters, but they might not meet current FCC regulations.

1ms synchronization with WIFI is by no means "certain".  It may be possible, but having tried to do that, it's actually rather tricky - especially if there is a router in between, packet latency can vary widely.  Nor is a simple on-off-keying demodulator likely to yield nice results, as it will be very subject to interference.  However it could possible be used as input to a software phase locked loop - a local timer which would over time speed up or slow down if it found that the radio pulses it did detect tended on average to be a little earlier or later than expected.

Ultimately, some of the simple SPI-interfaced 2.4 GHz RF chips/modules probably could provide a solution - nrf24L01 type stuff - which is cheaper, easier, and less likely to false trigger in the presence of interference than a DIY RF link.  Either a software PLL, or a series of "count down" messages could be used to bridge missed messages.

@ChrisStratton, those are cool, and cheap too! (voted). Point taken about the home brew radio transceiver. You'd need to make an FM transmitter and receiver using PLLs, and that would take quite a few components. Why not post you suggestion as an answer? Seems like the best solution.

Although I was suggesting building one Arduino-based transmitter and a bunch of analog radio receiver based LED flashers. The nrf24L01 solution would require an Arduino per flasher, so the total cost per receiver would be fairly high. Could you rig those up with an ARTiny?

With efficient programming, yes, it should be able to be done with an ATtiny85.  And even an ATmega328p isn't that expensive, nor does it require more support components.  Much of what you pay for in an "Arduino" is the USB interface, PCB, power circuitry, connectors, etc.


text:
Flame Sensors Problems
I am making a fire fighting robot and I need a sensor. I want the sensor detection range to be about 6m or 7m (about 18ft to 20ft).
The question is which sensor should I choose to get that detection range? I've found that some small IR sensors are not suitable for my range required.
I'm making a simulated one. It might be confused if there are non-fire distractions so I'm asking for a technique that can improve the sensor range and determination very very effective... or which sensor should I choose??
I don't want the IR sensor to be more directional. If I need it to be more directional I can use 2 or 3 or more. It is no problem. I want the IR sensors to improve their detection range. I can only get 2m now. I want it to be about 4m or 5m.

Are you fighting real fires or simulated ones such as a candle in a maze?  What possible non-fire distractions exist in the environment which might confuse it?

You'd probably want the IR sensor to be more directional. Try putting some heat-shrink around the sensor, so it can only see light from straight ahead.


text:
SIM 900 + Arduino Mega attachGPRS problem, GPRS_READY
I have connected my GSM module to my Arduino. Using AT commands I am able to connect to internet.
  Using the following link of tutorials, I tried to connect to internet
http://arduino.cc/en/Tutorial/GSMExamplesXivelyClient
  In this the device is showing not connected. So I tried to debug it. In the attachGPRS
(gprs.attachGPRS(GPRS_APN, GPRS_LOGIN, GPRS_PASSWORD)==GPRS_READY)
gprs.attachGPRS(GPRS_APN, GPRS_LOGIN, GPRS_PASSWORD = 2
and GPRS_READY = 4
Why is this happening? What is GPRS_READY ?

Your question doesn't make sense. I know english isn't you first language, but please try to rephrase it. The code you provide is also weird, with for example missing parentheses.

Welcome to Arduino SE! First of all, did you solve your other question yet? Also, it seems like you're relying on external code. Can you please add any relevant code? Thanks!


text:
I2C seems to stop working when I attach an AF motor shield
I have a cheap MPU 6050 chip that communicates over 3.3V I2C. I can talk to it just fine on my Leonardo. If I add an additional Adafruit Motor shield (the old one), my MPU 6050 demo sketch hangs somewhere, and I get nothing back.
As far as I see, the pins I use for the I2C communication are not used at all by the motor shield.
What could be wrong here?
I have the MPU6050 connected to SCL, SDA, GND and 3.3V, the motor shield uses almost all other pins.
Additional Info:
I am using this sketch currently: https://github.com/jrowberg/i2cdevlib/tree/master/Arduino/MPU6050
Update:
Lots of "Serial.println"s later, I've narrowed it down a bit. The example sketch above hangs on the statement "Wire.endTransmission();" on line 279 of the I2CDev library.
Update:
Connecting the motor shield to external power seems to fix my problem. Weird =) I am still interested in the reason for this behavior.

Did you modify the code at all? Can you isolate the problem to a small section of the sketch and include that? Does the 'blink' sketch work? Thanks!

With both the motor shield and the mpu 6050 connected, the blink sketch works fine. I can even talk via Serial.

So, it is something with your code. Can you post the minimum code required to reproduce this issue?

I'll try... this will take a while, since I don't understand one bit of what the MPU 6050 library linked above really does =)

Wait... didn't see your edit. Which example are you using?

The "raw" one. https://github.com/jrowberg/i2cdevlib/blob/master/Arduino/MPU6050/Examples/MPU6050_raw/MPU6050_raw.ino

How are you powering the Arduino? Sounds like the motor shield is drawing too much power and thus the 3.3V output from the Arduino is dropping too low and stuffing up I2C. You can confirm with a multimeter

Motors draw large amounts of current, and will either cause your power supply voltage to sag if you draw more current than your power supply can support, or cause blips in the power supply that will cause you all sorts of problems.
You need to take steps to isolate the power from the motor shield from the power for the Arduino.
How are you powering the motor shield? How are you powering the Arduino?
If your power supply has enough current to support both your Arduino and your motors then you can probably solve the problem by adding an isolation capacitor between the Vin port on your Arduino and ground.
What that does is to filter out temporary variations in the input voltage that's being fed to the Arduino. Without it, the Vin voltage to the Arduino is probably dropping as your motor draws large pulses of current, and that causes the output from the voltage regulator to droop as well.
I don't know how to pick the rating of the cap. A trip to the Electrical Engineering stack exchange is probably in order.


text:
How to free up Flash space by removing the bootloader on UNO?
In order to fit maximum user program into the chip, how to free up Flash space (0.5 kilo bytes for UNO, 2 KB pro Mini, 8KB for ATMega2560) by removing the bootloader on Atmega328 (UNO, Pro Mini, or similar)?
What software development tools needed (like Atmel AVR Studio software or similar)?
What hardware flash writing / debug tools needed (like JTAG hardware programmer/debugger)?
How is the procedure? Where can I get more information.
Many thanks in advance.
edit: Update boot loader size for different boards

On UNO, the optiboot loader takes only 0.5KB not 2KB, so removing it will not be a big gain.

You'd need something like an USBASP programmer. You can use the regular Arduino IDE for programming, though you'd probably have to edit the boards.txt file a bit.

I looked at C:\Program Files\Arduino\hardware\arduino\broads.txt and, to my surprises, many boards use different boot loaders (hex file has different name)

You'll need to use an ISP programmer with avrdude. Perform a chip erase and then unprogram the BOOTRST fuse in the high fuse byte.


text:
OBD Connector to Arduino
I bought an OBD connector from Sparkfun to try to connect to my vehicle via arduino.
I'm just beginning and am not sure if I can just connect the connector pics to the arduino directly, or if there is some other required hardware?
Does anyone know if I can connect directly and why or why not?

I briefly read up on this subject and I found out this:
It seems like there's a protocol called J1850. There's no native support on the Arduino for that, but you might be able to do something bit-banging if you can find the specifications for this protocol. If you do this, I'd advise accessing the registers directly and skipping the digitalRead() command.
There are a few protocols in use, so it is hard to know without knowing the car you drive to even tell what the car will send.
More on this topic...
Anyway, it seems like you need a chip to use with this. Sparkfun also sells a breakout board for the STN1110 OBD-II to UART chip (tutorial). I couldn't really find anything else besides this.
Anyway, you probably need another chip to do this work. The Arduino isn't meant to do all of these protocols, and the OBD isn't UART-compatible.

Thanks for the help!   I also found an pdf here https://www.google.com/url?sa=t&source=web&rct=j&ei=uvPxU-vjLo27oQTW2YDgCA&url=https://www.cs.purdue.edu/homes/millerrv/Ryan_Miller/Projects/Entries/2010/12/21_Arduino_OBD-II_Interface_files/CS497_presentation_miller.pdf&cd=1&ved=0CBwQFjAA&usg=AFQjCNEguP_tgEU-i6_6MbNqOoXj9er37A&sig2=1teeC0hht_QSnBZAc9JrBQ

@mECH interesting! It looks like they used the MC33290 and bit banging to do this. I don't have time now to look into it more now, but a library with hardware timers would be helpful...


text:
Why bootloader sizes differs from 0.5 to 8 kilo bytes for different boards?
According to official web info bootloader sizes are 0.5, 2 and 8 kilo bytes for UNO, Pro mini and ATMega2560. I believe all three boot loaders do similar job of receiving serial link data and write to Flash memory.
UNO and Pro mini use same/similar ATMega168/328 chips but boot loader size are 0.5 and 2 KB.
ATMega2560 apparent has a more advanced MCU which presumably should use similar or even less memory to do the same task, but the size is significantly large at 8 KB.
Why sizes differ? Small difference may be explained by different development teams, but, should be that much different, from 0.5 to 8KB.

Different bootloaders have different capabilities.

Bootloader of the Mini and Uno are pretty much the same. (I can't find the source-code but the hex files are only slightly different).
The 2k is because they haven't updated mini328.upload.maximum_size in boards.txt. Probably because that would break the board for users that haven't updated the bootloader yet.
The 2560 is using a stk500v2 compatible boot loader instead of Optiboot (uno and mini), because optiboot only supports upto 64kb addresses. Not sure why it is that much bigger though.

How to find out if UNO, Pro Mini/ATMega2560 boards are loaded with latest version boot loader (hoping that it is smaller in size to allow max user program)?  Where can I get latest boot loaders for these 3 boards?  If needed, how to re-program boot loader of UNO/Pro Mini/ATMega2560?

Uploading the latest is probably easier than testing which version is on it. Bootloaders can be found at: https://github.com/arduino/Arduino/tree/master/hardware/arduino/bootloaders . Just google how to upgrade. If you can work it out ask a new question here on SE.

Generally speaking the chips offer four possible bootloader size configurations. For example, on the Atmega328 you can have 512, 1024, 2048 or 4096 bytes (notice that the sizes increase by a power of 2).
The chips with less program memory offer smaller bootloaders because they won't want to use a lot of that memory for something that is only used to upload code. The chips with more memory (like the Atmega2560) offer larger bootloaders, ie. 1k, 2k, 4k, 8k (again it increases by a power of 2).
The Uno manages to use a 512 byte bootloader (Optiboot). The Mega, which has more complex instructions (to handle a larger address space) would need larger bootloaders. Also in some cases the bootloader writers add in extra stuff like a debugging console.


text:
Does ATMega 328/2560 chips support JTAG-type programmer and hardware debugger?
As stated in www.Arduino.cc FAQ, "Can I use an Arduino board without the Arduino software? Sure. It's just an AVR development board, you can use straight AVR C or C++ (with avr-gcc and avrdude or AVR Studio) to program it."
For UNO/Pro Mini(ATMega328) and ATmega2560, does these two chips support JTAG type (some chip manufacturers may use different name) programmer / hardware-based debugger in same manner as the ST-Link/J-Link programmer/debugger where one can load code into the MCU and perform hardware break point and single stepping? Example as in  STM32 development board with ST-LINK programmer / debugger where the chip has built-in debug circuit that communicate with ST-Link.
Many thanks in advance.

The ATmegaXX8 does not support JTAG, but the ATmegaXX0, 'XX1, and 'XX4 do. The 'XX8 (as well as other AVR families) supports debugWIRE, which allows debugging over ISP. You will need one of Atmel's debuggers such as the AVR ONE! or the Atmel-ICE as well as Atmel Studio in order to use it.

I use an AVRDragon board with Atmel Studio to do JTAG on a 2560 board and DebugWire on the smaller chips. This is probably the lowest cost solution.

Is the Mega 2560 included in the "ATmegaXX0" class?

@AnnonomusPenguin: Yes. It includes the ATmega640, ATmega1280 (Arduino Mega), and ATmega2560 (Arduino Mega 2560), which only vary by amount of flash available.


text:
Can two LEDs attached to different pins share their resistor?
I'm designing an Arduino style board with built-in LEDs for several of the pins. To simplify assembly of the board and save on components, I was wondering whether it would be safe for those LEDs to share a single resistor, as in this diagram:

Obviously, the power dissipated through the resistor (3mA per pin @ 3V) is not a real problem. The reason I was hesitating is that LEDs in a parallel configuration should not share resistors, but is it safe to think that separate microcontroller pins don't count as a common anode, even if both pins are high?

While not part of your question, generally speaking, if at all possible it is preferable to drive the cathode of the LED rather than the anode, as most microncontrollers and other IC's are better at driving negative outputs than positive, as N-channel FET's work better than P-channel ones.

@ChrisStratton, I've heard this before, but what are the practical implications of "better"? Faster switching speed? Closer to theoretical voltage? (I want these LEDs for diagnostic purposes, so having them active low is semantically undesirable anyway).

Can two LEDs attached to different pins share their resistor?

can : yes
should : probably not

Your resistor act here as a current limiter, say to 3mA
If you light one LED at a time, you give 3mA to that LED
If you light 2 LEDs, you give 3mA for both of them (more of less 1.5mA each)
If you light 3 LEDs, you give 3mA for all of them (on average 1mA each)
Things are even a little bit more subtle, as different LED might have different forward voltage, so one LED might very well drain 10% more current than an other.
As "Amps made LED bright", less Amp is less light. On LED light with that setup will give "full light on", and more LED you add, less would bright each one.

As an edit to that answer, there is one case I might consider that arrangement for "multi-LED lighting". This is if you are multiplexing your LEDs
That is lighting only one at a time, but cycling fast enough from one LED to the next so that the human eye would see them all lit at once.

Ah yes, that I had not properly considered, and for my purposes, it's a fatal objection.

Your circuit is safe from the electronic viewpoint, so long as the LEDs used can withstand a back-emf of 4v or so.
If only one LED is on at a time, all will be sweet. But if two or more are on, the brightness will drop and the brightness between LEDS will probably be inconsistent. The forward voltage drop of individual LEDS tend to vary a little, so one is likely to hog most of the available current.
A separate resistor per LED is probably best.

Mixing colors will give even wost results. If you have a blue and a red led (both ON), the blue led will not light up (or extremely dim), since blue leds have a higher voltage drop.

If one is making many thousands of something and there will never be any need to light more than one LED, using a shared resistor may save a half a penny each, which could add up to real money.  On the other hand, even if the application won't require lighting multiple LEDs being able to do so can be nice during debugging.  It's possible to make it look as though multiple LEDs are lit simultaneously, with predictable brightness, if one rapidly cycles among them, but sometimes during debugging it's more useful to be able to independently control the LEDs directly.


text:
Is it possible to run a binary from EEPROM?
Say I wrote a compiled sketch to EEPROM then read it. Could I run the program from EEPROM? I guess the question is: Can an Arduino run software not in flash memory in the middle of executing the software in flash?

Short answer: No; From the atmega328's data sheet (though it applies to all AVR's):

AVR uses a Harvard architecture – with
  separate memories and buses for program and data. Instructions in the program memory are
  executed with a single level pipelining. While one instruction is being executed, the next instruction is pre-fetched from the program memory
...
Program Flash memory space is divided in two sections, the Boot Program section and the
  Application Program section. Both sections have dedicated Lock bits for write and read/write
  protection. The SPM instruction that writes into the Application Flash memory section must
  reside in the Boot Program section

It's architecture prevents using external program memory, but you can load anything into program memory at boot. At that point I would venture to say you are just programming AVR and not arduino, since you would need to replace the arduino bootloader and break the arduino IDE's ability to upload programs.
Alternately you could also use an emulator or interpreter of some intermediate language; basically code that steps through and runs other code. As a general rule an emulator runs around 8x slower.
There are micro-controllers from other brands that do support this functionality, I know a couple different PIC's do.

No. The foundation of a Harvard architecture such as AVR is to only allow code that exists within program space to be executed, and EEPROM is not within program space. It is possible, however, to write a virtual machine that will run from flash. This VM can then read program-become-data from anywhere and take action based on it.

+1. Note that some MCUs use modified Harvard architecture that allows the CPU to read/write data in program space, so you can copy the code from RAM to ROM and run it like self-modifying code

For the VM thing, all you'd have to do is get the compiled C++, check the EEPROM for which instruction to be ran, and run that instruction. Of course, running it nativity on the chip would be multiple times faster and that is no easy task, but it'd be a fun project to learn about lower level stuff on the 328P...

Yeah, but if you're going to do that then you may as well run something fun like Forth or Python.


text:
GPS logging on SD card using TinyGPS
I'm a beginner in Arduino world and I want to create a simple SD datalogger that works with GPS (module NEO-6M) and light sensor. I know there are a number of tutorials on GPS logging including:

Create a GPS Data Logger Using The Arduino (Bob Cravens)
Geo Data Logger: Arduino+GPS+SD+Accelerometer (Instructables)
Making a SD card GPS logger with Arduino and MTK3329 GPS module (Arduinodev)

but my problem is that those tutorials are either too complex (i.e. include extra stuff like displays) or they don't use TinyGPS or TinyGPS++ library. In the first step I've managed to get GPS working and displaying the result on my laptop screen (via Serial.print()) using example code from TinyGPS library. In the next step I managed to use tutorial for Adafruit Data Logger to log data on SD card. The problem: light sensor logs ok, but for GPS it only logs a strings of 99.999999. Tried various tweaks but so far not sure what I got wrong. I use Arduino Uno, NEO-6M GPS, Catalex MicroSD Card Adapter, simple LDR. Here is my current code:
    #include <TinyGPS++.h>
    #include <SoftwareSerial.h>
    #include "SD.h"

    //input for the light detecting sensor (LDR)
    int LDR = A3;

    //inputs and triggers for GPS
    TinyGPSPlus gps;
    SoftwareSerial ss (7, 8); // TX=7, RX=8

    // digital pin 4 for the SD cs line
    const int chipSelect = 4;
    File logfile;// the logging file

    //data logger timing and other
    #define LOG_INTERVAL  1000 // mills between entries
    #define SYNC_INTERVAL 1000 // mills between calls to flush() - to write data to the card
    uint32_t syncTime = 0; // time of last sync()
    #define ECHO_TO_SERIAL   1 // echo data to serial port
    #define WAIT_TO_START    0 // Wait for serial input in setup()

    void setup() {
      Serial.begin(9600);
      ss.begin(9600);
      Serial.println();

      #if WAIT_TO_START
        Serial.println("Type any character to start");
        while (!Serial.available());
      #endif //WAIT_TO_START

      // initialize the SD card
      Serial.print("Initializing SD card...");

      pinMode(10, OUTPUT);

      // see if the card is present and can be initialized:
      if (!SD.begin(chipSelect)) {
        Serial.println("Card failed, or not present");
        // don't do anything more:
        return;
      }
      Serial.println("card initialized.");

      // create a new file
      char filename[] = "LOGGER00.CSV";
      for (uint8_t i = 0; i < 100; i++) {
        filename[6] = i/10 + '0';
        filename[7] = i%10 + '0';
        if (! SD.exists(filename)) {
          // only open a new file if it doesn't exist
          logfile = SD.open(filename, FILE_WRITE);
          break;  // leave the loop!
        }
      }

      Serial.print("Logging to: ");
      Serial.println(filename);

      logfile.println("date,time,lat,long,light");

      #if ECHO_TO_SERIAL
        Serial.println("lat,log,date,time,altitude,light");
      #endif// attempt to write out the header to the file
    }

void loop(void) {

   // delay for the amount of time we want between readings
   delay((LOG_INTERVAL -1) - (millis() % LOG_INTERVAL));

   //here is GPS data (if I got it right)
   while (ss.available() > 0)
   gps.encode(ss.read());
   logfile.print(gps.date.value());
   logfile.print(", ");
   logfile.print(gps.time.value());
   logfile.print(", ");
   logfile.print(gps.location.lat(), 6);
   logfile.print(", ");
   logfile.print(gps.location.lng(), 6);
   logfile.print(", ");
   #if ECHO_TO_SERIAL
      Serial.print(gps.date.value());
      Serial.print(", ");
      Serial.print(gps.time.value());
      Serial.print(", ");
      Serial.print(gps.location.lat(), 6);
      Serial.print(", ");
      Serial.print(gps.location.lng(), 6);
      Serial.print(", ");
   #endif

   //Read light intensity
   float lux = 500/(10.72/(5-(photocellReading * 0.00488759))*(photocellReading * 0.00488759));
   logfile.println(lux);
   #if ECHO_TO_SERIAL
      Serial.println(lux);
   #endif //ECHO_TO_SERIAL

   //write data to disk
   if ((millis() - syncTime) < SYNC_INTERVAL) return;
   syncTime = millis();
   logfile.flush();
}

file.print maybe has different arguments - http://arduino.cc/en/Reference/FilePrint

have you seen Jeremy Blum's tutorial here?
http://www.jeremyblum.com/2012/07/16/tutorial-15-for-arduino-gps-tracking/comment-page-1/ I'm just trying to get it working with the UBlox LEA 6H at the moment. I think tinyGPS library may have changed slightly since he made the tutorial but it doesn't seem too hard to follow so far otherwise.