keithSo I got my Parallax USR2SER in yesterday. Man is this thing tiny!! About the same width of my finger, and about 1/3 the length! And its mostly surface mount stuff…..
It works like a charm. Easy installation, I was just using hyperterminal which will accept up to 921600 baud, so that’s what I was trying. I was bit-banging a port with the “pauseus” SX/B command just for some quick tests. It’s LSB just like RS-232, but not inverted, and is 0-5v. Its ASYNC and so you need start/stop bits which are exactly the same length as a data bit. The start/stop is also inverted from 232 too, which I guessed. The normal idle condition is HIGH, and so the start bit is low, 0’s are low, 1’s are high, and stop bis are high just like the idle condition. So you have to remember to separate your bytes by an extra idle period, but that’s easy enough.
The green RX activity LED on the unit stays on solid when xmitting at 921,600.
I really like the nature of USB and serial vs using a parallel port. I can’t quite explain it, but it feels more solid and reliable to me. I guess the ASYNC nature of it means there are no goofy clocking issues to deal with. And although I’m not sure how windows handles this at any level, but I’ll bet there’s some buffering going on someplace to ensure data doesn’t get dropped.
I haven’t tried receiving the data through my own windows software, but that’s the next step.
We’re silent but captured fans holding our breath out there 🙂
I am not idling, too; I am struggling now with real floppy interface as can be seen at the shot!
https://milliways.chance.ru/~tnt23/pics/amiga/fddinterface.jpg
Two more shots I can’t help but post!
https://milliways.chance.ru/~tnt23/pics/amiga/megadrive-menu-preview.jpg
https://milliways.chance.ru/~tnt23/pics/amiga/megadrive-menu.jpg
Kick ass man!! Those pictures are great. So that’s your LCD interface huh? That’s great. Good job. The interface looks very cool as well.
Looks like you are killing me on pure progress.
I just keep beating my head against the wall, and I’m hoping I can find a way through one of these days. As you’ve seen from my last few posts, I’m really suspecting the PC now. I really hope that the PC *is* the problem.
The current issue I have to deal with is that since the data must arrive at the UART of the USB2SER converter async serially, the data must be presented in perfect timing order. What this means is that I can’t have an ISR fire in the middle of a byte. If that happens, I’ll get garbage. Most of my code is STRICTLY in the ISR, which was fine before, but now I can’t both be in the ISR to handle edges AND be in the ISR for the UART transmission.
And the data has to arrive at the right time, so if an edge triggers the ISR, the next serial bit might not be ready to be xmitted until the middle of the ISR, so this presents some problems.
My plan is to move more of the code to main, and so I’m only in the ISR due to edges for a short period of time. SO the ISR will handle transmission to PC(because this is a regular event, requiring active timer rollovers), and count the time between edges. Main would take input from the ISR and shift the data as necessary.
Oh, and hey, if you are reading directly from the floppy drive to your device, and happen to notice something ODD that you haven’t seen me talk about yet, make sure you post a message.
The main things that might be throwing me for a loop are
1. really short time between edges (less than 4us)
2. really long time between edges (more than 8us)
I really think I’m on to something with the PC — let’s hope I’m right.
Thanks! The interface is quite minimalistic, with only two buttons – I ran out of spare MCU pins – and in a very erly alpha stage.
I see you’ll have to talk to your USB2SER in serial? That means some sort of ‘software UART’ which can be rather complex to implement provided you’ve already got one time critical task to tolerate.
I haven’t got to the point where I’d read from floppy yet. This, if it ever happens, will require a good deal of work, probably with interrupts like you do, for edges detection. Once the track is sampled and stored in external RAM (I’m using SIMM modules) it can be further analyzed and even squashed into pure sectors to be delivered to PC.
I think I discovered last night what you were saying about two time critical tasks being a pain in the butt.
Did you mean complex from a time-management perspective? I mean, the actual code to transmit to the uart is easy. Send a start bit, right shift the bits, send a stop bit.
I have to do some bandwidth calculations today to figure out some stuff, but having an interrupt fire every 1us for ISR to transmit to the UART is TOUGH. This doesn’t leave much time for MAIN even though the ISR exits immediately if there is nothing to send.
I’m glad my serial memory is plenty fast, as that’s the next step. The serial memory runs upwards of 15mhz, and I was planning on running it around 8mhz or so. This means I’m writing 8 bits in 1us. I can do this without an ISR by bit-banging(my phrase for the week). This is 60ns high, 60 ns low for the clock. I still have to put more thought into this….
Hi – I don’t have enough knowledge to help you but I was collecting some info because I was thinking in creating some kind of external 880k compatible floppy to pc. That’s why I read every page of this blog and come back. First I think about some kind of USB connection and I think they are some 8-bit controllers that can do the SX part – like I said i dont understand electronics enough 🙁 yet 🙂 – if interested here’s a link https://www.lvr.com/usbchips.htm. The atmel AT43USB family looks great to me.
I was trying to find some PAULA (sound and I/O from amiga) but didn’t find yet. Emulating Paula as soluction?
Well, I got more questions that answers but I will continue follow this site and hope that you reach your objective.
Cya
Yeah, what I meant was that you have two different “sides” of SX to interact with, the floppy side and the serial flow side, both with very strict timing requirements and almost no way of synchronizing one with the other.
That applies only to the situation when you have no additional RAM storage, and everything is done in realtime – obtaining bits from floppy, forming byte and sending it to PC immediately.
If you first buffer some lengthy chunk of bit flow into your serial SRAM, then you can safely leave transfer stuff for later.
BTW, one reason I am using MCUs like Atmel’s AVR series is that they feature a number of interfaces in hardware – SPI and mainly UARTs, so all you have to do is put a byte you wish to transfer to appropriate register.
The hardware will handle the transfer completely, while you can perform calculations or other I/O business. You don’t even have to bother checking the UART, there are special interrupt vectors to notify your code when the data has been sent or received.
As long as you’re generating “inverted TTL-level RS-232”, why not run it through a MAX232 and from there to the PC serial port ?
Oh, I see — the 115 Kbps maximum on commodity PC serial port isn’t quite fast enough. (Did you say you needed 600Kbps ? !).
I thought your SX chip had a built-in UART, so you didn’t need to bit-bang — but perhaps I’m confusing it with some PIC chip.
Technically the data is rate is 500bkps, but in reality, it’s a little faster than that. So I say 600kbps, so when I’m selecting components etc I’ve got some breathing room if necessary.
Trying to decide which mcu to use, sure there are some trade offs.
No, the SX doesn’t have a built-in UART. It has what’s called a virtual peripheral UART that you can combine with your code. I haven’t figured out how to use them, but I don’t see a direct advantage yet.
PICs are SLOW(unless you go high end, with associated more expensive programmers/debuggers/etc), take 4 cycles for one instruction, etc.
The SX at 50 MIPS really gives me breathing room(and time to do other stuff etc). I can’t yet optimize assembly on an mcu yet — or at least not very well.
Of course it is all about things we’ve got used to, so someone with good knowledge in PICs would recommed using PIC microcontrollers, while someone else would probably point at ARM core MCUs of which there is plenty.
Again, I am stuck with AVRs, with decent number of hardware features to choose from. Besides, they deliver processing power almost equal to their clock frequency; at 8MHz you get up to 8 MIPS (eight million instructions per second) using one-clock instructions (because there are also 2- and 3-clock instructions there).
Atmel makes a set of evaluation boards (well, what vendor nowadays does not?) with buttons, LEDs, serial ports and pins, a true paradise for experiments (maybe slightly more expensive than real paradise would be).
Oh, btw: what’s the maximum speed your built-in UART can handle? Alot of them top out at 115k or 230k or something.
I guess there are external high speed uart chips you could buy too….
Can’t find docs for my ATmega8515, but for ATmega128 maximum UART speed is 250Kbps. This hardly makes ~25 Kilobytes per second (8 bit frame, 1 stop bit). And with decoded MFM we get 125KBps, right? That is as good as ~16Kbytes per second. Hmm.
I am terribly bad at maths 🙂 Let me try this way. In MFM, I know, every bit is encoded within 4us. So complete byte comes every 32us.
Puzzling enough, that gives me precisely the MIDI interface speed, or 31250 bits per second. Ok, I am completely bananas now.
Here is Atmega8515 https://www.atmel.com/dyn/resources/prod_documents/doc2512.pdf
UART = USART?
Cya
Yes, U(S)ART can also work in (s)yncronous mode, as opposed to async-only UART.