David Kuehling wrote:
> But is it inverted or not?
It's non-inverted. The controller is an ATmega48, which has only
non-inverted serial. (Alas, the ability to invert UART in/out is
fairly rare. PSoC-1 have it, but they're quirky. Alas, PSoC-3
let alone PSoC-5 still don't seem to have advanced beyond sample
stage, ...)
> Your board reminds me off a single-chip USB-UART bridge, where the
> chip usually handles buffering
> and (optionally) flow control and bursts rather large amounts of
> coalesced data over the usb bus.
Yes, I picture a communication protocol along these lines:
MOSI: TX-CMD length data-1 data-2 ... data-N
MISO: xx xx xx xx xx xx
MOSI: QUERY xx xx
MISO: xx tx-queue-space rx-queue-len
MOSI RX-CMD length xx xx ... xx
MISO: xx xx data-1 data-2 ... data-N
plus control commands for bit rate, possibly flow control, break,
flush, etc.
> I dislike the compile-upload-run overhead involved with doing
> C-programming with cross-compilers. But that probably depends on the
> tools and scripts one uses.
Yeah, Makefiles are your friend :) Here's an excerpt from what I
currently use for atusb (connected to a Ben for flashing and for
power):
...
upload: $(NAME).bin
scp $(NAME).bin jlime:
prog:
ssh jlime avrdude -F -p $(CHIP_AVRDUDE) -c nanonote_atusb -e \
-U flash:w:$(NAME).bin:r \
-U lfuse:w:0x60:m # external clock, slow start-up
on:
ssh jlime poke 0x10010318 4
...
So any change is tested with make upload prog on
(The Ben has my id_rsa.pub in ~/.ssh/authorized_keys, so there are
no passwords required.)
> But then I guess user-space C programming is still much more fun than
> trying to debug a kernel module :)
It tends to save quite a few reboots ;-)
> Or,
> other idea: would it be possible to implement the mmc-uart protocol on
> the controller side, so Linux would work out-of-the-box ?
Ah, good idea. I haven't thought of this. MMC may not quite fit
(unless used in SPI mode), but in case there's already a driver
for some SPI-attached UART, making the firmware act in a
compatible way may indeed save some work.
- Werner
_______________________________________________
Qi Hardware Discussion List
Mail to list (members only): [email protected]
Subscribe or Unsubscribe:
http://lists.en.qi-hardware.com/mailman/listinfo/discussion
