Hola svalls,

La velocidad máxima del 2560 es 16Mhz, no 20Mhz -->http://www.atmel.com/devices/atmega2560.aspx

A ver si nos cuentas que tal lo llevas!

Un saludo

Tu profesor es un troll.

Si miras las datasheet del 328p y del mega2560, verás que la frecuencia máxima es 16MHZ, y la frecuencia se puede dividir, pero nunca multiplicar, ya que no puedes dar mas de lo que tienes!


Un saludo

Si estas seguro de que el mando funciona a 433MHZ, compras un receptor de código manchester en ebay que funcione a la misma frecuencia, y haces un sketch que lea a 2400bps por el puerto serie y te muestre TODO lo que pilla.

Entonces pones el mando al lado del arduino, le das a reset al arduino, y sin soltarlo, pulsas el boton del mando. En ese momento y sin dejar de pulsar el mando, sueltas el reset, y debe de aparecerte una trama repetitiva de numeros en el terminal de puerto serie. Ese es tu código.

No obstante, deberías de repetir el proceso varias veces para ver si el código cambia, y si cambia, vete olvidando...


Un saludo y espero que sirva de ayuda.

PD: A todos los que quieren abrir puertas de garages, coches y demas, este método no funciona, ya que dichos automatismos utilizan rolling code.

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

BR

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

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

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

You cant do parallel tasking. Only one instruction can be active at a time, so if you want to do stuff until you receive data on serial for example, i would recommend to check from time to time if there is anything in the serial data buffer.

And dont worry, you would need to do pretty heavy stuff to slow down the due by using serial.

Best method: loop--->(Code, test, improve+research) until you are satisfied with results.

BR

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

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

[Serial]

You shouldnt need to use softserial on Due, since you already have 4 serial ports!

To select which one you want to send the command to, simply add the number of the serial port after the "Serial" state.

For example:

Serial.begin(9600); would affect TX0/RX0, since you didnt write a number.
Serial1.print("Hello"); would affect TX1/RX1.
Serial2.read(); would affect TX2/RX2.

I hope this helps!

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

Arm doesn't have PROGMEM.  In theory, the DUE ide should have defined all the PROGMEM 'keywords' as nothing and all of the <xxx>_P functions as <xxx>, but maybe they missed a few places.

If you are only programming on the Due, and no longer target the AVR based microprocessors, just take out the PROGMEM stuff.  If you need to run on both platforms, then you probably should do something like:

Code:

#if defined(__arm__) && !defined(PROGMEM)
#define PROGMEM
#define PSTR(STR) STR
#endif

You probably need more than that, depending on your program.

Ok, got the point! I am currently developing some stuff that should work on both platforms (for performance issues), so i'll stick to what you mention.

Thanks for the tips!

BR

Well, i have a sketch that passes the check and works on Mega2560 on 1.0.3 and 1.51, but i just tried to compile it for Due (with 1.51 ) and it is returning an error.

The error comes from this line of code:

Code:

const char ArduBytes[] PROGMEM = {0x32,0x11,0xE5,0x10,0x12};

The error that 1.51 returns is "expected initializer before 'PROGMEM'".

Is it a sw error or am i doing something wrong?

BR

I just hope they enable Analog Comparators on this one, because it would be simply hilarious to be able to use video experimenter on this one...


BR