Replies: 4 comments 6 replies
-
|
Hey @vhdlnerd, sorry to hear that the latest changes broke your design setup. I tries to keep the peripherals as small and easy to understand as possible. I thought that the HW flow control was just another over-engineered feature that is rarely used. Furthermore, I thought that removing it would shrink the size of the UART. Apparently, however, I was too hasty and both assumptions turned out to be wrong. So, sorry, and thank you for the constructive feedback! I think it should be no big deal to reintegrate RTS/CTS flow control. Still, it might be possible to shrink and simplify it a bit. Maybe a single control register bit would be sufficient to enable both handshake signals (if both are not required then they can be left unconnected / tied to zero)!? 🤔 I'll make a PR with a first proposal - would you be willing to help debugging (if required at all)? 😉 By the way, I think this case is a nice example for a community-driven project: sometimes I do not see what the actual users are seeing/requiring. So, as always, feedback is highly welcome! |
Beta Was this translation helpful? Give feedback.
-
|
First after rereading my post, the tone was a little harsher than I intended -- I should not post when I'm in a hurry and tired. Sorry about that. Sure, I can help test the RTS/CTS update you come up with, if needed. |
Beta Was this translation helpful? Give feedback.
-
|
No worries! I use a lot of open source stuff and quite often I am like "What the #*!&?! Why did they change that???" - So I can understand you 😅
Thank you very much! 👍 |
Beta Was this translation helpful? Give feedback.
-
|
Agreed. Even the basic UART should support RTS/CTS.
The cost of these signals is near zero, so I would suggest including them.
|
Beta Was this translation helpful? Give feedback.
-
|
Agreed! 👍 |
Beta Was this translation helpful? Give feedback.
-
|
As to what my current neorv32 project is: My main SW project I'm running on this setup is a Forth language (interpreter) that I wrote almost completely in RISC-V assembly (yes, I'm that crazy 😃). I need the HW handshaking lines for my Forth. I download Forth code via a simple ASCII upload over the UART. Since the Forth code sent is complied on-the-fly, there is a delay before it can accept the next piece of code. This will cause UART overruns without the handshaking lines. I hope to have my neorv32 setup to a point to upload to github soon. I want to link to it off the neorv32-setups repo if possible. |
Beta Was this translation helpful? Give feedback.
-
|
Interesting project! Especially the L2 cache sound interesting (an internal data cache is on my to-do list for ages...).
Impressive! 🤯
That would be really great! 👍 |
Beta Was this translation helpful? Give feedback.
-
|
For the records: |
Beta Was this translation helpful? Give feedback.
-
|
I tested the newly re-added RTS/CTS UART signals and everything worked in my projects. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the feedback! |
Beta Was this translation helpful? Give feedback.
-
I'm disappointed with the recent removal of the UART hardware handshaking lines. This breaks all my neorv32 based designs. I'm a little shocked that functionality would be removed from a basic interface. I use the UARTs at 921600 baud sending commands to the neorv32 that take time to process -- hardware handshake lines are required to avoid dropping commands.
The two workarounds mentioned in the change notes (adding a non-crippled UART as a custom function or a wishbone module) are equally poor. Either way means having a custom bootloader and worst not being able to use any of neov32's SW library functions that uses UARTs (neorv32_uart_printf, ...).
Brian
Beta Was this translation helpful? Give feedback.
All reactions