JChristensen / mighty-1284p

Mighty 1284P Platform for Arduino
http://maniacbug.wordpress.com/2011/11/27/arduino-on-atmega1284p-4/
64 stars 32 forks source link

SleepBeauty variant Readme.txt and pins_arduino.h.old were not intended to be committed #17

Closed bperrybap closed 9 years ago

bperrybap commented 9 years ago

The Readme.txt and pins_arduino.h.old under the sleepingbeauty directory were not intended to be commited to the tree.

pico-- commented 9 years ago

Fixed.

On 6/16/2015 2:41 AM, bperrybap wrote:

The Readme.txt and pins_arduino.h.old under the sleepingbeauty directory were not intended to be commited to the tree.

— Reply to this email directly or view it on GitHub https://github.com/JChristensen/mighty-1284p/issues/17.

pico-- commented 9 years ago

As you can see, I also added extra menu options to boards.txt.alt

BTW, Jack's mini does have a LED attached at PB7, so there was no great issue leaving the "flash B7" bootloaders available there.

The only boards that didn't have a LED connected on B7 were the original maniacbug Mighty layout, and avr_developers. So I just got rid of the clock options that required the "flash B7" bootloaders for those boards in boards.txt.alt (wasn't an issue in boards.txt).

On 6/16/2015 2:41 AM, bperrybap wrote:

The Readme.txt and pins_arduino.h.old under the sleepingbeauty directory were not intended to be commited to the tree.

— Reply to this email directly or view it on GitHub https://github.com/JChristensen/mighty-1284p/issues/17.

bperrybap commented 9 years ago

This will need to be tested. There are some issues that I ran into that relate to default values for the values set by the menu that come into play when you use more than a single menu which is why I left clock support off SB.

I still think that given all the combinations and confusion over bootloaders for this core, that alll the bootloaders should have better names that indicates more of what is in them.

pico-- commented 9 years ago

My testing didn't show any issues, but if you can point to something concrete, let me know.

On 6/16/2015 3:37 AM, bperrybap wrote:

This will need to be tested. There are some issues that I ran into that relate to default values for the values set by the menu that come into play when you use more than a single menu which is why I left clock support off SB.

I still think that given all the combinations and confusion over bootloaders for this core, that they bootloaders should have better names that indicates more of what is in them.

— Reply to this email directly or view it on GitHub https://github.com/JChristensen/mighty-1284p/issues/17#issuecomment-112149107.

bperrybap commented 9 years ago

The issue I had before was that by default none of the radial entries in a menu were selected and so none of the menu variables were set if you didn't explicitly select an entry for each menu item, which caused things to break when you didn't make selections in each menu. I can't seem to re-produce that as now it seems be selecting the first menu entry as a default. But if anything shows up, it should be another issue anyway as it is unrelated to these intended checkin/commits

per1234 commented 8 years ago

@bperrybap I'm assuming you were involved in adding the Sleeping Beauty variant. I'd like to use sleepingbeauty/pins_arduino.h to add direct support for that variant to another project or two but unfortunately there is no license information for it(or Mighty 1284P in general). Currently the users have to install Mighty 1284P so I can reference the non-licensed variants, which works but isn't terribly user friendly. Is there anything you can do about this, or can you give me a lead for someone to contact?

bperrybap commented 8 years ago

Yes I was very involved with the SleepBeauty variant and some updates to some of the other variant files to correct issues and make them better/easier to use - but all those updates are are on the 1.6.3 branch. I did most of the variants updates in that branch but gave the updated files to Mark who did the merges in to the repo and added a few updates of his own during the process. There seems to be quite a bit of forks floating around these days so I'm not sure what people are using these days. 1.0.6 is very far behind the 1.6.3 branch in terms of having updated variant files.

I'm actually a stickler for licensing. I'll add my comments about licensing over in issue #21 since that seems to be about the actual licensing.