spencekonde / megatinycore Goto Github PK

To avoid painting ourselves into a corner, we need a table of all the megaAVR attiny chips that are planned for support. This is a great way that people interested in megaAVR who aren't up to digging around in the core itself to help the project - hunt down datasheets, grab data, update spreadsheet, say something in this issue to let me know that an update has happened

This should list:
Number of each timer available on each part.
Amount of SRAM on each part
Presence/absence of DAC on each part (is this just all 1-series have a DAC, all 0-series do not? Is TCD like that too?)
Amount of EEPROM on each part

If you find any parameters that ought to be listed as well, add a column to the spreadsheet and add them.

Here is a google docs spreadsheet link. Editing is enabled (i'm trusting that everyone who bothers to see this will act in good faith and not vandalize it, hopefully I won't be disappointed in humanity)

https://docs.google.com/spreadsheets/d/1qALSjPBiLNx4_Er7RJg_b-INfTGehrhXASba9B7dShI/edit?usp=sharing

We need to set all fuses, not just the ones we are changing from defaults, because we don't know what the user previously did with the system.

Yeah, I'm not going to do this myself, but we should really have it.
The information is all in the table, see examples in other pins_arduino for different variants

Pity they didn't make an SOIC-24 version of this!

Note that many of these depend on design decisions not yet made - this is mostly to gather up a list of what needs to be done

We need
ReadMe.md with general information
Installation.md - covering manual and board manager installation
Part-specific documentation files - maybe? Maybe not, as these are far less individual than the classic AVR attiny series. Maybe it just needs to be a 0-series and 1-series doc?

There are a few subtle differences between the t1616/3216 and t416/816. We need to account for these. At present it's not clear to me whether this can be done with the same variants files or whether a new variant is needed. But it looks like it may just work? I don't see TCB being used for anything?

Called out with a comment in the xy2 pins_arduino.h

How does this work, when these parts don't have native USB?!

Does this rely on firmware on the interface chip on the Uno WiFi Rev. 2? In that case, it needs to get the axe.

There's no reason not to support PA0 in the event that someone later bothered to set PA0 as GPIO.

Important decisions need to be made regarding which timers to use for what on which chips.

Discuss selection of which timer/counter units to use for what here.

