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.
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 ?
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.
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
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.
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.
I changed it from USART2 to USART1, but still getting exactly the very same thing on the LA.
The weird thing is that it does the "LOW/HIGH" thing before serial printing "123456" for the first time, while that is supposed to go after printing it.
You mean K-Line I think so you have the same Problem I have with L-Line and the USART may you can use an K-Line Transciever and the Lin support from the SAM.