MCUdude
Add initial support for Attiny10 and Attiny9
I have modified part of the code for adding support for the Attiny10 and Attiny9. There is lot of limit (32 byte ram, 8 bit analog resolution, only 3 I/O pin, no eeprom) but it is really very small and its good for simple work. Both have 1024 byte of program memory, 32 byte SRam, one 16-bit timer with 2 pwm pin. Only the Attiny10 have a 8 bit Analog to Digital Converter.
This is a initial work. Everything has not been tested and it is not guaranteed that all works.
The Travis CI build is failing because you used true tabs in your code:
- avr/cores/microcore/wiring_digital.c:24:
- avr/cores/microcore/WInterrupts.c
- avr/cores/microcore/wiring.c
- avr/avrdude.conf
- avr/variants/ATtiny13Micros/pins_arduino.h
- avr/variants/ATtiny9NoMillis/pins_arduino.h
- avr/variants/ATtiny10Millis/pins_arduino.h
- avr/variants/ATtiny13Millis/pins_arduino
- avr/variants/ATtiny13NoMillis/pins_arduino.h
We decided to require all code to consistently use spaces instead (except in keywords.txt where they are required). You might want to wait to get input from MCUdude on this proposal before doing additional work but a good editor should be able to do a quick replacement. Just check how many spaces per indent level were used in the equivalent files for consistency. Once that issue is resolved, Travis CI will be able to proceed to a more thorough testing of the the code.
Thanks for the contribution! I'm afraid it's going to take some time before I can merge this. I don't own an ATtiny9 or 10, nor a development board either. I guess I'll have to design one!
Another problem with ATtiny4/5/9/10 is that these are "Reduced Core TinyAVR", which means the compiler can not make the code as efficient on ATtiny13. This means a program that fits in a ATtiny13 may not fit in an Attiny10 even though they have the same amount of code space.
I don't like the system added here of having a separate variant file for each micros()/millis() option. It leads to a lot of duplicate code that will be more difficult to maintain.
I do think the idea of allowing MicroCore features to be enabled/disabled via a custom Tools menu is worth considering. This might go some way to resolving https://github.com/MCUdude/MicroCore/issues/58 (though if they can be left on always with no overhead as suggested by https://github.com/MCUdude/MicroCore/issues/58#issuecomment-377713905 that would be even better). However, I think this would be better achieved by adding -D flags to build.extra_flags in boards.txt instead of messing with the variant files.
That feature is also unrelated to the stated purpose of this pull request. This pull request should be exclusively about adding support for ATtiny10 and ATtiny9 and the proposal for adding the new Tools menu should be submitted as a separate PR.
This might go some way to resolving #58 (though if they can be left on always with no overhead as suggested by #58 (comment) that would be even better). However, I think this would be better achieved by adding -D flags to build.extra_flags in boards.txt instead of messing with the variant files.
I don't want to fill the boards menu with tons of options. Just have a look at how many options this core for ATtiny4/5/9/10/13 has.
I wasn't suggesting adding extra Tools > Board menu items, rather a more efficient way to accomplish the same Tools > Millis & Micros functionality @bbc25185 added in this PR.
If you're saying you don't want to add too many custom Tools menus, that's understandable, and exactly why I was saying this PR should solely be about adding ATtiny9/10 support rather than throwing in some unrelated change that should be proposed in a separate PR. That would allow you to easily accept the support for additional chips while rejecting the increase in configuration options and keep the discussion focused to each individual proposal.
Updated the way for add the AtTiny 9 & 10... Used ExtraFlag and -D for enabling Millis and Micros.