An interesting Observation

While tinkering i thought i would test out the capabilities on the Duemilanove, this is that i found, using the blink sketch example and taking out the delays pin 13 toggles at 126.2Khz, nothing exciting there but talking to pin 13 direct

void setup()
{                
DDRB=255;
}

void loop()                     
{
  PORTB =32;
  PORTB = 0;
}

and pin 13 toggles at 1.223Mhz now that is interesting.
so it take 13 clock cycles to execute the above code, i bet doing the same in ASM will toggle pin 13 even faster,
oh well bored testing that now, just thought i’d mention it

Yeah, Direct Port Manipulation is about 10x faster than using digitalWrite().

Thanks for providing those specific numbers, though :).

Try this one:

void setup()
{
DDRB=0xFF;
}

void loop()
{
  PORTB ^=32;
}

I’m not sure if it works this way, but should toggle the bit at 8Mhz

Thanks Senso, yeah i did it toggled at 567.9khz & 51% Duty

wher as
PORTB =32;
PORTB = 0;
toggle at 40% duty
??? strange

i think it’s interesting from a comunication point of view, not only infrared in the 10’s khz range but maybe point to point laser in 100’s khz range

Is your arduino running with the internal rc oscillator?

no the 16mhz external onboard

try

void setup() {
  unsigned char highval = 32;
  unsigned char lowval = 0;
  DDRB = 0xFF;
  asm volatile (
    "ioloop:\n\t"
    "out %[portb], %[highval]\n\t"
    "out %[portb], %[lowval]\n\t"
    "rjmp ioloop\n\t"
    :
    : [portb] "i" (_SFR_IO_ADDR(PORTB)),
    [highval] "a" (highval),
    [lowval] "a" (lowval)
    :
  );
}

void loop(){
}

Should result in 4mhz at 25% duty

Very good mdmetzle
Yes 3.974 Mhz @ 55% Duty

You someone rewrite the digitalWrite method to accept port names? Ot seems odd that such a problem could exist in the first place.

it’s not a problem graymalkin, it’s just the way compilers work by including so much useless code into the resulting hex file, normally speed isn’t a problem in everyday coding but there are situations where speed is everything and timing is critical which is where assembly code and talking to the hardware direct is useful.

I think your missing the point of the Arduino I/O statements. They were able to build in a abstraction of the I/O port/pin addresses and there secondary functions. That results in having Arduino pin 13 be the same regardless of what port and pin or special additional features a specific AVR processor I/O pin has. Therefore it becomes portable over the Arduino board offerings. Their thought was this abstraction would be easier for non-programmers to start with. However one is free to utilize direct port access to I/O pins at the expensive of portability. It’s convenient to be able to have the choice, as direct I/O can be beneficial at times, as say inside a ISR function where code speed is important.

Lefty

I don’t think that the abstraction should be removed, but it would be nice for there to be the option to skip past it with preference to speed, eg digitalWrite(PortName, state, 1) to be an override of digitalWrite(PinNumber, State)

I don’t think that the abstraction should be removed, but it would be nice for there to be the option to skip past it with preference to speed, eg digitalWrite(PortName, state, 1) to be an override of digitalWrite(PinNumber, State)

I do believe the Arduino team is working on a fast digitalRead and write functions. possibly released with the version 1 project?

Lefty

I hope no-one thinks im running down the Arduino developers or digitalwrite, im not, all i did was see how fast one pin could switch and ways to make it go faster, i used to be a PIC fan and still am but since getting two duinos and a bunch of shields i now really like the platform for ease of development