Separate board selection from cpu selection to simplify boards menu.

[GoogleCodeExporter]

The boards menu is really overwhelming and we need to simplify it.

Possibilities:

- auto-detecting the microcontroller / bootloader baud rate

- limited selection of boards that's customizable in a dialog box

- separate board and microcontroller menus

- pictures of the boards

- descriptions of the boards

Original issue reported on code.google.com by dmel...@gmail.com on 15 May 2010 at 6:37

[GoogleCodeExporter]

This patch is the boards.txt configurable menu options that have been used with 
Teensy.  It can allow board-specific options to be moved to another menu item.  
I'll post an example boards.txt.

Original comment by paul.sto...@gmail.com on 16 Nov 2010 at 2:58

Attachments:

• arduino_menu_cleanup.diff

[GoogleCodeExporter]

Here is an example boards.txt which makes use of these configurable menus.

Here are screenshots, so you can see how this looks.

http://www.pjrc.com/teensy/beta/arduino_menu_cleanup.png

Original comment by paul.sto...@gmail.com on 16 Nov 2010 at 3:14

Attachments:

• boards.txt

[GoogleCodeExporter]

screenshots

Original comment by paul.sto...@gmail.com on 17 Nov 2010 at 2:43

Attachments:

• arduino_menu_cleanup.png

[GoogleCodeExporter]

Do you think it's possible to make the boards.txt format any simpler?  It's 
part of the Arduino user interface in some sense (even if an expert one), so it 
seems worth some thought.  

What about something like:

mega.cpu.atmega2560.name=ATmega2560
mega.cpu.atmega2560.upload.protocol=stk500v2

?

For now, I feel like it could even be fine to hard-code the menu types and 
names, since we're only using one.  If / when we add more, we can find a way to 
specify them in a config file.  

Original comment by dmel...@gmail.com on 22 Nov 2010 at 5:22

• Changed title: Separate board selection from cpu selection to simplify boards menu.

[GoogleCodeExporter]

Would you believe I initially had the menu names hard coded?  In fact, the 
delay from when this was requested on the mail list was for me to get around to 
removing the hard coded names (which were 2 menus specific to Teensy).  Well, I 
also cleaned things up a bit and made that boards.txt for Arduino and tested it 
on a couple boards.

I would really prefer not to hard code the menu names.  Teensy already uses 2 
menus.  Other 3rd party boards could find this very useful, as could Arduino in 
the future.  It's already built and pretty well tested to be flexible and fully 
configurable.  Discarding that seems like a step backwards.  Of course, if you 
use this patch, a benefit for me is reducing the number of lines of code I'm 
separately maintaining, which is the other reason I'd like to avoid 
Arduino-specific hard coding!

Certainly boards.txt format can be changed.  I'm not sure I fully understand 
the proposed simplification.  An essential piece I don't see is the index 
within the menu.  Perhaps this could be inferred by the order of the lines in 
boards.txt.  However, that would require the prefs system providing a way to 
iterate all items (in order) matching a certain base.  My understanding is the 
API only provides get() and set() style access.

A line like this:

mega.menu.cputype.name0=ATmega2560

could be shortened to something like this:

mega.cpu.name0=ATmega2560

or maybe something like this:

mega.cpu.option0.name=ATmega2560

or this:

mega.cpu0.name=ATmega2560

or any number of other styles.

Unless the prefs system provides an iterator or ordered list API, I can't see 
any way to avoid the index number.  The code needs to build valid strings for 
getBoardPreferences.get() as it populates the menu, and also when it searches 
for the user's choice.  Starting at zero and incrementing until 
getBoardPreferences.get() returns null is simple.  If there were a way to get 
the next line from boards.txt, or the next line with a matching prefix string, 
or an ordered list of all lines matching a prefix, then other styles would be 
possible.  Absent those methods, I don't know any way to do it using only 
"get()".

I originally went with the lengthy "board.menu.menuId.nameX=" mainly to avoid 
possible conflict with future Arduino features.  But if you're happy shortening 
it, I'll rework the patch.  I just need a little more explanation on how you'd 
like it to look, and of course the scheme needs to be possible with the prefs 
API.

Original comment by paul.sto...@gmail.com on 22 Nov 2010 at 8:19

