Friend wanted to give me programmer board for me to try to learn but it use serial RS282 connector, but i don't have it on my labtop. I was told centain USB to serial converter don't work. The best is to build your own using FTDI chip. I wish i knew how to do it. But is there on the market that i can buy that is ready made USB to RS232 (Real or future UART) or even PCMCIA to RS232 (Real or latest UART), eeerrr....cheap? That way, i can get started learning the coder immediately.
Any help would be appreciated.
PS : I seened eBay sell a lot of those USB/PCMCIA to serial RS232 adapter really cheap. Which one will work best?
Some programs works with just about any USB-to-RS232 adapter.
Some programs on the other hand fails to use quote a number of adapters. It's probably a question of timing, since the USB interface - and the huge FIFO normally available in the adapters - leads to longer latencies. Some programs assumes that a received character should be visible almost instantly.
Try to ask around for an adapter you can try. If it works, then you know what to buy.
I would guess that you can get two or three USB-to-serial for the price of one PCMCIA-to-serial, but the prices may be different where you live.
No, it'd be better to buy one ready-made and, therefore, tested.
apple.clickandbuild.com/.../ftdichip
I use the PL-2303 without problems ~$20
www.amazon.com/.../B00073MPAS
I think you're right: the problem lies in the programs, not the adaptors.
Programs that use the serial port purely for its intended purpose of transferring data should work with any and all adaptors;
Programs that try to play "clever" tricks by, for example, manipulating the modem control signals are likely to fail - because it was never intended that those signals should be used in that way.
The same can be said of much stuff that relied upon non-standard use of the parallel port...
Always beware of such tricks - and anyone who recommends them...
true in many cases, however FlashMagic (not an 'amateur issue') has problems because many such adapters do not handle DTR/CTS etc, correctly and, quite often (flash write time) a flash update programm need to take a break from receiving data,
Erik
"The best is to build your own using FTDI chip."
FTDI chip carries the RS232 handshake signaling with the main-stream data exchange over the same USB bulk endpoint; bulk OUT EP: TxD - RTS, DTR bulk IN EP: RxD - CTS, DSR, DCD, RI
Then, at least, the order of the signaling is preserved. But the detailed timing is not guaranteed.
For example, when we handle serial lines on a PC application as follows, 1) PC sets RTS 2) 3 ms delay 3) PC sends data over TxD
On the RS232 side of the chip, we will observe this sequence. 1) RTS change 2) 0 ms or more delay 3) TxD starts
SiLabs and Prolific chip carries the handshake signaling over the default endpoint, instead of the bulk one. The timing between different endpoints is not guaranteed, even for the order. In above example, we may see this result on the RS232 side. 1) TxD starts 2) some ms delay 3) RTS change
FTDI is better, when the handshake signaling is applied. But when the application makes the detailed timing on the PC app, it may still fail even on FTDI chip. This argument is extended to all USB application. When we want to guarantee the timing over USB, there is no other way than applying the USB frame (or microframe) number to synchronize the host app and the device. Otherwise, we have to take some 10 ms order of delay into account.
The better way for design is that the PC application provides a time table as the data to the device, and the device executes this time table on the local clock.
Tsuneo
My above post may be too strict for hobby project, which allows around 10% order of error. In this criteria, the chips don't have so much difference.
When you test a USB-serial cable, I recommend you to arrange the PC environment. - Stop heavy background service temporarily. - Plug off the Ethernet cable, or stop wireless connection. - Run just the programmer app. - Connect a USB 2.0 hub between the USB-serial cable and the PC. - Plug off all USB device from the PC and the hub, except for the cable. - Use PS/2 keyboard and mouse, instead of USB.
Even on this environment, I don't guarantee 100% success, but the possibility will rise much more.
I have tested other model of USB2RS232 with a selvik programmer and with a sattalite box and in both cases the software doesn't run so I will not waste my money on it.
my friend sayed usb devices never work and do never buy them.
Buy a PCI with RS232 and it will work . Regards
No, that is wrong.
I have been using USB-to-RS232 adaptors for very many years (>10?) with very few problems.
Again, I'm convinced that the "problems" are mainly down to bad applications that make unwarranted and/or unsafe assumptions about the serial interface.
"Buy a PCI with RS232 and it will work"
A USB-to-serial will probably work in 98%, and a PCI adaptor in 99.5% - but it still won't be 100.0%
There are some poor applications that won't even work properly with all "real" COM ports...
Agree, Andy,
PCI RS232 card has better possibility than USB-serial cable. PCI card is more straightforward than USB-serial, which has additional USB device driver and hardware layer. In either way, however, as the possibility depends on the PC environment, the others may succeed on a device, but someone may fail on the same device.
As long as the PC programmer app is sensitive to critical timing of milliseccond order, it is still far from production quality. PC application on Windows after Win95 don't guarantee this extent of realtime-ness. Just device driver does.
If you want (almost) 100% guarantee, buy a programmer pod with a MCU which handles critical timing in local. Recently, MCU manufacturers have released low-cost development system around US$25 or so. The cost is comparable to USB-serial cable.
"ToolStick" on SiLabs www.silabs.com/.../ToolStick.aspx
Unfortunately, the pods aren't a universal programmer across many manufacturers of '51. But you may be able to make a universal one on the MCU and your PC. Isn't it a good hobby project? :-)
A PCI-connected RS232 port is identical to the ports built into the motherboard. The built-in ports are logically connected after a PCI bridge, even if they are available directly on the motherboard.
As serial ports, they should be just about 100% reliable. BUT our operating systems are not. Neither Windows nor Linux are designed for abusing an RS232 port with an external adapter for multi-drop use, where the transceiver may need to be switched from transmit mode into receive mode within a fraction of the transmit time of a single byte, to avoid data collisions on the single transmit/receive line.
This is the reason why some MS-DOS applications could do wonders with an RS232 port, while todays Windows machines can't match even with a 10 or 100 times faster hardware. In MS-DOS, the application where in 100% control, with the exception of the interrupts for time, mouse and keyboard. It was the application that decided if and when to perform any disk operations.
A PC-Card adapter may either use the old 16-bit PCMCIA interface, or the newer 32-bit CardBus interface. The 16-bit interface is basically the 16-bit AT-Bus introduced in 286-class PCs. The 32-bit interface is basically a PCI interface. Both solutions should work well, but to the largest part limited by the capabilities of the used OS.
Anyway, because of the limitations of - to a large part - our OS, I do recommend critical timing to be handled by external hardware. With the low price of microprocessors, all programming adapters should contain their own intelligence.
How many laptops have got PCI slots?
Not many laptops have PCI slots, but a number of laptops have PC-Card support. Same thing, but in a different form factor.
But you may be able to make a universal one on the MCU and your PC. Isn't it a good hobby project? :-)
do not even try. If you look at ISP programming of NXP, Arghmel and SILabs you will find 2% similarity and 98% difference.