MicroUSB. Whats a preferred alternative interface?
in [Commodore]
|
From: Tristan Mumford on 8 Dec 2006 07:32 On Fri, 08 Dec 2006 03:18:36 -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? > > Also, I would suggest that if you use the User port, a good solution > would be to solve the connection problem for homebrew User port devices > once and for all with a board that has the relevant lines connected to > a DB25 female, and use a DB25 male on the card holding the uC. My "Test" C64 actually has a D25 Male (not sure why I put a male on there) mounted in the case above the original user port connector. I use it to test uC projects because it has the +5v, gnd, and (lets just pretend) RS232C lines at TTL level. > > And DB25 plugs are (at least for not) somewhat more readily available > than classic spacing edge card connectors. Sorry about replying to this one first. The other reply looks god to me but my mind is a little dull right now to take it in properly. Going to give it a good read tommorrow morning. I was just working on the prototype board. I made one notable alteration. using the IRQ feature of the USB IC to interface with an IRQ pin on the micro. Now I can cut out polling. Thanks for your help by the way. Much appreciated. -- -----> http://members.dodo.com.au/~izabellion1/tristan/index.html <----- ===== It's not pretty, it's not great, but it is mine. =====
From: agila61 on 8 Dec 2006 11:25 Tristan Mumford wrote: > My "Test" C64 actually has a D25 Male (not sure why I put a male on there) > mounted in the case above the original user port connector. I use it to > test uC projects because it has the +5v, gnd, and (lets just pretend) > RS232C lines at TTL level. The serial port connection ... that's why you put a male there ... terminals and printers were both "peripherals" and connected with male plugs to the female plugs on "real" minicomputers ... I guess interface cards were more valuable than cables, so you put the pin side on the cable. But then free standing modems were developed to let terminals talk to minicomputers on the phone lines, so the rack modems connected to "real computers" and free standing modems connected to peripherals. The first microcomputer serial ports were designed to work with available modems and printers, so the plugs were flipped around. Don't matter ... If all lines are connected, you've got your port for your external UserBox port right there. If only the ones needed for the 9600 bps hack are connected, there are about five more to connect. I worked out a much more complex approach a few years back I really wanted to get an 8-bit IDE interface run off the UserPort for access to Compact Flash memory, but when I had the money to work on hardware I had no time, and when I had the time to work on hardware I had no money. So I kept playing around with it until I realized that 128 register addresses were really all I needed to control anything that I could ever hope to cook up. For example, if you wanted to do a quick and dirty (to implement, not to run!) 16-bit IDE interface, use PA2 for Data/Control, with /Control a write select on a couple of 4 bit latches. With 8 IDE registers on PB0, PB1 and PB2, CS1/ and CS/2 taken by splitting PB3, you can use PB4 to select between high byte and low byte, as a channel select on a couple of 4 bit multiplexors (with a high CS, which is also tied to PA2). ORing PB4 with the PC2 handshake flag gives a handshake on the lower bank of addresses only, and that is used as a /select for a demultiplexer to split PB7 between read and write. Then in 8 bit mode, you just write a byte at a time. In 16-bit mode, you read low then how, and write high then low. According to classic discussion of interfacing a controllers to an IDE device by Peter Faasse ... http://www.pjrc.com/tech/8051/ide/wesley.html#idecon .... the only other signals that you benefit from connecting in the most basic IDE mode are /Reset, /IRQ, and /ACT. So connect /IRQ to /Flag, /Reset to PB5 through the latch, and /ACT to PB6 through the latch, with PB5 writing into the latch and PB6 read from the latch. At that point in time I was looking at nybble wide CMOS parts, so there's a line driver in there somewhere that helps keep data and control straight while making sure that reads are coming in at TTL levels. But I never got around to it and now everything is PLDs and FPGAs. I probably would have made a hash of it anyway ... its easier to throw away a bad project and start again with software.
From: Tristan Mumford on 9 Dec 2006 02:46 On Wed, 06 Dec 2006 02:19:08 +0000, Tristan Mumford wrote: I know its a reply to self, but it barely seemed worthwile creating another thread. I finished building the first prototype of the interface today. Doesn't work. Will figure it out later. Anyway for now I'm just using an RS232 connection from the userport on the C64. It also draws its current from there. The reset signal for the USB IC is also derived from there. The uC is running off the 25th pin of the D25 on the userport. That pin is attached to the dotclock. The logic there is if the C64 works the PIC should be working. The USB chip has its own 12MHz xtal. Later on I hope to implement a better interface. But that will wait until it is working. If you are wondering, the +5 and +3.3v are working fine so its not a power problem either. Such a shame. I was hoping to share a success with everyone. -- -----> http://members.dodo.com.au/~izabellion1/tristan/index.html <----- ===== It's not pretty, it's not great, but it is mine. =====
From: agila61 on 9 Dec 2006 08:44 What uC part#? Tristan Mumford wrote: > Later on I hope to implement a better interface. But that will wait until it is working. If you are wondering, the +5 and +3.3v are working fine so its not a power problem either. Precisely the way to proceed. How are you handling getting the CMOS levels of the uC up to TTL levels? Or does the part do line-level RS-232 as CMOS-In, TTL-Out? > Such a shame. I was hoping to share a success with everyone. No dramas, this just builds the suspense.
From: Tristan Mumford on 9 Dec 2006 19:00
On Sat, 09 Dec 2006 05:44:51 -0800, agila61 wrote: > What uC part#? > > Tristan Mumford wrote: >> Later on I hope to implement a better interface. But that will >> waituntil it is working. If you are wondering, the +5 and +3.3v are >> working fine so its not a power problem either. > > Precisely the way to proceed. How are you handling getting the CMOS > levels of the uC up to TTL levels? Or does the part do line-level RS-232 > as CMOS-In, TTL-Out? The whole uC works at +5v. However I believe I realised my problem. The previous types of PIC that I have interfaced to a C64 were configured differently. Ie they used portb (which has pullups)instead of portc and a software UART which can invert signals unlike a hardware uart (which I still prefer). I just can't remember whether I need to use an inverter or not. I'm fairly sure about the pullups though. 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. I found what the bigger problem I was having was. I'd left /MCLR floating (more or less the same as reset). It was strange. The board would sit idle until I held my hand within 10cm of it. When I did that I'd hear a clicking from the speaker. That was what tipped me off to the problem. Now it gets as far as the startup beep. I don't know how far it gets after that though. Once the serial connection is working I may put a bootloader on the uC. So I can just update it using the C64 instead of needing to go through all the process of unplugging the board, connecting it to the programmer etc. After all it is a lot easier just to put the hex file on a 3-1/2" floppy to use on the c64. It has a dedicated 386 notebook with 64HDD on it. > >> Such a shame. I was hoping to share a success with everyone. > > No dramas, this just builds the suspense. -- -----> http://members.dodo.com.au/~izabellion1/tristan/index.html <----- ===== It's not pretty, it's not great, but it is mine. ===== |