MicroUSB. Whats a preferred alternative interface?
in [Commodore]
|
From: agila61 on 10 Dec 2006 14:47 Tristan Mumford wrote: > On that subject. I'm still > not comfortable with directly interfacing 5v IO with 3.3v IO (the USB IC). > Its IO is 5v tolerant, but surely it would result in a partially on state > for the uCs interfacing gates causing power drain. Unless they have some > extra level of protection to cope with dodgy IO. A pair of bus switches (Nat. Semi 74CBT3245 is what I saw in sci.electronics.design) would handle that for parallel, I'm assuming if there's a one-way octal part there has to be a two-way serial part. The next step up in speed from "logic-level RS-232" might be a master-slave half duplex. One serial line is used to put a control byte out, which includes the I/O mode, and the other is used to either read to or write from the device. I know that half-duplex with the C64 as the serial bus master can run far faster than asynchronous. Its 5 lines .... Control, Data, Clock, Select, and DeviceReady. And if a block transfer can always finish once it starts, then you could get away with just four and have a status register on the device side. And actually, there's be very little difference in perceived performance. "Check for Ready, Load/Store byte" in a parallel port would not need many if any NOPs to redirect it to the register for the serial line used for data.
From: agila61 on 10 Dec 2006 21:33 Tristan Mumford wrote: > At any rate because of my silly problem I took an alternate route. I > decided to use a uC for now to handle the low level stuff. This leaves me > free to conenct it to other things. > As it is my options seem to be either User port, or Tape port. > In the case of the user port I have no idea how to establish an effective > communication method. Parallel would be nice, but how would I do it? > The biggest stumbling point is data direction. I'd need to be able to > synchronise the direction between the userport and the uC somehow. Any > ideas? Looking around searching for USB interfaces used for microcontrollers .... I ran across the Maxim 3421E http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3639 This uses an SPI interface. I'm not sure if I have this right, because I learned about the SPI interface after I went through the period of being keen to connect the UserPort to a FlashCard, but ... The SPI is the "four line" interface. In full duplex mode it is synchronous serial: MISO (Master In - Slave out) MOSI (Master Out - Slave in) CLK Select Sometimes there's an IRQ (which would make it a five wire if you had both Select and IRQ). This is basically the interface that is used in the Playstation controller/memory card port. >From what I read in the PRG description of the CIA serial ports, it seems that to set up an SPI interface on the User Port, all you need to do is to tie the two serial clock lines together, set up on serial as input and the other as output, and away you go. If I understand it correctly, the fastest that it can be set up at is 2 system clock cycles per serial port transition, which means 4 system clock cycles per serial port clock cycle, which means 250khz (the frequency that PS1 controller and memory cards run their SPI bus on). That's slow, but if the SPI bus device has no minimum frequency, then there's no problem. The Max3421E has no minimum frequency. And 64 bytes FIFO buffer for both input and output. There's not even a need to use multiplexing or any other parts to control multiple SPI chips ... the parallel port gives 8 perfectly good select lines for 8 devices, or more likely 4 select lines and 4 IRQ lines, with the IRQ's tied together to FLAG as well to generate an IRQ tell the system to look for which IRQ has been triggered. 4 SPI devices could give quite a lot: * USB (Maxim 3421E, FTI FT2232D http://www.ftdichip.com/Documents/DataSheets/DS_FT2232D_091.pdf) * UART (SC16IS75x/76x has 3 Serial ports supporting 232C, 422c) * Flash RAM (1M AT25F1024 SPI http://www.chipcatalog.com/Atmel/AT25F1024.htm) All my hardware is in Oz, so when I get set up again here in Ohio, that's what I'll be looking at. But USB would be the last item in my list, since the programming is more of a challenge (indeed, the Flash RAM may be required just to store the device drivers for different USB devices).
From: Tristan Mumford on 10 Dec 2006 23:29 On Sun, 10 Dec 2006 18:33:04 -0800, agila61 wrote: > Tristan Mumford wrote: >> At any rate because of my silly problem I took an alternate route. I >> decided to use a uC for now to handle the low level stuff. This leaves me >> free to conenct it to other things. > >> As it is my options seem to be either User port, or Tape port. >> In the case of the user port I have no idea how to establish an effective >> communication method. Parallel would be nice, but how would I do it? >> The biggest stumbling point is data direction. I'd need to be able to >> synchronise the direction between the userport and the uC somehow. Any >> ideas? > > Looking around searching for USB interfaces used for microcontrollers > ... I ran across the Maxim 3421E > http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3639 > > This uses an SPI interface. That sounds strangely familiar. I'll have a look into it next time I have a few uninterrupted minutes. I wonder if it's one of the hardware supported things that the uC I'm using uses. I know it has I2C, Serial, PSP (parallel slave port. Another useful thing), and may have a single wire networking interface (CAN?). I was considering I2C because there are software interfaces for lots of things out there. But as I'm only connecting one device, the addressing ability is somewhat lost. Then there's one other protocol that has been overlooked, JTAG. I know it may seem a little odd considering what its used for. Consider it though. It allows a single master (the C64), and daisy chained slave devices. Each device in the chain can have data written to any internal 'address' in a serial manner and returned via the chain. Given the signals it uses it could work effectively off the cassette port. I don't mean to detract from your idea(s) though I like them. Especially with the interrupt capability. I like interrupts. They save throwing away so much time on polling. That's one reason my C64-uC-USB monstrosity has the interrupt line from the '11HS to the uC. > > I'm not sure if I have this right, because I learned about the SPI > interface after I went through the period of being keen to connect the > UserPort to a FlashCard, but ... Well you could o that... There is an SD card slot with controller piggybacked, with builtin FAT support etc for sale. I don't remember where I saw it though. Might have been spark fun or Dontronics. it would take most of the hassle out of that sort of interface. > The SPI is the "four line" interface. In full duplex mode it is > synchronous serial: > > MISO (Master In - Slave out) > MOSI (Master Out - Slave in) > CLK > Select > > Sometimes there's an IRQ (which would make it a five wire if you had > both Select and IRQ). > > This is basically the interface that is used in the Playstation > controller/memory card port. Interesting. Very interesting. Ages ago I wanted to know how the PS port worked. I believe I wanted to use one of the 8mb PS1 memory cards on the C64. And also use said interface to edit PS1 savegames. Dever did it though. > >>From what I read in the PRG description of the CIA serial ports, it > seems that to set up an SPI interface on the User Port, all you need to > do is to tie the two serial clock lines together, set up on serial as > input and the other as output, and away you go. If I understand it > correctly, the fastest that it can be set up at is 2 system clock cycles > per serial port transition, which means 4 system clock cycles per serial > port clock cycle, which means 250khz (the frequency that PS1 controller > and memory cards run their SPI bus on). I know this is probably a stupid question, but why tie the serial clocklines together? Come to think of it, here's another stupid question. I've never used the dotclock line on the expansion connector until recently. I'd assumed it was ~8MHz. That part of the circuitry had never really concerned me. I couldn't help noticing that the c64 uses a ~17MHz xtal to derive the dotclock from. I guess what I'm saying is the dotclock is the xtal freq/2, right? Just asking because that's what I'm running the uC off (but not the USB IC). if I'm wrong I'm still within the frequency range of the uC, but it means my delay is wrong. > > That's slow, but if the SPI bus device has no minimum frequency, then > there's no problem. The Max3421E has no minimum frequency. And 64 bytes > FIFO buffer for both input and output. That's not bad. I have some 512k deep 8 bit FIFOs which could really add to that too. But they have their own intended use already :) > > There's not even a need to use multiplexing or any other parts to > control multiple SPI chips ... the parallel port gives 8 perfectly good > select lines for 8 devices, or more likely 4 select lines and 4 IRQ > lines, with the IRQ's tied together to FLAG as well to generate an IRQ > tell the system to look for which IRQ has been triggered. I think I'd still use a demuxer or two to drive extra things, even if I didn't have them. The multiple IRQ idea is good. Save a lot of processing time. > > 4 SPI devices could give quite a lot: * USB (Maxim 3421E, FTI FT2232D > http://www.ftdichip.com/Documents/DataSheets/DS_FT2232D_091.pdf) * UART > (SC16IS75x/76x has 3 Serial ports supporting 232C, 422c) * Flash RAM (1M > AT25F1024 SPI > http://www.chipcatalog.com/Atmel/AT25F1024.htm) > > All my hardware is in Oz, so when I get set up again here in Ohio, > that's what I'll be looking at. But USB would be the last item in my > list, since the programming is more of a challenge (indeed, the Flash > RAM may be required just to store the device drivers for different USB > devices). Why would you want to leave this wonderful country! j/k. Anyway It should be interesting to see what you find! I apologise if this is a little bit rambling. It was written over a period of a few hours in short fragments. -- -----> http://members.dodo.com.au/~izabellion1/tristan/index.html <----- ===== It's not pretty, it's not great, but it is mine. =====
From: agila61 on 11 Dec 2006 10:00 Tristan Mumford wrote: > > This uses an SPI interface. > That sounds strangely familiar. I'll have a look into it next time I have > a few uninterrupted minutes. > I wonder if it's one of the hardware > supported things that the uC I'm using uses. I know it has I2C, Serial, > PSP (parallel slave port. Another useful thing), and may have a single > wire networking interface (CAN?). Some of the things I saw had I2C and SPI, some had I2C alone. I2C works OK up to around 400khz with some modern gear, but I don't know what they are clocked at ... SPI can work up to the 10's of MHz range, but like I said, 250khz is, I think, the max for the C64 User Port. > I don't mean to detract from your idea(s) though I like them. Especially > with the interrupt capability. I like interrupts. They save throwing away > so much time on polling. Yes! I would not through away select lines for nuthin! > > I'm not sure if I have this right, because I learned about the SPI > > interface after I went through the period of being keen to connect the > > UserPort to a FlashCard, but ... > Well you could o that... There is an SD card slot with controller > piggybacked, with builtin FAT support etc for sale. I don't remember where > I saw it though. Might have been spark fun or Dontronics. it would take > most of the hassle out of that sort of interface. I was going for dirt cheap and simple hardware, and the effort in the software. So when I said Flash, I meant CompactFlash ... that guarantees access to an 8-bit IDE controller if the socket can be wired correctly. That was why I had PA2 toggle between a control byte and data bus, since then all you need is a an octal latch and a 1 line demux to split R/W into R and W. > Interesting. Very interesting. Ages ago I wanted to know how the PS port > worked. I believe I wanted to use one of the 8mb PS1 memory cards on the > C64. And also use said interface to edit PS1 savegames. Dever did it > though. I used to have links to sites that gave the protocol. Writing the output line always automatically reads the input line. > >>From what I read in the PRG description of the CIA serial ports, it > > seems that to set up an SPI interface on the User Port, all you need to > > do is to tie the two serial clock lines together, set up on serial as > > input and the other as output, and away you go. If I understand it > > correctly, the fastest that it can be set up at is 2 system clock cycles > > per serial port transition, which means 4 system clock cycles per serial > > port clock cycle, which means 250khz (the frequency that PS1 controller > > and memory cards run their SPI bus on). > I know this is probably a stupid question, but why tie the serial > clocklines together? If the input serial clock is not tied to the output serial clock, then the input serial port never shifts the input data in. > Come to think of it, here's another stupid question. I've never used the > dotclock line on the expansion connector until recently. I'd assumed it > was ~8MHz. That part of the circuitry had never really concerned me. > I couldn't help noticing that the c64 uses a ~17MHz xtal to derive the > dotclock from. > I guess what I'm saying is the dotclock is the xtal freq/2, right? > Just asking because that's what I'm running the uC off (but not the USB > IC). if I'm wrong I'm still within the frequency range of the uC, but it > means my delay is wrong. That I don't know. Is it the same crystal for PAL and NTSC? I would assume that they would use the crystal that made the display work. > > That's slow, but if the SPI bus device has no minimum frequency, then > > there's no problem. The Max3421E has no minimum frequency. And 64 bytes > > FIFO buffer for both input and output. > That's not bad. I have some 512k deep 8 bit FIFOs which could really add > to that too. But they have their own intended use already :) The big thing that made me want to go with flat select lines is that if you have an SPI device that can has on I/O line on MOSI (like, it also supports I2C), you can select it, tell it to do a block write and output on the MOSI line, deselect it and select another one, get it set up for a block read, then select both, and copy directly from one SPI device to the other. To do that, you need to put dummy data into the Userport MOSI register, but switch the MOSI bus from the Userport MOSI to the MISO line. That's what I would use PA2 for, with the PB and Flag dedicated to a bank of 4 select/irq pairs. > > 4 SPI devices could give quite a lot: * USB (Maxim 3421E, FTI FT2232D > > http://www.ftdichip.com/Documents/DataSheets/DS_FT2232D_091.pdf) * UART > > (SC16IS75x/76x has 3 Serial ports supporting 232C, 422c) * Flash RAM (1M > > AT25F1024 SPI > > http://www.chipcatalog.com/Atmel/AT25F1024.htm) > > All my hardware is in Oz, so when I get set up again here in Ohio, > > that's what I'll be looking at. But USB would be the last item in my > > list, since the programming is more of a challenge (indeed, the Flash > > RAM may be required just to store the device drivers for different USB > > devices). > Why would you want to leave this wonderful country! j/k. Anyway It should > be interesting to see what you find! I had to leave ... I was a temporary resident for 10 years, but my last contract ran out, so I had to come back to a place where it was legal for me to continue working. My plan to make a million dollars and retire to Oz just never happened.
From: Tristan Mumford on 11 Dec 2006 21:30
On Mon, 11 Dec 2006 07:00:30 -0800, agila61 wrote: > Tristan Mumford wrote: >> > This uses an SPI interface. > >> That sounds strangely familiar. I'll have a look into it next time I have >> a few uninterrupted minutes. > >> I wonder if it's one of the hardware >> supported things that the uC I'm using uses. I know it has I2C, Serial, >> PSP (parallel slave port. Another useful thing), and may have a single >> wire networking interface (CAN?). > > Some of the things I saw had I2C and SPI, some had I2C alone. I2C works > OK up to around 400khz with some modern gear, but I don't know what > they are clocked at ... SPI can work up to the 10's of MHz range, but > like I said, 250khz is, I think, the max for the C64 User Port. I don't think clocking is too important with I2C. Not completely sure how that works though. SMBus (I think is the name) is I2C. However it is the sort that PC motherboards use, and runs at a much lower speed. Many of the popular PC addons like fanspeed and temp. monitors connect to this bus via a motherboard header. It is theoretically possible to network all sorts of things using it. I believe there is at least one amiga program that uses it. Although I'm not sure how hard it would be to transfer big data like files etc over it. >> I don't mean to detract from your idea(s) though I like them. >> Especially with the interrupt capability. I like interrupts. They save >> throwing away so much time on polling. > > Yes! I would not through away select lines for nuthin! > >> > I'm not sure if I have this right, because I learned about the SPI >> > interface after I went through the period of being keen to connect >> > the UserPort to a FlashCard, but ... > >> Well you could o that... There is an SD card slot with controller >> piggybacked, with builtin FAT support etc for sale. I don't remember >> where I saw it though. Might have been spark fun or Dontronics. it >> would take most of the hassle out of that sort of interface. > > I was going for dirt cheap and simple hardware, and the effort in the > software. So when I said Flash, I meant CompactFlash ... that guarantees > access to an 8-bit IDE controller if the socket can be wired correctly. > That was why I had PA2 toggle between a control byte and data bus, since > then all you need is a an octal latch and a 1 line demux to split R/W > into R and W. Thats true. I mean its not too hard to use 16 bit data on an 8 bit bus, but reading and writing it can be a shade more fiddly. I was actually looking at one of the 8-bit bus sony cd-roms recently wondering about interfacing it to an 8 bit machine. > >> Interesting. Very interesting. Ages ago I wanted to know how the PS >> port worked. I believe I wanted to use one of the 8mb PS1 memory cards >> on the C64. And also use said interface to edit PS1 savegames. Dever >> did it though. > > I used to have links to sites that gave the protocol. Writing the output > line always automatically reads the input line. i looked for info a long time ago but was probably looking in the wrong place. > >> >>From what I read in the PRG description of the CIA serial ports, it >> > seems that to set up an SPI interface on the User Port, all you need >> > to do is to tie the two serial clock lines together, set up on serial >> > as input and the other as output, and away you go. If I understand it >> > correctly, the fastest that it can be set up at is 2 system clock >> > cycles per serial port transition, which means 4 system clock cycles >> > per serial port clock cycle, which means 250khz (the frequency that >> > PS1 controller and memory cards run their SPI bus on). > >> I know this is probably a stupid question, but why tie the serial >> clocklines together? > > If the input serial clock is not tied to the output serial clock, then > the input serial port never shifts the input data in. Oh I see now. > >> Come to think of it, here's another stupid question. I've never used >> the dotclock line on the expansion connector until recently. I'd >> assumed it was ~8MHz. That part of the circuitry had never really >> concerned me. I couldn't help noticing that the c64 uses a ~17MHz xtal >> to derive the dotclock from. > >> I guess what I'm saying is the dotclock is the xtal freq/2, right? Just >> asking because that's what I'm running the uC off (but not the USB IC). >> if I'm wrong I'm still within the frequency range of the uC, but it >> means my delay is wrong. > > That I don't know. Is it the same crystal for PAL and NTSC? I would > assume that they would use the crystal that made the display work. Different crystals. I don't remember the values of the top of my head though. I can tell you the PAL version is slightly slower though. The end effect is that the NTSC ver. runs at a little over 1MHz and the PAL slightly under 1MHz. > >> > That's slow, but if the SPI bus device has no minimum frequency, then >> > there's no problem. The Max3421E has no minimum frequency. And 64 >> > bytes FIFO buffer for both input and output. > >> That's not bad. I have some 512k deep 8 bit FIFOs which could really >> add to that too. But they have their own intended use already :) > > The big thing that made me want to go with flat select lines is that if > you have an SPI device that can has on I/O line on MOSI (like, it also > supports I2C), you can select it, tell it to do a block write and output > on the MOSI line, deselect it and select another one, get it set up for > a block read, then select both, and copy directly from one SPI device to > the other. > > To do that, you need to put dummy data into the Userport MOSI register, > but switch the MOSI bus from the Userport MOSI to the MISO line. That's > what I would use PA2 for, with the PB and Flag dedicated to a bank of 4 > select/irq pairs. I see what you mean. > >> > 4 SPI devices could give quite a lot: * USB (Maxim 3421E, FTI FT2232D >> > http://www.ftdichip.com/Documents/DataSheets/DS_FT2232D_091.pdf) * >> > UART (SC16IS75x/76x has 3 Serial ports supporting 232C, 422c) * Flash >> > RAM (1M AT25F1024 SPI >> > http://www.chipcatalog.com/Atmel/AT25F1024.htm) > >> > All my hardware is in Oz, so when I get set up again here in Ohio, >> > that's what I'll be looking at. But USB would be the last item in my >> > list, since the programming is more of a challenge (indeed, the Flash >> > RAM may be required just to store the device drivers for different >> > USB devices). > >> Why would you want to leave this wonderful country! j/k. Anyway It >> should be interesting to see what you find! > > I had to leave ... I was a temporary resident for 10 years, but my last > contract ran out, so I had to come back to a place where it was legal > for me to continue working. My plan to make a million dollars and retire > to Oz just never happened. That's a shame. I guess you were being too useful and not crooked enough. <rant> The owner of the house I was renting in Melbourne was a great example. Never paid any bills (used the address of the house I was at), was ripping off centrelink in at least 3 ways, running a business without declaring the income And using the gains to build a house in the backyard of the place I was at, against the tenancy board laws etc. </rant> Anyhow. I'm sure you'll get what you're truly after. -- -----> http://members.dodo.com.au/~izabellion1/tristan/index.html <----- ===== It's not pretty, it's not great, but it is mine. ===== |