Re: [Simulavr-devel] Adding UART support

[Theodore A. Roth]

[OT: Ken, can you try to make your email client wrap lines? This looks 
aweful in the archives. Thanks.]

Sorry if I don't give much feed back on this right now. The wine makes it a 
bit difficult to grasp what your saying. ;-)

Go ahead and start hacking on this. I'd avoid tying into stdin/stdout if 
possible. I know that I already do that with the port io but, I want it to 
go away.

Also, I'm going to be doing some major refactoring of the way virtual 
devices are mapped into the memory space. I hope this is won't be visible at 
the level you want to work, but I don't know at this point, as it's only 
been an idea brewing in my head and I haven't looked into details yet. 
Hopefully I can make things easier and faster.

Ted Roth

On Mon, 9 Sep 2002, ken restivo wrote:

:)Ted-
:)
:)I need to add UART support in order to simulate an app that is
:)UART-centered.
:)
:)I was going to do my usual "quick 'n ugly" hack method, but then I thought
:)it might be nice to try to do it "the right way", so that maybe it can get
:)merged in and maybe I'll have a few less "M"'s and "C"'s showing up when I
:)do a cvs update ;-)
:)
:)So, I notice there's no HOWTO for adding virtual device support, just an
:)interesting README on external devices and some "FIXME: empty place
:)holder" in the docs, but... perhaps this can be the start of one? I'll be
:)glad to write up whatever I discover along the way, so that others may
:)have an easier time of it.
:)
:)So far, I'm thinking of attaching the UART to either stdin/out by default,
:)or a pty or fifo specified on the command line. I'm going to start with
:)something simple: no interrupts, just a handler for when UDR is written,
:)which writes the char out to the fd, and a handler for when UDR is read,
:)which simply reads from the fd. As for reading chars, I need to be able to
:)accept both literal bytes and hex representations of bytes in ASCII. I was
:)going to do this by checking the input fd for the chars "0x", and dispatch
:)anything up to a newline to the hex2nib() from gdbserver.c (er, and maybe
:)moving hex2nib() to utils.c?). Probably need a switch on the command line
:)to turn that escape sequence off, in cases where the simulated UART is
:)talking to something that sends bytes literally. There are probably other
:)(better?) ways to do this though.
:)
:)Of course, all this would assume that RXC is always set, which is hideous,
:)but will work for the kind of tightly-polled I/O that my target app does.
:)Adding RXC and interrupt support to the UART looks like it would get
:)really hairy: the simulator would have to select/poll the fd, then set the
:)RXC flag and trigger the IRQ_UART_RX interrupt, etc.  I'm not sure where
:)such a function should reside. TXC might be OK to leave always set, or
:)maybe later on pol the fd for writablity before setting it (maybe even
:)hairier if it's a fifo).
:)
:)My apologies if the very discussion of all this slash-and-burn hacking
:)makes you nauseous ;-). Please let me know what the "rules of good
:)conduct" are for a new VDev, and I'll be glad to follow them.
:)
:)So here's what I think the steps might be:
:)      - Create the new files (uart.[ch])
:)      - Add them to the Makefile.am
:)      - Put the object stuff in the .h file
:)              - Define an enum for the base, size, and indexes for any regs 
needed
:)              - Create enums for the bits and masks for any regs needed
:)              - Create the struct for the VDevice object
:)                      - Include byte's for the registers indexed above
:)                      - Read the simluavr object model docs several more 
times ;-)
:)              - Define new/consruct/destroy methods
:)      - Write the object methods in the .c file
:)      - Add the vdev to the devsupp.c file (?)
:)      - Add the globals and command line-switches, if any, into main.c
:)      - Write a short test program for test_c (or test_asm)
:)              - Uh, make sure it works.
:)      - Run the regression tests
:)              - Install python ;-)
:)      - Submit a nice clean patch to the list, if desired
:)              - Follow the hacking guidelines in the docs
:)                      - Er, *write* the hacking guidelines for the docs ;-)
:)      - Anything else?
:)
:)
:)Thanks for your patience.