Closed SpenceKonde closed 1 year ago
SpenceKonde
commented
1 year ago I told people tocheck analog write and the dac in 1.5.0, but only hear 5 versions later!
Okay, more information please - analogWrite broken everywhere or just on the DAC pin and you say the dac doesn't work anywhere?
SpenceKonde
commented
1 year ago @ikkei3 which pins are you using for analogWrite that don't work? There are 23 PWM capable pins on each of those two parts, of which 11 can be active simultaneously. Ya gotta help narrow tthis down for me
How have you configured the PORTMUX?
Have you read the part specific documentation?
https://github.com/SpenceKonde/DxCore/blob/master/megaavr/extras/DB32.md https://github.com/SpenceKonde/DxCore/blob/master/megaavr/extras/DD32.md - PWM pins that the core selects at startup are in bold, though for TCA and TCD, you can switch to other rows of the table just by setting the PORTMUX.TCAROUTEA or PORTMUX.TCDROUTEA (DD only due to errata on the
ikkei3
commented
1 year ago I'm only using PIN_PA7 for analogWrite() for PWM. and PIN_PD6 for analogWrite() for DAC.
I am not using PORTMUX. Leave as default. What are the necessary PORTMUX settings for errata?
2023/03/01 5:44、Spence Konde (aka Dr. Azzy) @.***>のメール:
@ikkei3 which pins are you using for analogWrite that don't work? There are 23 PWM capable pins on each of those two parts, of which 11 can be active simultaneously. Ya gotta help narrow tthis down for me How have you configured the PORTMUX? Have you read the part specific documentation? https://github.com/SpenceKonde/DxCore/blob/master/megaavr/extras/DB32.md https://github.com/SpenceKonde/DxCore/blob/master/megaavr/extras/DD32.md - PWM pins that the core selects at startup are in bold, though for TCA and TCD, you can switch to other rows of the table just by setting the PORTMUX.TCAROUTEA or PORTMUX.TCDROUTEA (DD only due to errata on the — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
SpenceKonde
commented
1 year ago The necessary settings for the portmux errata on AVR DA and AVR DB are that the it be left at the default setting. This erratum is corrected on the AVR DD-series and I pray for a die rev to fix it on the DA and DBs, I very much want to get the other mux options for the TCD so someone can move it off of the incredibly crowded PORTA - like the barren PORTG on the 64 pin ones , which is particularly barren on the AVR128DA64 because of another erratum: the PORTE and PORTG mux options for TCA1 don't work. That one they fixed in time for the DB. The TCD one unfortunately they did not. On parts effected by Otherwise enabling PWM on pin 0 (CMPAEN) on that TCD0 pinset enables PWM on pins 1, 2, and 3, and CMPBEN, CMPCEN, and CMPDEN are non-functional. (note that the timer can only generate 2 PWM signals (though a third 8-bit pwm signal can be bodged up with PROGEV, 2 event channels and an even numbered CCL LUT (or 3 event channels and and odd numbered LUT), but only under certain combinations of prescaling settings.
I've found and have a fix for the issue with TCA, but I'm confused since you're using a TCD pin and reading the code I don't understand why the TCD PWM on my device works.
SpenceKonde
commented
1 year ago In the meantime, you can easily workaround the bug. The bug caused the wrong pin to be set output... and it didn't sem to be setting it at all for TCD, which is why I need to investigate more closely.
If impacted by a TCA pin not outputting PWM,
pinMode(PIN_Pxn, OUTPUT); //before or after analogWrite
pinMode(PIN_PAn, mode); // where mode is the mode that PAn is supposed to have, can be skipped if if PAn is supposed to be OUTPUTFor the DAC, I haven't finished analysis (and have found other problems too) but as a workaround, instead of using analogWrite
void DACWrite(uint8_t val) {
PORTD.PIN6CTRL = PORT_ISC_INPUT_DISABLE_gc; //per manufacturer recommendations, the digital input buffer should be disabled when the DAC is in use. I do not know if this is because it will be an an intermediate value which will simply raise power consumption, or if there is a different - more important - reason.
DAC0.DATAH = val;
DAC0.CTRLA = 0x41;
}
void DACOff() {
DAC0.CTRLA = 0;
PORTD.PIN6CTRL = 0;
}While we're thinking about errata - never run the DAC without teh output buffer enabled on a DA or DB. CTRLA = 0x00 or 0x41, or for runstby, 0xC1, 0x80 being harmless (run standby but disabled). But not 0x01 (enabled but without the buffer) or 0x81 (enabled without the buffer and run in standby mode) - this can be used by some internal peripherals, but if this is done without the buffer enabled, there is enough drift over the lifetime of the part in the DAC accuracy that Microchip felt a need to call it out in the errata (I know of several minor issues they are aware of and have not mentioned in the errata, so not every tiny bug makes the grade of showing up on an errata listing. In these particular cases, I think they may be debating whether they should be considered bugs and fixed, whether they even can be fixed or whether to issue a "datasheet clarification" (ie "Oh sorry if we were unclear about that, it was, uh, a typo, yeah, that's right. We didn't mean to say the flash had a 10,000 cycle endurance. It's 1,000 and we'll be sure to make thats clear in the next version of the datasheet. Fix it? Nope, there's nothing to fix. We totally didn't find out 2 years after release that our latest parts had a tenth of the flash endurance we claimed, don't be ridiculous" - The DA and DB did get their flash endurance spec downgraded by a factor of ten and that's always what the DD was advertised with. What I really want to know is if the 10,000 figure was fine at normal conditions (room temperature etc) and that the figure only had to be downgraded because these parts can have temperature grades rated for up to 125C . Flash endurance is reduced by high temperatures during the write and/or erase process or so I have been told by persons who do not work for or with Microchip and have access to no special information. Same guy also claims that at least on classic AVRs the flash endurance was incredibly conservative, and claims to have held the parts near the top of their temp range and done several times the maximum number of erase/write cycles without manifesting problems, though I cannot speak to whether these claims are accurate. Though if I can find my Zetex mineral tape, I'll be ableto make my heated cell, which will fit a small breakout board, and test at elevated temperature. That's another reason I really wanna find that tape (the hot cell was designed* for a totally different purpose, but will serve well for this too.
(on my device, PWM definitely comes out on PA7 even before my fixes - the TCD PWM pins worked correctly, only the TCA0 PWM pins (Px0-Px5 on any port, core defaults to PORTD on AVR-DB, since despite losing the first pin on the DBs, it's still better than encouraging the MVIO pins to be used for PWM (the most common configuration I think is Vdd = 5V, Vddio2 = 3.3V, and the most common applications of PWM would prefer the 5v vs the 3.3v), so since - the default was miserable (TCA0 defaults to PORTA... where of the six pwm capable pins, the first two pins are your crystal pins, the next two are your non-MVIO-pin I2C host pins, and the last two are the only option left for USART0 on the DB) - and hence we didn't default the core to the chip default, we chose default for the most common use cases.
* Calling that project "designed" is an insult to designers everywhere, It was being thrown together and designed as I went until Irealized I couldn't find my insulating tape and it came to a standstill.
ikkei3
commented
1 year ago OK. OK. I know very well that the defaults are the best. So why is this code able to output PWM on AVR64DB32 but not on AVR64DD32? Neither DAC comes out.
void setup() { // do nothing }
void loop() { static uint8_t a = 0; analogWrite( PIN_PA7, a); analogWrite( PIN_PD6, a * 4); a++; delay(10); }
I'm sure you know why.
Best regards,
2023/03/02 6:58、Spence Konde (aka Dr. Azzy) @.***>のメール:
In the meantime, you can easily workaround the bug. The bug caused the wrong pin to be set output... and it didn't sem to be setting it at all for TCD, which is why I need to investigate more closely (on my device, PWM definitely comes out on PA7 even before my fixes - the TCD PWM pins worked correctly, only the TCA0 PWM pins (Px0-Px5 on any port, core defaults to PORTD on AVR-DB, since despite losing the first pin on the DBs, it's still better than encouraging the MVIO pins to be used for PWM (the most common configuration I think is Vdd = 5V, Vddio2 = 3.3V, and the most common applications of PWM would prefer the 5v vs the 3.3v), so since - the default was miserable (TCA0 defaults to PORTA... where of the six pwm capable pins, the first two pins are your crystal pins, the next two are your non-MVIO-pin I2C host pins, and the last two are the only option left for USART0 on the DB) - and hence we didn't default the core to the chip default, we chose default for the most common use cases.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
SpenceKonde
commented
1 year ago I know sort of why there is the DAC issue (only sort of though). I have no f'ing clue whats's up with the PWM on the DD, and will note that you got lucky in picking a pin that would do PWM at all on the DB as TCA PWM (which is 5/11ths of the PWM pins and 5/9ths of the independant channels) was busted completely.). I am fixing the PWM issue. Then I will look into why there an issue with the DD PWM.
ikkei3
commented
1 year ago DAC issues This is not a big deal as setting the register directly works just fine.
If DD PWM is fixed, I'm happy with that.
2023/03/02 10:08、Spence Konde (aka Dr. Azzy) @.***>のメール:
I know sort of why there is the DAC issue (only sort of though). I have no f'ing clue whats's up with the PWM on the DD, and will note that you got lucky in picking a pin that would do PWM at all on the DB as TCA PWM was busted completely.). I am fixing the PWM issue. Then I will look into why there an issue with the DD PWM. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
SpenceKonde
commented
1 year ago It's not fixed yet, and I've been working on it pretty much straight out. As it was released, absolutely, analogWrite() should not work anywhere on any pin in the release on any part. at a minimum the direction bit was not being set, and I suspect additional issues with on the DD's TCD PWM because of the PORTMUX support. And yet it does work on the DA and DB
I think the errata listings are missing a few entries.. I'm currently trying to assemble a ~DB32~ DD32 that works I fried the first one when I stupidly connected the MVIO power backwards and am now building one on generic protoboard.
Both the DAC and PWM issues ones I consider to be critical - anything where the top-level Arduino functions are not behaving, I would consider critical (l and as soon as I have verified code I am going to do a release, squawk at a bunch of people. Apparently even microchip folks are doing something with my core now, This fix needs to work and it needs to get out there ASAP
I finally got my DD32 working and programmable. there was something wrong with the one I was using a DA32 breakout for -and swapping the chips didn't help but (part of why the soldering on that chip looks awful) when swapping the chip didn't fix it, I pulled the new chip off and put it on my generic breakout board. that chip was soldered onto pcb that was already populated including pin header, then removed using a desoldering spatula because the pinheader defeats the hotplate, and then soldered back down. (If you like the look of the breakout board, I have them for just about every square QFN up to QFN 32, some DFN sizes, and a few rectangular whackjob QFNs
Not much to look at but it does accept programs
In these functions, defects are considered critical almost automatically, and where any differences from official behavior are critical to have documented
DxC and mTC have this too, and intentionally work differently (very simple - you only get 3 options, 8, 10 and 12 bits the native resolution of the parts. If you want fewer bits that's what the >> operator is for, and id disagree vehemently with their attitude that it's okay to let someone ask for 32 bits from a 12-bit ADC, and respond by taking a 12-bit reading and leftshifting it 20 places. Which the official core does. (our extensions, analogReadEnh, and least uses the oversampling/decimation procedure endorsed by Microchip, and limits how many bits we'll give the user that way (to one accumulated reading for the oversampling, followed by decimation like normal - 64 readings on 0/1-series, 128 on Dx, and 1024 on 2-series and future Ex-series), leading to an extra 3 bits, or 5 for the new ADC (though the idea that any board designed by me, or by arduino, or by anyone who's not a deeply knowledgable mixed signal electrical engineer, will be measuring anything other than noise with the 17th bit a 2-series reads with 1024 accumulated samples after decimating is laughable).
Pulse in's timeout here is accurate both before and after the start of the pulse. I fixed this in 2020, not sure if it ever got merged. But they were making assumptions about what the compiler was outputting, then then changed so they generated the .S file with the old compiler and used that (apparently they don't know how to write inline assembly. At some point i'm going to rewrite that as inline assembly that can be more easily read by a human. They
There are ways I could make both of these scream. A shiftOutPlus might happen some day - more likely a library. You'd need to pass it a compile time known constant set of pins, but without loop unrolling, and assuming you need a hold and setup time of 4 clocks worst case between any two transitions (this adds 3 clocks 2 words), and that a 5/14ths duty cycle on the clock was acceptable, you can blast out a byte in 14 clocks per bit with 12 instruction words of code.
I hate maintaining tone.
See Ref_timers.md - I put a LOT of effort into outlawing time travel, the stock implementation only is able to keep time when the clock speed is a power of 2, otherwise (typically) micros() % 1000 will either not get all the way to 1000 before going back to 0, or will go above 1000 and then jump back when millis rolls over when running at odd speeds. That's of course totally unacceptable. Forwards time travel is moderately bad (as it is in real life - it's called getting blackout drunk), but backwards time travel is catastrophic (again, like in real life, because you could then kill your grandfather or bring a list of winning lotto numbers back in time with you). Even a few microseconds of backwards time travel can lead to delay expiring instantly.
In configurations where millis() is not available millis is not defined, library authors can use that to avoid calling millis when millis is disabled and barfing. Same goes for micros(). (if RTC used for millis, micros is not available, if millis disabled, both unavailable)
celay() work as long as interrupts are enabled or millis is disabled (ie, unless interrupts are disabled while millis is enabled) If millis is disabled delay works with caveats noted in the docs (mainly, normally delay(1000) will delay for 1000ms, and it doesn't matter if interrupts fire during that time as long as they execute in under 1ms. When millis is disabled, time spent in interrupts is time during which the delay does not count down. So if during a delay(1000 in which interrupts that didn't take a ms to execute but fired very frequently were using, say 50% of the CPU time, delay(1000) would delay for 1 second with millis enabled, but 2 with it disabled. I believe this is covered in Ref_timers - the official core of course doesn't let you disable millis to save space and get rid of the periodic interrupt, so there isn't a precedent of how to handle that. Which is good cause they'd have made pessimal decisions.
delayMicroseconds() always works.
These haveall been tightened up to ensure they return correct info, and several approached considered to minimize flash usage,.
I think these got tightened up too to prevent unexpected sideffects
Never used these, never ad to modify em.
One of the libraries i plan to release is called rngBetter. It's a 16-bit (and by release, I hope to have 32-bit as well) simplified xorshift prng. ("simplified" because the canonical xorshift algorithm from the original paper used more bits of state than the value it returned, ex, 128b of state for a 2^128-1 repeat period. We don't generally need random numbers that good, and we dont have the luxury of a 128-bit or even 64 bit states. You have to be able to kethoughep two copies of it in registers during the calculation, or else it becomes dreadfully inefficient. Probably still faster than the arduino official implementation, which calls the avrlibc official implementation, which is terrible because it involves dividing a 4 byte integer. If anyone knew how costly division was and that you should avoid it, you'd think it would be the AVRlibc people. Ya know, since they like, wrote the routine to do division. In asm..... The division takes like 600 out of the 700-some clock cycles random takes!
These are horribad. But livewithable
These two do not do it efficiently. The way to do this is to typedef a union of the target type and a byte array and use that. At some point I'm going to release a series of several libraries, One of them based on my dirty tricks header, one called TypeUnion which provides unions of 2. 4. and 8 byte types, and a flexPtr that has uint16_t a, and uint8_t b[2] as members, in additiion to pointers to all basic types eg, uint8_t b_ptr, int8_t c_ptr, int16_y i_ptr, uint16t w_ptr and so on. along with flexPtrVol, which is just like the above, but all the pointers are declared volatile. The compiler does not compile these to something as intelligent as you might expect, and the macro doesn't take advantage of this opportunity to optimize.
attachInterrupt should be avoided like a transgenic ebola-covid hybrid. You should quarantine any code that comes into contact with it for 14 days, wear a mask while working with it, and disinfect yourself with bleach afterwards. It wins the lead (as in the metal often used in solder) medal in the category of "most evil function in the API"
These are just aliases for sei and cli!
Serial, SPI, and Wire are all substantially modified in from the stock core (in the case of serial, these modifications are extreme indeed) order to save space and improve efficiency. However all of the standard API functionality is supported so anything that works elsewhere should work. The inverse is not the case, our serial, TWI and SPI API's are a superset of the stock ones.
SpenceKonde
commented
1 year ago I am able to reproduce your observation that PWM does not work from TCD. Additionally, I notice that the mux is not configured to match the docuementation
PWM selftest
Testing TCA0 mux number 3 channel 0
Pin is 12
Pin does not exist on this part
Testing TCA0 mux number 3 channel 1
Pin is 13
One second togglecount: 2940
Testing TCA0 mux number 3 channel 2
Pin is 14
One second togglecount: 2939
Testing TCA0 mux number 3 channel 3
Pin is 15
One second togglecount: 2938
Testing TCA0 mux number 3 channel 4
Pin is 16
One second togglecount: 2939
Testing TCA0 mux number 3 channel 5
Pin is 17
One second togglecount: 2937
Testing TCB0
AltPin 24
One second togglecount: 1
Testing TCB1
AltPin 25
One second togglecount: 0
Millis is using TCB2
The current configuration does not permit PWM from this timer channel.
Testing TCD0 mux number 2
Pin is 20
One second togglecount: 1
Testing TCD0 mux number 2
Pin is 21
One second togglecount: 0
Testing TCD0 mux number 2
Pin is 22
One second togglecount: 0
Testing TCD0 mux number 2
Pin is 23
One second togglecount: 0
The test has completed
Pass: 5/11I checked analogWrite(). It gets worse and worse as the version goes up. Early versions were better.
2023/03/04 1:02、Spence Konde (aka Dr. Azzy) @.***>のメール:
I am able to reproduce your observation that PWM does not work from TCD. Additionally, I notice that the mux is not configured to match the docuementation PWM selftest Testing TCA0 mux number 3 channel 0 Pin is 12 Pin does not exist on this part Testing TCA0 mux number 3 channel 1 Pin is 13 One second togglecount: 2940 Testing TCA0 mux number 3 channel 2 Pin is 14 One second togglecount: 2939 Testing TCA0 mux number 3 channel 3 Pin is 15 One second togglecount: 2938 Testing TCA0 mux number 3 channel 4 Pin is 16 One second togglecount: 2939 Testing TCA0 mux number 3 channel 5 Pin is 17 One second togglecount: 2937 Testing TCB0 AltPin 24 One second togglecount: 1 Testing TCB1 AltPin 25 One second togglecount: 0 Millis is using TCB2 The current configuration does not permit PWM from this timer channel. Testing TCD0 mux number 2 Pin is 20 One second togglecount: 1 Testing TCD0 mux number 2 Pin is 21 One second togglecount: 0 Testing TCD0 mux number 2 Pin is 22 One second togglecount: 0 Testing TCD0 mux number 2 Pin is 23 One second togglecount: 0 The test has completed Pass: 5/11
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
SpenceKonde
commented
1 year ago I checked analogWrite(). It gets worse and worse as the version goes up. Early versions were better. Best regards, --------------
That was a non-constructive (had you pointed out specific versions and what regression occurred there, that might have been useful but you didnt). I don't know if you meant it that way, but I found that comment rude and insulting, especially when I've spent the better part of the last week working on fixing it (though a cabinet of drawers in my room collapsed and I've had to devote time to repairing it). Yes, a regression occurred this is software, it happens sometimes.
I've built a test board and written a rigorous PWM test sketch that all pins that are expected to have PWM available do have PWM and that digital write does turn off that PWM.
During this process I found a case of several semi-user facing macros (unlikely to be called from user code, but very likely to be called from libraries, that, while they didn't cause problems with this in particular, could cause almost arbitrary undefined behavior if called using a signed integer as a pin number instead of an unsigned one (because of the fact that macros don't check or implicitly convert types), and I'm rather surprised that I haven't gotten bug reports about them already (though they may be the underlying cause of some library compatibility issues). I consider those issues to be serious by I think I have those fixed.
As for the problem at you have there is something something VERY strange going on. It's trivial to reproduce, but only on the DD, yet what appears to be be causing it should cause it to happen on the DA and DB as well. And yet it doesn't. Preliminary evidence suggests that the issue had gone unnoticed on the DB and DA parts because of an undocumented silicon bug relating to the port overrides. I need to shutdown and restart my PC as it's got an unrelated hung process dragging performance down, meaning I have to close and figure out what to do with over thirty unsaved documents. Once I've completed the reboot, I will resume work on this issue. The way you talk, one would think you were paying me or something. I'm doing this for free, and I'm making it such a priority because PWM is widely used and very important to all users.
ikkei3
commented
1 year ago What I checked about analogWrite() is fact. I believe that this fact will be a hint to solve the problem. I have no other thoughts.
2023/03/04 20:52、Spence Konde (aka Dr. Azzy) @.***>のメール:
I checked analogWrite(). It gets worse and worse as the version goes up. Early versions were better. Best regards, -------------- That was a non-constructive (had you pointed out specific versions and what regression occurred there, that might have been useful but you didnt). I don't know if you meant it that way, but I found that comment rude and insulting, especially when I've spent the better part of the last week working on fixing it (though a cabinet of drawers in my room collapsed and I've had to devote time to repairing it). Yes, a regression occurred this is software, it happens sometimes. I've built a test board and written a rigorous PWM test sketch that all pins that are expected to have PWM available do have PWM and that digital write does turn off that PWM. During this process I found a case of several semi-user facing macros (unlikely to be called from user code, but very likely to be called from libraries, that, while they didn't cause problems with this in particular, could cause almost arbitrary undefined behavior if called using a signed integer as a pin number instead of an unsigned one (because of the fact that macros don't check or implicitly convert types), and I'm rather surprised that I haven't gotten bug reports about them already (though they may be the underlying cause of some library compatibility issues). I consider those issues to be serious by I think I have those fixed. As for the problem at you have there is something something VERY strange going on. It's trivial to reproduce, but only on the DD, yet what appears to be be causing it should cause it to happen on the DA and DB as well. And yet it doesn't. Preliminary evidence suggests that the issue had gone unnoticed on the DB and DA parts because of an undocumented silicon bug relating to the port overrides. I need to shutdown and restart my PC as it's got an unrelated hung process dragging performance down, meaning I have to close and figure out what to do with over thirty unsaved documents. Once I've completed the reboot, I will resume work on this issue. The way you talk, one would think you were paying me or something. I'm doing this for free, and I'm making it such a priority because PWM is widely used and very important to all users. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
pcfreak1201
commented
1 year ago BTW: Spence, you earlier talked about setting up some kind of sponsoring. Do you have something else than tindie? (Because I want to sponsor you and not the US post service - and I have all chips I want to play with ;-)
SpenceKonde
commented
1 year ago I'm going to have patreon if I ever get a break from these issues long enough to do the writeup. I am bad at social media, and the person I used to ask about things like that vanished, which sucks
SpenceKonde
commented
1 year ago So this appears to work now on the DD32 after fixing bugs all over the place.
Then I removed the direction set macro call.
The test results were unchanged. The direction setting was a red herring and all kinds of timer have a peripheral override of PORTx.DIR!!!!! This is directly contrary to the datasheet, which states, and I quote:
The direction for the associated port pin n must be configured in the Port peripheral as an output
Anyone got any hardware for which this is the case? Or are you all seeing the same thing I am? Like, you can downgrade to the last 1.4.x version and use a DA or DB, analogWrite() a PWM pin, and then pinMode() that pin as input.... the PWM continues? If you do pinMode(some pin that's making PWM, INPUT)
SpenceKonde
commented
1 year ago In any event I've checked in what I belive to be a fix for this on the DD32. Some of the problems were in the variant file itself, which was not consistent with the part-specific documentation, which said we run with TCD0 on the high half of PORTA and TCA0 on PORTF, and the TCBs on PA2 and 3. all of those were swapped... in some places.... but not others... which was part of the problem, but not all of it; there were also bugs throughout analogWrite()
SpenceKonde
commented
1 year ago Should be fixed. Finally
Discussed in https://github.com/SpenceKonde/DxCore/discussions/409