Using Arduino Duemilanove with on-board USB UART (FT232RL) for read-only?

[robsmithdev]

Using Arduino Duemilanove with on-board USB UART (FT232RL) for read-only?

[RobSmithDev]

Hi Curious what disk format you will be targeting! Anyway, yes the FTDI external module is only for write because of the CTS as you suspected. The Arduino I have been using is a 328p at 16mhz anyway so should be compatible. 2M is the max the Arduino can do at 16MHz, so as long as the on board device can do that you should be ok. You could if needed change it and the PC software to 1M baud if needed, I just wanted to minimise writing errors. Hope this helps Best wishes Rob Smith Creative/Frontend/Backend Developer http://robsmithdev.co.uk

…

On 19 Mar 2018, at 21:19, Ewen McNeill ***@***.***> wrote: This looks like a real exciting project, and I'm considering trying to adapt it for my (non-Amiga) use case. Could you clarify the Arduino hardware requirements a little further for me? In particular I happen to have a AT Mega 328-based Arduino Duemilanove board here already which I'm wondering if I can use "as is" (the early Duemilanove boards came with a AT Mega 168, but later ones were 328-based, and mine has a sticker staying AT Mega 328; according to the Arduino website it's an AT Mega 328P). It looks like the Arduino Uno is also AT Mega 328P based. As best I can tell your project needs: AT Mega 328P-based Arduino (eg, 2KB RAM) or bigger 16MHz clock (for the timing loops) USB-serial capable of 2Mbps on standard Arduino TX/RX pins For write support only (which I don't need), wired access to control the CTS serial line to slow down PC host from sending data, eg via using an external USB/serial module with a CTS line The Arduino Duemilanove board has a FTDI FT232RL onboard, which seems to be capable of 2Mbps serial. Is this likely to be sufficient for read-only purposes? (AFAICT CTS is just grounded on the Duemilanove onboard USB-serial, so I'm assuming write support is a no go without an external USB-serial device.) AFAICT the Arduino Uno does not have a FT232RL on it; instead programming seems to be via a smaller AT Mega device, which presumably has its own serial IO implementation. I'm not sure if that one will do 2Mbps? Can you clarify if an external USB-serial device is needed even for read-only access? (AFAICT many of those external USB-serial, eg, PMOD, devices are using, eg, FT232RL or similar). Thanks, Ewen — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[ewenmcneill]

Hi Rob,

Per #4, I'm looking at IBM PC-like 5.25" floppies. Although in my case most of them were actually written on an Amstrad CPC6128 with a 5.25" drive attached. The Amstrad CPC had its own disk formats, but due to the use of the NEC 765 disk controller (identical chip to the early IBM PCs) in practice the only real difference to read them back is the sector numbers being offset by some amount (different for each format, it was how it detected the format). Most of my floppies are actually in a "NigDos" (Amstrad extension ROM) double sided format -- 42 tracks, 10 sectors/track, 2 sides (out side A, then out side B), 512 byte sectors -- with yet more different sector numbers.

I read a bunch of them years ago (14+ years ago) under Linux by using the raw interface to the floppy controller via Linux, so I know the format is "fairly standard" (by "modern" floppy disc standards). But it's been at least half a dozen years since I've had a PC with a floppy drive attached.... so I've been looking around at other options other than trying to get a bunch of old PC parts to work again!

From what you've said it sounds like the more recent Arduino Duemilanove boards (like mine), with the AT Mega 328P should work as is, which encourages me to give it a try since it seems like I already have the parts I need on hand (other than spare time :-) )

I'll close this issue now as I have the answer I need. But when/if I try it and get it working I'll try to remember to add a "for the record" comment for later reader's benefit.

Ewen

[ewenmcneill]

FTR, I've started trying to make this work today. At least from Linux there are a few challenges in trying to make the Arduino Duemilanove on-board FT232RL work as the serial port of the floppy tools:

• The RTS/CTS flow control lines of the FT232RL are not connected up at all AFAICT. So any attempt to use hardware flow control will cause no data to be transmitted/received, which means everything will be very quiet. At least the Linux tool I started with (usbamigafloppy explicitly tries to use RTS/CTS), so I had to work around that. (I think the Arduino firmware only tries to use RTS/CTS around write / write tests, so that side is probably mostly okay.)

• On the default Arduino, the USB UART is shared between the BootLoader and the loaded application. When DTR is pulsed low, the Arduino will be reset and go into the bootloader. By default Linux will set DTR high/low around open()/close() of the serial port, which I think means immediately after starting a program to talk to the Arduino over the serial port, it will be in the boot loader, rather than the application. I suspect the only real work around here is to out-wait the bootloader. (I'm trying to use a modified version of the Linux tool in the usbamigafloppy version, as a place to start, but I believe that's written assuming there will be no Arduino bootloader, as they're using the AVR processor directly.)

• Modem Manager wants to talk to all new USB serial ports, and send them AT commands, which I suspect will cause confusion at the Arduino end. I've worked around this with the usual approach of disabling Modem Manager.

• For interactive testing (eg, kermit), it is tricky to select a bps rate over 115200 as the rest were not possible with traditional hard wired UARTs. Sometimes multiples of 115200 are possible to select (eg, 230400), but those are difficult to program accurately on the ATMega328P side due to the clock divider's accuracy (eg, see ATMega328P DataSheet page 190 for the 16MHz rates/errors); and the 250k/500k/1M/2M rates supported on the ATMega328P are often not available in traditional serial tools :-(

So I've been able to confirm I can talk to the Arduino at 115200bps from kermit, and send "?" to get the firmware version back, but I have not been able to confirm any higher transmission rates. I have a feeling if I could wait out the boot loader before sending commands, I could make the Linux tool work, and that might allow confirming higher transfer speeds also work.

In kermit I need to do:

set line /dev/ttyUSB0
set speed 115200
set flow-control none
set carrier-watch off
c

to connect to the Arduino. Then sending "?" should return a string with the version number in it.

Ewen

[ewenmcneill]

Based on some quick experimentation it does seem to work with a 2 second sleep() between opening the serial port and trying to send the "?" firmware enquiry. And it does seem to work at 2Mbps, with that 2 second delay and RTS/CTS disabled. (1 second seems to be almost but not quite long enough; the bootloader source shows the delay is a loop count, and for the Arduino Duemilanove ATMega328 -- "atmega328" -- the loop count is set in the Makefile with MAX_TIME_COUNT=F_CPU>>4, which seems to work out to 1M loops, and presumably takes "about" 1-2 seconds. But I have been unable to find an actual "wait this long" time documented anywhere useful.)

Ewen

[RobSmithDev]

Sounds like you are making some progress then at lease, keep up the good work! Rob Smith Creative/Frontend/Backend Developer http://robsmithdev.co.uk

…

On 2 Apr 2018, at 05:49, Ewen McNeill ***@***.***> wrote: Based on some quick experimentation it does seem to work with a 2 second sleep() between opening the serial port and trying to send the "?" firmware enquiry. And it does seem to work at 2Mbps, with that 2 second delay and RTS/CTS disabled. (1 second seems to be almost but not quite long enough; the bootloader source shows the delay is a loop count, and for the Arduino Duemilanove ATMega328 -- "atmega328" -- the loop count is set in the Makefile with MAX_TIME_COUNT=F_CPU>>4, which seems to work out to 1M loops, and presumably takes "about" 1-2 seconds. But I have been unable to find an actual "wait this long" time documented anywhere useful.) Ewen — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.