Go Down

Topic: Support for mega1284 - the never-ending saga (Read 4825 times) previous topic - next topic

oric_dan

Nov 08, 2014, 09:29 pm Last Edit: Nov 08, 2014, 09:30 pm by oric_dan
I decided to break this out from the related thread, here,
http://forum.arduino.cc/index.php?topic=275718.30

Given all the confusion, I decided to take another look at library support in the various IDEs, etc.
Basically, NONE of the following IDEs have libraries updated for the mega1284 chips:

- IDE v.1.0.5 - as noted in 2013

- IDE v.1.5.x - as noted yesterday, on the other thread

- IDE v.1.0.6 - just checked, same as v.1.0.5 - although wiring_analog.c in the core has
 apparently been fixed to Jack's satisfaction, but not the libraries.
https://github.com/arduino/Arduino/tree/1.0.6

- IDE v.1.0.7 [I'm "assuming" this is the v.1.0.7 update] - appears to be no changes from v.1.0.6
https://github.com/arduino/Arduino

------------------------

Of happy note, most of the relevant libraries in Jack's 1284 distribution have been fixed by pico [yea!!].
https://github.com/JChristensen/mighty-1284p/tree/v1.0.6

The exception is, neither "official" or "unofficial" SD libraries have the Bobuino variant included, and the board variant callouts don't match in the 2 versions, in any case.
https://github.com/JChristensen/mighty-1284p/blob/v1.0.6/patched-libs/official/SD/utility/Sd2PinMap.h
https://github.com/JChristensen/mighty-1284p/blob/v1.0.6/patched-libs/unofficial/SdFat/utility/DigitalPin.h

So, the goal has almost been reached here, but not hardly in "any" of the IDEs.

bperrybap

I took Jack's core and the associated modified libraries and have it up and running on 1.5x
To me it is much easier than 1.x because of the way the core and libraries work on 1.5x.
You can unzip and install everything all at once down in your sketchbook/hardware directory
rather than piece meal as was required with the 1.x support.


If you buy into the 1.5x way of doing things for 3rd party core support,
it can become easier to maintain and much easier for users to install.
I couldn't seem to get much interest for looking at 1.5x over in the other thread.



--- bill

mrburnette

Quote
I couldn't seem to get much interest for looking at 1.5x over in the other thread.
There was interest!  Just seemed that the volunteers wanted to work at a non-beta level.  I think 1.5.7 and previous releases have been out in the wild long enough not to be hampered as "beta".  But we all have opinions and since I was not volunteering to do the effort Jack undertook, I elected not to push any harder than I did...

Quote
Of happy note, most of the relevant libraries in Jack's 1284 distribution have been fixed by pico [yea!!].
Thanks for looking this over... Great info to know.

Quote
The exception is, neither "official" or "unofficial" SD libraries have the Bobuino variant included, and the board variant callouts don't match in the 2 versions, in any case.
So, the goal has almost been reached here, but not hardly in "any" of the IDEs.
Crap!

Well, at least I now know where the sinkholes are located.


Ray

oric_dan

#3
Nov 11, 2014, 04:25 am Last Edit: Nov 11, 2014, 05:38 am by oric_dan
Crap!

Well, at least I now know where the sinkholes are located.
Ray, if you have a Bobuino with SD card, it should be a trivial issue to get [most any] SD library working with it. Just go to the following page, and cut out the Bobuino bit, and patch it into whatever library you want to use.
https://github.com/greiman/SdFat-beta/blob/master/SdFat/utility/DigitalPin.h

I included the code here, and you can see how it fits in from the page just cited.
Code: [Select]
#elif defined(VARIANT_BOBUINO)
// Bobuino Layout
static const pin_map_t pinMap[] = {
  {&DDRD, &PIND, &PORTD, 0},  // D0  0
  {&DDRD, &PIND, &PORTD, 1},  // D1  1
  {&DDRD, &PIND, &PORTD, 2},  // D2  2
  {&DDRD, &PIND, &PORTD, 3},  // D3  3
  {&DDRB, &PINB, &PORTB, 0},  // B0  4
  {&DDRB, &PINB, &PORTB, 1},  // B1  5
  {&DDRB, &PINB, &PORTB, 2},  // B2  6
  {&DDRB, &PINB, &PORTB, 3},  // B3  7
  {&DDRD, &PIND, &PORTD, 5},  // D5  8
  {&DDRD, &PIND, &PORTD, 6},  // D6  9
  {&DDRB, &PINB, &PORTB, 4},  // B4 10
  {&DDRB, &PINB, &PORTB, 5},  // B5 11
  {&DDRB, &PINB, &PORTB, 6},  // B6 12
  {&DDRB, &PINB, &PORTB, 7},  // B7 13
  {&DDRA, &PINA, &PORTA, 7},  // A7 14
  {&DDRA, &PINA, &PORTA, 6},  // A6 15
  {&DDRA, &PINA, &PORTA, 5},  // A5 16
  {&DDRA, &PINA, &PORTA, 4},  // A4 17
  {&DDRA, &PINA, &PORTA, 3},  // A3 18
  {&DDRA, &PINA, &PORTA, 2},  // A2 19
  {&DDRA, &PINA, &PORTA, 1},  // A1 20
  {&DDRA, &PINA, &PORTA, 0},  // A0 21
  {&DDRC, &PINC, &PORTC, 0},  // C0 22
  {&DDRC, &PINC, &PORTC, 1},  // C1 23
  {&DDRC, &PINC, &PORTC, 2},  // C2 24
  {&DDRC, &PINC, &PORTC, 3},  // C3 25
  {&DDRC, &PINC, &PORTC, 4},  // C4 26
  {&DDRC, &PINC, &PORTC, 5},  // C5 27
  {&DDRC, &PINC, &PORTC, 6},  // C6 28
  {&DDRC, &PINC, &PORTC, 7},  // C7 29
  {&DDRD, &PIND, &PORTD, 4},  // D4 30
  {&DDRD, &PIND, &PORTD, 7}   // D7 31
};

I don't have a Bobuino myself, but I modified the above to match my board's similar header pinout, and patched it into the SD library that's included with IDE v.1.0.5, and it's working fine. You should also be able to do this with either of pico's SD library versions on Jack's github page, or with any of Bill Greiman's several versions of the SD library that are also missing the Bobuino variant.

You will also need to know which Arduino Dx pin on the Bobuino the SD card's CS pin maps to, and use that in the initialize function.
------------------

NOTE: if you use IDE v.1.0.x through v.1.5.x SD library, remember they're all 5 years out of date, and do have some problems.

Eg, there are 2 example sketches that display the SD card files, listfiles and CardInfo, plus a couple of examples that show how to write and read files on the SD card. Well, it turns out [at least for me] that, the listfiles scheme is not compatible with the simple read/write operations, but the CardInfo scheme is ok. Specifically, listfiles no longer works once either read or write has been done, and I couldn't figure out how to fix it, so stay with the CardInfo scheme. Bizarre.

oric_dan

I took Jack's core and the associated modified libraries and have it up and running on 1.5x
To me it is much easier than 1.x because of the way the core and libraries work on 1.5x.
You can unzip and install everything all at once down in your sketchbook/hardware directory
rather than piece meal as was required with the 1.x support.
I'm not very familiar with v.1.5.x. Are you saying you can include a complete extra set of libraries in the sketch folder, with all having the exact same names,etc as the ones in the IDE, and they will be picked up preferentially without any conflicts?

mrburnette

#5
Nov 11, 2014, 03:03 pm Last Edit: Nov 11, 2014, 03:04 pm by mrburnette
Ray, if you have a Bobuino with SD card, it should be a trivial issue to get [most any] SD library working with it. <...>
Thanks!  I have 3 of the Bobuinos and I love them, but long ago I made the decision to off-load SD to serial-TTL logging on a dedicated SD/328P module.  This simply eliminates all SD issues in the main sketch.  When I design an Arduino sketch, I build a debug/logging channel on one of the hardware serial ports.  I use a byte of EEPROM that is settable at PoR or RESET to control logging OFF/on and the details of logging: LOW/high.

Another relative nice feature of off-loading SD to a separate uC is that you can stop worrying about allocating time slices between the main sketch and the SD routines.  Dedicated routines are small and can use the entire memory space of the uC.  I also like the idea of varying density of logging data.  Often, having the entire microcompter and SD conveniently located in a project is a challenge; making the two physically separate really opens the door to locating the SD in a convenient place.  I use standard CAT5 or CAT6 cable for the data signal as this is adequate and cheap.

Of course, this is just my way of doing stuff and I know many people like to have the SD card right on the same board and use an SD library with the single uC on the board.  It's a sound approach that works well where the SD is used to host files integral to the program logic.

Cheap External SD Card Data Logger

Oh, thanks for the code snippet.

Ray

oric_dan

You might at least try SD with your Bobuino  board, so we can get some additional feedback on the experience, and possible problems. Especially if you're using any of the newer libraries.

mrburnette

You might at least try SD with your Bobuino  board
Yes, I sound like a self-centered ass but I did not mean it quiet as rough as it sounded... I'm messing around with the STM32 Maple Mini clones and have my workbench is quiet a disarray.  I do not have the Bobduino with the SD card onboard... rather, I have the older FTDI external header unit.



If I get over this hardware SPI mess with this $5 STM32 board, I'll throw an SD socket on the breadboard and give it a whirl.  Most regretful... even retired, I never seem to have enough time to play.


Ray

oric_dan

#8
Nov 11, 2014, 09:29 pm Last Edit: Nov 11, 2014, 09:32 pm by oric_dan
I figured it was worth an attempt to try and keep the thread about testing and using various libraries with the mega1284.

[and my dissarray is certainly bigger than your disarray. Right now, besides wires everywheres, 3 robots in pieces, 4 RFM12 radio nodes with 328s and 1284s for my home automation system, with the SD card on the Hub 1284-board, plus 3 other RFM69 radio nodes on 1284-boards to go to robots and outside cars, all in development in parallel. And I spend "most" of my time debugging and fixing other people's libraries that should have been fixed years ago, foo]

mrburnette

#9
Nov 11, 2014, 11:44 pm Last Edit: Nov 12, 2014, 12:34 am by mrburnette
Quote
And I spend "most" of my time debugging and fixing other people's libraries that should have been fixed years ago
Libraries... a two-edged sword.  Allow for reuse by the author and abuse by those using it who are not the author.  The concept is good and C/C++ has many great examples from the compiler and language view.  However, it is when we move up the programming model that things generally become an issue (IMO).  Library misuse is common, documentation may be sparse, examples may not fully exercise the library, rarely is there test data and known-good output, and the list goes on.


Ray

bperrybap

I'm not very familiar with v.1.5.x. Are you saying you can include a complete extra set of libraries in the sketch folder, with all having the exact same names,etc as the ones in the IDE, and they will be picked up preferentially without any conflicts?
Yes. (in the sketchbook folder - down under the hardware core directory)
With 1.5x if you create the proper directory tree under your sketchbook for a 1.5x
hardware core, you can override things from the IDE and its built in cores, when
your core is used.


In this case:

{usersketchbook-dir}/hardware/1284core-name/avr/

Just like 1.x the 1.5x has a search order for libraries.
Under 1.x the "libraries" under the user sketchbook override the "libraries" in the IDE.
Now with 1.5x the "libraries" directory under the core can override the "libraries"
in the IDE.
There is a search order/precedence.
This is the order that each of the "libraries" directories is looked at/used:

- user sketchbook
- user hardware core
- IDE

You can create subdirectories under the the users hardware core directory
to use "libraries" that overrides the IDE "libraries" directory but only when
that core is used.
i.e. The board type selects the core, and the h/w core can have a "libraries" directory
that contains libraries that are used for that core/board which override the IDE libraries.

For 1.5x you also have to create a few other files:
boards.txt, platform.txt

All pretty simple stuff.

I brought this up starting back in June 2014:
http://forum.arduino.cc/index.php?topic=235521.msg1766650#msg1766650

And then went ahead and just did it for myself:
http://forum.arduino.cc/index.php?topic=235521.msg1781012#msg1781012

The value of the 1.5x way of doing things is that you can create a single tar/zip image that
you can extract and everything is installed at once and "just works".
No futzing around with libraries, and the libraries included with the core are only used with that core
and so there is no danger of breaking the other cores.
It is also really easy to remove should you want/need to do that as well since everything
is contained under a single directory.

I brought this up back in june because I thought that this should be being looked because
Team Arduino is not very focused on 3rd party support and doesn't really have a way to test
what they have done since they don't really do any 3rd party stuff.
The reason to start looking at it sooner
rather than later is because it may need some tweaks, and if you wait to long to start using it and finding any potential wrinkles, it may be too late to get Team Arduino to change things before
the next official release.
i.e. you may get stuck with having to live with some sub optimal ways of doing things.

I'm currently using 1.5x to test my openGLCD library with a 1284 based SleepingBeauty board.

--- bill


oric_dan

Quote
I brought this up back in june because I thought that this should be being looked because
Team Arduino is not very focused on 3rd party support and doesn't really have a way to test
what they have done since they don't really do any 3rd party stuff.
Thanks for the comprehensive explanation. The problem with that previous thread is, it went for 425 posts, and although I was there in it, I wasn't comprehending all the issues from every direction. But at least, we're slowly getting these things worked out. And good excuse to try IDE v.1.5x.


oric_dan

Libraries... a two-edged sword.  Allow for reuse by the author and abuse by those using it who are not the author.  The concept is good and C/C++ has many great examples from the compiler and language view.  However, it is when we move up the programming model that things generally become an issue (IMO).  Library misuse is common, documentation may be sparse, examples may not fully exercise the library, rarely is there test data and known-good output, and the list goes on.
You can flavor this how you like, but even forgetting about 1284 support, it's still a big PITN when something like the SD library in the IDE hasn't been updated in 5 years, and the example sketches are incompatible with each other [as mentioned previously]. That's a big onus on using the "official" stuff. 3rd party libraries, you have to expect to take with a bushel of salt.

mrburnette

#13
Nov 12, 2014, 02:29 pm Last Edit: Nov 12, 2014, 02:30 pm by mrburnette
Quote
... it's still a big PITN when something like the SD library in the IDE hasn't been updated in 5 years, and the example sketches are incompatible with each other ...
Affirmative!  If you are running for office, you have my vote.


I am completely in the dark as to why a library that ships in the Official Install would be so old unless the decision makers thought it was "good enough."  You, I, and most senior members that have been around a few years understand that the Arduino 1.0.x distribution is long-in-the-tooth by software standards.

But troubling is that the 1.5.x distribution does not update these older 3rd party libraries.  Perhaps (pure speculation on my part) the intent is to maintain backward compatibility with the old hardware while making it easy to transition the base of 1.0.x users to 1.5.x easily.  Were the Arduino makers to act as Microsoft (example) then they would just pull the support rug out from 1.0.x and pull it from the web for download and publicly state that 1.0.x was history and the only course for users of that environment was to move forward.  I liken this approach to the way my mom taught me to remove a band-aid ... 'pull it off briskly so the pain will peak and subside quickly'.  In many ways, Mom knew best.

My preference would be for included libraries to be refreshed with input by the original authors (if they were willing) or by the Arduino team.  This however would likely lead to some turmoil or at least a few summit meetings!  Cypress with their PSoC line scans every component library with each execution of the compiler and offers to update locally older components with new ones... the final choice being the workstation operator (and hopefully) the software author!  I managed Java middleware developers in a Corporate 100 setting for years - can you imagine the nightmare such a self-updating tool would have had on rigid software regression testing? 

Maybe the answer is simply the way things are now... an active forum where 3rd party developers have a voice into articulating the merits of their newer product versions and linking us to those installations.  In this scenario, at least the programmer (sketcher?) can make an informed decision.  But while I am old and feeble in the memory department, I am (almost) certain that Massimo Banzi has not asked for my input... and I doubt he will; perhaps, you will be more fortunate as I can easily defer my opinion to yours as we see things similarly.


Ray

oric_dan

UPDATE:
I noticed that within the past 2 days, Bill Greiman has now updated his "main" SD library to include the Bobuino variant:

https://github.com/greiman/SdFat/blob/master/SdFat/utility/DigitalPin.h

Quote
Ray said:
But troubling is that the 1.5.x distribution does not update these older 3rd party libraries. 
...............
My preference would be for included libraries to be refreshed with input by the original authors (if they were willing) or by the Arduino team.
Bill Grieman mentioned he has notified [or notifies] Ardunio-Centrale of his SD library updates.

Go Up