SpenceKonde
Adding Dual Mode example
As promised, the Dual Mode example.
There are actually a few more ideas I have, like cleaning up the mess with begin() in Wire.cpp or adding Wire.read(buffer, len), but I'll wait until all the changes from mTC are carried over.
Can't merge until the core can compile sketches, It can't compile a fucking thing right now.!
Ok, so I made a bunch of quick fixes to make it compile on my end, but I have not taken care of the lint. Furthermore, Serial RX is broken with the new features. You also had the offsets wrong, but I figured out a way to calculate them at compile time. Still have to write it down by hand, but I'm pretty sure it is better then before
Edit:
"andi r18, 0x54" "\n\t" // In the case of parity error, BDF or ICFIF, no valid data was received, therefore the character
"rjmp _end_rxc" "\n\t" // so we are done here and skip the rest of the routine. .
(UART.cpp, line 130) - pretty sure there is a skip if bit set or so missing, because right now it always skips to the end. And it's too late to reverse engeneer whatever you've came up with in the assembly....
Yes I know the offsets are wrong abecause I wasn't don't porting the uart code from mTC
Spence Konde Azzy’S Electronics
New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: @.***
On Sun, Aug 14, 2022, 14:04 MX682X @.***> wrote:
Ok, so I made a bunch of quick fixes to make it compile on my end, but I have not taken care of the lint. Furthermore, Serial RX is broken with the new features. You also had the offsets wrong, but I figured out a way to calculate them at compile time. Still have to write it down by hand, but I'm pretty sure it is better then before
— Reply to this email directly, view it on GitHub https://github.com/SpenceKonde/DxCore/pull/320#issuecomment-1214424216, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTXEW44TUTFFUJ3PA7XSA3VZEYMNANCNFSM56BGUXXQ . You are receiving this because you commented.Message ID: @.***>
While doing some tests, I've noticed that using Wire.pins(Default SDA, default SCL) will result in the library to use ALT1 - obviously, this was not intended, but I was wondering, maybe it would be useful to make the library toggle between ALT1 and DEFAULT configuration every time the default pinset is called? Or would it lead to more question then usage? It affects only the Dx Series (a #if condition can be used) so the flash usage increase might not be critical. What do you think, @SpenceKonde ? Edit: ALT1 has the same Master pins, but different Dual Mode pins, and right now there is no way to choose the ALT1 settings, or rather DEFAULT for that matter, through Wire.pins() )
Why do people use pins()?
Whyyyy?
pins always gives the lowest number set that matches master pins. the slave pins are not considered. It would need to go to 4 arguments if we wanted to let people specify master and slave pins, and that would break compatibility and Wire.pins is strictly worse than wire.swap. For christ sake, we'd be specifying up to 4 arguments to select between two options on most parts.
I was thinking to make it toggle between ALT1 and DEFAULT when using the standard pins, but to continue using only two Arguments. I guess it makes more sense to keep the old implementation. But I've implemented a check for (sda_pin+1 == scl_pin) to make the whole .pins() a bit simpler.
Oh you noticed that in serial? Yeah you can do that trick on DX and EA, but not tinyAVR.
That concept of calling with current pins on TWI to switch slave onlty dual mode pins has some appeal. and it only applies to DxEA series - though the latter will go down to 8kso we can;t throw flash around like a drunken sailor like we could if it was DA/DB only (hell where flash > 32k, I throw RAM around recklessly currenty (all the pins.arduino tables). But the API returns a bool so how to we tell the user which pinset they got? and if we don't tell them, I think we take a turn towards behavior that people will find surprising, like when they call an init routine that haopens to set pins and we pass the same arguments, they should get the same results the second time. I'd have returned an int8_t or uint8_t if I designed the API. (0 = success, and then you get to give error codes but.... that's not what he did in MegaCoreX where the syntax is copied from
On Wed, Aug 24, 2022 at 2:10 AM MX682X @.***> wrote:
I was thinking to make it toggle between ALT1 and DEFAULT when using the standard pins, but to continue using only two Arguments. I guess it makes more sense to keep the old implementation. But I've implemented a check for (sda_pin+1 == scl_pin) to make the whole .pins() a bit simpler.
— Reply to this email directly, view it on GitHub https://github.com/SpenceKonde/DxCore/pull/320#issuecomment-1225242956, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTXEWYCCJLA4T3HXQXSV4TV2W4HHANCNFSM56BGUXXQ . You are receiving this because you were mentioned.Message ID: @.***>
--
Spence Konde Azzy’S Electronics
New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore https://github.com/SpenceKonde/ATTinyCore: Arduino support for all pre-2016 tinyAVR with >2k flash! megaTinyCore https://github.com/SpenceKonde/megaTinyCore: Arduino support for all post-2016 tinyAVR parts! DxCore https://github.com/SpenceKonde/DxCore: Arduino support for the AVR Dx-series parts, the latest and greatest from Microchip! Contact: @.***
No, I didn't see it in Serial. I guess I managed to came up with the same solution. technically it shouldn't add that much Flash, probably only around 10 bytes (never double checked), but I do think that it will lead to more issues then there will be use. Furthermore, there is a workaround with swap, so I guess the best way to go would be to keep it as is.
What is tethe most recet part of this PR i relatio to? I see a lot of little changes, not all of which I understand. Why te digitalPortToPortStruct() where it is, instead of grabbig ports directly? It's eqivalet to what was there, but it looks like it would be strictly worse, But you may know somethig I don't (I mean somethign relevat to this. There are defiitely places were I've doe a inline asm ldi of 0x04 to te high byte and swap, leftsift te port number, I'm abotu to hit the road (see that's swhy my typing is missing letters - external kb already packed), bt wit te eagle fiall vaquised, I will work o this tonight if I can clear a spot o y desk at ome to pt te laptop (it's hhhh...... it's bad)
please don't add non-idempotent behavior to .swap(DEFAULT) - I sometimes use an alt position as a mux and keeping track of where it is pointed is annoying vs just setting it where it should be.
@SpenceKonde I suspect the reason people like .pins is the documentation on which pins are on which alt position is terrible but if they specify the pins they know where it gets set.
The (3) in the IO multiplexing table stopped being useful when we got more than one alt position. I don't think it is obvious to most users to consult the port multiplexer peripheral's documentation. I have new style diagrams for everything supported by mTC and DxCore that I think make it clear what to pass to swap to get particular pins. If we added tables to the per-chip documentation it might also help. I've been going back and forth with Microchip getting clarifications where the various sources disagree (iomux, portmux, and atdf).
Where have you found any ambiguity in the portmux options? I was unaware of any for a released product using current versions of the datasheets. Now, there's that preliiminary datasheet for the 412 that is still making the rounds and omits a shitload of important portmux stuff, but the corrected version has been available for 4 years. The words "preliminary datasheet" are a euphemism for "this datasheet is wrong, even WE don't know how well they work [no typical characteristics] but only a moron would buy something based only on the product brief". One of course always wonders how it is the DD-series gets a preliminary datasheet on the year-late release.... Do you think the problem is that monkeys are scarce (endangered species and all that), or a pandemic-related goods shortage, and they don't have enough typewriters to go around? https://dilbert.com/strip/1989-05-15
Other than the occasional copy/paste error in early versions of the headers, that resulted in mux options with no pins being listed (which I can't see causing much confusion since like, what're people gonna do set it to use pins on port B when the part aint got a port B? You'd think they'd have figured out somthing was amiss when they tried to wire it up... Do they have their breadboard nailed to the wall to use like a dart board? Do they need a new pair of glasses? Or did they hear that microdosing on lsd ifor productivity was all the rage in silicon valley but missed the "micro" part?
Anyway, I'm in favor of leaving the behavior of the current release (where pin mappings with the alternate dual mode pins but the same master mode pins must use swap and pins expects master pins, two of them and only that) and I'll amend the documentation to clarify that. We probably should have supported pin mapping tabels in all the part specific documentation pages. It'd help bulk em up too, right now they look too much like a powerpoint slide. Of course, a large body of evidence suggests that we could put the monkeys on typewriters docs group on the task and nobody would know, because I've had blatant mistakes like the wrong name of the part at the top of those pages for ages and nobody pointed it out.
@SpenceKonde First I just added the Dual Mode Example, then I decided to fix Serial, and it the last part I fixed the Wire library itself. Since this ended up as a kind of a mess, I'm thinking about to just close the Pull request and provide a zip of the Wire library, including examples. I'd still like to add one more example, of how to use master and slave simulataniously, like someone requested in some other discussion thread. But I'd to write it tomorrow morning. maybe rework the examples a bit too, to reduce the count. I've thought about putting the writes and reads into one, but allowing enabling and disabling them with defines).
@ObviousInRetrospect there was no mention of changing the behaviour of swap. yet. (I didn't quite understood what you were trying to tell, wether or not there is a bug). swap itself is the workaround to change between the DEFAULT pinset an the ALT1 pinset, as .pins() can't change it back.
We have two PRs relating to wire and the files PR'ed to megaTinyCore. Which ones are the latest ones?
I'd say the best would be to use the most up to date version from mTC, and close this PR. l don't see any use of using the weird sleep handling.