Sharing sketches between projects

marceltrapman

I have searched the internet but could not find any other answer than 'use a library' or 'copy files around'. So here is what I want:

I would like to use the same code across different sketches.

From what I understand using libraries means doing c++ which is not my main thing (Java, Servoy, Xojo, Objective C are).

Ideally I would make one sketch. Add one or two methods that I want to use and share that sketch. Certainly while developing the methods this would be ideal.

Possible?

Zeph

The so called "Arduino" language IS essentially C++.

They do some preprocessing, so for example you don't have to predeclare your functions before you use them (they scan the file for functions and generate declarations for you, to be inserted before the C++ compiler see it). They also combine multiple .ino files together and a few other tweaks.

In other words, if you can write sketches, you can write C++ with just a tiny bit more effort. Including making a library.

Adapting some functions or classes that you include in your .ino file to be standalone libraries is usually very easy.

And there is no need to learn the esoterica of C++ like templates (tho you can).

marceltrapman

@Zeph Thanks, Guess I will have to put some energy in doing this...

hek

Yeah, a library is probably the easiest way of reuse code between your 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.

Sharing sketches between projects

24

11.7k

11.2k

113.1k