cac0ns3c / arduino

Automatically exported from code.google.com/p/arduino
Other
0 stars 0 forks source link

Add more support for 3rd party boards and other mcu families #317

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
It would be easier to create third party boards with a bit more help from the 
IDE, if it were to provide a #define for the board and mcu_family. Further, the 
xmega fuse bits are much different than other AVR's. Would be nice to use those 
fuse bits if they are defined in boards.txt.

See attachments to be provided soon.

Original issue reported on code.google.com by GorillaCoder on 5 Aug 2010 at 8:48

GoogleCodeExporter commented 9 years ago
Patch defining BOARD and MCU_FAMILY.
Patch using fuse0 - fuse5 if defined.

Original comment by GorillaCoder on 5 Aug 2010 at 8:51

Attachments:

GoogleCodeExporter commented 9 years ago
This is exactly what I was looking for in item #308. An ability to specify the 
board type in "boards.txt" This will dramatically simplify new boards. I have 
the entire core working on half a dozen 3rd party boards with only changes to 
pins_arduino.c

Mark

Original comment by mark.l.s...@gmail.com on 5 Aug 2010 at 9:17

GoogleCodeExporter commented 9 years ago
Your message was the inspiration for my pulling this out of xmegaduino and 
creating this issue. Created a separate issue so that if it's rejected, your 
more general issue remains.

Original comment by GorillaCoder on 5 Aug 2010 at 9:50

GoogleCodeExporter commented 9 years ago
One more thing. DavidM is rightly sensitive to changes to the arduino core that 
include support for non official arduino boards. Part of this patch includes 
changes to setting up the source file path, so that pins_arduino.[ch] can be 
provided per board, while leaving the other files where they are.

Original comment by GorillaCoder on 5 Aug 2010 at 9:53

GoogleCodeExporter commented 9 years ago
As the designer of one of the "non official" xmega boards (Boston Android 
boards), I'd like to contribute. What's the best way for me to get involved at 
this point and help out? I'll start with downloading all the sources of course.

Sorry, if this is marginally offtopic; couldn't see how to contact anyone 
privately.

All the best.
-Paul (paul@bostonandroid.com)

Original comment by pmcc...@gmail.com on 12 Aug 2010 at 11:41

GoogleCodeExporter commented 9 years ago
Hi paul,

Check out the xmegaduino project for my start at an xmega port. I'd welcome any 
contribution you would like to make and would be glad to give you committers. 
I'm hoping that once the xmegaduino project has demonstrated its worth that the 
david and the rest of the arduino team will be interested in pulling relevant 
changes back into arduino.

Original comment by GorillaCoder on 13 Aug 2010 at 1:54

GoogleCodeExporter commented 9 years ago
This is a great idea.

However, for the BOARD symbol, please consider using the same approach as the 
2nd MCU_FAMILY symbol.  The reason is because the C preprocessor can not check 
for equality of strings.

http://c-faq.com/cpp/ifstrcmp.html

In other words, when it comes to actually making use of these symbols:

#if BOARD == "fio"       // illegal
#if defined(BOARD_fio)   // correct

Being able to test this would be really useful inside Firmata, for example, so 
boards knows to have only 6 analog inputs (DIP package) could be configured for 
6, otherwise default to 8 (because TQFP package has 2 more).

It would also be really nice to have a symbol for the TARGET, or make the BOARD 
symbol a concatenation of the target plus board.  Because each target has its 
own boards.txt, the names are not necessarily unique without the target (and 
would be identical if someone just copied the arduino target as their starting 
point and didn't change them inside their new boards.txt)

Original comment by paul.sto...@gmail.com on 28 Aug 2010 at 6:33

GoogleCodeExporter commented 9 years ago
I like to do something like "gcc -DBOARD=BOARD_BAZ -DBOARD_BAZ=1" and then in 
the code:
    #if BOARD_FOO==BOARD
    ...
    #elif BOARD_BAR==BOARD
    ...
    #elif BOARD_BAZ==BOARD
    ...
    #else
    #error don't know how to handle board
    #endif
As BOARD_FOO and BOARD_BAR are not defined, they don't match BOARD (if I recall 
correctly, the standard requires that references be resolved to 0). BOARD_BAZ 
does match BOARD, so that clause is expanded.

Original comment by GorillaCoder on 29 Aug 2010 at 4:52

GoogleCodeExporter commented 9 years ago
Yes, that's fine.

My concern is not regarding any particular implementation details or syntax, 
but only that whatever implementation is ultimately used be one that actually 
works.  When(if) this becomes part of Arduino, I'll be happy to use it Firmata 
and other libraries, so they can properly adapt to details of well-known boards 
and fall back onto the generic assumptions they're forced to make today.

Again, I'd like to emphasize that board names are not necessarily unique 
without also including the target name.

Original comment by paul.sto...@gmail.com on 29 Aug 2010 at 12:49

GoogleCodeExporter commented 9 years ago
Agreed, board names must be unique, but they should not include target. Those 
are two different things. If you really care about both, you can test for both.
#if BOARD_DUEMILANOVE == BOARD && ATMEGA328 == TARGET

Original comment by GorillaCoder on 30 Aug 2010 at 9:02