Show Posts
Pages: 1 ... 19 20 [21] 22 23 ... 25
301  Using Arduino / Microcontrollers / Re: Using an Arduino to flash new image? on: July 15, 2011, 10:56:23 am
What about using one Arduino board to multiplex programming to the others?  If your sketch doesn't make use of pins 0 and 1 this could be very simple:



FTDI = USB-to-serial interface
DI = digital input
DO = digital output
DTR = serial signal normally used to auto-reset Arduino prior to re-programming

The multiplexer is an Arduino running a simple sketch which distributes the DTR auto-reset signal to one of the downstream boards.  Whichever board received the reset then runs its bootloader and finds itself talking to AVRDUDE.  Of course the other boards must be sure to keep their serial-ports silent during this process.

It doesn't matter if the Arduinos have onboard serial interfaces or not.  You could use the cheaper Pro-Mini boards for this.
302  Using Arduino / Programming Questions / Re: Digital analog inputs? on: July 12, 2011, 06:26:19 pm
http://arduino.cc/en/Reference/DigitalRead
303  Using Arduino / Microcontrollers / Re: Freetronics Eleven vs Genuine Arduino on: July 01, 2011, 07:50:00 am
That Freetronics board looks rather good.  Does anybody know if they're available in Europe?
304  Using Arduino / Microcontrollers / Re: New optiboot; beta testers welcome... on: June 28, 2011, 02:58:06 pm
Does Optifix update the processor on which it is running or does it update other processors?

AFAIK it's not possible to rewrite the bootloader memory internally.  But if anybody wants to try out the new Optiboot v4.4 and they have two Arduino boards, the Optifix sketch avoids the need to disable auto-reset on the board acting as programmer.  Once one of the boards has Optiboot v4.4 installed it will run ArduinoISP properly (again without fiddling about disabling the reset signals).  Although for this purpose IMHO Optifix is easier to use than ArduinoISP + AVRdude.

I hope WestfW doesn't mind me beating this particular drum.  It's all his work.
305  Using Arduino / Microcontrollers / Re: New optiboot; beta testers welcome... on: June 28, 2011, 11:29:52 am
You don't need to disable auto-reset in order to upload a new bootloader.  Look for WestfW's Optifix sketch.  You'll need to update the binary data at the end of the sketch, but it's very easy to do.
306  Using Arduino / Microcontrollers / Re: Is the Arduino in trouble on: June 28, 2011, 11:25:54 am
For homebrew/standalone projects it's hard to pass up the advantages of a DIP chip for some users, like me.  smiley-grin

The Pro-Mini boards are phenomenally small -- not much bigger than a DIP chip -- and even manage to include a voltage regulator and a reset button.  Admittedly they're more expensive than a bare chip, but for simple projects you don't need any external components or even a PCB.
307  Using Arduino / Microcontrollers / Re: Is the Arduino in trouble on: June 27, 2011, 05:01:37 pm
I'm yet to see a nice and free C compiler that works with PIC. It's not chance that Arduino is based on AVR...

This is at the heart of the Arduino's success.  Until somebody comes up with PIC-GCC, PIC microcontrollers will never compete for the hearts and minds of hobbyists.  And if PIC-GCC does arrive, it won't compete with AVR-Arduino, it will just be added to it.  There will be PIC-based Arduino boards as well as AVR-based ones, and everybody will be happy.
308  Using Arduino / Programming Questions / Re: Will interrupts interfere with I2C comms? on: June 25, 2011, 05:13:34 pm
An interrupt will not disturb the transmission of an individual byte, since this is done in hardware.  And as long as the interrupt routine isn't terribly slow it will have returned by the time the EEPROM is ready for another byte.
309  Using Arduino / Microcontrollers / Re: problem uploading to atmega on breadboard on: June 25, 2011, 05:05:19 pm
The 16MHz clock frequency is high enough to cause RF interference.  Breadboard circuits with their long unshielded interconnects and dry joints are especially susceptible to interference, and this could be the cause of your problems.  To minimise this interference it's important to keep the wires as short as possible, especially for those carrying very high frequency signals such as those from the crystal.  You also need extra smoothing on the power supply, so put 100nF capacitors between V+ and Gnd at the points where they arrive at the CPU.
310  Using Arduino / Microcontrollers / Re: Bootloader and MCU reset register on: June 24, 2011, 12:45:40 pm
OK forget that idea - the interrupt vectors appear to reside in the application program memory, and are therefore not (easily) determined by the bootloader.
311  Using Arduino / Microcontrollers / Re: Bootloader and MCU reset register on: June 24, 2011, 07:53:31 am
Thinking about the Optiboot reset logic a little more...  After an External reset the bootloader runs, executes a Watchdog reset, runs again, and starts the application.  Is there any objection to having the WatchDog call appStart() via an interrupt, avoiding the extra reset and the need to clear MCUSR?  The "Watchdog Interrupt Enable" flag is apparently cleared automatically, avoiding any risk of creating a loop.

