FTDI Garbage bits

[jmumby]

Hello,

Anyone played with the FTDI usb to serial converter chips? I have one hooked up for serout of say pin6 of a 28x1 and after ummm 3 days fluffing have found that the first few bytes from thsi unit are actually garbage. I was trying to read the first byte of a i2c eeprom. I wrote some code to manually enter the address and that worked fine. If I tried to read the address immediatly with nothing else to the console the char that should have been an 'X' was always coming up as <<FD>>.

I should say Im doing this in Aiterm. I have put a couple of CR,LF at the begining now but now I have a <<C3>> turning up serout

C3 OD OA OD OA

Once I get past these initial bytes it's fine. Just wonder if it is picking up some noise on the picaxe reset. I suppose if I put some pull-ups on the TX/RX lines that would be a good start.

 

[westaust55]

FTDI vs i2c ?????

@jmumby,

Not sure that I have your intentions correctly identified.

You mention using FTDI chipset from a 28X1
("I have one hooked up for serout of say pin6 of a 28x1 ")

Then you indicate that you are trying to talk to an EEPROM
("I was trying to read the first byte of a i2c eeprom.")

i2C EEPROM can be written to and read from directly by the 28X1 which has i2c comms support. See PICAXE manual 2 for the commands hi2csetup, hi2cwrite, hi2cread.

Think that you need to explain more clearly what you are trying to do and maybe a copy of your code.

With respct to FTDI chipsets, have a look at the AXE027 cable datasheet. It includes a schematic diagram for the USE to 3.5mm serial interface

 

[hippy]

It is quite common for serial transmission to carry 'garbage' when they are first turned on and voltages rise to their required levels. This can sometimes be more noticeable when suing SEROUT with a Txxxx baud rate.

What happens is the change of level indicates to the receiver something is being sent, even when it isn't, and the receiver proceeds to read something which isn't there. If it starts reading something it may read part of the bytes intended to be sent while doing so and subsequent data can also show up as garbage until the receiver's hardware sorts itself out. The corruption is not always consistent, nor always even present.

The best advice is to take the output line to be transmitted on high early in the program if using Txxxx baud rates and, for both Txxxx and Nxxxx add a delay ( of at least one byte's length, 10 x 208.3us, ~2mS for 4800 baud ) before sending the first data byte with SEROUT.

In my experience it is best to use Nxxxx baud rates whenever possible as this seems to cause less problems in this respect.