I am just getting my hands on with 1284P MCUs for a project. I have downloaded Jack’s Mighty 1.0.5. I am confused with the names. I know Bobuino is a variant of 1284p with some different pin mappings. But what about Mighty? Is Mighty a variant or is everything that supports 1284P called Mighty? Help me straighten out the terms!
I’m combing through the 1.0.5 version (I’m using IDE 1.0.5). Here are what I found that need some confirmation:
Two versions of the bootloader are provided, a standard and an optiboot. I know who wrote the optiboot and I’m using it for 328P. So this one is just a modded version that sits at 128K FLASH location (confirmed with hex address pointing at 1000:F800) maybe with some 1284P specific pin assignments? Then the standard version is the original bootloader modded for 1284P, right? Do people still use standard instead of optiboot?
A complete set of core files are provided under Mighty. So if the 1284P is selected then this core file set is used. What’s the difference? I first compared the HardwareSerial.cpp. There is no difference. In wiring_analog there is one tiny change. So what in general are modified to accommodate 1284P?
There are several variants including standard. So what are changed here? Bobuino has all pins swapped and seems to have better consistency between UNO’s pins 10-13 being SPI pins than the standard. Again, the standard variant in original ide defines only 328P and the standard variant in the Mighty defines only 1284P. Do I merge them or else? Makes no sense. How do I put this variant in IDE?
Then all the official and unofficial libraries are modded, then what in general are the modifications? I need to modify my libraries that are not in the unofficial so is there any guideline?
I’ve done IDE mods before but not to this extent. I know I should have the Mighty core under IDE’s core folder, and variants under the variants folder, then bootloader under the bootloader folder. This is a bit beyond me. How do I handle the standard variant provided in Mighty?
OK, I found the README to be helpful for installing the mod. Everything goes into a hardware folder inside the sketchbooks folder, separate from the IDE’s files, correct? The actual mods are not discussed except for update notes though.
I’ll give it a try once I get my 1284P chips and get back with more specific questions. I’ll use 1.0.6 now.
I thought you were kidding. How can a guy with 7400 posts call himself a beginner, :-). Most of your questions are straight-forward Arduino stuff, and have nothing to do with the 1284, per se (as noted in italics below).
There have been probably 12-15 threads and maybe 2000 posts in the past 2 years about getting the 1284 up to speed with the IDE. It's a big can of worms. I was hoping you would see that from the link I posted.
Today, everyone pretty much uses optiboot. Same as the other cpus.
You can use any of the board variants, it only depends upon which header pinout your board uses, as shown in the diagram at the top of most pins_arduino.h files. Same as the other cpus.
Which bootloader you use has nothing to do with the header pinout or pins_arduino.h file. Same as the other cpus.
In the "core", apparently the only change needed for the 1284 was to wiring_analog.c, as you mentioned, and the rest of the core was ok for the 1284.
I'm not going to go into the library modifications, because that was endlessly and forevermore discussed in those other 12-15 threads and 2000 posts.
But yes, the maniac1284 library is supposed to go in your sketches directory. Same as with every other "3rd party" library.
If you want to know why maniacbug did everything the way he did, you'll have to ask him. But it doesn't matter, just use optiboot, pick the variant for the header pinout you want to use, and go. You might buy a Bobuino just in order to make the process of getting into 1284 a little easier. There may be some commercial boards being sold that use one of the maniac variant pinouts other than Bobuino, but I'm not up on that.
One other issue that's buried in a thread with maybe 29 or 42 pages is the RX0 crosstalk problem on the DIP40 1284 chips. The fix is to use the Full-Power oscillator setting. I assume Jack incorporated that.
It's a big can of worms, and if you really need to "understand" it, it'll take you a LOT of digging on your own. All in all, there is about as miniscule explanation, and as terse documentation, for this as with everything in the Arduino IDE. I find that my solution to almost everything in the Ardunio world is to have to go into and reverse engineer the source code all down the line. Even for avrdude.
Thanks oric_dan. From the over 7000 posts only a few are about this processor so I'm new to this scene. I've modded IDE before but not my strongest suite. I mainly do user interface libraries and hardware development, programming and circuit design. I've dug into the cores several times all for reasons not involving accommodating a new MCU. Sometimes I wanted to know why wifi.print takes so long so I looked into the files and found it repeatedly calls write(char) which creates one char pay loads over the airway! Othertimes I wanted to know how to make my own Catrina bootloader so I went into the files (relevant to using new MCU). So thank you for the information. Especially the RX0 crosstalk with dip chip I would have a very hard time extracting from 2000 posts. I'm only prototyping with dip chips but still knowing what I'm doing is paramount. I'm making a device for many so I can't afford not to know the stuff behind the doors
You just saved me countless hours not having to look into the core files and compare for differences. I'll generate some documentation or study guide when I'm through my learning process. Maybe in a year or so all the complications will be covered by arduino mist and the ide just takes care of everything for us like for other ATMEGA MCUs. Keep fingers crossed.
Maybe in a year or so all the complications will be covered by arduino mist and the ide just takes care of everything for us like for other ATMEGA MCUs.
From what I call tell, this is not going to happen for the 1284 chip, since there are no "official" Arduino boards that use it, so no standards for it. maniacbug just made up his own, I guess.
BTW, just for reference, there are 2 [essentially unrelated] bugs that I found recently in optiboot that directly pertain to the coding architecture of the 1284, but as pure luck would have it, they magically offset each other, so uploads work ok. This was mentioned on one of those 12 or 15 threads, and I imagine a fix will eventually be incorporated into one of the newer IDE versions of optiboot.
You can try and read through all those threads, but your head will likely start spinning in place after a short while, and then you'll need an exorcism.
Like I said, the 2 bugs magically offset each other, so uploads work correctly. You'll have to ask someone else when and if the fix is in. Or check the optiboot source code in Jack's repository for the 1284. And the latest IDE source for optiboot for every other chip.
So if I copy everything mighty related (1.0.6) to sketchbooks/hardware and sketchbooks/libraries, will arduino 1.0.5 fail to compile code for 1284p?
I looked at the sdfat library mod. Jack said that he changed DigitalPin.h What is the actual change? The DPM() macros are mapping the pins for what variant, bobuino?
Was "Mighty" a term created by maniacbug? I'm hesitant to replace my working libraries with these without knowing how they have been altered. Clients won't be happy if SD card or Ethernet shield locks up after I make switch to this mod
Both pins and FLASH are running out on 328P also I needed a dedicated serial port for wifi/xbee/bluetooth. Yes, I'd like to play with one different device too. Tried 32U4 and hated it. VID is expensive and bootloader bricks too easily, not good for developing an open source device for teachers. With added pins (12 more), I can run SD card, xbee module, and the rest of the functions with a few pins to spare. My standard firmware has hit the 32K maximal. If I compile for standard bootloader (I embedded arduino nano with standard bootloaders for a couple dozen units), then the firmware won't compile, out of FLASH. I didn't run out of RAM but having 16KB will allow the users of this device to do a lot without having to consider preserving RAM.
The easy option is just to buy a Mega2560, as that would work with no additional effort
If your devices are 3.3V compatible and you want to try an alternative board, you could look at the Maple mini (official or clones), or generic STM32F103 boards.
The spec is
MCU: STM32F103RCBT6, a 32-bit ARM Cortex M3 microprocessor
Clock Speed: 72 MHz
128 KB Flash and 20 KB SRAM
34 digital I/ pins (GPIOs)
12 PWM pins at 16 bit resolution
9 analog input (ADC) pins at 12 bit resolution
2 SPI peripherals
2 I2C peripherals
7 Channels of Direct Memory Access (DMA) (dma.h)
3 USART (serial port) peripherals
1 advanced and 3 general-purpose timers
Nested Vectored Interrupt Controller (NVIC) (including external interrupt on GPIOs)
Supplies up to 500 mA at 3.3 V, with separate 250 mA digital and analog regulators for low-noise analog performance
(ref Maple | LeafLabs) however the spec if a bit missleading as the pins are shared, so if you use 2 hardware serial ports, you loose 4 ADC inputs etc.
There are now "hardware" files for these devices, compatible with the Arduino 1.5.x Beta, as they use the same compiler as the Due.
(See the really long thread on this forum about STM32 with IDE 1.5.x)
These boards are still not 100% compatible with all existing code, but it depends on exactly what you are doing, i.e if you just want lots of serial ports and lots of memory, at $4 from Aliexpress the Maple mini cone is quite a good deal
Roger, as a result of that other thread, I've been looking at the Maple. Looks very nice, but too bad it only has 20KB of RAM, and the board is designed so you cannot plug in an Ethernet shield. Also, the library support seems a bit thin - even after 4 years. It actually looks like kind of half-hearted support. But the other specs look great.
Support is for STM32F103 in general (though some tweaks would probably be needed to boards.txt),
I bought a STM32F103RCT based board and I have tested the basic functionality and it appears to work.
256 Kbytes of Flash memory
48 Kbytes of SRAM
Unfortunately, the board I got (from eBay) seems to be slightly faulty and I think I may have broken it while trying to replace a faulty switch
I have ordered a STM32F4 168Mhz boards, (from the STM Discovery range), which I hope will arrive next week some time, so it will be interesting to see what functionality works straight away and what modifications need to be made to the current file to support the F4.
BTW. There are loads and load of different STM32 boards available from Chinese suppliers, so I'd be surprised if you cant find one with the amount of ram you were looking for
I had also noticed the Discovery boards, and especially like the F4 chips. However, my main interest at this point in time is staying with boards that can mount regular Arduino shields, eg Ethernet, LCDs, etc, and have good library support. So those nice $4 modules in DIP48 (or whatever) form factor are not quite what I was after. A Maple with UNO form factor, F4 chip, and good library support would be my ideal choice.
STM's Nucleo line of boards are supposed to be Arduino pin compatible, but if you want library compatibility then your only choice is the Arduino AVR boards, as even the Due is far less compatible with libraries.
@liudr, sorry to be late to this party; I'm relatively scarce these days because I can hardly stand to use the forum since the alleged upgrade.
Downloading the 1284P core and getting it going is truly easy, just follow the installation instructions in the ReadMe file. Install the patched libraries if they are needed, else that part is optional.
Pinouts vary among the supported boards/variants but mapping from the hardware to Arduino pin number is handled under the covers. Pick a board based on the mapping that seems most appropriate (or whatever other criteria you may have) and go with it.
As far as v1.0.5 vs. v1.0.6, there should be little or no difference in the "user experience" (to use a phrase I hate). I prefer Optiboot since it's the current state of the art but AFAIK the other bootloaders work as well.
I wouldn't overthink things too much in advance. Give it a try and let us know if you have issues.