[GoogleCodeExporter]

I'd rather modify Preferences.java to preserve (or support) ordering of these 
preferences based on their order of appearance in the file.  That's what we do 
with the boards themselves.  Also, I'd like to avoid having to specify the 
menus and menu names for each board separately, which is redundant if we're 
going to keep the menus constant while switching boards (to avoid the confusion 
of them appearing and disappearing).  If we really wanted to be generic, the 
board menus could be configured in the global preferences.txt or similar, but 
I'm not convinced we need that generality.  The .menu. key element seems 
reasonable, though, to prevent potential conflicts.

That would give us something like:

mega.menu.cpu.atmega2560.name=ATmega2560
mega.menu.cpu.atmega2560.upload.protocol=stk500v2

mega.menu.cpu.atmega1280.name=ATmega1280
mega.menu.cpu.atmega1280.upload.protocol=stk500v1

What do you think?

Also, what happens if a preference is determined by a combination of menu item 
selections?  For example, if we had choices for both CPU type and CPU speed; 
the choice of bootloader .hex file would depend on both selections.  Should we 
worry about that case?  What would we do there?

Original comment by dmel...@gmail.com on 23 Nov 2010 at 4:44

[GoogleCodeExporter]

Looking at the prefs and target system, yes, I could redo this using 
target.getBoards() and iterate.  I had been thinking in terms of conventional 
hash maps and using only "get()", but they're all the special linked hash map 
type, so this should work.  I'll give it a try.

I agree the menu list is redundant, but the menu title has to be specified 
somewhere.  Perhaps the actual title could be used right in the boards.txt 
lines?  Then it would look like:

  mega.menu.CPU_Type.atmega2560.name=ATmega2560
  mega.menu.CPU_Type.atmega2560.upload.protocol=stk500v2

  mega.menu.CPU_Type.atmega1280.name=ATmega1280
  mega.menu.CPU_Type.atmega1280.upload.protocol=stk500v1

Another possibility would be to eliminate the name, which is also somewhat 
redundant, and just use the actual text that appears in the menu.

  mega.menu.CPU_Type.ATmega2560.upload.protocol=stk500v2

  mega.menu.CPU_Type.ATmega1280.upload.protocol=stk500v1

About making an option depend on a combination of 2 settings... sure, it's 
possible, but what would the boards.txt syntax look like?

  mega.menu.CPU_Type.ATmega2560.menu.CPU_Speed.16_MHz.bootloader.file=stk500boot_v2_mega2560.hex

??

Original comment by paul.sto...@gmail.com on 23 Nov 2010 at 2:27

[GoogleCodeExporter]

It feels awkward to use fully-cased names as keys.  Why not just specify the 
menus and menu names in another file?  And retain a .name key for the name of 
the individual menu item entries.  For example, the global preferences.txt 
could have something like:

editor.board_menus=cpu, speed
editor.board_menu_names=CPU Type, CPU Speed

Maybe this could be overridden in an optional per-hardware folder / platform 
preferences.txt?  Although if it's going to require modifications to the IDE 
code to make use of these other menus, I don't think it's unreasonable to 
require patching of the main preferences.txt along with the patching of the IDE 
code to use the additional or alternative menus.

Original comment by dmel...@gmail.com on 23 Nov 2010 at 3:04

[GoogleCodeExporter]

Ok, if you want these defined in another file, I'll do it.  How would you feel 
about "menus.txt" located alongside "boards.txt" in each target directory?

Original comment by paul.sto...@gmail.com on 23 Nov 2010 at 8:54

[GoogleCodeExporter]

Hmm, maybe just some top-level entries in the boards.txt file?  Something like:

menus=cpu, speed
menu_names=CPU Type, CPU Speed

might be less confusing than a menus.txt file with very little in it.  But 
either could work.

Original comment by dmel...@gmail.com on 23 Nov 2010 at 10:23

[GoogleCodeExporter]

A couple lines at the top of boards.txt sounds great.

For ease of implementation, how would you feel about 1 line per menu, something 
like this:

  menu.cpu=CPU Type
  menu.speed=CPU Speed

