Hi Nate, Nate Lawson schrieb: > > It's an interesting design. He hooks the READ_PORT_UCHAR functions > in Windows or traps the inb/outb with debug registers. He gets around > the latency problem by trying to package multiple bit manipulations > in a single USB packet. Two back-to-back writes may get sent as a > single USB packet and then split apart again on the microcontroller. of course, that's why I mentioned it. > However, in the cases where the software reads twice, he is stuck by > the 125 us packet delay as well. So it is not always smart enough to > handle the IO cases. I think it will be fast enough for XE/XA1541 > serial use (possibly even with speeders) but certainly not parallel > nibbling. > > Have you tested it? No, because I never considered it to be helpful for "our" X[AEMPH]?15.1 cables. Once I needed something to convert my good old GALblast hardware hack (built onto a stripe raster PCB) and was sure that Henrik's solution would work. But then I found a cheap chinese programmer with an incredibly ugly software frontend that could not only GAL devices, but also the usual Flashes, EEPROMs, EPROMs, MCUs and more. So I never bought one, but had little talk with Henrik about version 1.3. I was much more interested in the 68013A controller because at that time I was also experimenting with an 68013A development board. This is still my top-number-one USB controller for any sort of sophisticated USB device, because a) it is high speed b) has lot's of SRAM (it _is_ SRAM, because the program is also loaded into SRAM via USB or serial EEPROM and not flashed) c) reprogrammable by design, because of b) d) built-in super-fast state machine Sadly it is a very, very complex device which is not only caused by the reason that it is a 8051 derivative. On the other side I really like such super-complex thingies as long as I don't need to do anything productiuve with it ;-) For example, there are some very special control registers for fast autoincrementing pointers into XRAM (the SRAM memory which also holds the program). Later datasheet revisions of the device do not mention the meaning of these registers anymore, but the functionality is still available and working. I don't know, why the datasheets now forget to explain this functionality, but it makes the MCU much more interesting, not only as a USB controller. Such a feature speeds up a standalone controller enormously. And then there is the built-in programmable state machine which is used to configure the control logic for super fast memory block transfers between external devices and the controller and between the controller and the USB engine of the MCU. I really love it, but never had the time to perhaps implement the xu1541 onto it. Not it is done with the AT90USB162 which is the much more cheaper and easier solution. More robust and although it is only a full speed controller, more than fast enough for parallel burst nibbling. > He is considering implementing a "bulk" mode where multiple commands > are queued up, including any delays between, and the whole batch is > executed by the microcontroller. Of course, that requires major > software changes to the user's code to support. This is the model the > xum1541 uses, especially for nibbling. As long as the programmed device does not depend on maximum delays in the µs/1ms range, even old DOS bitbanging software will work with this concept. The drawback is that this software becomes a lot slower, when each bang (from bitbang) is packaged into a complete USB packet and then sent. Womo Message was sent through the cbm-hackers mailing listReceived on 2010-06-23 23:00:06
Archive generated by hypermail 2.2.0.