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
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
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?
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
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 ?
Trying to do some ISO-9141 (car ECU) communications, and i need to send a 5-baud start sequence which is done with:
pinMode(TX0, OUTPUT);
pinMode(RX0, INPUT);
digitalWrite(TX0, HIGH);
....
Serial.begin(10400);
BR
Thanks for your response. Looked up that code, very interesting
The "code" was so what i meant could be understood, not a sketch!
Here is the full code for the function:
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
Ouch, I meant that iso code
Going to have a look at your code, though
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:
BR
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
Bi0H4z4rD:
Ouch, my missunderstanding too i guessAnyway 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:
GitHub - Magister54/opengauge: Automatically exported from code.google.com/p/opengauge
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
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
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.
Thanks stimmer, will definitely try this out and post results as soon as i do it.
BR
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.
thanks for your reply aethaniel
what i want to send is 8N1 bits at 5bps (baudrate), not 5 bits
I'm still up to testing it, which should happen sometime before sunday.
BR
oooops i read a bit fast your posts, sorry.
I have found what i was looking for:
USART2->US_CR = US_CR_TXEN;//Enables USART2 TX
USART2->US_CR = US_CR_RXEN;//Enables USART2 RX
USART2->US_CR = US_CR_TXDIS;//Disables USART2 TX
USART2->US_CR = US_CR_RXDIS;//Disables USART2 RX
But now i find that if i have set the pins as digital previously like this:
pinMode(16, OUTPUT);
pinMode(17, INPUT);
the USART2 wont start, and will stay in LOW status, and therefor, not read anything.
Any clues on how to solve that?
I already tried the
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)
and it didnt do the job.
BR
Now, this is weird...
This code:
#define IN 17 //RX2
#define OUT 16 //TX2
void setup(){
Serial2.begin(115200);
Serial.begin(115200);
Serial2.print("123456");
delay(1000);
USART2->US_CR = US_CR_RXDIS;
USART2->US_CR = US_CR_TXDIS;
pinMode(OUT, OUTPUT);
pinMode(IN, INPUT);
delay(1000);
digitalWrite(OUT, HIGH);
delay(200);
digitalWrite(OUT, LOW);
delay(200);
digitalWrite(OUT, HIGH);
delay(200);
digitalWrite(OUT, LOW);
delay(1400);
USART2->US_CR = US_CR_TXEN;
USART2->US_CR = US_CR_RXEN;
Serial2.print("123456");
delay(20);
Serial2.print("123456");
Serial.print("Done");
}
void loop(){}
Gives the following response:
Uploaded with ImageShack.us
The red square represents the first (one time) "Serial2.print("123456");".
Any clues of what might be happening here?
BR
Serial2 is USART1, not USART2.