Sharing sketches between projects

[marceltrapman]

@HEK already working on it. Easier than I thought :)

[Yveaux]

@marceltrapman If 90% of your code is identical between sensor sketches (e.g. all the MySensors stuff etc. etc) except for e.g. the code to read the sensor and send the value, a simple way could be to use #defines to conditionally compile code, e.g.

// Compile your sketch this time with TEMP sensor, but no HUM sensor
#define TEMP_SENSOR
// #define HUM_SENSOR

void setup()
{
  // ... Do all your normal stuff
  #ifdef TEMP_SENSOR
  gw.sendSensorPresentation(0, S_TEMP);
  #endif
  #ifdef HUM_SENSOR
  // Not compiled in this run
  gw.sendSensorPresentation(0, S_HUM);
  #endif
}

void loop()
{
  // ... Again, all the regular stuff
  #ifdef TEMP_SENSOR
  gw.sendVariable(0, V_TEMP, readTemp() );
  #endif
  #ifdef HUM_SENSOR
  // Not compiled in this run
  gw.sendVariable(0, V_HUM, readHum() );
  #endif
}

Then, later on, when you compile your humidity sensor code, you only change the top #define's :

// #define TEMP_SENSOR
#define HUM_SENSOR

Compile, flash and you've created a humidity sensor.

[marceltrapman]

@Yveaux Also a nice idea.
I am not yet at a point that I know how much of my code is the same though.
The only disadvantage I see is that it can get a bit cluttered/hard to read.

Right now I opt for the library option.
I have the work done already so it was not as hard as I thought :)

The reason I wanted to do this is adding a battery check to some of my sketches.
One simple constructor and a check method and I am good to go...

[BulldogLowell]

@marceltrapman

I like this idea and the existing MySensors library and the sketches we work with are relatively low overhead (memory usage). This means there is usually room for a bit extra...

[marceltrapman]

@BulldogLowell said:

I like this idea and the existing MySensors library and the sketches we work with are relatively low overhead (memory usage). This means there is usually room for a bit extra...

Well, I have not yet optimised the code but I was a bit disappointed by how much overhead was added (forgot how much) but I was thinking about dropping the boot loader anyway.

[Zeph]

@marceltrapman said:

Well, I have not yet optimised the code but I was a bit disappointed by how much overhead was added (forgot how much) but I was thinking about dropping the boot loader anyway.

Your library shouldn't add much overhead (and in general no more than incuding the code in each module).

Are you talking about the overhead of the Arduino core libraries, or the MySensors libraries, or the Arduino bootloader itself?

Arduino bootloaders are typically 512 bytes (Optiboot) to 2K bytes (older Arduino).

I think the APM may tend to use the larger boot loader. Does anybody know if it can use Optiboot or why not?

I think there may also be an issue with the boards.txt and the Arduino IDE; the "Arduino Pro Micro" entries may assume a large bootloader in any case (ie: reserve space for it in their memory layout). So even if one could load a 512 byte Optiboot, they might need to modify boards.txt as well. But this is a little outside my confident knowledge zone.

AND of course you may be going to ditch the serial bootloader entirely and program the full memory using the ICSP connector and an external programmer (instead of a USB to serial adapter) - 0K for the bootloader.

@moderator @marceltrapman This might be a good candidate for thread splitting - starting at the next post, there are some good messages about altering the bootloader.

[Yveaux]

@Zeph said:

I think the APM may tend to use the larger boot loader. Does anybody know if it can use Optiboot or why not?

Yes, it works very well! I compiled optiboot 5.0a to run at 76k8 baud, as I got problems with 115k2.
It's true that you need to add an entry to boards.txt, but that's not too hard.
When done, your new entry shows up in arduino and can be used just like any other target board.

[Zeph]

@Yveaux said:

Yes, it works very well! I compiled optiboot 5.0a to run at 76k8 baud, as I got problems with 115k2.
It's true that you need to add an entry to boards.txt, but that's not too hard.
When done, your new entry shows up in arduino and can be used just like any other target board.

Any tips on how to do this? (Do you have a favorite reference URL?)

[hek]

@Zeph said:

I think the APM may tend to use the larger boot loader. Does anybody know if it can use Optiboot or why not?

Yes, optiboot should work fine. Uploads becomes faster and you can use watchdogs.

Just bought a couple of these ISPs to be able to change bootloader. Will probably add them to the shop.

AVR ISP programmer for Arduino bootloader

[Yveaux]

@Zeph Yeah, on my harddrive in Dutch...
I can give you a very short description on how I did it for Arduino Pro Mini, 3v3 @ 8MHz, though.

• Download https://code.google.com/p/optiboot/downloads/detail?name=optiboot-v5.0a.zip

• Extract to c:\Arduino_1.5.5\hardware\arduino\avr\ (rename existing optiboot dir, when required)

