Re-program the Arduino Uno without losing a base (custom firmware) sketch

Using Arduino Programming Questions
#1

Hi,

I wonder if it is possible to load a custom sketch as some sort of a permanent "firmware" to Uno and then re-program it with new sketches without losing the base sketch.

I am trying to use a BLE Shield to communicate with an Uno so I have a custom written simple Firmata-like sketch so that I can control the pins in real time using BLE. Now I want to save new sketches to the Uno through BLE (simple Blink code for example), but the same time I do not want to lose the base sketch used to communicate over BLE.

Should I use two ATMega328p chips... one to control the BLE part and the other to save sketches?

Any help would be greatly appreciated! Thanks a lot!

#2

I wonder if it is possible to load a custom sketch as some sort of a permanent "firmware" to Uno and then re-program it with new sketches without losing the base sketch.

No. There can only be one sketch at a time loaded.

#3

Is it possible if the base sketch is the bootloader, expanded with the new functionality?
Have to fit into 2048 bytes.

#4

Many thanks for the quick reply!

Is there any other way to do something like this? Maybe using a custom designed board to handle the communication part / base sketch?

I wonder how they do it in www.spark.io and Cortado - An Early Look at the Cortado—the Arduino You'll Never Plug In - Make:

Thanks.

#5

Those examples you linked to will have their own equivalents of the bootloader. If you are already competent to design, write and debug an Arduino bootloader the stuff you are thinking about should be possible. (I will happily leave it to @CrossRoads to assist you :))

If not, then the only option is to take the working sketch you already have and make a new version of it with added features.

...R

#6

Is it that hard to make your functionality a library and hide the internals from the user? If you want users to be able to interact with it without revealing teh source code, you can always ofuscate it.

#7

You don’t have to squeeze the boot loader into 2k - you can have the whole memory as boot loader, but you need to make sure then that the code you load isn’t allowed to write to flash memory, otherwise the base code could be overwritten.

#8

I have the impression the OP is a newbie looking for a simple way to add functionality to some working code he already has without the trouble of having to learn how to write a whole new sketch.

That seems an awfully long way from writing or modifying a bootloader.

…R

#9

Could be - but when you download a sketch, the entire memory is rewritten.

So perhaps the better question would have been:
How do I read 2 input pins and decide which of 4 programs will run?
Or perhaps, how do I set a value using #IFDEF and select one of 4 code sets to run?

#10

And, is it even possible to refer to functions in the boot loader from the "normal" sketch? I am sure it is possible, but the arduino IDE does not make it easy.

#11

You could do it through a fixed vector table.

#12

Thanks everyone for the great response!!

What I really wanted to do is to create something similar to this. (Found it after posting the question).

In that, we can always keep the BLE communication going on and still re-program new sketches wirelessly over BLE itself. So it seems like the Bluetooth communication part is included in the bootloader somehow, isn't it?

Thanks!

#13

Then you need to write a boot loader that gets the program from the BT link.

always keep the BLE communication going on

Your "normal" BT comms will stop during the upload process though unless you can write some pretty clever self-modifying code (is that even possible on an AVR?)

Rob

#14

Great!

Actually, in my case it is okay to stop the BT communications while uploading the sketch… as long as it starts again automatically after the upload.

I will look into the boot loader stuff. :slight_smile: Thanks!

#15

Actually, in my case it is okay to stop the BT communications while uploading the sketch... as long as it starts again automatically after the upload.

Really? It's OK to quit listening to the BT device that is accepting the new sketch?

#16

Oh, think I got it wrong. I thought it usually stops during the upload... for a couple of seconds or msecs, after receiving the complete sketch. In that case, it is fine.

Thanks.

#17

When you reset the Arduino to load another sketch, all communication with the bluetooth device stops, until you re-write the bootloader.

If that's OK with you, it's OK with me. But it hardly seems productive to me.

#18

So that means, when we reset the Arduino before upload the sketch, we lose the communication line to transfer the compiled code. Now that's bad. :slight_smile:

Can this be fixed with a custom boot loader?

#19

Can this be fixed with a custom boot loader?

If you are capable of writing one, yes.

#20

I may not be considering something essential here, but if the BT module communicates via UART and has a DTR output (like the USB interface on an Arduino), why not connect the BT to the in parallel to the USB interface (BT's DTR to the 328's reset circuitry, BT's RX and TX to pins Arduino's 1 and 0, respectively). Configure on your computer to have a virtual com port that works through the computer's BT radio, then upload from the IDE through BT instead of USB by selecting a different com port. From a (very) quick perusal of the Bluno wiki page, it seems they have the BT radio module replacing the UART to USB circuitry normally found on an UNO.

Is there something different about the BT module that you are wanting to use that I'm not aware of?