This should not do digitalWrite() but rather set DAC0.DATA=255, else it will jump from 254 255ths of the DAC VREF voltage (which can't be set to Vcc) all the way up to Vcc.

May also need exceptions as part of #51.

What are these PIN_An numbers supposed to mean?
The last few are correlated with digital pins, but the first few are not.

@freemovers can you let me know what the intent here was? (and either fix or reassign)

This is a long way off, but all these boards have UARTs. We should be able to put a bootloader on them - however considerable work would be required to create a serial bootloader for these, and we have no timeline for this.

Arduino pins 0 and 1 (PA4,5) are listed in pins_arduino as supporting PWM. analogWrite does nothing on these pins.

For 3216/1616/816/416, 3217/1617/817

These are the 8-pin (5 GPIO) versions.

Again, looks like just needs a pinmapping (plus solution for tone and the shortage of timers described in #11)

It looks like release tools for the official atmega4809 core?

We need a megaAVR compatible implementation of Servo.h. See also #16 regarding where to use what timer.

On reflection, I think removing these will create more problems than it solves.

It's much simpler here though, since the ADC on the megaAVRs doesn't have differential channels (interesting - they dropped a feature that the classicAVRs had from the megaAVRs - I suspect the reasoning being that hardly anyone used them)

:-(

I'd be happy to set up Travis CI on this repository when you're ready for it. Here is the list of tests I can add:

• Compile sketches for all board configurations
  • There is the option of publishing a CSV report of the compilation results (compile sizes and warning count for each sketch compiled) to a dedicated branch of the CI-Reports repository. These reports can be used to analyze the impact of a proposed change.
• Additional checks on bundled libraries
  • Check for common problems with library structure
  • Check for common problems with library.properties
  • Check for common problems with keywords.txt
• Code formatting check
  • Strictness levels:
    • 1: Code formatting configuration used by the Arduino IDE's Tools > Auto Format: https://github.com/arduino/Arduino/blob/master/build/shared/lib/formatter.conf
    • 2: Code formatting configuration used by Arduino on their example sketches: https://github.com/arduino/Arduino/blob/master/build/shared/examples_formatter.conf
    • 3: Custom code formatting configuration I wrote based on common practices in the official Arduino code base: arduino/ArduinoCore-avr#71 (comment)
• File formatting checks:
  • UTF-8 BOM encoding
  • Files starting with a blank line
  • True tabs
  • Non-Unix line endings
  • Trailing whitespace
  • Extra blank lines at end of files
  • Files that don't end in a newline
• Spell check

My preference would be to all of the above, but you are welcome to pick and chose whichever ones you like.

Required infrastructure:

• Enable Travis CI for this repository:
  • Open this page https://travis-ci.org/account/repositories
  • Set the switch next to megaTinyCore to the on position
• If you want compilation report publishing:
  • Create a megaTinyCore branch in https://github.com/SpenceKonde/CI-Reports.
  • Open https://travis-ci.org/SpenceKonde/megaTinyCore/settings
  • Under the "Environment Variables" section, enter REPORT_GITHUB_TOKEN in the "Name" field.
  • Enter your personal access token in the "Value" field. This can be the same token used for ATTinyCore, or you can create a dedicated one if you prefer. If creating a new token, check the box next to public_repo to give it the necessary permissions.
  • Make sure the "Display value in build log" switch is in the off position.
  • Click the "Add" button.

I'm going to rearrange the files so it can be sync'ed to hardware for manual install, instead of being board manager only.

Also need to update platform.txt to identify it at megaTinyCore. Once things are working, we'll probably want to remove the non attiny boards. I'm going to look into the available megaAVR attiny parts and order some in SOIC to start playing with this.

What kind of programmer do I want to buy for these, to get started?

This macro seems to be wrong... as the SPI and I2C pins are included in NUM_DIGITAL_PINS (maybe they aren't on the '4809 as used in the WiFi Rev 2?), but those are added together to get NUM_TOTAL_PINS, which thus exceeds the number of actual pins.

We don't have a timer for it that can be used without hosing millis().

Currently worked around by just #ifdef'ing out all of tone if there's no TCB1, but this isn't a good longterm solution

Current the core and it's libraries are flash hogs. This is problematic on the smaller ATtiny parts. We now create the assembler listing when dumping the compiled binary, so we have the tools we need to see where space is going and whether we can slim things down.

It would be helpful to flag up any libraries or core functions that you find to be particular space hogs for special attention within this issue.

We have other timers which look less useful.

There's even an RTC timer. Maybe we should use that?

The original Arduino core has a separate repository for the API. Add installation instructions for the API as well (see following note from the readme file), or add the API folder to this repository:

Developing

Create an <SKETCHBOOK>/hardware/arduino folder. Where <SKETCHBOOK> is the location of your Arduino sketchbook.
Change directories: cd <SKETCHBOOK>/hardware/arduino
Clone this repo: git clone https://github.com/arduino/ArduinoCore-megaavr.git megaavr
Change directories: cd megaavr/cores/arduino
Copy or symlink the api folder from the ArduinoCore-API repo.
Restart the IDE

And I'm not sure why.

Is there any reason this isn't the case?

Would simplify the number of files and changes that need to be tracked for variants.

Why is there a vid/pid here? These boards to not have native USB, and are used with a jtag2updi programmer.

at1616.vid.0=0x2341
at1616.pid.0=0x0058

Why is there a bootloader file for the 4809 when these are programmed via UPDI without a bootloader?

Is that fuse file correct for the tiny series? Is "burn bootloader" required for the new megaAVRs to set fuses to the correct clock speed or other parameters?

at1616.bootloader.tool=avrdude
at1616.bootloader.file=atmega4809_uart_bl.hex
at1616.bootloader.SYSCFG0=0xC9
at1616.bootloader.BOOTEND=0x00
at1616.bootloader.OSCCFG=0x01
at1616.fuses.file=fuses_4809.bin

128 bytes! For a library on chips with only 256b of ram!

Right now, you need to stop the timer, delay(1), and restart it to enable or disable PWM on a pin.

I would love to find a more graceful way of doing this, as it pulls in delay(), blocks for a millisecond, and makes a glitch on the other timer d pin.

I think if I moved the digitalWrite() tests for 0 and 255, and didn't use that shortcut for the timer d pins (and adjusted digital write to effectively analogWrite() the pin 0 or 255), I would get the desired behavior. If not in DS mode, maybe in a different mode - the different modes are very hard to understand from the datasheet. They clearly don't have people of the same caliber writing the datasheets now as they did in the classic AVR days.

Looks like our options are 1MHz internal, 16MHz internal, 20MHz internal?

C:\Users\svandebor\Documents\Arduino\hardware\megaTinyCore\megaavr\cores\arduino\wiring.c:71:8: warning: missing terminating " character

#error "No millis timer selected.

    ^

C:\Users\svandebor\Documents\Arduino\hardware\megaTinyCore\megaavr\cores\arduino\wiring.c:75:0: error: unterminated #if

#if defined(MILLIS_USE_TIMERA0)

There are no differences between the variants in this core, nor will there be, with regards to what needs to be in this file. But if I simply move variant.c into the core, it builds, but no code appears to execute.

More mop-up of the moronic analog pin naming baggage imported from the official core.

We got rid of the lookup table for analog channels.

digitalPinToAnalogInput is probably all we need here? But someone needs to dig into how these are used by wiring_analog and hence what they need to be changed to to make them work.

It looks like OSCCFG is set to run at 16MHz, but boards.txt specifies FCPU at 20MHz....

I think this may be as simple as dealing with the smaller number of timers? (#16)

Am I missing anything?

This is @MCUdude's department, but I'm going to need his help here. Of course, this is gated by the actual creation of said pinouts!

Remove ones that aren't good examples and/or which don't compile on parts with small memory.

If this leaves an absence of basic examples, create some.

Script for determining the channel for each analog input pin is not correct. I have trouble writing the code for the pre-processor. Pins 0 to 5 should return with 4 to 9 (which works) while 8 and 9 should return 10 and 11, and 14 to 16 is 1 to 3. Currently 8 and 9 return 1 and 2 since that is referring to index 8 and 9 in the PROGMEM analog_pin_to_channel[]
#define digitalPinToAnalogInput(p) (((p) < 6 || (p) == 8 || (p) == 9 || (p) > 13) ? pgm_read_byte(analog_pin_to_channel + p) : NOT_A_PIN)

I can make it work by changing the PROGMEM analog_pin_to_channel[] to:
const uint8_t PROGMEM analog_pin_to_channel[] = { 4, 5, 6, 7, 8, 9, 255, 255, 10, 11, 255, 255, 255, 255, 1, 2, 3 };

But there might be a cleaner solution?

Make it like non-bootloader chips for ATTinyCore, so programmer is selectable, and will be used for normal upload rather than forcing jtag2updi only.

Every ATtiny 1-series supports DAC to write to PA6 for a real analog output. analogWrite only supports PWM at this moment. Should we use analogWrite for the DAC (like it is done on the SAMD) or use something like dacWrite (like the ESP32).

Before people actually start using this stuff we should make sure that we've picked a good pin mapping - it's absolute hell to realize later that your pin mapping could have been better, and have to go back and change it (leaving people who are using the core out in the cold), or offer a second pin mapping (confusing new users). Best to put some thought into this now.

The current pin mapping has the advantage of matching the SOIC pinout, so the numbering on a PCB will be continuous. .

On the downside, pins on port A are split between the lowest and highest ports, and most of the pins are numbered in the opposite order as their bit positions, and the analog pin numbers don't match the digital ones, which is a nice feature to have.

Pity they picked PA0 for reset - PB5 (the last bit in a weird 6-bit port) would have been the natural choice IMO.

As with before, should be reasonably simple, just a pinmapping. but complicated by the fact that the parts come only in awful, inconvenient packages for prototyping.

We need to run automated tools over the code to do the following:

• Replace tabs with 2-spaces
• Ensure trailing newline on all files
• Ensure no trailing whitespace on any line

This is required when we add automated travis testing.

That looks like the firmware that goes on the interface chip for 4809 boards, which won't be in use for attiny boards. Stuffing a SAMD microcontroller into a tiny board is contrary to the idea of a small low cost processor.

These are the 14-pin (11GPIO) versions.

I think everything that applies to the x16 series applies here - there don't look to be substantive differences. May just need a pinmapping!

Something about what I did with TimerA seems to have hosed everything!

We need a menu option for EESAVE configuration. It should default to enabled.