This fits the existing key & value parsing approach, which would make it easy 
to simply test if the board name is "menu" and put the pair into a menus 
hashmap instead of the boards hashmaps.

If you really want the comma delimited list approach, that's certainly doable, 
but the implementation might not be as clean (checking mismatched list lengths, 
handling multiple lines, etc).

Original comment by paul.sto...@gmail.com on 23 Nov 2010 at 10:53

[GoogleCodeExporter]

That sounds good.  I'm not attached to the particular format, just didn't want 
to repeat it for each board.

Original comment by dmel...@gmail.com on 23 Nov 2010 at 11:28

[GoogleCodeExporter]

Here is a new patch which implements the boards.txt format we've discussed.

Original comment by paul.sto...@gmail.com on 26 Nov 2010 at 9:37

Attachments:

• arduino_menu_cleanup2.diff

[GoogleCodeExporter]

Here is an updated boards.txt file.

Original comment by paul.sto...@gmail.com on 26 Nov 2010 at 9:38

Attachments:

• boards.txt

[GoogleCodeExporter]

Opps, looks like that patch has a minor conflict with the new serial prompt.

Here is a new copy which removes an incompatible type.

Original comment by paul.sto...@gmail.com on 26 Nov 2010 at 9:50

Attachments:

• arduino_menu_cleanup2b.diff

[GoogleCodeExporter]

This patch also adds display of the currently selected value, which makes it 
much easier to see all the settings at once and (hopefully) notice if anything 
isn't as expected.

Here's a new screenshot.  The board, serial port and CPU type are all shown 
right in the menu.

Original comment by paul.sto...@gmail.com on 26 Nov 2010 at 9:56

Attachments:

• screenshot2.png

[GoogleCodeExporter]

What about CPU speed?
Let's say I wanted to use a atmega8 on a breadboard using the internal 8mhz. 

Original comment by bapcc...@gmail.com on 23 Mar 2011 at 2:16

[GoogleCodeExporter]

Yes, this patch is perfectly capable of implementing a "CPU Speed" menu, which 
controls the F_CPU symbol used to compile the sketch, libraries and core.

Of course, you would need to edit boards.txt to define that menu, using the 
syntax discussed above.  Within the boards which allow their CPU speed to be 
changed, you'd need to change the board.build.f_cpu= to multiple speeds using 
the menu you defined.

When/if this patch becomes part of Arduino (or if you apply it and recompile), 
you can make almost anything that's controlled by boards.txt into a menu 
selection.  The official boards.txt distributed with Arduino will probably only 
define 1 menu, but you can easily customize boards.txt any way you want.  If 
you only want to build one custom board for your own needs, it might be simpler 
to edit boards.txt the normal way (eg, create a completely new board, with 
different settings).  But if you want CPU speed to be menu selectable (eg, 
you're creating an Arduino clone of some sort which has several different clock 
options... or you just want it to be a menu, even for 1 board in existance), 
this patch is very general, and it certainly can be used that way.

Original comment by paul.sto...@gmail.com on 23 Mar 2011 at 3:46

[GoogleCodeExporter]

Original comment by dmel...@gmail.com on 16 Aug 2011 at 10:38

[GoogleCodeExporter]

I've applied the patch, it seems very effective.

https://github.com/cmaglie/Arduino/commit/0ddce6f9c1ec2eddfbdad9410f89e8e06a50e2
ae

some notes:

- I see that the getBoardPreferences call here was not updated:
https://github.com/cmaglie/Arduino/commit/0ddce6f9c1ec2eddfbdad9410f89e8e06a50e2
ae#L3L166
IMHO is an error, can someone give a look?

- many other place where getBoardPreferences is used was not updated the same 
way as above (i've taken a look into Eclipse "Call Hierarchy" view), it is 
correct or we should update also?

- I tried compiling but failed, the compiler didnt find pins_arduino.h. I think 
this is caused by the "variant" patch recently introduced in boards.txt. David 
can you take a look at this?

- Someone (different from Paul) should do a last proofreading to the board.txt.

C

Original comment by mega...@gmail.com on 26 Aug 2011 at 2:05

[GoogleCodeExporter]

Original comment by dmel...@gmail.com on 16 Dec 2011 at 10:08

• Removed labels: Milestone-1.0