..or, to make it simple, to make your IO defs based on (boards.txt):
atmega32_11_115.build.core=mighty32
atmega32_11_115.build.variant=mighty32
retrolefty,
Well that's why the user's hardware variants allow for unique pin mappings for different board pin out assignments even if the same avr chip is being used. For example the mighty 1284P and the Bobuino 1284P define different pins_arduino.h files to be used when their board type is selected even though they use the same avr chip. Can't your IO additions utilize the standard pin mapping that automatically gets selected when the board type is chosen?
Lefty
No you can't generate fast bit set and bit clear instruction with the variant maps.
fat16lib:
retrolefty,Well that's why the user's hardware variants allow for unique pin mappings for different board pin out assignments even if the same avr chip is being used. For example the mighty 1284P and the Bobuino 1284P define different pins_arduino.h files to be used when their board type is selected even though they use the same avr chip. Can't your IO additions utilize the standard pin mapping that automatically gets selected when the board type is chosen?
Lefty
No you can't generate fast bit set and bit clear instruction with the variant maps.
Well then I guess you will just have to decide which 1284P 'boards' you wish to support for you IO command additions, as there is no 'official' arduino standard pin out assignment for the 1284P or 644P board types, or for that matter any AVR chip that is not already used in a Arduino company produced board type.
Lefty
Something like:
#elif defined(__variant_mighty32__) || defined(__variant_mighty64__)|| defined(__variant_mighty1284__).. etc.
// Mighty Layout
..
#elif defined(__variant_bobulino32___) || defined(__variant_bobulino64__)...
// Bobulino Layout
..
#elif defined(__variant_sanguino32___) || defined(__variant_sanguino64__)...
// Sanguino Layout
..
where the variant_XY comes from actual boards.txt used:
atmega32_11_115.build.core=mighty32
atmega32_11_115.build.variant=mighty32
pito,
I can't pursue the toggle problem since I don have hardware. The data sheet says it should work and it seems to compile correctly:
DigitalPin<31> pin31(1);
void toggle() {
pin31.toggle();
}
4: d7 9a sbi 0x1a, 7 ; 26
6: 08 95 ret
pito,
How do symbols like variant_mighty32 get define?
How do symbols like variant_mighty32 get define?
From within the build environment - it is get parsed from boards.txt as it is used in the build process (in order to select cores an variants folders for the actual build)..
I can't pursue the toggle problem since I don have hardware. The data sheet says it should work and it seems to compile correctly:
My hw (atmega32) keeps the pin level low when doing:
pinXY.toggle();
delay(250);
in a loop. It is my understanding it should have blinked..
PS: it stays at the level set with ie:
pin13.config(OUTPUT, HIGH);
pito,
I searched all the maniacbug-mighty files and don't find the symbols.
Does this sketch print Yes?
void setup() {
Serial.begin(9600);
#ifdef __variant_mighty32__
Serial.println("Yes");
#else
Serial.println("No");
#endif
}
void loop() {}
My hw (atmega32) keeps the pin level low when doing:
Code:pinXY.toggle();
delay(250);in a loop. It is my understanding it should have blinked..
It does on Uno and Mega.
I searched all the maniacbug-mighty files and don't find the symbols.
I used that symbols as an example - there must be an environmental variable which contains the variant and the core name..
The output stays at the level set previously with ie:
pin13.config(OUTPUT, HIGH);
So it seems like the toggle in loop gets optimized out 
The following demo stays at low or high based on the pin13.config level set:
// Demo of config() and fast toggle() function.
#include <DigitalIO.h>
// Class with compile time pin number.
DigitalPin<13> pin13;
void setup() {
// Set mode to OUTPUT and level LOW.
pin13.config(OUTPUT, LOW);
}
void loop() {
pin13.toggle();
delay(200);
}
I used that symbols as an example - there must be an environmental variable which contains the variant and the core name..
Not that I know about.
What happens if you put a print in loop with the toggle?
int n = 0;
void loop() {
pin31.toggle();
Serial.println(n++);
delay(500);
}
It prints the increments twice a second.. LED lits on (pin low).
For record: IDE 1.5.2., atmega32L, mighty1284p variant and core (unmodified).
It works on Uno, Leonardo, and Mega.
I can't do more for 1284 or ATmega32.
It works with 1284p. So the issue is probably that I use mighty1284p unmodified variant and core with the atmega32. Or something else with silicon?
It works with 1284p.
That's progress.
If you insert following line into ie. /variants/mighty1284/pins_arduino.h:
#define __variant_mighty1284__
the result of your above code checking the variant will be "YES"..
So append new #elifs into your IO library based on that variant info for all "new variants" we create, for example. Let the current be as they are, and the new #elifs with variant defs will overwrite them, hopefully
Putting a define in the the pins_arduino.h files will work but there are only three choices so their should only be three defines.
- 'Mighty 1284p 16MHz using Optiboot'. The main board. Use this unless you have some clear reason to use another board. This uses a straightforward pinout that is especially helpful on a breadboard-built unit.
- 'avr-developers.com pinouts 16MHz using Optiboot'. Some people prefer the pinouts from avr-developers.com. The classic pinouts.
- 'Bobuino'. CrossRoads' board built for maximum compatibility with Arduino Uno-class shields.
These three are in the folders:
variants/avr_developers
variants/bobuino
variants/standard
I only want three symbols and they should be defined by the maintainer of mighty-1284p.
For now I will just use the "standard" map for these processors.
"Standard" is fine as it is the mighty layout. The key message here is an user may define a new variant (and a new core) end he/she might expect your IO library will work.
For example the "standard" variant is the "DIL40 mighty 1284" bare metal pin definition. It is basically a super-set of 16/32/324/64/644 DIL40 variants (the same pinout but different number of pwms and uarts). So it might be applicable to any of those bare metal chips, probably. When I take an atmega32 and I use the "standard" one, your IO lib shall work fine..