Hi Tim,

thanks a lot for you work! I've uploaded your sketch to the JP1 file area, so it doesn't get lost.
 
  Michael

[Serial]

I have been playing around with auto-reset for the Arduino-BT some years ago. For practical reasons auto-reset is not really what I wanted, because always resetting your sketch when you connect via Bluetooth is a pain and you need an option to turn it off.

For the BlueController board I have adapted the Arduino Bootloader and added the following features which are much more practical:
1. enter the bootloader by calling a function from the currently running sketch
2. enter the bootloader by pressing a switch on the board together with the reset switch
In both cases the bootloader remains active for around 30 seconds (can be adjusted)

Normally I use the first variant and only when my sketch is totally screwed up I have to use the local switch as a last resort.

How it works? In your loop() you will normally process commands which arrive from the serial port. Just add one command to switch to the bootloader:

void loop(void)
{
  int16_t ch;
  while((ch = Serial.read()) >= 0)
  {
      switch(ch)
      {
        case 'y':
          Serial.println("enter_bootloader()");
          enter_bootloader();
          break;    

        case 'x':
          Serial.println("soft_reset()");
          soft_reset();
          break;
      }
    }
}

Before Downloading a new sketch, you have to open the Serial Monitor and enter "y" to start the bootloader, then press the download button.

The whole project can be found here.

Another project I'm working on is a ISP-programmer based on the BlueController board which speeds up the bluetooth download by factor 10. The programmer needs 7 seconds for the complete download (incl. verify) compared to 70 seconds using the bootloader without the optimization. Unfortunately the code is too large to fit in the bootloader.

  Michael

I think your patch would make that worse, assuming the watchdog is still always reset in getch().  Normally, getting to the sketch promptly when the character stream doesn't look like bootloader commands is a good thing.   Any ideas on resolving this incompatibility?

The watchdog is reset in getch() even when waiting for but not getting a new character, but there is a configurable time limit based on timer overflow. One timer overflow takes about 4.2s@16MHz, so the app would start after this timeout.

It's too late to think about it today, I'll be back in a week.

  Michael

I plan to include an example program to read files on a PC/Mac since the files are binary. What language would be best for the PC part of the example? I am considering Java, Perl, or Python.

I'm really impressed about the performance!

Why don't you use Processing as base. I haven't used it myself, but it's portable and using Java.

My os is arch linux (if that helps anything)

Do you have a recent version of avrdude? The older versions didn't support the "toggle DTR/RTS line" feature which is needed for auto-reset. I'm currently using V5.10 on a Mac.

Actually, it must detect nothing but corrupt data for the entire bootloader timeout (~1s) to exit.  I'm not sure that that's a great algorithm, but it seems to be working OK.

No, one character which doesn't fit in the protocol is enough:

Code:

### default case of main loop:
 else {
      // This covers the response to commands like STK_ENTER_PROGMODE
      verifySpace();
    }

### will start app if the next character is != CRC_EOP
void verifySpace() {
  if (getch() != CRC_EOP) {
    watchdogConfig(WATCHDOG_16MS);    // shorten WD timeout
    while (1)                         // and busy-loop so that WD causes
      ;                               //  a reset and app start.

This is one of my changes. As long as the initial sync sequence has not been detected, all errors are ignored:

Code:

#if defined(BLUECONTROLLER) 
    if(ch == STK_GET_SYNC) {
      // this is the initial sequence, sent by avrdude
      verifySpace();
      blueCAvrdudeSynced = 1; // ignore all errors as long as this is 0
    }
    else 
#endif

void verifySpace() {
  if (getch() == CRC_EOP)
  {
    putch(STK_INSYNC);
  }
  else
  {
#if defined(BLUECONTROLLER)
    // ignore error when not synced, otherwise some initial garbage will exit the bootloader
    if(blueCAvrdudeSynced)
      appStart();
#else
    appStart();
#endif
  }
}

The Uno was over TWICE as fast as the FTDI-based Arduino, with everything else being the same

They are playing in a different league

The bluetooth communication of the BlueController and the Arduino BT is around 30 times slower than the direct serial communication, so an additional three seconds really don't matter.

When I have the time I will do some investigations about the problem. I think the reason is the much larger latency and not the throughput of the connection. Every ping-pong takes its time.

  Michael
 

[+ if (address < NRWWSTART)+ 1fcba: 80 e0 ldi r24, 0x00 ; 0+ 1fcbc: e8 16 cp r14, r24+ 1fcbe: 80 ee ldi r24, 0xE0 ; 224+ 1fcc0: f8 06 cpc r15, r24+ 1fcc2: 20 f4 brcc .+8 ; 0x1fccc <main+0xcc>+ __boot_page_erase_short((uint16_t)(void*)address);+ 1fcc4: 83 e0 ldi r24, 0x03 ; 3+ 1fcc6: f7 01 movw r30, r14+ 1fcc8: 87 bf out 0x37, r24 ; 55+ 1fcca: e8 95 spm+ 1fccc: c2 e0 ldi r28, 0x02 ; 2+ 1fcce: d2 e0 ldi r29, 0x02 ; 2]

Hi westfw,

• Code space reduction (alas, more features show up to consume the saved space)
• 380 optiboot has problems uploading sketches bigger than about 30 KB

the fix for issue 380 (see below) is consuming 32 additional bytes which I badly needed for my BlueController extensions. Therefore I could not use the overlapping boot_page_erase() and serial communication. For the Bluetooth communication this doesn't matter. Comparing the time with and without overlapping erase gave no difference. I haven't tested it with USB UART communication right now.

The code that could be saved is in bold:
+      // If we are in RWW section, immediately start page erase
+#if !defined(BLUECONTROLLER)
+      if (address < NRWWSTART)
+   1fcba:   80 e0          ldi   r24, 0x00   ; 0
+   1fcbc:   e8 16          cp   r14, r24
+   1fcbe:   80 ee          ldi   r24, 0xE0   ; 224
+   1fcc0:   f8 06          cpc   r15, r24
+   1fcc2:   20 f4          brcc   .+8         ; 0x1fccc <main+0xcc>
+        __boot_page_erase_short((uint16_t)(void*)address);
+   1fcc4:   83 e0          ldi   r24, 0x03   ; 3
+   1fcc6:   f7 01          movw   r30, r14
+   1fcc8:   87 bf          out   0x37, r24   ; 55
+   1fcca:   e8 95          spm
+   1fccc:   c2 e0          ldi   r28, 0x02   ; 2
+   1fcce:   d2 e0          ldi   r29, 0x02   ; 2
+#endif
[...]
+      // If we are in NRWW section, page erase has to be delayed until now.
+      // Todo: Take RAMPZ into account
+#if !defined(BLUECONTROLLER)
+      if (address >= NRWWSTART)
+   1fcd8:   f0 e0          ldi   r31, 0x00   ; 0
+   1fcda:   ef 16          cp   r14, r31
+   1fcdc:   f0 ee          ldi   r31, 0xE0   ; 224
+   1fcde:   ff 06          cpc   r15, r31
+   1fce0:   20 f0          brcs   .+8         ; 0x1fcea <main+0xea>
+#endif
+        __boot_page_erase_short((uint16_t)(void*)address);
+   1fce2:   83 e0          ldi   r24, 0x03   ; 3
+   1fce4:   f7 01          movw   r30, r14
+   1fce6:   87 bf          out   0x37, r24   ; 55
+   1fce8:   e8 95          spm
+      }
+#endif

Without loosing any performance or functionality, the code can be optimized to compare only the high-byte of the NRWWSTART, (because the low byte of NRWWSTART will always be zero) which saves 6 bytes:

Code:

     // If we are in RWW section, immediately start page erase
#if !defined(BLUECONTROLLER)
      if ((uint8_t)(address >> 8) < (uint8_t)(NRWWSTART >> 8))
    7eb0:       8d 2d           mov     r24, r13
    7eb2:       99 27           eor     r25, r25
    7eb4:       08 2f           mov     r16, r24
    7eb6:       80 37           cpi     r24, 0x70       ; 112
    7eb8:       20 f4           brcc    .+8             ; 0x7ec2 <main+0xc2>
        __boot_page_erase_short((uint16_t)(void*)address);
    7eba:       83 e0           ldi     r24, 0x03       ; 3
    7ebc:       f6 01           movw    r30, r12
    7ebe:       87 bf           out     0x37, r24       ; 55
    7ec0:       e8 95           spm
    7ec2:       c2 e0           ldi     r28, 0x02       ; 2
    7ec4:       d1 e0           ldi     r29, 0x01       ; 1
#endif      
[...]
      // If we are in NRWW section, page erase has to be delayed until now.
      // Todo: Take RAMPZ into account
#if !defined(BLUECONTROLLER)
      if (!((uint8_t)(address >> 8) < (uint8_t)(NRWWSTART >> 8)))
    7ece:       00 37           cpi     r16, 0x70       ; 112
    7ed0:       20 f0           brcs    .+8             ; 0x7eda <main+0xda>
#endif
        __boot_page_erase_short((uint16_t)(void*)address);
    7ed2:       83 e0           ldi     r24, 0x03       ; 3
    7ed4:       f6 01           movw    r30, r12
    7ed6:       87 bf           out     0x37, r24       ; 55
    7ed8:       e8 95           spm
      }
