DxCore
DxCore copied to clipboard
SpenceKonde
finish port of Hardware serial so it can receive
As I added to my last comment in the pullrequest, i suspect the problem being following. Maybe it helps
"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....
I still don't think it works, i just need to go through and fix the offset to find the buffer's head and tail after getting rid of the unnecessary variable that you demonstrated could be removed in megatinycore - right now serial is busted on both cores because they both have half each of an enhancement.
Also, as you probably noticed, that assembly is frankly kinda scary and arguably evil.
please take a look at my changes at UART.h, line 142 and UART.cpp, line 168. It should make offset generation much easier. Should be also possible to do with the tx buffer index, but I haven't put much thought into it yet.
Also, as you probably noticed, that assembly is frankly kinda scary and arguably evil.
It would certainly make things significatnly less scary, if you would also provide the idea in C ^^
just found this:
#define getOffset(class, member) (size_t)&(((class *)0)->member)
could be used directly in the assembly input operands section. Compiler will complain about the members being protected at first, but this can be solved by declaring the _do_xyz function as friends. Seems to work on my end. (gcc provides __builtin_offsetof , but it is designed to work with structs and unions, so it thows some warnings)
Also, as you probably noticed, that assembly is frankly kinda scary and arguably evil.
It would certainly make things significantly less scary, if you would also provide the idea in C ^^
There are C versions of them - but they're well out of date by now, and don't support a bunch of important stuff.
And like, the last time I was aware of what the C code looked like was while I was first writing them. If you challenged me to produce the C code that duplicates the functionality, well... If there were a bookmaker offering a bet on whether I'd be able to generate working c code to duplicate the current functions, you'd maximize your chance of getting some extra spending money to bet on "no".
Besides, there is absolutely no way that a naked ISR, which uses a dirty trick to grab the address of a C++ object, pushing just enough registers to fit that, before it jumps to a naked assembly function shared among every serial port to avoid a function call because the ABI would impose too much overhead .... theres's no way that's not going to be scary.... you can put all the makeup and lipstick and frilly dresses that you want onto something, but if it's 15 feet tall, with sword-like claws, a fierce curved beak, two dozen eyes distributed irregularly across it's green skinned body, reeks so strongly of brimstone that your eyes start to sting a block away and has a severed arm belonging to your (former) neighbor hanging out that beak, those cosmetic measures won't make it significantly less scary. It's still an obvious representative of some otherworldly demonic force