Chip specific information

[CvRXX]

A lot of chips require a propriatary flasher which we can't include into the toolchain because of licence reasons. It would be good if there was some file for each chip telling the user what he should do to get things running. Other information could also be added. For example that the due has an second chip for flashing that is triggered by changing the boudrate.

What do you think about this? @ManDeJan @cjsmeele

[ManDeJan]

I think there should be a boards folder at the root level of the repository, inside the boards folder we could have folders for each vendor and inside those a folder for each chip. In the chip folder we could make a board specific folder with a readme like file for each board with that chip, which has information on how the particular board is flashed plus extra information like links to pin-out schematics. Along side that we could have each board folder contain a board.cmake file which automaticly sets the correct compiler, board and flasher script. (this would also help with the problem form #2 ) I could write a python script to generate all the vendor/chip/board folders with a readme and a generic cmake file in them.

To clarify, this is an example of how the folders structure should be for the arduino due:

boards/atmel/sam3x8e/arduino_due
in which we would find the following 2 files:
readme.md and arduino_due.cmake

Including arduino_due.cmake in your CMakeLists.txt would then automaticly set the right compiler, target and flash script.

[odinthenerd]

I'm not a big fan of focusing so much on dev boards as many other frameworks do. On one hand it does make it easier to start but most real world apps will be on custom boards. If one can easily create custom boards this might be a good solution.

[CvRXX]

Yeah that was my problem with it too. Dev boards support server the hacker/student community well but companies end up making there prototype on a custom pcb. Our toolchain now works by selecting 4 files:

• Compiler
• Chip
• Flasher (optional)
• Serial console (optional)

What we could do is to create a board folder which has these files set right for a certain chip. This makes it easy for newcomers into the embedded field but keeps the possibility for flashing own boards. A bit like the "everything is possible but we give you a default" philosophy. I think that would work.