Add SDU usage example

[sandeepmistry]

cc/ @agdl

[tuxedo0801]

Okay, that's seems to be quite easy for the user.

Regarding my questions from #203 :

• How do I enable this feature? Just include the "SDU" lib in my sketch?
  --> Answered by the SDU usage examle. Just include SDU.h ...

Open Questions:

• Is it possible to use alternative pins for accessing sd-card? If yes, how?
• Is it somehow foreseen to easily use an alternative "SDUBoot.ino" implementation? (like using an SPI flash chip instead of a SD card)
• Is this "2nd stage bootloader" always present? Do I then loose the flash-space this 2nd stage boot loader requires even if I don't use it actively?

[facchinm]

Hi Alex,

• to use different pins you must recompile SDUBoot.ino, include it as an header file, and rename your library so it can be picked up without any name clash.
• the space allocated for the 2nd stage bootloader is handled by the linker, so if you don't provide one the sketch won't grow.
• using the same infrastructure, you'll be able to create different "2nd stage bootloaders" (using SDUBoot.ino as a stating point) that handles different types of backing storage. The implementation is agnostic but you must make sure not to mess up with the normal sketch initialization. There is no intrinsic flash occupation limit but the linker will align the sketch to a multiple of 0x2000 boundary (see https://github.com/arduino/ArduinoCore-samd/blob/master/variants/arduino_zero/linker_scripts/gcc/flash_with_bootloader.ld#L70) so you must take care of it in your "2nd stage".

[tuxedo0801]

to use different pins you must recompile SDUBoot.ino, include it as an header file, and rename your library so it can be picked up without any name clash.

using the same infrastructure, you'll be able to create different "2nd stage bootloaders" (using SDUBoot.ino as a stating point) that handles different types of backing storage.

Hmm, okay :-( That's an valuable option for a single sketch/product/development. I'm developing a kind of framework-library that would rely on this updateability (it receives the new sketch from serial from a home automation system). The sketch writer is just using the library.
So everyone trying to use my library will then need to "modify" the samd-core (w.r.t. SDUboot.ini) to make use of the update-feature (adapt to corrent pins and/or use SPI flash instead of sdcard) :-(
I guess it would be not that easy (or even impossible) to let the sketch-author decide in his sketch (or via ArduinoIDE menu) which SDUBoot.ini to use?!

the space allocated for the 2nd stage bootloader is handled by the linker, so if you don't provide one the sketch won't grow.

That's good to know.

[facchinm]

There is no need to modify the core, you simply need to provide an alternative library that maps to the different pins (and #include "YOURSDU.h" in the skecth)

[tuxedo0801]

facepalm
oh, you're totally right. I was totally fixated on the sduboot.ino itself.

So, I copy&paste the sdu.h/.cpp, point to my pre-compiled version of "boot/zero.h" ... And that's it...

Great, thank's for this hint.