#endif

I don't understand why the compiler generates the mov+eor+mov instructions for the first compare, maybe you have an idea?

  Michael

Hi westfw,

I've been working on the Arduino copy of optiboot, and have a new version that could use some testing.
Hex file (for m328) attached.  Source and stuff at https://github.com/WestfW/Arduino

Yesterday I started a new optiboot clone at google code which includes almost the same changes to the original optiboot you also mentioned  

My main focus was to integrate the BlueController board in the Arduino environment. The BlueController includes a Bluetooth module BTM-222 onboard (just like the Arduino-BT), but using my modified optiboot bootloader, the download of sketches works much more reliable as on the Arduino-BT!

Some additions were necessary for the BlueController which can be useful for any other boards which don't support auto-reset, even for the Arduino-BT. Currently I use the #define BLUECONTROLLER to distinguish between the BlueController board and other boards, but it makes sense to use multiple #defines for hardware specific code (like the LED pin number) and the support of the longer timeout for boards without auto-reset.

Is there a reason using GitHub instead of Google code? I wanted to merge back my changes to the original optiboot branch, therefore I used Google code. The most obvious advantage is that my project is directly linked together with the original project. Actually I wouldn't have started the new clone if I had seen yours before.

  Michael

Hi ksamay,

1Mbps / 10 bits/char = 100000 chars/s
16 MHz / 100000 chars/s = 160 CPU cycles per character

receiving at 1 MBps requires a very tight timing and even disabling IRQs for a very short time (1 character = 160 CPU cycles) is enough for the serial receive ISR to lose data.

This means:
1. avoid to disable IRQs whenever possible
2. if you have to disable IRQs, keep the the time as short as possible
3. the same as #1&#2 for other ISRs, e.g. the timer IRQ used for millis()/micros()

The timer ISR is called every 1024 microseconds and it might take more than 160 CPU cycles. When you don't need the time functions, you can disable the timer ISR:

Code:

     cbi(TIMSK0, TOIE0);

Please try if this fixes your problem.

  MikeT

Hi ZNero,

The iWrap documentation can be downloaded from sparkfun without registering:
 http://www.sparkfun.com/datasheets/Wireless/Bluetooth/iWRAP3_User_Guide.pdf.

Normally the WT-11 on the Arduino-BT has iWrap 2.2.0 so you have to take care which features are missing.

The bluetooth heart rate devices should use the Health Device Profile (HDP) which will be supported by iWrap4 so either you have to implement the profile yourself, or upgrade your firmware.

Some information about iWrap+HDP:  http://www.bluegiga.com/files/bluegiga/Pub%20files/Bluegiga_iWRAP_HDP_Application_Note.pdf.

You should have a  look at the receiver module RMCM01 for Polar Heartrate belts http://www.sparkfun.com/commerce/product_info.php?products_id=8660. It should be much easier to use than the Bluetooth devices, because the protocol is much simpler. The range is limited to at most 80cm.

Another alternative are the Garmin Heart Rate Belts for which you would need the receiver chip nRF24L01+ http://www.sparkfun.com/commerce/product_info.php?products_id=690. I haven't found anything about the protocol so this really a challenge.

  MikeT

Hi Steffen,

the Arduino-BT works even with power sources which provide less than 2.0V.

  MikeT

[and hold]

Hi Steffen,

Do you have any hardware connected to the board? => remove it
Can your measure the 3.3V and 5V voltages?

You can try the following:
1. Disconnect the power
2. Press and hold the reset button
3. Connect the power
4. Search for bluetooth devices (reset button still pressed)

  MikeT

[SP3]

Hi Steffen,

Does the driver of your usb bluetooth device support the serial port profile (SPP)?

I suggest to deinstall the original bluetooth driver and update to XP+SP3 which includes a simple bluetooth driver that works with most of the hardware. It only supports the most important bluetooth profiles, but SPP is supported.

Do you have a sketch running? Try it with the simple "Blink" sketch and avoid any Serial.print() until you succeed with connecting from your PC.

  MikeT

Hi,

SD-Cards draw a large current when they are inserted or powered up because they have a built-in capacitor (500 nF or 1uF ?). Do you have an appropriate capacitor (e.g. 1 uF) for the SD-Card between Vcc and GND?

Are you using a ATmega168 or ATmega328? The RAM in the 168 is very limited with 1024 byte because the SD-Card read/write buffer needs 512 byte, the serial buffer 128 byte, etc. so there is not much left for your application. When you run out of memory with a stack overflow, you will get funny effects and in the best case a restart of your sketch. The ATmega328 with its 2048 byte RAM is the better choice.

  MikeT