[Simulavr-devel] Adding UART support

[ken restivo]

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

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.
 
- -ken
- -- 
- ---------------
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

iD8DBQE9fWj0e8HF+6xeOIcRAnjwAJ0Zs6546juoIL3vlsgy5q03KY8JLACgqSN4
Pvgsa+CyDiQBIkkbjNafUCU=
=wu2S
-----END PGP SIGNATURE-----