Re: XU1541 and more USB stuff

On Jan 22, 3:58 pm, Jim Brain <br...@xxxxxxxxxx> wrote:
Which describes the uIEC (www.jbrain.com/vicug/gallery/uIEC)  It uses an
ATMEGA128 uC for all the heavy lifting, with an option for the external
memory (but not required).  All of the hardware is finished, and SW is
coming along nicely this week (FAT12/16/32/LFN support working for read
and write, integrating the IEC routines and adding the CMD HD-style
subdir support is progressing)

Thanks for the website link. Nice projects!

I used the ATmega2561 on a project for work (a drop-in replacement for
the ATmega128L we had in a previous project). Given that this is
doing all the IEC stuff pretty flawlessly, it sounds very doable.

I was working on my own FAT16/32 LFN library, but I recently found FatFs
which did all of the pieces I had yet to do (cluster chaining, etc.), so
I added LFN support to FatFs and modified it so it can use a single 512
byte buffer for all disk accesses.  It works for IDE, CF, and MMC/SD,
which is the target peripherals for uIEC.

We used the FlashFile code from Priio (see
https://www.priio.com/productcart/pc/viewCat_P.asp?idCategory=10) for
our last project. It doesn't support FAT32, but it was a commercial
product, and there is a fear of Microsoft patents on FAT32. It
doesn't support AVR GCC, but we used ImageCraft anyways for the
project. Heck of a lot easier than trying to write our own.

FatFs requires 512 bytes for FS/FP buffer, 256 bytes for LFN name,
leaving 3.25K free on M128.  LEaving some stack room (512-1K), that
leaves room for 9 256 byte buffers, and removing 1 256 buffer for
Channel 15 leaves 8 buffers for channels, more than the 1541.

The FlashFile library we used was pretty light on the RAM end of
things, but then we configured it to only allow 2 open files at a
time. But it sounds like you have consumed about the same amount of
space.

The discussion of memory was more to address the nibbler aspect of
such a project. A parallel cable would require more RAM in order to
support reads of an entire track. Having the excess RAM also allows
for significantly more buffering reducing the overhead of the USB
interface--though latency may still be an issue.

The reason I throw all these options out is that there could be a
single board to meet a variety of needs.  Basically a uC, an IEC port,
a USB port, and a CF/IDE interface.  Heck, throw in an SPI interface
and you have support for SD cards as well.  The trick is to find a
single uC that supports USB, CF/IDE, SPI (and possibley MMC) with the
lots of flash and ram (or at least support for external memory).  Then
just a PCB with the processor and stuffing options for all the
connectors--possibly all of them--and we can do all the work on a
single board.

Well, MMC/SD is easy, as SPI is most often available.

When i finish uIEC and VIP, I intend to roll a new board with the
AT90USB1287.  My code will move nicely, and USB is built-in.  The cost
is $1 more than the M128/M1281.

That lines up well with what I am trying to do. Perhaps we can
coordinate on the development of such a board. The AT90USBKEY is a
great springboard for this development. Since all the GPIO ports are
available as through-hole connectors, a simple breadboard development
for the IEC interface could be done until a PCB is developed.

The sd2iec looks interesting, as well as the 1541 Ultimate.  Both of
which are interesting projects in themselves as well.

The 1541 Ultimate is in a class by itself.  But, we need to look at
pricing.  sd2iec is dirt cheap (M32 and a MMC/SD port).  $50-$75 is the
uIEC target.  U1541 is $150 or so.  With some work, I think uIEC and
sd2IEC/mmc2iec can share a codebase, as they are so much alike.  That
would give the modder a tiny package, leaving cash for a single Ultimate
purchase.

$150 for the the U1541? I can't find a website for the development,
though I did find something here: http://commodore-gg.hobby.nl/innovatie_1541kaart_eng.htm

I can't figure out all the parts, but it appears to have an FPGA (and
an accompanying platform flash), an Intel flash part, and (perhaps)
some RAM/SDRAM. If I were to do this, I'd shy away from the Xilinx
parts, since they require separate configuration prom/flash part
(though the new BFI mode will make regular flash more usable). Actel
has flash based FPGA, and the Actel parts are much easier to generate
power supply rails for. The Xilinx parts all have difficult power
rail requirements, and strict power sequencing that makes design
difficult.

