-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't get nnew DxCore serial to build: #5
Comments
In file included from C:\Users\Spence\Documents\Arduino\hardware\DxCore\megaavr\cores\dxcore/UART.h:30:0, |
HWSERIAL1_MUX_OFFSET and the like - yeah they ain't defined anywhere, and where are they supposed to be defined and as what? I can't figure out where it's used in order to deduce that values uit wants.... Is that just group position? If so why not use the group position defines - those are defines, it's only the group codes that are enums |
The Dx Series might use 2 register for MUX, the pins_arduino.h files supply the base address PORTMUX.USARTA (or similar) for the Dx and PORTMUX.CTRLA (or similar) for the tinies. to keep everything as small as possible, the pins_arduino supply an offset, USART 4 and 5 are +1, making it to point to USARTB. Try the 48 pin version first. I didn't bother to do the rest should it be changed again. P.S.: MUX_OFFSET is used in _mux_set() through a pgm_read |
48pin-standard.zip |
If the changes are alright, I'm gonna change the other files as well |
I'm now getting different errors....
|
Is there some other file I'm missing the right version of? And isn't the offset being used to determine the register that's in it's own define above? |
AAaha! I'd missed UART_private, and it now compiles successfully |
I think I've gotten it working correctly now. I did some rewriting of your functions because I couldn't convince myself that they were working correctly, and because I was uncomfortable with using "any negative number" for "none" There's now a MUX_NONE defined, 0x80 numerically that I use to signal that that is to be set - though the semantics may change... tried to rip as many defines out of the variant files as were readily removable, since most of that information is just duplicating information in the io headers - ya know like "If there's a USART0, we HAVE_HWSERIAL0, and it's vectors are USART0_DRE_vect, and so on. Why they felt a need to enumerate those in variants when they, you know, don't vary, is beyond me. I fixed the problem with the setting macros too, and laid the groundwork for the new features I wanted to do relating to RS485. Things are shaping up nicely. I gave in and started taking full advantage of the fact that for all Dx and Ex parts - I explicitly test use that in a few places. the trick with word reads is clever, I hadn't realized the ompiler missed that, though I'm not surprised, having seen what it does to my bitshift division in wiring.c. |
|
I just remembered something: I think the 32u4/Leonardo was using the HAVEHWSERIAL define, since Serial0 was the USB serial, emulated by software, the hardware Serial is called Serial 1 and is even using xxx1 named registers. Who knows how the DU series will be implemented.... |
DU-series if the pulled brief is accurate will have a USART0 and USART1. What they had to sacrifice to USB was the TCD and it's PLL. But that can be entirely acomodated by my changes. I guess some of the code that generates the swap table would need to be adjusted if it assumes that there are no cases where USARTn exists whike USART n-1 doesn't - but there's no indication that will happen or could happen any time soon so we can burn that bridge when we come to it. |
A comment on your comment in the .cpp file: asm volatile ( First off, uh - why not just, like, pass the pointer in the z register by specifying that you need it in "z"? But that doesn't exactly solve the problem - a big part of the problem is that the actual ISR calls a function.
It's also that it gets called by this:
Notice that the function doesn't use r19, r20, r21, r22 or r23. Or r0, for that matter. 0x3b is RAMPZ. Sometimes it likes to save and restore that one too. I dunno on what criteria either, since I swear i've seen interrupts not save and restore it shrug but it does even on 128k parts I think I have a solution though - though it's a little scary how I enter it. It relies on two dubious things which I've done elsewhere, though not extensively.
The part which is definitely sketchy is ducking out of assembly to grab a global variable address in a constraint and immediately returning asm, while So here my thinking: NAKED_ISR(HWSERIAL0_DRE_VECTOR) { So then, your actual isr, is a function declared (naked) (used) void
|
Because The compiler was putting the pointer to the Serial object in r24&r25 iirc. It was easier to do this way to test if the function itself was working. Also, I didn't knew I could just use 'z' in the assembler code, it was basically the first time I wrote code in assembler.
This is the tricky part. For the example I grabbed it from what the compiler generated and noticed that there was a weird offset of +6. This +6 comes from the print class that saves an uin32_t millis for timeout and some vPointer (thank you, AS7 debugger) And the other offset of +12 is -6 from print leaving 6 bytes what represents the offset in the UART class if you count the variable sizes. The tricky thing is, and one of the reasons why I would rather not do it in assembler, if one were to change just the order of the variables, it might break the whole assembly part. So before doing that, we need to find a way to automatically generate the offsets. Or do some checks, is the pointer of the USART module still +12 bytes from the UART class?
Basically, yes, that is what I was thinking about doing. Except, that we have to keep it an actual function with CALL (I thought about using ICALL and that's why I wanted to keep Z register unused in the first drafts, but now I realized it will be worse then CALL since that means we have to load two bytes in the Z register). This part of code is also called by flush, meaning we can't put a reti at the end of it, the reti has to stay in the ISR.
Sorry, I have troubble following, there is too much cat inteference on the line... (at least I hope so) |
Okay so my suspicion that figuring out the offsets within the UsartClass structure is the hard part is correct it sounds like. I may come back to this when done with the other stuff argh, Yeah that's not Zuzu's fault. Sometimes when tired, my hands stop syncing up well with what I want to type, though it still feels like I'm hitting the right keys and if I don't have auto-spellcheck, the result is crap like that; I typed that out in a text editor and copy/pasted so it didn't get spell checked.
|
What is the assembler listing you are talking about? Are that the assembler file that the compiler generates? If so, The Arduino IDE is still generating a .lst file with the code in the build directory (/AppData/Local/Temp/arduino_build_xxxxxx/) |
While trying to get an example for you I learned something important about this issue.... It only happens on optiboot boards. Sometimes about those confuses objdump o_o I posted example output showing the two different blocks of output - if the build is for an optiboot definion, it doesn't use the core files.... |
Look at this MESS that avr-gcc is shitting out:
we get....
but just uncommenting the MyUSART and using that instead:
And you can get it to do the adiw/st x/sbiw crap too depending on how the lines are organized. Yargh.... |
Well, technically, it does everything right. Afterall the _hwserial_module variable is a global volatile pointer, so the compiler is reloading it everytime, being afraid it might change. I think there was an Atmel pdf about how to make a local copy of volatile variables in ISRs to stop the compiler of loading it all the time. Well, avr-gcc is technically open-source. One might try to change it up to at least optimize the X register operations, but I think this is a Pandora's box: Many bad things will pop up doing this, until we get the boon at the bottom of that. |
No description provided.
The text was updated successfully, but these errors were encountered: