next topic »

[on:]

On the 8bit AVR you would use the "UCSR2B &= ~(_BV(RXEN2))"  command to disable a serial port on it (USART2 in this case).

Does anyone know how to do the same thing with Due?

BR

[Reply #1 on:]

what do you mean by disabling a serial port?

I'm not expert in AVR but I know that all peripherals are clocked by default, so consuming power even if not used.

I know a bit more the SAM3X and in its case the peripherals are not clocked by default.
This means that all pins are dedicated to General Purpose I/O Controller and not to a multiplexed peripheral (like USART).
Thus, the pins need to declared as being used by a peripheral to be used and the peripheral to be clocked before any use.

Am I guessing right what is behind your question?

[Reply #2 on:]

Thanks for your reply aethaniel

What i mean is, that i want to send some data over serial, then disable serial on the pins that it uses for it (lets say 0 and 1 of the Due board for USART0), and enable those pins as digital pins to do some stuff, and after the digital stuff is done, then turn back on the serial.

BR

[Reply #3 on:]

Sorry for the silly question, but what's connected to those pins ? Doesn't the DUE have enough GPIO pins to avoid going down that (seems to me) overly complicated path ?

[Reply #4 on:]

Trying to do some ISO-9141 (car ECU) communications, and i need to send a 5-baud start sequence which is done with:

Code:

pinMode(TX0, OUTPUT);
pinMode(RX0, INPUT);

digitalWrite(TX0, HIGH);
....
Serial.begin(10400);

BR

[Reply #5 on:]

Thanks for your response. Looked up that code, very interesting

[Reply #6 on:]

The "code" was so what i meant could be understood, not a sketch!

Here is the full code for the function:

Code:

void iso_init()
{
  long currentTime = millis();
  static long initTime;
  switch (ISO_InitStep)
  {
    case 0:
      // setup
      ECUconnection = false;
      serial_tx_off(); //disable UART so we can "bit-Bang" the slow init.
      serial_rx_off();
      initTime = currentTime + 3000;
      ISO_InitStep++;
      break;
    case 1:
      if (currentTime >= initTime)
      {
        // drive K line high for 300ms
        digitalWrite(K_OUT, HIGH);

        initTime = currentTime + 300;
        ISO_InitStep++;
      }
      break;
    case 2:
    case 7:
      if (currentTime >= initTime)
      {
        // start or stop bit
        digitalWrite(K_OUT, (ISO_InitStep == 2 ? LOW : HIGH));
        initTime = currentTime + (ISO_InitStep == 2 ? 200 : 260);
        ISO_InitStep++;
      }
      break;
    case 3:
    case 5:
      if (currentTime >= initTime)
      {
        // two bits HIGH
        digitalWrite(K_OUT, HIGH);

        initTime = currentTime + 400;
        ISO_InitStep++;
      }
      break;
    case 4:
    case 6:
      if (currentTime >= initTime)
      {
        // two bits LOW
        digitalWrite(K_OUT, LOW);

        initTime = currentTime + 400;
        ISO_InitStep++;
      }
      break;
    case 8:
      if (currentTime >= initTime)
      {


        // bit banging done, now verify connection at 10400 baud
        byte b = 0;
        // switch now to 10400 bauds
        Serial.begin(10400);

        // wait for 0x55 from the ECU (up to 300ms)
        //since our time out for reading is 125ms, we will try it up to three times
        byte i=0;
        while(i<3 && !iso_read_byte(&b))
        {
          i++;
        }

        if(b == 0x55)
        {
          ISO_InitStep++;
        }
        else
        {
          // oops unexpected data, try again
          ISO_InitStep = 0;
        }
      }
      break;
    case 9:
      if (currentTime >= initTime)
      {
        byte b;
        bool bread;
      
        bread = iso_read_byte(&b);  // read kw1

    
        bread = iso_read_byte(&b);  // read kw2


        // 25ms delay needed before reply (url with spec is on forum page 56)
        // it does not work without it on VW MK4
        delay(25);
      
        // send ~kw2 (invert of last keyword)
        iso_write_byte(~b);

    
        // ECU answer by 0xCC (~0x33)
        // read several times, ECU not always responds in time
        byte i=0;
        bread = iso_read_byte(&b);
        while (i<3 && !bread)
        {
          i++;
          bread = iso_read_byte(&b);
        }
      
        if (b == 0xCC)
        {
           ECUconnection = true;

        }
        ISO_InitStep = 0;
      }
      break;
  }

void serial_rx_off()
{
  UCSR0B &= ~(_BV(RXEN0));  //disable UART RX
}

void serial_tx_off()
{
   UCSR0B &= ~(_BV(TXEN0));  //disable UART TX
   delay(20);                 //allow time for buffers to flush
}

I need to replicate the last two functions ( serial_tx_off() and serial_rx_off() ) on Due in order for this to work.

BR

[Reply #7 on:]

Ouch, I meant that *iso* code

Going to have a look at your code, though

[Reply #8 on:]

Ouch, my missunderstanding too i guess 

Anyway code is not mine, im just modding it to do some other stuff, but that's the part i need to get working.

If you want to see the full project for the code i have posted, you can find it here:

http://code.google.com/p/opengauge/wiki/OBDuino

BR

[Reply #9 on:]

Section 29.2.2 of the SAM3X datasheet and block diagram in section 29.2.3 suggest peripheral clocks can be independently disconnected. So I guess one way to "turn off" an USART would be to disable its clock.

Disclaimer: just thinking out loud, I've just skimmed the datasheet

[Reply #10 on:]

Ouch, my missunderstanding too i guess 

Anyway code is not mine, im just modding it to do some other stuff, but that's the part i need to get working.

If you want to see the full project for the code i have posted, you can find it here:

http://code.google.com/p/opengauge/wiki/OBDuino

BR

Hey, that's a nice project! Think I've googled you up a couple years ago

Getting some data off that OBD connector hidden somewhere under my steering wheel is one of the things I'd like to do sooner or later... Just bookmarked your project

[Reply #11 on:]

Thanx for the reply! That code/project is not mine, i am using parts of its code to do some other stuff, like reading ecu sw info and other service operations.

Anyway, i found some bugs in that code which are now corrected (and tested) and enable fast init, aswell as the bitbang for a more standard 9600bps communication speed instead of 10400bps.

Just for the record:



Uploaded with ImageShack.us

BR

[Reply #12 on:]

The SAM3X has registers PIO_PER and PIO_PDR which control whether a pin is used as a digital output or by a peripheral:

g_APinDescription[pin].pPort -> PIO_PER = g_APinDescription[pin].ulPin;  (pin is digital io)
g_APinDescription[pin].pPort -> PIO_PDR = g_APinDescription[pin].ulPin;  (pin is peripheral)

Posting this in the hope that it just works - if it does, great, if not then you're probably going to need to study the datasheet.

[Reply #13 on:]

Thanks stimmer, will definitely try this out and post results as soon as i do it.

BR

[Reply #14 on:]

hi Bi0H4z4rD,

sorry for late reply on this but yes, you should use what stimmer suggested you. This is the only way to assign a pin either to GPIO multiplexing or to a peripheral.

by the way, if you want to send 5bit frames, maybe are you able use the USART with the proper configuration. That way you won't have to do it manually:

36.2 Embedded Characteristics
• Programmable Baud Rate Generator
• 5- to 9-bit Full-duplex Synchronous or Asynchronous Serial Communications

I didn't check deeply the DS, so maybe am I wrong.