• Edit bootloaders\optiboot\Makefile to change baudrate (line 562)

    atmega328_pro8:
    	$(MAKE) $(CHIP) AVR_FREQ=8000000L LED_START_FLASHES=3 BAUD_RATE=76800
  

• Start cmd shell in c:\Arduino_1.5.5\hardware\arduino\avr\bootloaders\optiboot

• make clean

• make atmega328_pro8

• flash optiboot_atmega328_pro_8MHz.hex using your favourite ISP

• Fuses: Low = 0xFF, High = 0xDE, Extended = 0xFE

• Close any active Arduino windows.

• Edit c:\Arduino_1.5.5\hardware\arduino\avr\boards.txt

• Add (based on Arduino Pro or Pro Mini (3.3V, 8 MHz) w/ ATmega328):

    ## Arduino Pro or Pro Mini (3.3V, 8 MHz) w/ ATmega328 - Optiboot 76k8
    ## --------------------------------------------------
    pro.menu.cpu.8MHzatmega328ob=ATmega328 (3.3V, 8 MHz, Optiboot 76k8)
  
    pro.menu.cpu.8MHzatmega328ob.upload.maximum_size=30720
    pro.menu.cpu.8MHzatmega328ob.upload.maximum_data_size=2048
    pro.menu.cpu.8MHzatmega328ob.upload.speed=76800
  
    pro.menu.cpu.8MHzatmega328ob.bootloader.low_fuses=0xFF
    pro.menu.cpu.8MHzatmega328ob.bootloader.high_fuses=0xDA
    pro.menu.cpu.8MHzatmega328ob.bootloader.extended_fuses=0x05
    pro.menu.cpu.8MHzatmega328ob.bootloader.file=atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex
  
    pro.menu.cpu.8MHzatmega328ob.build.mcu=atmega328p
    pro.menu.cpu.8MHzatmega328ob.build.f_cpu=8000000L
  

• Start Arduino IDE

• Select Board -> Arduino Pro or Pro Mini

• Select Processor -> ATmega328 (3.3V, 8 MHz, Optiboot 76k8)

• File->Upload

That's it :+1:

[hek]

@Yveaux

Could you perhaps post this separately? Candidate for stickie.

[Zeph]

@Yveaux
Thanks! Very helpful.

There's something I've been considering for a while. I'd like a unique ID on each Arduino. A short number would be fine if I'm assigning my own.

My thought is that there seems to be a few unused bytes at the top of OptiBoot (not specified in the .hex, and remaining the unprogrammed FF value when read). I was thinking I could put my unique unit number there. Unlike eeprom or application flash, it would remain stable (until and unless I reflashed the boot flash). The fuses have to be programmed to make the boot flash readable by application code of course.

I was thinking to use about 3 bytes, with a 2 byte ID number and a checksum. The checksum doesn't have to be very robust, it's mainly just to confirm that there is indeed a unit ID there (would be all FF otherwise, or other values if fuses don't let you read it).

Then I could have a very tiny utility routine which allows me to ask a node which Arduino it's running on (the system corresponding to the ID would be described in a row of a Google spreadsheet so I don't misplace it)

I was thinking that this could be perhaps done by editing the.hex file before programming the bootloader (with some code, or by hand if neccessary - I don't have THAT many ardu's) There is a simple per row checksum in the .hex file, but I'm not aware of a overall checksum on the whole image to be adjusted.

How feasible / difficult does this sound? Any ideas on how to implement it?

[Yveaux]

@Zeph sound feasible and useful.
Google for hex file format (I know there are many variants so be careful) or tools to modify them.
You could also just decode (or take the binary file generated by the linker) the hex file, change it and then convert to hex again.

[Yveaux]

@hek said:

Could you perhaps post this separately? Candidate for stickie.

Moved it to my blog: http://yveaux.blogspot.nl/2014/07/changing-arduino-bootloader-to-optiboot.html

[Zeph]

@Yveaux I was about to ask about using 31.5 KiB for application code with optiboot, but I'll put the comment on your blog instead.

[Zeph]

@Yveaux said:

Yes, it works very well! I compiled optiboot 5.0a to run at 76k8 baud, as I got problems with 115k2.

That makes sense - 115k2 is kind of marginal anyway in terms of bit rate accuracy for async serial on the ATMega @16 MHz, and many Arduino Pro Micros have ceramic resonators with +/- 0.5% (vs more accurate crystals for the Uno). I see that 76k8 is actually a pretty good match even with an 8 MHz F_CPU. (0.2% error)

I had not noticed that there was a good match for 76k8, so thanks for that indirect "tip" as well.

[Yveaux]

@Zeph Yeah, I know, but I didn't want to devote a whole article on baudrate calculation!