oric_dan:
If you look in \variants\bobuino, you'll see the only useful file is pin_arduino.h (the .ods file is vestigial), and all it specifies is the chip pin to header mapping. This has nothing to with which boot loader is installed, or the basic functional compilation of code, only with the header mapping. The compilation business, and any differences, are specified in the boards.txt file.
Why, of course!
This thread runs deeper and the dialog centers around testing of changes to the core that are being made and published in an alpha fashion right now. There are a variety of boards using AVR 1284 chips. The question to the working team was simply that two different boards are using the same core and the only difference is in the pins_arduino.h mapping. Must each be tested? Or, can only one be tested? Who really owns the pins_arduino.h (and .c for some AT_tiny) ... this is not a technical question so much as a political one.
Jack,
Thank you, that is all I needed to know. Somewhere down the line, a decision is going to have to be made about pin mappings and ownership of the mapping process, that is, the pins_arduino.h (and .c for AT_tiny). At this moment, I still think that the mapping file should be defined as outside-the-scope of the core refresh initiative.
@CrossRoads:
You may wish to contact the Sleeping Beauty author, Wayne Chu, and discuss the inclusion of your Bobduino files within his ZIP distribution. As i stated earlier, I was initially unaware of this until I discovered 2 separate Bobduino entires on 1.0.5r2 and started looking for the cause. As changes are made to your official release of Bobduino core files, it would be easy for an end-user to become confused with multiple entries in their GUI. (Issue runs much deeper, IMO.)
I think the obvious answer is , the guy who made the new board owns pins_arduino.h - unless the header pinout exactly matches one of the originals. And he just supplies this plus his boards.txt file with the board. If the header pinout matches one of the originals, he just says select that board in the IDE.
Otherwise, maniacbug will have to add a new variant to the github repository for each new board. And if you've been paying attention, you'll see m-b is MIA completely. Eg, he's never even addressed the bugs I discovered in the bobuino variant 1-year ago, and mentioned on my page cited earlier.
And/or someone in central-receiving would have to add a patch to files-centrale for every new board in creation.
I know that the 1.5x IDE sets those types of defines and passes them in.
But in reality knowing the board usually isn't what is really needed.
Can you make things work? Sometimes, but not in all cases.
Like I've been saying all along what often really matters is the variant within the core.
For example, suppose the code triggers on a particular board, but then the user goes in and creatse a few extra board
types to be able to do things like have a proper board type than can fully use the flash when ISP programming
vs bootloader programming.
Currently, it takes a different board type to do this since the board indicates the available flash size and it is just a bit bigger
when not using a bootloader.
Or perhaps I want to automate using an ISP programmer so I can just push the upload button vs using the
upload using programmer.
That too currently requires a new board type.
So the problem becomes, code that wants to do special optimizations based on the variant,
can't reliably use the board to detect the variant since many boards can all be mapping to the same core/variant combination.
I really wish there were defines for ALL the information:
core
variant
boardname
That way everything that people might want/need would be available.
As it is today, 1.x provides nothing, and 1.5x IDE only provides the core and the boardname.
Thanks pico, now I begin to understand. Maniac-bug added the \cores\standard\ files to the library because \cores\arduino in previous incarnations of the IDE didn't include handling of ATmega1284 chips - as I discovered a year ago ... http://www.ot-hobbies.com/resource/ard-1284.htm#lack2
My 1284 code compiles ok after making the change to my boards.txt file, so I assume it will run alright too.
EDIT: also, I had no idea what Jack was talking about in his opening post, because as I see it, the necessary changes for the 1284(P) chips had already been included in IDE v.1.05 - and they work, since I've been using that IDE for over a year now - although many of the libraries still need fixing, as I noted, http://www.ot-hobbies.com/resource/ard-1284.htm#lib2
I think the obvious answer is , the guy who made the new board owns pins_arduino.h - unless the header pinout exactly matches one of the originals. And he just supplies this plus his boards.txt file with the board. If the header pinout matches one of the originals, he just says select that board in the IDE.
GeeWhiz...
"own" was meant in the context of this thread not in some philosophical property sense. I am not going to rehash all of the dialog before...
Otherwise, maniacbug will have to add a new variant to the github repository for each new board. And if you've been paying attention, you'll see m-b is MIA completely. Eg, he's never even addressed the bugs I discovered in the bobuino variant 1-year ago, and mentioned on my page cited earlier.
People do become ill. His blog has been idle for 2 years as has his forum presence. Or, maybe he ran off with his neighbor's wife before getting back to you on those errors. Based upon all of his previous involvement and activity, I fear something has occurred beyond his control and I simply respect his previous effort and products for Open Source. Errors in Bobuino pins_arduino.h · Issue #5 · maniacbug/mighty-1284p · GitHub
And/or someone in central-receiving would have to add a patch to files-centrale for every new board in creation.
I love sarcasm.... I sometimes use it too.
mrburnette:
People do become ill. His blog has been idle for 2 years as has his forum presence. Or, maybe he ran off with his neighbor's wife before getting back to you on those errors. Based upon all of his previous involvement and activity, I fear something has occurred beyond his control and I simply respect his previous effort and products for Open Source. Errors in Bobuino pins_arduino.h · Issue #5 · maniacbug/mighty-1284p · GitHub
I suppose he's just gotten on to other things ... and there are only so many hours in a day. Hopefully, Crossroads mentions not to use the buggy maniac-bug github bobuino variant when he sells his boards, and supplies something correct.
[quote author=Jack Christensen link=topic=235521.msg1710113#msg1710113 date=1399313076]
But more changes are coming as there are issues with the bobuino variant.[/quote]
BTW, I had mentioned some of these to m-b a year ago, in case you hadn't seen it,
mrburnette:
Jack,
Thank you, that is all I needed to know. Somewhere down the line, a decision is going to have to be made about pin mappings and ownership of the mapping process, that is, the pins_arduino.h (and .c for AT_tiny). At this moment, I still think that the mapping file should be defined as outside-the-scope of the core refresh initiative.
Thanks, I'm just trying to keep scope creep to a minimum for now. Other boards and ownership are very good topics for discussion though and whatever conclusions we come to should be documented in the core's ReadMe file. I think I pretty much agree that the designer of a board is responsible for the pins file, but we also need to consider what happens if that person drops out of the picture for any reason (maybe the answer is do nothing, and I'd be ok with that too).
Having said that, given the approach we're taking here, I feel some obligation to not have the refresh introduce errors or unexpected changes, so am taking on some responsibility to make changes to the pins files to achieve that end. This is partly because either I'm not sure of who the owner is, whether they are available, etc (the exception being Crossroads of course ). I would have started with maniacbug but I'm assuming he's not interested at this point. But that only leaves two variants to deal with besides the bobuino so it's not a super big deal.
All, I just pushed an update that should be ready for some serious testing. I think I've done fairly exhaustive analogRead() testing on all three variants and I think all is well, but of course I'll feel better with second opinions.
Summary of changes.
Copied the vanilla core files from 1.0.5 back in as wiring_analog.c needed to be changed. Put them into a directory called cores/mighty. (maniacbug's version used cores/standard, but I found that confusing since there is a board variant named standard.)
Modified the wiring_analog.c file so that it always uses the analogPinToChannel() macro for ATmega1284/P and for 644/A/P/PA. Therefore, analogPinToChannel() is required to be present in every pins_arduino.h file in the core (this was not previously the case). The vanilla wiring_analog.c code uses only the analogPinToChannel() macro. By rewriting the analogPinToChannel() macros, it was unnecessary to use additional macros and only a single line was changed in wiring_analog.c. (The maniacbug core version of wiring_analog.c also used the digitalPinToAnalogPin() macro. Where they existed before in the pins_arduino.h files, I have preserved the analogInputToDigitalPin() and digitalPinToAnalogPin() macros unchanged, in case they are used by libraries, etc.)
The avr_developers and standard pins_arduino.h files had NUM_DIGITAL_PINS defined as 31, these were changed to 32.
In all variants' pins_arduino.h files, "static const uint8_t LED" was changed to LED_BUILTIN to be consistent with Arduino v1.0.5.
All entries in boards.txt files were changed to point at the mighty core (.build.core=mighty).
I downloaded your latest package and retested my analog input pins for my Bobuino board. I tried all combinations using 0-7, A0-A7, 14-21, and all work fine. Even found a jumper pin pad I forgot to solder on Bob's feature option to map either A4 and A5 or the two I2C signals to the shield pins!
Also retested INPUT_PULLUP and it still works.
I sure thank you and the others that are helping with this long overdue effort.
I just discovered that I could copy the Ethernet library from the IDE directory over into the \libraries subdirectory in my sketch folder, so there are now 2 identical libraries, and the 1284 code compiles ok without error.
The following compiler msg indicates that the compiler went to the IDE directory to get the SPI library, which was not cloned, but got the Ethernet library code from the cloned version in the sketch subdirectory.
-IC:\winapps\ArduinoIDE\arduino-1.0.5-windows\libraries\SPI
-IC:\Documents and Settings\Wanderer\My Documents\Arduino\libraries\Ethernet
-IC:\Documents and Settings\Wanderer\My Documents\Arduino\libraries\Ethernet\utility C:\Documents and Settings\Wanderer\My Documents\Arduino\libraries\Ethernet\EthernetUdp.cpp -o
LATE EDIT: btw, the reason the Ethernet library worked here at all was because I had previously patched the library residing in the IDE directory so it would work with the 1284. So, the patched version was the one copied to the sketch folder. I've patched all the libraries residing in my current IDE v.1.05 directory.
oric_dan:
I just discovered that I could copy the Ethernet library from the IDE directory over into the \libraries subdirectory in my sketch folder, so there are now 2 identical libraries, and the 1284 code compiles ok without error.
Very good to know, thanks! I think I'll take the same approach.
retrolefty:
I downloaded your latest package and retested my analog input pins for my Bobuino board. I tried all combinations using 0-7, A0-A7, 14-21, and all work fine. Even found a jumper pin pad I forgot to solder on Bob's feature option to map either A4 and A5 or the two I2C signals to the shield pins!
Also retested INPUT_PULLUP and it still works.
I sure thank you and the others that are helping with this long overdue effort.
Appreciate the testing and feedback! I just recently started playing with the 1284P so the whole thing is really just a self-serving project
oric_dan:
EDIT: also, I had no idea what Jack was talking about in his opening post, because as I see it, the necessary changes for the 1284(P) chips had already been included in IDE v.1.05 - and they work, since I've been using that IDE for over a year now - although many of the libraries still need fixing, as I noted, http://www.ot-hobbies.com/resource/ard-1284.htm#lib2
(Having trouble keeping up with all the posts here.)
It is certainly possible that we have just re-discovered the wheel. If nothing else (assuming the current commit is substantially correct) we now have a 1.0.5-based core that supports three variants with very minimal changes and have made improvements to the pins files. Two of the three variants in the core required a small change to a core file, the popular bobuino being one of them.
If the core changes required are really going to boil down changing one line of code in one core file (wiring_analog.c), then a user installing the "Mighty" stuff over a 1.0.5 installation could simply copy an updated version of wiring_analog.c over the "official" distro one as part of the new "Mighty 1284p" install. Either manually, or as part of the unzip process. Basically a documentation fix to the "Mighty" distribution.
And if a 1.0.6 ever surfaces, the requisite fix to wiring_analog.c will already be there, one would assume.
Then, (if all turns out as expected), we are in the happy position of simply having to require a hardware developer to provide a new pins_arduino.h for every new variant with an ever more imaginative pin mapping that arrives on the scene! SB, Goldilocks, FooBoard1284p9000 etc. can just add their pins_arduino.h file, and the appropriate required addition to boards.txt (too bad there isn't a nice modular why of adding to boards.txt at the variant level. A little boards.txt with a single entry in the bobuino directory under variants, for example.)
The whole boards.txt, both the IDE and the user's hardware folder addition, now results in a board selection menu list from hell. I just spent a bunch of time adding #'s in from of every line for the board types I don't have (or want) and haven't even started with the IDE's main copy. I applaud the Arduino developers policy of still supporting even the >6 year old original board, but with all boards they have added over the years, plus any 3rd party boards added via user's hardware method, we now have a almost unmanageable list to deal with. Be nice to have the IDE offer a means to "check list" on or off the board types to be displayed from the main menu board selection menu.
