How to change the UART buffer size?

[specternecter]

This may be a dumb question but I do not understand this new version of megaTinyCore. I have been working on a programmer that runs on the new version of attinys and can take UART and translate it to UPDI programming protocol. It works flawlessly on the old version of megaTinyCore, but only because I was able to change the buffer size. The UPDI protocol sends up to 139 bytes so you need a buffer equal or greater than that. This project is still under development but there's a lot of really cool features, such as auto-sensing when to switch between programming and debug mode. This new version of megaTinyCore allows you to use the half-duplex/open-drain configuration that makes everything run internally and more smoothly, but it's incapable of programming anything at all with a 64 byte buffer size, and I can't figure out how to change it. I really think I'm missing something simple and am going to feel really dumb about this, but how the HELL do you change the buffer size?

[specternecter]

Also, I raised a previous issue over the inability to get serialupdi to work over Bluetooth. It actually does work if you have the right hardware. When I started digging into the UPDI protocol to write my own programmer, I noticed the problem pretty quickly. The UPDI protocol uses even parity and 2 stop bits. Most Bluetooth modules don't have the ability to change this configuration but if they do, UPDI over Bluetooth does actually work.

[SpenceKonde]

Wow, that's all it was?

About buffer size:
Buffer sizes of larger than 256 are not supported (nor were they ever properly supported, - I think they' work in one direction, and most but not all of the time in the other direction)

Buffer sizes that are not a power of 2 are ALSO not supported. nor were they ever - not for like 1.5-2 years when I realized the compiler was missing optimizations possible for (byte value) % 2^N, and switched to the proper optimization (& ((2^N)-1))

I did incidentally drop support for 256b RX buffers, when USE_ASM_RXC or USE_ASM_DRE are enabled (these save some flash, and makethe ISRs markedly more efficient. The compiler does a piss poor job of compiling those ISRs and I wasn;'t going to meet my own merge criteria if I didn't slim down the binary size). and didn't provide a way for a variant or command line argument to override USE_ASM_* macros.

I've corrected these in the github version of both cores; supporting 256 was pretty much trivial. However, anything higher than that would get quite a bit more complicated; but you can just just off ASM_RXC and ASM_DRE in that case by defining them as 0.

[SpenceKonde]

So you can now change buffer sizes just as you could before, with SERIAL_TX_BUFFER_SIZE and SERIAL_RX_BUFFER_SIZE (which must be defined in the variant file or passed as a command line flag through the board definition)

[SpenceKonde]

BTW, you need to get 2.5.1/1.4.1 anyway if you're using serial, I just found a show-stopper bug. Serial is unusable in sketches that compile to silzes larger than 8192b.

[specternecter]

Yeah if you don't use even parity and 2 stop bits, UPDI can't possibly understand what you're trying to say. I had a BLE module that was able to change this configuration and instantly I was able to get through to the actual data upload portion of the process. But then it would fail there. Looking at the data that was being exchanged, I noticed the buffer size was set to 64 by default because it didn't repeat anything over that, even though I had already set the BLE module's buffer (MTU) to 150 because I knew I would need something around there. Once I changed the core's UART buffers to 256, everything worked.

Most Bluetooth modules can't change the parity bit and stop bits, but the very common HC-05 can for example. I have not tested this module because I don't use them, but there's absolutely no reason it shouldn't work if somebody was interested in UPDI directly over Bluetooth. They're very common and inexpensive, so that's probably the best option. I plan on doing a whole writeup on this subject once I finish my project.

Due to most Bluetooth modules not being able to change this configuration, I found the best option for me was to use a new series ATtiny as a programmer (similar to JTAG2UPDI) since they have 2 UARTs and a bunch of other very useful features. They can change the configuration themselves on the UPDI side of the UART port, so a Bluetooth module or any other UART source doesn't need to. This also allows you to read the incoming data and compare it to the UPDI starting process before sending it back out to the other port. If it recognizes the UPDI starting process, it can switch it into UPDI mode and act accordingly, otherwise serial monitor and whatnot can operate normally. So the serial monitor and UPDI both work automatically, without having to change how the TX/RX lines are set up. The absolute maximum speed of software UART in AVRs (one-wire or two wire) is about 9600bps/MHz, so really the new series ATtinys are ideal for this job if the speed aspect of UPDI is important to you. Also, as touched on previously, the new ATtinys can actually connect TX and RX together internally, which is rather amazing for doing something like this.

And thank you for that modification of the core. I was able to set the buffer size in the variant file with no issues.

[specternecter]

BTW, you need to get 2.5.1/1.4.1 anyway if you're using serial, I just found a show-stopper bug. Serial is unusable in sketches that compile to silzes larger than 8192b.

Yeah, I'm only at 2212b flash and 1082b ram for this project so I haven't hit an issue yet, but that's very helpful to know