I don't think any of that is at issue, though. The problem is that Arduino1.0.3 doesn't seem to obey the dictates of programmers.txt. I was hoping someone who has dealt with this issue could tell me what my problem is.
I've been searching everywhere for help on this, but part of the problem is that virtually nobody says whether what they are describing is happening in Arduino1.X or in the pre-1.0 version of Arduino. The differences between those two are pretty big (and software incompatibility has kept me using Arduino23 (pre 1.0) for any actual work I do. That said...
I cannot for the life of me figure out how to get my PonySerial programmer working in the Arduino 1.0.3 IDE. I tried editing programmers.txt, but the IDE (unliked Arduino23) seems to completely ignore that info. I know, because I changed the names of the programmers and nothing changed. Evidently it is pulling its programmers.txt file from somewhere other than C:\Program Files (x86)\arduino\hardware\arduino . Argh! I'm about ready to cry. Why couldn't things work like they did under Arduino23? Part of the reason I try to stick with open source as opposed to proprietary environments is that changes tend to be evolutionary and not revolutionary.
Here's my solar controller, which involves master/slave Arduinos, an LCD, a real time clock, a range finder, and EEPROMs, so there should be plenty of example code in here for those who are hungry for that sort of thing. Most recently I created an interactive menu system using an LCD and an IR mutifunction remote (the code is all in the slave arduino).
the thing is, if you don't know the name for something and are simply experiencing a problem that you think you can solve, you find yourself designing something (at least in your head) until finally your research takes you to the wheel that has already been invented. i did a lot of research on how best to implement a 555 "auto resetter" (as i called it) before stumbling across a web page that spoke of watchdogs. at that point i found atmel builds watchdogs into their chips and i was ecstatic! i didn't have to build anything, i just needed a different bootloader and a couple lines of code. the more i work with arduino, the more i discover how rich an environment it is. there's the arduino layer, but just beneath that is this huge avr layer. i do a google search, find some non-arduino page referencing libraries that turn out to exist in the the arduino environment. it's continually surprising (but in a good way).
a few days ago, i found myself needing a watchdog without evening knowing there was such a thing and that it had a name. my initial plan was to hook up two 555 timers (actually, two such timers in a 556 package), using one as a missing pulse detector and the other as a brief one-shot (it would have to work through a logical inverter). i'd dedicate an arduino pin to sending regular pulses to the missing pulse detector, and if that ever failed, i'd fire the one shot, which would strobe the reset pin through the inverter. it wouldn't be difficult to implement and wouldn't require a special bootloader. but then i discovered that watchdogs are real things and are implemented in hardware on atmel chips. the tricky part was getting past the stock bootloader, which is inherently incompatible with the built-in hardware watchdog. if i were in your position and gave up on the bootloader, i might implement the dual 555 analog watchdog.
After much experimenting, I was finally able to implement the Atmega328's watchdog. This required, among other things, use of the Optiboot bootloader (which works so much better than stock bootloaders!). My question is: does anyone know if a reset generated by the watchdog timer actually pulls the Atmega328's reset line low electrically? I'm curious because that line is connect to other things and it would be nice to know that they are also rebooting (or, if they are not, i might need to do something). I know I could watch the reset line with an oscilloscope, but I don't feel like taking the circuit out of its application and hooking all that up right now.
i don't have the arduino cookbook. things are moving so fast with arduino that a book would probably get out of date pretty fast. i started working on atmega8s and my old sketches resemble my first VIC-20 BASIC programs: short and primitive.
this is in reply to nick about the use of Wire.available(). interestingly, i'd had code in there to do that but had bypassed it for some reason (i notice it's occasionally not used when communicating with certain other i2c devices when the byte count to be returned is known). re-enabling it seems to be making my communication completely reliable. thanks for the idea!
Can you explain exactly what you mean by "synchronously" in this context? Do you mean, you ask a question and get an answer?
i mean to ask a question of a device and then stop everything while waiting for an answer (as opposed to asynchronously, where i ask a question, go on with the program, and get the answer later, perhaps as an interrupt or in some place i can poll).
What is the problem with global variables? The response is done in an interrupt handle
there's nothing wrong with it -- but initially i'd thought the onRequest handler could also read data being passed in with the request. this does not appear to be the case. i'd found no examples of anyone using a slave to do request-response type data exchanges of the type done by, say, a 24LC512 EEPROM, and i wanted to implement it.
I have done some examples of sending/receiving data via I2C here (scroll down to "Request/response"):
nice! i would have loved to find this example when i was working on the problem.
You shouldn't need to send things three times. Why do that?
i did it because i'd often get zero instead of the byte i'd requested. i have no idea why -- it was being flaky. i need to investigate further. the other i2c devices on the bus all seem to work fine; it's just the slave that occasionally throws out glitch zeroes in response to queries.
i don't know how to slow things down on the i2c bus -- there doesn't appear to be support in the Wire library for that. as for the amount of code -- that's the whole system and i didn't have time to break out the parts. the slave code (slaverman.pde) is actually the most interesting, since it allows the slave to behave like any good synchronous query-and-respond i2c slave (such as the Ds1307 real time clock).
to be clear, the i2c stuff is entirely separate from the serial communications to the computer i use to program the arduinos. basically, i have an old-school arduino setup using a max232 chip instead of the USB chip an arduino normally has (i'm not actually using an arduino board -- just the bootloader and the IDE). it's all in the basement 100 feet from my computer, so i had to use rs-232 for communication since usb range isn't very good.
down in the basement are two atmega328s connected via their i2c ports (pins 28 and 27). the master can read and write the analog and digital pins on the slave by specifying which ones it wants. it can also read and write the slave's eeprom. it cannot reflash the slave's firmware. to do that i have to throw a switch that decides which atmega's serial port (pins 2 and 3) is connected to the rs-232 cable. if you look at the source code in the link, you can see the details of the i2c communication. as far as i know, this is the only example online of reasonably-successful synchronous query-response communication between master and slave arduinos.
the reason it is so important to be able to query the slave from the master is that the master's code supports a sort of telnet-style interpreter to which i can send commands. these commands come to the master via rs-232 and can then be forwarded onto the slave.
as for the range of i2c communications, i've kept that bus short because it gets unreliable when it gets longer than a few feet. however, the rangefinder (which reads fuel level in an oil tank) has to be twelve feet away. to read it, i temporarily connect a "long range i2c" cable via quad bilateral switches for just the time necessary to make the reading. this seems to work okay.
This is just to report my progress with getting a master Arduino to send query information to a slave Arduino, which then synchronously returns the specified data.
I'm using a master-slave Arduino pair (along with a real time clock, two 24LC1025 I2C EEPROMs, and a SRF08 range finder as part of a solar/boiler controller in my basement. All of this is networked via RS-232 (not USB, since it doesn't have the range) to my laboratory computer.
A thought occurred to me about the master and slave Atmegas in the solar controller and why I was having such a difficult time making a system allowing the master to synchronously request data from the slave. The documentation of "Wire," the library responsible for I2C communication in Atmegas, is spotty and example-free, and I've been able to find no examples online of anyone sending requests from a master for the return of specific data from a slave. Part of the problem I'd been having was my assumptions about how the Wire.onRequest (http://www.arduino.cc/en/Reference/WireOnRequest) handler works. I'd assumed that this handler could be used to retrieve data sent by the master (since other I2C devices seemed to work this way). But it turns out that this is not the case. To send data to a slave as part of a synchronous request followed by a returned result, the slave can only retrieve the request data using the onReceive (http://www.arduino.cc/en/Reference/WireOnReceive) method. On the slave side, this means that the onReceive handler has to take the data passed to it, process it however it needs to be processed, and put the results into global variables that can then be queried in the onRequest handler.
I stayed up late working on this problem but wasn't having much luck solving it. This morning I got up early and continued to work on it, trying a few things that occurred to me after I'd awaken (but before I'd gotten out bed). But no matter what I did, I couldn't make synchronous communication completely error-free, but I managed to come close by sending three copies of all the data being requested and testing to see if they all matched. Those as frustrated by this problem as I have been are welcome to download my code (http://asecular.com/ran/1103/release02.zip), which includes this master-slave synchronous communication (along with many other things).
i have several different arduinos (or arduino-like boards) connected to my computer on several different serial ports. what i would find useful is an implementation of the IDE where different windows could remember the board type and serial port independently of one another. this would allow me to have several windows up and i could reflash to the various boards from the various windows without having to keep changing the connection and board settings as i go back and forth (some are atmega168s, some are atmega 328s, and all use different serial ports). this might sound like a small thing, but in a complex setup such as i have, it makes sense for the IDE windows to remember their state. how hard would it be to hack the IDE to do this?
So what fuse state should the 328 be left in after the bootloader has been uploaded? Feel free to reply in terms of acceptable fuse setting command as it would be entered into AVRdude.
Also, what might a good fuse unlocking command (issued prior to a bootloader upload) be? Again, feel free to give your answer as you would make it to AVRdude. I don't need an explanation of what the bits are and what they do and the history of how they have changed from Atmel processor to Atmel processor through the years, although I'm sure that is a fascinating subject.
I'm asking this because the bootloader I keep writing in AVRdude keeps getting overwritten by the Arduino IDE - and perhaps this is an IDE problem and not a fuse problem.