Anyone has some sample codes or links to share on this?

So far, I only found this:
http://code.google.com/p/fprpbm/source/browse/#svn%2Ftrunk%2Fexamples%2Fminiuart%253Fstate%253Dclosed

Thanks in advance.

Dennis

Synaser:

http://synapse.ararat.cz/doc/help/synaser.html

-Michael

Dennis Poon wrote

Anyone has some sample codes or links to share on this? So far, I only found this: http://code.google.com/p/fprpbm/source/browse/#svn%2Ftrunk%2Fexamples%2Fminiuart%253Fstate%253Dclosed

http://www.ctrlterm.com/

Michael,
I used the synapser.pas unit but the compiler choked at line 232 at the identifier 'B500000', 'B576000' .... not found.
Any idea ?

Dennis
------------

Rates: array[0..MaxRates, 0..1] of cardinal =
(
(0, B0),
(50, B50),
(75, B75),
(110, B110),
(134, B134),
(150, B150),
(200, B200),
(300, B300),
(600, B600),
(1200, B1200),
(1800, B1800),
(2400, B2400),
(4800, B4800),
(9600, B9600),
(19200, B19200),
(38400, B38400),
(57600, B57600),
(115200, B115200),
(230400, B230400)
{$IFNDEF DARWIN}
,(460800, B460800)

   {$IFDEF UNIX}
     ,(500000, B500000),
     (576000, B576000),
     (921600, B921600),
     (1000000, B1000000),
     (1152000, B1152000),
     (1500000, B1500000),
     (2000000, B2000000),
     (2500000, B2500000),
     (3000000, B3000000),
     (3500000, B3500000),
     (4000000, B4000000)
   {$ENDIF}

{$ENDIF}

Dennis Poon wrote

Michael, I used the synapser.pas unit but the compiler choked at line 232 at the identifier 'B500000', 'B576000' .... not found. Any idea ?

I believe you have an outdated version on Synapse then... Here is my version of the code snippet you posted - and it compiles fine under Windows, Linux and FreeBSD. I must confess, I had to make a minor tweak to my synapser.pas unit for FPC 2.6.2 under FreeBSD to compile that unit
- but that change was in a different place in the synapser.pas unit you mentioned.

-----------------------------
const
{$IFDEF UNIX}

  {$IFDEF BSD}
  MaxRates = 18;  //MAC
  {$ELSE}
   MaxRates = 30; //UNIX
  {$ENDIF}

{$ELSE}

  MaxRates = 19;  //WIN

{$ENDIF}
Rates: array[0..MaxRates, 0..1] of cardinal =
(
(0, B0),
(50, B50),
(75, B75),
(110, B110),
(134, B134),
(150, B150),
(200, B200),
(300, B300),
(600, B600),
(1200, B1200),
(1800, B1800),
(2400, B2400),
(4800, B4800),
(9600, B9600),
(19200, B19200),
(38400, B38400),
(57600, B57600),
(115200, B115200),
(230400, B230400)
{$IFNDEF BSD}
,(460800, B460800)

  {$IFDEF UNIX}
    ,(500000, B500000),
    (576000, B576000),
    (921600, B921600),
    (1000000, B1000000),
    (1152000, B1152000),
    (1500000, B1500000),
    (2000000, B2000000),
    (2500000, B2500000),
    (3000000, B3000000),
    (3500000, B3500000),
    (4000000, B4000000)
  {$ENDIF}

{$ENDIF}

    );

{$ENDIF}

{$IFDEF BSD}
const // From fcntl.h
  O_SYNC = $0080;  { synchronous writes }
{$ENDIF}

-----------------------------

Regards,
- Graeme -

After some studying, synaser.pas seems to deal with com port instead of the low level UART interface.
Can you give me some pointer on directly using UART? I need to implement half-duplex using UART for rs-485 protocol.

Thanks.

Dennis

Dennis Poon wrote

Can you give me some pointer on directly using UART? I need to implement half-duplex using UART for rs-485 protocol.

In a Linux system, accessing the hardware by user code is strictly discouraged, at least whenever interrupts are involved (as with UARTs). A decent system should provide rs-485 support in the "TTY" driver, when the hardware allows for such.

If your system does not do so, you should find or do a device driver yourself.

In fact what do you mean by "rs-485 protocol" ?

With RS-485 hardware you can - and supposedly need to - do "half-duplex with output enable", if your hardware provides this.

The hardware might or might not provide automatic output enable (if not, you need to set and reset RTS in software).

The hardware might or might not provide echo cancellation (if not the software needs to actively ignore anything that the hardware echoes back when sending it).

If your hardware provides both auto output enable and echo cancellation, your software can happily ignore the "rs-485 protocol".

Usually both can be done in userland software even with standard TTY drivers that (usually do) setting and resetting support RTS, or (better) by dedicated support in the device driver.

-Michael

After days of google search, I am afraid the bcm2835, the Soc of Raspberry Pi (the hardware I have to use) does not provide this hardware support :-(
It states that it does not even support interrupt. Polling is the only way for events :-(

I have no experience in the above tasks you mentioned :-( It's going to take many days of trial and error. haiiii......

Thanks for your advice.

Dennis

Dennis Poon wrote

am afraid the bcm2835, the Soc of Raspberry Pi (the hardware I have to use) does not provide this hardware support :-( It states that it does not even support interrupt. Polling is the only way for events :-(

As already discussed here the RPI is strictly meant for educational use and not very suitable for embedded designs (that I think is the only kind of projects that use field-bus specifications such as RS-485).

So I recommend using a different board.

-Michael

Al 04/07/13 11:16, En/na Dennis Poon ha escrit:

If that's true, you could use an usb to rs485 adapter, most of those do the tx/rx switching automatically, so you just see a "normal" serial port (of course you'll have to manage the high level protocol yourself). I've mostly used them in 422 mode (4 wires/full duplex) but I used one of them once in rs485 mode (2 wires/half duplex).
IIRC the brand was VSCom.

Bye

thanks.
I am not using the fpc email as it seems off topic.

May I know the exact brand and model number of the adapter you used? I have an ATEN usb-to-serial cable (UC-232A) but I am not sure how to connect its serial pins to rs-485 's DIFFERENTIAL LINES and how to set that adapter into half-duplex translation mode.

Dennis

Dennis Poon wrote

I have an ATEN usb-to-serial cable (UC-232A) b

That is not suitable.

There are dedicate RS485 Adapters (many of those also support RS422 mode (differential full duplex) ).

But the problem might be that they don't come with a Linux driver for ARM.

-Michael

[...]

(apparently it went into FPC list anyway)

For RS485 adaptation, use a MAX232 like chip (to convert +-12 to ttl)
and then a RS485 transceiver chip;

A MAX232 has 4 [IIRC] level changers, 2 in each direction; so you can use one pair to convert tx/rx, and one of the remaining ones in 232-ttl direction, to convert one RS232 signal to switch the RS485 trx into 'sending' mode;

Of course you need an additional +5V supply to the above too.

HTH,
-L.

Lukasz Sokol wrote

For RS485 adaptation, use a MAX232 like chip (to convert +-12 to ttl) and then a RS485 transceiver chip;

If you want to create hardware anyway, better use a PIC24 (pr PIC32) chip with USB plus a RS485 tranceiver chip. So you get rid of the " ATEN usb-to-serial cable (UC-232A)" and you have both sides of USB under your control so that you can do the USB procedure you want.

Another way is using a pre-programmed PIC chip available by Microchip with USB to-Serial software plus a RS485 tranceiver chip.

-Michael

Al 04/07/13 12:08, En/na Dennis Poon ha escrit:

thanks. I am not using the fpc email as it seems off topic. May I know the exact brand and model number of the adapter you used?

I don't know the exact model, but it is one of these

http://vscom.de/1_1_09.htm

however there are other brands that should work equally well

I have an ATEN usb-to-serial cable (UC-232A) but I am not sure how to connect its serial pins to rs-485 's DIFFERENTIAL LINES and how to set that adapter into half-duplex translation mode.

That's not good: you'll need a level converter (which will probably cost more than an usb to rs485 adapter) *and* use one of the control pin to commute between tx/rx, the problem is, when you transmit you don't know when the last bit exits the serial port, so you cannot reliably control the switching pin. An usb<->485 adapter usually does it all by itself at the right time.

Bye

Al 04/07/13 12:24, En/na Michael Schnell ha escrit:

But the problem might be that they don't come with a Linux driver for ARM.

Since the driver for prolific/ftdi usb to serial bridge (which is the one these adapters use) is in the kernel since, like, forever, it will work with any architecture.

Bye

My favorite is the USB-RS485-WE-1800-BT made by FTDI. It is sold by many companies:
http://www.ftdichip.com/Products/Cables/USBRS485.htm

It supports 24000 baud which many other adapters don't.

I've only used it under Windows but as it is made by FTDI I would think using it under Linux should be no problem.

www.CtrlTerm.com has Synapse and SynaSer code that should work on the RPi (for serial and TCP/IP communication) as I did test that recently. Please let me know if you have any problems and I will do further testing on my RPi.

+1 if OP wants to create his own hw and sw for that purpose

Another way is using a pre-programmed PIC chip available by Microchip with USB to-Serial software plus a RS485 tranceiver chip.

+1 if OP wants to use standard hw...

-L;

Luca Olivetti wrote

Since the driver for prolific/ftdi usb to serial bridge (which is the one these adapters use) is in the kernel since, like, forever, it will work with any architecture.

I do know that there is a "standard" for how many USB-to-serial adapters work. But in fact I also know that some don't adhere to that.

In fact I only did a research on that for Windows. Here the "standard" driver by Microsoft works with many adapters, but it lacks some features (e.g. allowing the software to handle DSR/DTR). But e.g. the W&T devices come with their own driver that can do this. I don't know whether they also can work with the standard driver, if DSR/DTR are not necessary.

-Michael

Discussion elsewhere suggests that the RPi has an internal 16550 port, and controlling the 485 signals using e.g. CTS might be viable.

In any event, my experience is that USB->serial converters are very poor for anything that involves accurate timing, and I suspect that controlling a 485 transceiver in conjunction with one would be problematic. I think I asked FTDI about this a couple of years ago, and was told that their hardware had facilities that would help but exploiting them would take a non-standard driver.

Yeah I seem to remember http://www.hobbytronics.co.uk/raspberry-pi-gpio-pinout I guess for 485 direction setting, one of GPIO will need to be used; Sigh. Why do people keep reinventing ethernet starting from half duplex without galv. separation ? :)

Well that's a question of OP's project goals agenda...

-L;

Al 04/07/13 17:24, En/na Mark Morgan Lloyd ha escrit:

In any event, my experience is that USB->serial converters are very poor for anything that involves accurate timing, and I suspect that controlling a 485 transceiver in conjunction with one would be problematic.

Not if the converter manages the rx/tx switching all by itself

I think I asked FTDI about this a couple of years ago, and was told that their hardware had facilities that would help but exploiting them would take a non-standard driver.

The ones I used worked with the standard driver: send something, it automatically enables the transmitter, after the last bit has been transmitted it goes in high impedance mode ready for listening/receiving.

Bye

Yes, but I was considering the case of using an off-the-shelf USB->RS232 device, followed by an RS232->RS485 converter (OP's note of this morning).

A couple of years ago I was reverse-engineering the protocol used by some HP protocol analysers (so that I could use them for reverse-engineering protocols...) and my initial hack used a couple of standard USB devices. Unless I slowed the data stream right down (300 Baud) the driver buffering messed things up to the extent that I couldn't determine where there were gaps, let alone measure them so I could work out what the timeouts were.

Hi,

Can this thread please be moved to the fpc-other list?

Thanks,

Jonas
FPC mailing lists admin

Mark Morgan Lloyd wrote

In any event, my experience is that USB->serial converters are very poor

Same here !

Standard USB stuff is not really suitable for embedded use.

Due to electrical disturbances the data on the USB line can be corrupted and the link between host and device can be lost. In that case the _device_ needs to initialize a reconnection. The host can't do that because the protocol does not offer this option. But OTOH in many cases the device can't detect that the link is lost at the host. You can help this by doing your own software in the device and implement a life check protocol. But Standard devices don't feature this.

-Michael

Here is my favorite USB to RS-232 serial adapter (4 port, sold at Amazon, has FTDI chipset):
http://www.gearmo.com/shop/gm-ftdi4x/
This worked on my RPi.