Skip to content
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

Risc-V communication with host #38

Open
JulioSDDR opened this issue Aug 23, 2019 · 4 comments
Open

Risc-V communication with host #38

JulioSDDR opened this issue Aug 23, 2019 · 4 comments

Comments

@JulioSDDR
Copy link

Is there any abstraction layer to make a serial communication between the fomu and the host pc? I have been taking a look at the implementation that is used at the micropython port, but it is a bit too low level.

@xobs
Copy link
Member

xobs commented Aug 26, 2019

There isn't one yet.

One option might be to adapt dummyusb to provide a simple Tx/Rx interface.

@apullin
Copy link

apullin commented Apr 8, 2024

I wanted to ping this ancient thread with the same question as initially proposed:

Is there an example of bare metal firmware for the pre-built LiteX/VexRISC core that demonstrates using the UART to communicate with the host?
I don't think there's an out-of-the-box example of that available.

There's a number of sub-questions there - details that I am not quite sure of...

There's already a Micropython port, and that can definitely communicate over USB-serial - so I looked there first.
As far as I can tell ... that requires running the TinyUSB lib to provide a USB-CDC, and then the actual UART driver for micropy is in @mithro 's fork of Micropython, here:
https://github.com/mithro/micropython/blob/7a4245d24b1f185d6a7a1a863349e148a2c74c5a/litex/uart.c

But then I am not sure where uart_rxtx_write actually gets implemented.
And it's a bit unclear how that code works or what it is doing.

For that solution - is it ultimately going through TinyUSB?
Unclear if any UART that LiteX might add is actually being used, or if it is just a character stream with CDC transport.

I should/will try copying that driver in the micropy port, rolling it into an otherwise empty firmware derived from riscv-blink example, do some stdio redirection, and get the minimum working example that I am looking for.
Although, per everything above, I wanted to check if this would be expected to work, or if I am misunderstanding a component.

Beyond that, there seems to be some related discussion here:
#421

but they might be chasing a different kind of solution.

Given that people are therein proposing a gateware implementation of USB-CDC, would it potentially be possible to roll a bitstream that required zero C-code level support, and just followed the standard RISC-V low-level code of hitting a couple of UART registers to pend/send characters (e.g. here), and then the gateware would invisibly get it to the host? That would be a pretty wonderful solution. Outside of my skillset to implement, sadly.

@xobs
Copy link
Member

xobs commented Apr 13, 2024

It's ultimately going through TinyUSB, yes.

If you want USB-CDC without TinyUSB, you have two options:

  1. Implement it yourself using eptri. This hardware block is documented at https://rm.fomu.im/usb.html and is what TinyUSB uses.
  2. Implement it as a replacement hardware block. There was an implementation someone did as part of a C64 implementation which you could adapt: https://github.com/jamesacraig/6502-on-fomu/blob/master/fomu_usb_cdc.py

@apullin
Copy link

apullin commented Apr 18, 2024

@xobs Ah, ok, great. I will try roll a minimum working example of the blink bare metal example incorporating the CDC config and driver taken from the micropython port. That should only be a matter of software, without having to tweak anything else.

I think that other thread was also proposing a similar solution, of a driverless hardware block. Beyond my abilities for now, but that'll be next steps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants