Pico - I am interested to see the changes required for the SDfat library as that is what I use. I don't recall any issues with the previous Mighty-1284 version.
At any rate, do you have a link where I could download the fixed version of SDfat for 1284?
Just wanted to also say thanks to @Pico for his work on the libraries. Awesome!Great timimg, as I've just put one of his (Pico's) "Skinny Bob" kits together today. It all went together very fast (less 1 hour, and I don't think I'm a fast solderer). Loaded some example sketches after installing mighty-1284p-1.0.5.zip and -- success!Very satifying to start with a bag of parts in the afternoon and end up with a fully functioning board running programs just a few hours later! Thanks again to everyone who made this possible.
(One thing I would suggest is updating the Installation instructions on the GitHub page to include installing the libraries.)
Oops, good point, forgot about this... I'm not sure I can edit that page though. Perhaps you could update when you have time, Jack?
extern const uint8_t digital_pin_to_pcint; // this extern needed for mighty-1284p core support
In looking back at the commits, I see a pretty big change to the pins_arduino.h header file thatwas put in as part of a commit related to adding patched versions of Ethernet, Servo, & SD.It added defines for the bit and port for each pin.I'm assuming that these changes weren't needed for those libraries, but were tossed in for clarity?
If adding all these new port and bit defines for each pin is desired,I'd suggest moving down a path of what what Paul did in the Teensy core in his core_pins.h header file.(It was rejected by the Arduino team but I believe it is quite useful and makes a lot of sense)In his implementation, there are defines per pin for port, bit, and bitmask but I think it is better thanwhat is currently in the 1284 variant pins_arduino.h header files.You never use the port, bit, and bitmask defines directly but rather through macros and as and added bonus you have the added ability to specify AVR port/bit pins directly. i.e.digitalWrite(PIN_B0, HIGH);to set PB0 high.To make this happen, you create a define for each pin, whose name is PIN_Pb where P is the port and b is the bitand the value is the Arduino pin number.Then you have the port bit, and bitmask defines that are never used directly butrather through some concatenation macros.This allows you to access things like bit, bitmask or port: (examples for B7)CORE_BIT(PIN_B7)CORE_BITMASK(PIN_B7)CORE_PORTREG(PIN_B7)It is very clear and easy to visualize for things like the progmem tables.If there is interest in moving twards Paul's "core" defines (which goes a bit further than just these bits/masks/port defines),I'll be happy to do the mods, but I before doing it,I want to make sure people are ok with this.To see the defines and macros, look down in the teensy core at the file core_pins.h--- billOne other note:Making these changes and adding these defines, should have no impact on existing code.It merely adds defines that new code could take advantage of.
Guys,I'm seeing this:Code: [Select]extern const uint8_t digital_pin_to_pcint; // this extern needed for mighty-1284p core supportshow up in code. Like SoftwareSerial and the GSM libraries.To me this is wrong. This is an extern to support some macros likedigitalPinToPCICRbit(p) digitalPinToPCMSK(p)digitalPinToPCMSKbit(p)The code that uses those macros should have no knowledge about their internal implementationand shouldn't have to do special things to make them work.So in my view the extern declaration should be in pins_arduino.h where the macro definition is.i.e. the pins_arduino.h should do whatever it takes to make the macros/functions it uses & defines work and that should also include declaring extern references when needed.Was it just an "oops" or is there some reason why this wasn't done in pins_arduino.h?
Given that this extern declaration is the only change to SoftwareSerial, if the extern is moved to pins_arduino.hthen a patched version of SoftwareSerial wouldn't be needed.Another issue I'm seeing is that these patched libraries are interfering with other patched libraries.For example, the Teensy install modifies some libraries. SoftwareSerial is one of the libraries that Teensy modifies.So if you have Teensy installed and then try to copy/install the patched 1284 patched SoftwareSerial,you overwrite/replaced the SoftSerial with Teensy support.I think at least for SoftSerial, that if pins_arduino.h could be updated to include the extern for digital_pin_to_pcintthat this specific issue will go away.But this is hinting at the issue I was concerned about: supporting patched libraries.It is a very large task with almost no boundaries.--- bill
The digital_pin_to_pcint array is defined in pins_arduino.h, but for only the "bobuino" variant. Because it's an array, and pins_arduino.h is potentitally pulled into multiple libs, the declaration is guarded by a #ifdef ARDUINO_MAIN, so the linker doesn't complain about multiple declarations..Changing this so that #ifndef ARDUINO_MAINextern const uint8_t digital_pin_to_pcint; #elseconst uint8_t digital_pin_to_pcint[NUM_DIGITAL_PINS] =:#endifwill work just as well, and has the advantage of not needing a patched version of SoftwareSerial, so I will make that change, and then we can remove the patched SoftwareSerial lib from the repo.
But sorry, Bill, your hand-wringing and finger-wagging here leaves me as unmoved now as it ever has.
/* 6.0 WestfW: modularize memory read/write functions *//* Remove serial/flash overlap *//* (and all references to NRWWSTART/etc) *//* Correctly handle pagesize > 255bytes *//* Add EEPROM support in BIGBOOT (1284) *//* EEPROM write on small chips now causes err *//* Split Makefile into smaller pieces *//* Add Wicked devices Wildfire *//* Remove LUDICOUS_SPEED option */
"ludicrous speed" was 230400bps at 3.5% error. I like the idea of having 1Mbps at 0% error better!(except that I can't convince my Mac Host-side to support 1Mbps...)
Does it like 500kbps?
QuoteDoes it like 500kbps?Nope. Apparently only "standard" bitrates. I can't tell whether it's a MacOS thing or an FTDI driver thing :-((FTDI claims to support non-standard speeds, but when I look for details, all the info is about the windows driver(s))