Show Posts
Pages: [1]
1  Development / Suggestions for the Arduino Project / Re: Avoiding mismatch errors from verification on: December 04, 2013, 04:15:32 pm
westfw,

"The problem is that "verification" is done by avrdude, not by the ArduinoISP sketch.  Avrdude uses low-level commands to write one page at a time, and then more low-level commands to read back the memory (one page at a time), and compares the read-back version to the sent version."

Agreed. However, the ArduinoISP sketch can reasonably expect that page write commands will fail (with no error indications) if a chip erase command has not been previously received.

"(Also, the protocol used between avrdude and arduinoISP is pretty stupid, and doesn't offer any good ways to send back a detailed error indication like "I don't think I can program that page because it hasn't been erased.")"

Agreed. My (lame) idea is to send the error message back in the verification data. This is quite doable. However, only someone with verbose turned on would ever see the error message (and then only if they knew to look for it).

"Huh?  The IDE won't use the configured programmer unless you use the  "upload using programmer" option."

This is not correct. I went into boards.txt and set mighty_opt.upload.protocol=zebras. I then clicked on the standard Upload button and got

C:\Users\Peter\arduino-1.0.5\hardware/tools/avr/bin/avrdude -CC:\Users\Peter\arduino-1.0.5\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patmega1284p -czebras -P\\.\COM4 -b19200 -D -Uflash:w:C:\Users\Peter\AppData\Local\Temp\build7604730678725251018.tmp\Blink.cpp.hex:i

Of course, Avrdude didn't like it,

"That's not strictly true.  You can change "one bits" into "zero bits" in flash, even if there is already data there."

Agreed. However, as a practical matter... You have to do a chip erase to get a useful result from flash programming. Stated more broadly its always true that you can only change "one bits" into "zero bits". Chip erase simply forces all of the flash bits to "one bits" so that setting some to zero gives that correct code in flash memory.

"And the bootloader NEVER does a chip-erase; it can do a one-page erase before each page is programmed, assuming that avrdude doesn't decide to "optimize" by skipping pages that are already all ones."

Agreed. However, I am using the ArduinoISP sketch to upload sketches.

The underlying idea is that the Upload button shouldn't issue an Avrdude command with a -c set to anything other than arduino and the -D flag set, because the combination isn't likely to work. Instead it should point the user to the 'Upload Using Programmer' menu entry or just drop the -D flag (probably too dangerous because of the side effects).







2  Development / Suggestions for the Arduino Project / Re: Avoiding mismatch errors from verification on: December 04, 2013, 03:52:15 pm
Coding Badly,

IDE version is 1.0.5.

The actual problem (as I see it) is that it is possible (easy) to get a quite mysterious error message (verification mismatch) using the IDE, when the IDE (or even the ArduinoISP sketch) could detect the problem in advance and produce a much more intelligible error message or perhaps avoid the error by taking a different programming path.

What actually happens is this. Boards.txt has the upload protocol for some board set to stk500v1 (as in mighty_opt.upload.protocol=stk500v1). Of course, it doesn't have to just be stk500v1. Any ISP type programmer would probably produce the same error. Note that I specified stk500v1 because I was using the ArduinoISP sketch (running on an Uno R3) to load other sketches (blink for example) onto my target system (ATMega1284p).

You then click the standard upload button. The IDE generates the Avrdude command below.

C:\Users\Peter\arduino-1.0.5\hardware/tools/avr/bin/avrdude -CC:\Users\Peter\arduino-1.0.5\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patmega1284p -cstk500v1 -P\\.\COM4 -b19200 -D -Uflash:w:C:\Users\Peter\AppData\Local\Temp\build8679411521618747254.tmp\Blink.cpp.hex:i

Note that -c is set to stk500v1 (from boards.txt) and -p is atmega1284p (my target chip). Of great importance is the -D flag. The -D flag blocks the chip erase making sure that the sketch will never actually be stored on the ATMega1284p chip. Of course, you eventually get an error message.

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0159
         0xee != 0xec
avrdude: verification error; content mismatch

Now if you (intelligently) use the 'Upload Using Programmer' menu item the Avrdude command is.

