That wasn't it, but those do look interesting.
Here's what it I was referring to, I just found it:
http://www.novatek.com.tw/english/produ ... d=0.301948
Kestrel 8K Finished!
Kestrel Upload Tool is . . . uploaded.
I have updated the distribution on my website ( http://www.falvotech.com/projects/kestrel/8k.php ) to now include the Kestrel's upload tool. You can grab it using Darcs, or you can grab the .tar.gz file.
The upload tool is "Linux specific", but is easily modified for other OSes. I've factored the code mercilessly, so it should be easy to follow for anyone.
If anyone is willing to create a Windows port of the software, I'll be happy to include it in the distribution, but beware, I cannot test it.
I think my next step with the development of the Kestrel is the creation of a software-managed SPI interface with the host PC. Since the host PC represents an amalgamation of other utilities that I'd like to exploit from the Kestrel (e.g., a disk, mouse, keyboard, text- and/or graphical-display, network connection,e tc), I'm probably going to adapt some networking protocol over the SPI interface. I'm strongly considering ATM at the moment. However, I am also looking at time-division multiplexing as well (particularly effective since SPI is perfectly capable of full-duplex operation). A DTM-like system in particular looks rather trivial to implement, potentially even easier than ATM.
Traditional packet switching is also an option, but from what I've seen, software to support arbitrary length packets is more complex (and memory requirements aren't predictable). ATM and DTM involve fixed-length packets (called cells for ATM, and slots for DTM), which should make software development easier. DTM also promises less than 10% network overhead too, at least when fully utilized, while ATM imposes a fixed 10% network overhead. Traditional packet switching goes between 5% and 250%, depending on packet length.
The upload tool is "Linux specific", but is easily modified for other OSes. I've factored the code mercilessly, so it should be easy to follow for anyone.
If anyone is willing to create a Windows port of the software, I'll be happy to include it in the distribution, but beware, I cannot test it.
I think my next step with the development of the Kestrel is the creation of a software-managed SPI interface with the host PC. Since the host PC represents an amalgamation of other utilities that I'd like to exploit from the Kestrel (e.g., a disk, mouse, keyboard, text- and/or graphical-display, network connection,e tc), I'm probably going to adapt some networking protocol over the SPI interface. I'm strongly considering ATM at the moment. However, I am also looking at time-division multiplexing as well (particularly effective since SPI is perfectly capable of full-duplex operation). A DTM-like system in particular looks rather trivial to implement, potentially even easier than ATM.
Traditional packet switching is also an option, but from what I've seen, software to support arbitrary length packets is more complex (and memory requirements aren't predictable). ATM and DTM involve fixed-length packets (called cells for ATM, and slots for DTM), which should make software development easier. DTM also promises less than 10% network overhead too, at least when fully utilized, while ATM imposes a fixed 10% network overhead. Traditional packet switching goes between 5% and 250%, depending on packet length.
GARTHWILSON wrote:
The official spec. says I²C's clock and data lines are supposed to remain high when inactive; but in my limited experience, it simply doesn't matter what these lines do between the time a "stop" condition is generated and when the next "start" condition is generated. Maybe the idea is that low-power devices can scavenge their power from these lines between low pulses, like 1-Wire.