The following produces a 568-byte binary.  Any ideas for a more efficient way of setting the interrupt vector?
Code:
158a159
> #include <avr/interrupt.h>
289d289
<   MCUSR = 0;
654c654
<   WDTCSR = _BV(WDCE) | _BV(WDE);
---
>   WDTCSR = _BV(WDCE) | _BV(WDIE);
655a656,659
> }
>
> ISR(WDT_vect) {
>   appStart();
312  Using Arduino / Microcontrollers / Re: Bad Atmega328 chips? on: June 22, 2011, 07:45:27 pm
Maybe the PC is a little over-sensitive regarding bit-rate precision?  The programming bit-rate using ArduinoISP is lower and more precise than the sketch-upload rate (I don't know how it is with a genuine ICS programmer).
313  Using Arduino / Microcontrollers / Re: Bootloader and MCU reset register on: June 22, 2011, 06:28:01 pm
OK, so this doesn't work:
Code:
  // Adaboot no-wait mod
  ch = MCUSR;
  if (!(ch & _BV(EXTRF))) appStart();
  MCUSR = 0;
The watchdog is still running as the application starts, and resets it after a few ms - causing an endless loop.  Page 55 of the datasheet explains why:
Quote
WDE is overridden by WDRF in MCUSR. This means that WDE is always set when WDRF is
set. To clear WDE, WDRF must be cleared first.

This does work, at the cost of a couple of bytes of bootloader space:
Code:
  // Adaboot no-wait mod
  ch = MCUSR;
  MCUSR = 0; // required to prevent the bootloader from looping and the watchdog from biting
  GPIOR0 = ch; // <--- extra code
  if (!(ch & _BV(EXTRF))) appStart();
It goes slightly against the philosophy of having the bootloader interfere as little as possible with the state of the CPU, but all the IO registers are wiped anyway after a reset (p46 in the datasheet).

On powerup both the brown-out and power-on flags are set.  Presumably the brown-out condition is set as the power is removed and the on-board capacitors discharge, and remains when power is restored.  After an external reset, the watchdog-reset flag is set as expected.
314  Using Arduino / Microcontrollers / Re: Bootloader and MCU reset register on: June 21, 2011, 07:46:23 pm
Aaaah, now I understand.  So to avoid looping I need to write
Code:
  // Adaboot no-wait mod
  ch = MCUSR;
  if (!(ch & _BV(EXTRF))) appStart();
  MCUSR = 0;

My application will then be able to read the reset status, except that External resets will appear as Watchdog resets.
Hmm.  What about storing MCUSR in another register, such as GPIOR0?
Code:
  // Adaboot no-wait mod
  GPIOR0 = MCUSR;
  MCUSR = 0;
  if (!(GPIOR0 & _BV(EXTRF))) appStart();

Time for some experimentation.  Thanks again,
315  Using Arduino / Microcontrollers / Re: Bootloader and MCU reset register on: June 21, 2011, 06:25:22 pm
Thanks for the great info guys.  P54 of the ATmega datasheet indicates that the MCUSR flags have to be explicitly cleared between resets.  As far as I can see it is safe to do this in the application code: the worst that can happen is that the application fails to clear EXTRF before a non-external reset, causing the "no-wait" check to execute the bootloader needlessly.

I haven't quite wrapped my head around the Reset vectors yet.  Reading the Optiboot v44 code, if the bootloader receives no readable character within 1s, then the watchdog induces a system reset.  But with BOOTRST programmed, why does this cause the application to run rather than restarting the bootloader?
Pages: 1 ... 19 20 [21] 22 23 ... 25