C:\Users\Peter\arduino-1.0.5\hardware/tools/avr/bin/avrdude -CC:\Users\Peter\arduino-1.0.5\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patmega1284p -cstk500v1 -P\\.\COM4 -b19200 -Uflash:w:C:\Users\Peter\AppData\Local\Temp\build8679411521618747254.tmp\Blink.cpp.hex:i

Since the -D flag is missing a chip erase gets done. The following is from the Arvdude output

avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: Send: V [56] . [ac] . [80] . [00] . [00]   [20]

Of course, you don't see all of those messages about erasing the flash if you use the standard upload button.

What could be done about this? Several things come to mind. The ArduinoISP sketch could simply refuse to try to program any flash if it had not received a prior chip erase command (V [56] . [ac] . [80] . [00] . [00]   [20]). The standard Atmel chips don't allow flash to be programmed until a chip erase command has been received.

Changing the ArduinoISP sketch would work, but the sketch has no easy way to report errors back to the user. Most folks probably don't run with verbose turned on and wouldn't see any special response the ArduinoISP sketch might generate.

However, the upload button could detect that Avrdude is about to be invoked with a combination of options that won't work. Setting -c to stk500v1 with the -D flag simply won't work. Of course, many other possible values for -c won't work the -D flag. The one value for -c that will work with -D is -carduino. Why? Because -carduino uses the bootloader and the bootloader is allowed to update the flash even with the -D flag. In other words, chip erase is not required with -carduino because the bootloader updates the flash in a very different way.

If the upload button detected  that -c specified a programmer (other than -carduino) it could simply produce an error message telling the user to switch to 'Upload Using Progammer'. Of course, it could also just remove the -D flag and proceed. This will work. However, the downside is material. Chip erase wipes out the bootloader (if you have one installed) and that might be a very unexpected side effect.
3  Development / Suggestions for the Arduino Project / Avoiding mismatch errors from verification on: December 03, 2013, 04:20:25 pm
I have a modest suggestion for the 'Arduino as ISP' sketch. Basically, it should verify that a chip erase has been one before trying to store anything in the flash. The problem is that NOT doing a chip erase doesn't produce any errors, until the verification phase. In other words, the upload of a sketch will appear to work, with some sort of mismatch error being reported during verification.