The expense has to come from being Xilinx based. Not just the part
cost ($38 for a Spartan3-1200!), but all the power regulation
requirements, extra platform flash, then the external flash and RAM/
SDRAM. I'm not sure why all the external devices, like the flash and
RAM/SDRAM, are required. Though I imagine they need code and data
memory, and there probably aren't enough block RAMs available with the
part they chose. Using a uC should be considerably less expensive,
and going with a faster part (say a 50+MHz 16- or 32-bit uC) could
accomplish the same. And RTL development takes a lot longer, and more
tools, than to do than firmware.

RTL development would get you closer to cycle accurate. And it allows
implementations of actual 1541 parts in RTL. That's a plus. But the
cost sure seems prohibitive.

I notice that often there is mention of limitations on all of these
cables because of memory and/or processing power.  This is making me
question the suitability of using a simple 8-bit microcontroller for

I suppose, but the M32/M128 have plenty of HP for MMC/SD/IDE/CF
purposes.  USB might be a stretch, I don't know.  Truly, though, if one
wants to go after more, I think you either need to go the 1541 ultimate
approach and make a 1541 compliant system, or go with a processor fast
enough to emulate the 1541 is SW.  By the time you get there, you're
probably way over the pricing sweet spot.

The UC3A runs at 66MHz and goes for about $15. The AT90USB1287 goes
for about $16. I think the UC3A could maybe handle the 1541
ultimate. And if you find a similar processor that doesn't have USB,
etc, it probably goes for less.

If you're looking to solve your own problem, a larger unit is probably
best. But, if you're looking to re-use code and possibly share a
codebase, I'd highly recommend an AVR8 derivative with USB.  External
RAM is easy to add for plenty of room, SPI is there, and you can re-use
the SD2IEC or uIEC IEC routines wihtout having to re-invent the wheel.
FatFs is already ready to go and is used in both projects, if that is of
interest.

If a big chunk of the code is already in C, then it should be easy to
port to any architecture. All that is needed is to write low-level
drivers. And running something like FreeRTOS, allows direct access to
the hardware, while running things like the USB driver in a separate
task. Much easier than trying to coordinate code blocks, especially
for something as timing critical as the IEC protocol.
.

Relevant Pages

  • Re: Lifetime of flash memory
    ... FILE ON USB MEMORY" have come out of this. ... and overuse may wear out your memory stick pretty quickly. ... Do _not_ use journalling filesystems on flash memory sticks.) ...
    (Linux-Kernel)
  • Re: Unloading USB driver while device is attached.
    ... to `kldunload usb' without crashes a while ago, ... o Beginnings of interrupt pipe support for EHCI ... o Support for unloading the usb driver (leaks some memory) ... o Support for removing cardbus USB controllers ...
    (freebsd-current)
  • Re: Feasible to implement a router on a system on a chip?
    ... Cisco's executable images are up to 20mb a pop, and that firmware is stored in the flash. ... I tried like heck this morning to find the memory timeline/roadmap on Cisco's site, ... I honestly don't know what the breakdown of why that much is required --- but can tell you from practical experience that 64/256mb is considered standard for low-midrange (Note I'm specifically excluding SOHO routers) full-featured routers. ... you don't necessarily need more memory to support higher throughput. ...
    (comp.arch.embedded)
  • Re: Unloading USB driver while device is attached.
    ... :>: to `kldunload usb' without crashes a while ago, ... o Beginnings of interrupt pipe support for EHCI ... o Support for unloading the usb driver (leaks some memory) ... o Support for removing cardbus USB controllers ...
    (freebsd-current)
  • Re: usb memory stick performance
    ... I am struggling to understand why performance accessing my usb memory ... I know it's not the speed of the USB interface because if I use a USB hard ... The performance of a FLASH based USB stick will depend on the architecture ... and 16 Gb) now have write speeds that give hard discs a run for their money. ...
    (microsoft.public.windowsxp.hardware)