Closed Warren52 closed 3 years ago
The DAC/DACREF stuff they really seemed to take their sweet time to figure out - every series has been way different so far.
different atpaclks used different names for the the groupcodes. You were using an old version that called it ADC_MUXPOS_DAC_gc - the newer versions of the ATPACKs have the correct name for the group code that matches what the datasheet implies. Seeing as that version of the file dates to 9 months before the parts were available, it's not surprising that it does not match the released product....
On the megaAVR 0-series, (those are iomxx08/xx09 the files you saw, not iotn), they have an analog comparator with a DACREF - a DAC that can only generate reference voltages for the analog comparators and no DAC.
On the tinyAVR 1-series, there is DAC0, which has an output buffer and is the one you can get an analog voltage from. The 16k and 32k tinyAVR1-series parts have DAC1, DAC2 as well, but those can only act as DACREFs for the extra analog comparators; And on all 1-series tinyAVR parts, DAC0 also pulls double duty as the reference for AC0. Because DAC0 on the 1-series has the same function as DACREF0everywhere else, I provide defines for both names of it.
The Dx-series parts have up to three AC's each with a DACREF, as well as sa SEPARATE DAC0 with an ingenious left-adjusted data register so you casn write 8-bit values to DAC0.DATAH (the high byte) and uise it like an 8-bit one instead of a 10-bit one and convert more samples per second because you only have to write one register
And the tinyAVR 2-series parts have a single AC and DACREF for it, DACREF0.
The io headers from the (arduino install location)/hardware/tools from 1.8.13 will not help you to use the the 2-series parts.
If you want to work with these parts, just use boards manager to install it, and it will automatically download and install the version of the toolchain that the core was designed for and which it was tested with..... Otherwise you need to manually upgrade the toolchain in 1.8.13 (not 1.8.15 - it's got a bug that interferes with some manually installed cores depending on how they specify the version, and my perfectly valid version specification is rejected.
No response from OP, and nothing here appears consistent with a defect in the core.
My apologies!
I had responded to the e-mail I received rather than commenting directly to the open issue. I have never used github to report or reply to an issue before.
I had unzipped megaTinyCore into a \hardware directory of my development directory as it was easy to find code examples and what not. Once I moved it out of the \hardware directory then installed it into the Arduino IDE, all I had put together was working as expected.
Yup - one of the unfortunate consequences of the rapid development of the AVR platform recently is that manual installation is a pain in the ass now. I certainly prefer that over the alternative of the AVR architecture being a stagnant backwater, with parts that smell more foul with every device a competitor released at similar price and pincount. Which is what prevailed for a the half-decade or so before the 2016 revolution (and saying half decade may be being kind to Atmel... I am glad that my fears of Microchip buying Atmel with plans to take AVR behind the woodshed were unfounded)
My including SerialUPDI doesn't make it any easier.
Huh, you're supposed to be able to reply to the email from github, and have it automagically appear here - but that's github's problem not either of ours.
In the latest (June 26, 2021) code, file /megaTinyCore/megaavr/cores/megatinycore/Arduino.h, I have left myself the following comments and felt you would also like to know what I did to make a simple blink program work on an ATtiny 1624. Starting at line 102 in the file:
define ADC_TEMPERATURE ADC_CH(ADC_MUXPOS_TEMPSENSE_gc)
define ADC_GROUND ADC_CH(ADC_MUXPOS_GND_gc)
// -- I was trying to compile for an ATtiny 1624 device but this was throwing an error. // Eventually I got frustrated and looked through the Arduino_IDE code (v 1.8.13). // In the /hardware/tools/avr/avr/include/avr directory was a number of files. // One was iotn1624.h. It had ADC_MUXPOS_DAC_gc = (0x33<<0) // I had previously compiled code for an ATtiny 1614 without problem. // It's file - iotn1614.h - had ADC_MUXPOS_DAC0_gc = (0x1C<<0) // I did a search for 'ADC_MUXPOS_DACREF' in the files. // Found: iotn - 1608, 1609, 3208, 3209, 4808, 4809, 808, 809 but the comment // for each one was 'AC DAC Reference' So, not really ADC related I thought. // NO files had ADC_NUMPOS_DACREF0. // The ATtiny1624_26_27.pdf datasheet shows DAQREF0 is 0x33 (section 3.5.13) // So... I am going to use ADC_MUXPOS_DAC_gc for ADC_DACREF0 here and // wait for Arduino_IDE (or whatever) to catch up. // left off - 26jun2021 -- whh // #define ADC_DACREF0 ADC_CH(ADC_MUXPOS_DACREF0_gc)
define ADC_DACREF0 ADC_CH(ADC_MUXPOS_DAC_gc)
define ADC_DAC0 ADC_DACREF0 / for compatibility, since on tinyAVR 0/1-seies, the DAC0 voltage is also AC0 DACREF if used /
define ADC_VDDDIV10 ADC_CH(ADC_MUXPOS_VDDDIV10_gc)