The chip erase operation is easy to detect. If it hasn't been done, the flash can't be updated (although update attempts don't appear to return any errors). This program could be reported several ways. Perhaps the first few byte of the verification data could actually be set to a error message ('Chip erase required before updating flash - try Upload Using Programmer')

This problem can be resolved with the existing code just by using the 'Upload Using Programmer' file menu entry. Still making this change might help a few folks avoid mysterious 'mismatch' verification errors.

Of course, I found out about this the hard way... By NOT using the  'Upload Using Programmer' file menu entry when I needed to.

If it matters, I can make the code changes and submit them (assuming this is a desirable change).

Here is a different idea. Change the Arduino IDE so that any attempt to use the Upload button produces an error message if a programmer has been specified. The message could be something like 'Upload Using Programmer required with programmer xxxxxxxx'. Indeed, the Upload button could even invoke 'Upload Using Programmer' if a programmer was detected in the boards.txt file.

The overall idea is to make the upload process a bit more foolproof.
4  Using Arduino / Interfacing w/ Software on the Computer / Re: How do you run a Processing and Arduino Sketch's at the same time? on: April 06, 2013, 08:34:13 am
All of the answers so far are correct. However, let me try to answer the question in a somewhat different way. The Arduino IDE (running under OSX, Windows, Linux, etc.) only uses a serial connection to talk to the Arduino when a sketch is being loaded into the Arduino. This isn't quite true because you can bring up the Serial Monitor (under Tools) and send character data to the Arduino and receive data (characters) from the Arduino. However, one point is critical. The Arduino IDE needs access to the serial connection when it is attempting to upload a sketch.

Processing programs may or may not use zero or more serial connections while they are actually running. In my testing, Processing programs (also called sketches, but referred to here as Processing programs to avoid confusion) only really use a serial connection when they are running. Once they are stopped, the serial connection is released. Of course, they don't use a serial connection before they are started.

What this means is that you really have two choices. First, you can simply use separate serial connections for your Arduino versus your Processing programs. This is very reasonable unless it is your goal to have the Processing program communicate with your Arduino sketch. If that is true (Processsing program <-> Arduino sketch), then they must share a serial connection (very easy to do).

The second approach is to share one serial connection. This means that you must stop your Processing program every time you use the Arduino IDE to upload a sketch or invoke the Serial Monitor. Note the you don't need to terminate the Processing application altogether. Just stopping the running sketch will suffice.

My approach was to keep both IDEs active (Arduino and Processing). I stopped my Processing program each time I needed to upload a new version of my sketch. I then restarted the Processing program. This methodology worked smoothly in my testing.
5  Using Arduino / Networking, Protocols, and Devices / Re: UDP Packet to Every IP on: April 05, 2013, 03:58:24 pm
SFP,

Note that the code works with a standard Arduino Ethernet shield. Check out http://www.ebay.com/itm/300851543921?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649 for an example.

Also note that the Ethernet shield uses several pins including pin 4. That's why the LED code uses pin 5.
6  Using Arduino / Networking, Protocols, and Devices / Re: UDP Packet to Every IP on: April 05, 2013, 03:56:13 pm
SFP,

Sure. Just go to https://www.dropbox.com/sh/1ygg760hfygvimf/DtF0Erdfvm

Ignore the LED related code (you can delete it). The UDP code successfully reads UDP datagrams broadcast (probably multicast to be more accurate) from various Art-Net components.
7  Using Arduino / LEDs and Multiplexing / Re: Need help on sequencing LEDs on: April 05, 2013, 02:27:31 pm
A few notes:

1. You need an LED strip where each LED can be separately and uniquely addressed. Many are available from online sources.
2. You need an Arduino library that support addressing each LED separately. From experience I can assure you that FastSPI works smoothly.

My LED strip is WS2811 based which does support addressing each LED separately.
8  Development / Suggestions for the Arduino Project / Re: USB-Serial adapter gets "lost" on: April 05, 2013, 02:14:33 pm
All,

I have definitely seen this problem in Windows (7). I found that it was a power problem. I my Arduino had a heavy power draw (an LED strip in my case) attached to it, the serial connection (COMt6 in my case) was very, very flaky. Detaching the LED strip made the serial connection very stable.

I was able to keep the LED strip attached and keep the serial connection stable by adding an external 5V power supply to my Arduino.
9  Development / Suggestions for the Arduino Project / Sample Program Wrong in Ethernet UDP Read Example on: April 05, 2013, 02:08:21 pm
All,

The sample program over at http://arduino.cc/en/Reference/EthernetUDPRead is great. Works properly... Except for the not setting the serial data rate and doing a Serial.begin().

The following lines need to be added to setup()

const unsigned int BAUD_RATE = 9600;
Serial.begin(BAUD_RATE)

How can this be fixed?
10  Using Arduino / Networking, Protocols, and Devices / Re: UDP Packet to Every IP on: April 05, 2013, 02:02:25 pm
Interesting question. As I see it, you have two choice. First, you might be able to get you iOS device to use UDP broadcast / multicast. That way, the Arduino will get every packet as long as they are on the same subnet. I have used this approach very successfully. I am receiving UDP datagrams on my Arduino that were sent via various Art-Net enabled programs.

Second, you might have the Arduino code broadcast its IP address via UDP broadcast / multicast.

The first approach is easier (assuming that iOS will let you use UDP broadcast / multicast). The second approach is more efficient. 
11  Using Arduino / Networking, Protocols, and Devices / Sample Program Wrong in Ethernet UDP Read Example on: April 05, 2013, 01:58:05 pm
All,

The sample program over at http://arduino.cc/en/Reference/EthernetUDPRead is great. Works properly... Except for the not setting the serial data rate and doing a Serial.begin().

The following lines need to be added to setup()

const unsigned int BAUD_RATE = 9600;
Serial.begin(BAUD_RATE)

How can this be fixed?
Pages: [1]