[En-Nut-Discussion] Ethernut 2, RS485 on UART1

Douglas Pearless Douglas.Pearless at pearless.co.nz
Wed Nov 10 04:59:31 CET 2004


And another trap for the unwary,

I seems that NUT/OS takes about 2 characters at 115k on the RS485 network to
swap from transmit back to receive mode, so you need to ensure that the
slaves do not start transmitting too soon or you lose the first 2 bytes of
their transmission!!!

Douglas

-----Original Message-----
From: en-nut-discussion-bounces at egnite.de
[mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of Douglas Pearless
Sent: Wednesday, 10 November 2004 11:01 a.m.
To: Douglas.Pearless at pearless.co.nz; 'Ethernut User Chat (English)'
Subject: RE: [En-Nut-Discussion] Ethernut 2, RS485 on UART1

Well, 

I found the problem, the clue was in the posting from Zheng Anding on
Friday, 14 May 2004 7:45 a.m.

I was using &devUart0, &devUart1 NOT &devUsartAvr0, &devUsartAvr1.

Made that change, and viola, I worked!

Douglas.

-----Original Message-----
From: en-nut-discussion-bounces at egnite.de
[mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of Douglas Pearless
Sent: Wednesday, 10 November 2004 9:37 a.m.
To: Douglas.Pearless at pearless.co.nz; 'Ethernut User Chat (English)'
Subject: RE: [En-Nut-Discussion] Ethernut 2, RS485 on UART1

Hmm,

Could someone who is familiar with using RS485 on the Ethernut comment on
why I don't seem to be able to get NUT/OS to toggle PD5 so the RS485 driver
works properly in half duplex.

I'd REALLY appreciate some pointers...

#include <string.h>
#include <stdio.h>
#include <io.h>
#include <dev/uartavr.h>
#include <dev/usartavr.h>
#include <sys/timer.h>
#include <sys/thread.h>

static char *banner = "\nNut/OS UART Sample\n";

static char inbuf0[4];
static char inbuf1[4];

int main(void)
{
    int i;
	int UART1_USART_MF_HALFDUPLEX = USART_MF_HALFDUPLEX;
	unsigned char ch, ch0, ch1, ch2, ch3;
    u_long baud = 115200;
    u_long vertigo_baud = 115200;
	FILE *uart0, *uart1;

    //	Set up PD5 as the UART1 direction bit, high for transmit, low for
receive.
//    DDRD |= BIT(5);  // make an output
//    PORTD &=~BIT(5); // set low (listen to the BUS)

    NutRegisterDevice(&devUart0, 0, 0);
    uart0 = fopen("uart0", "r+b");
    _ioctl(_fileno(uart0), UART_SETSPEED, &baud);

    NutRegisterDevice(&devUart1, 0, 0);
    uart1 = fopen("uart1", "r+b");
    _ioctl(_fileno(uart1), UART_SETSPEED, &vertigo_baud);
	//In the NUT/OS configurator we set PORTD and pin 5 for half duplex
on UART1, so this should set
	//UART1 up correctly????
	//prevously not doing this and manually toggling PD5 sort of worked,
but not reliabily
	//BUT this doesn't seem to work at all!!!!
	i = _ioctl(_fileno(uart1), UART_SETFLOWCONTROL,
&UART1_USART_MF_HALFDUPLEX);
	// we always get i==0 as the return code from the above
	
	NutSleep(100);

    _write(_fileno(uart0), banner, strlen(banner));
    fflush(uart0);
	
    for(i = 0;; i++) {
      fputs("\n\rCMD for Vertigo ? ", uart0);
      fflush(uart0);
	  fgets(inbuf0,sizeof(inbuf0),uart0);
	  //so what did we get?
	  switch (inbuf0[0]) {
	  case '0': //trigger ignore the rest of the buffer
	  	   UCSR1A |= BIT(MPCM1); //turn on to send address to a
slave to get its attention
	  	   fputc(0x00,uart1);
		   fflush(uart1);

//		   UCSR1A &= ~BIT(MPCM1); //turn off to send data to a slave

	  	   break;
	  case '1': //get back the data
//		   PORTD |= BIT(5); // set high to transmit 
	  	   UCSR1A |= BIT(MPCM1); //turn on to send address to a
slave to get its attention
	  	   fputc(0x01,uart1); // address of first slave
		   fflush(uart1);
		   UCSR1A &= ~BIT(MPCM1); //turn off to send data to a slave
	  	   fputc(0x01,uart1); // command to send its data to us
		   fflush(uart1);
	  	   fputc(0x01,uart1); // dummy data byte
   	  	   UCSR1A |= BIT(MPCM1); //turn on to receive OUR address
from a slave to get its attention
//		   PORTD &= ~BIT(5); // set low to receive
		   fflush(uart1);
		   ch0 = fgetc(uart1); // our address (ignore this for the
moment)
		   UCSR1A &= ~BIT(MPCM1); //turn off to receive data from a
slave
		   fputc(ch0,uart0);
		   ch1 = fgetc(uart1); // data byte 1
		   fputc(ch1,uart0);
		   ch2 = fgetc(uart1); // data byte 2
		   fputc(ch2,uart0);
		   ch3 = fgetc(uart1); //data byte 3
		   fputc(ch3,uart0);
		   fflush(uart0);
	  	   break;
	  }
    }
}

-----Original Message-----
From: en-nut-discussion-bounces at egnite.de
[mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of Douglas Pearless
Sent: Tuesday, 9 November 2004 10:22 p.m.
To: Douglas.Pearless at pearless.co.nz; 'Ethernut User Chat (English)'
Subject: RE: [En-Nut-Discussion] Ethernut 2, RS485 on UART1

Hmm,

I have got a little further, reading the nut library code.

I think this is on the right track?

    NutRegisterDevice(&devUart1, 0, 0);
    uart1 = fopen("uart1", "r+b");
    _ioctl(_fileno(uart1), UART_SETSPEED, &vertigo_baud);
	_ioctl(_fileno(uart1), USART_MF_HALFDUPLEX, &something);

BUT what should &something point to? How do I get it to toggle PD5?

How can I use the ioctl to set / reset the MPCM bit in UART1 to enable /
disable the address vs data mode???

Any ideas?

Douglas

-----Original Message-----
From: en-nut-discussion-bounces at egnite.de
[mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of Douglas Pearless
Sent: Monday, 8 November 2004 8:22 p.m.
To: Douglas.Pearless at pearless.co.nz; 'Ethernut User Chat (English)'
Subject: RE: [En-Nut-Discussion] Ethernut 2, RS485 on UART1

I forgot to add, I use addressing (MPCM bit) to send 1 address byte and then
1 command byte and then 0 to 4 data bytes, depending on the command.
It seems as though only the address byte sometimes gets through, other
times, the address byte is repeated the same number of times as the total
number of bytes I send from the ATMega16, weird.

Douglas

-----Original Message-----
From: en-nut-discussion-bounces at egnite.de
[mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of Douglas Pearless
Sent: Monday, 8 November 2004 8:14 p.m.
To: 'Ethernut User Chat (English)'
Subject: [En-Nut-Discussion] Ethernut 2, RS485 on UART1

Hi,

Has anyone got some code that works for this???

I have an Ethernut talking to a ATMega16.  My raw code on the ATMega16
transmits the data correctly, but the Ethernut seems to get a bit messed up.

I have tried to understand how the NUT/IS handles it (read usart1avr.c,
usuartavr.c. uart.h etc) but can't quite get it to work.

Does anyone have some sample code I can review to assist with my
understanding?

HELP!

Douglas 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.788 / Virus Database: 533 - Release Date: 1/11/2004
 

_______________________________________________
En-Nut-Discussion mailing list
En-Nut-Discussion at egnite.de
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.788 / Virus Database: 533 - Release Date: 1/11/2004
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.788 / Virus Database: 533 - Release Date: 1/11/2004
 

_______________________________________________
En-Nut-Discussion mailing list
En-Nut-Discussion at egnite.de
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.788 / Virus Database: 533 - Release Date: 1/11/2004
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.791 / Virus Database: 535 - Release Date: 8/11/2004
 

_______________________________________________
En-Nut-Discussion mailing list
En-Nut-Discussion at egnite.de
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.791 / Virus Database: 535 - Release Date: 8/11/2004
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.791 / Virus Database: 535 - Release Date: 8/11/2004
 

_______________________________________________
En-Nut-Discussion mailing list
En-Nut-Discussion at egnite.de
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.791 / Virus Database: 535 - Release Date: 8/11/2004
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.791 / Virus Database: 535 - Release Date: 8/11/2004
 

_______________________________________________
En-Nut-Discussion mailing list
En-Nut-Discussion at egnite.de
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.791 / Virus Database: 535 - Release Date: 8/11/2004
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.791 / Virus Database: 535 - Release Date: 8/11/2004
 




More information about the En-Nut-Discussion mailing list