Re: [Simulavr-devel] Adding UART support

[ken restivo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

OK, I've added support for all the UART registers that are present on my device 
(the 163), and a test app shows the right data making their way into the 
registers, so far so good. 

I'm making a (probably wrong) assumption that all supported devices have an 
UART and they're all the same, so I'm not checking the mask_ stuff in 
devsupp.c. I suppose the subclassing and adding of more than one UART can be 
done later by someone who might need that.

Next, I'm going to add the file descriptor stuff to read/write data to the 
world at large. Probably will have a patch in a day or so, and then I can get 
back to testing my app....

- -ken
- ---------
On Mon, Sep 09, 2002 at 09:39:42PM -0700, Theodore A. Roth wrote:
> [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.

- -- 
- ---------------
The world's most affordable web hosting.
http://www.nearlyfreespeech.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9gAhye8HF+6xeOIcRAkskAJ9YVCDDyM7i0MW1cA3AB2zz9bnHYQCgstTJ
AmWJr3WBpJ4on87VTgw639Q=
=4lcC
-----END PGP SIGNATURE-----