As your topic does not relate directly to the installation or operation of the IDE it has been moved to the Programming Questions category of the forum
You should give a more comprehensive description of what "slow" means because that is always relative.
Try printing less often. At 1Mb/s, you can print 100,000 characters/second. The speed of your while-loop is probably faster than that and your serial buffer will fill up after which it slows down the complete process.
If you want to time it, call slowWrite() e.g. 1000 times, time that and print the result.
This does not matter.
The problem with array. If I write the functions separately within a function, the time is only 4 microseconds.
But 48 in Array loop......
The problem is not only in the array, but primarily in the for loop. At each iteration, you need to increment the variable, compare it with the limit, and make a transition from the end of the loop to the beginning. This all takes time, comparable to accessing pins. The fact that the cycle will be 2-3 times slower than direct writing to pins is normal.
However, the difference between 4 and 48us is too large. I think you didn't measure the time quite correctly. try repeating the tests several times and take the average:
microsec = micros();
// run test 12 times without loop
test.slowWrite(); test.slowWrite(); test.slowWrite(); test.slowWrite();
test.slowWrite(); test.slowWrite(); test.slowWrite(); test.slowWrite();
test.slowWrite(); test.slowWrite(); test.slowWrite(); test.slowWrite();
Serial.println((micros() - microsec)/12);
The library falls back to normal digitalWrite() when using an array.. I did not look too deeply into the reason why, it seems to be because you use a variable and not a value. I'll leave it up to the C/C++ specialists to explain more.
digitalWriteFast() is only able to use the "fast" technique when the pin number is known at compile time. Obviously, that's not the case when used with an array in a loop.
I was about to say that.
any who, in short, these processes take time, each process doesn't take very long, but all of the delays stack up and make a longer delay.
One could expect *foo to be evaluated once by the compiler and drop the xx thing, reasonable I think. I used digitalWrite() since it digitalWriteFast() reverts.
In the last few years, however, I would say any time I've tried to outwit the compiler I have failed, at the expense of less obscure code.
So the code below sets 5 pins HIGH then LOW on an Uno, in a loop, using direct port manipulation in under 12-16us. Not bad considering the loop and other overhead required.
I guess |= and &= are not atomic, so there's a possibility, albeit very small, that an interrupt routine could change the port bits between when this code reads them and updates them?
Does digitalWrite() also do this?
How long do interrupts() and noInterrupts() take?
Would it be better to remove these 2 lines when they are consecutive?
I think those are single-cycle instructions, then 62.5ns so a 16MHz AVR?
Yes, but I had assumed that the code from @r-istvan was just a demo and the real application needed an equivalent to digitalWrite(), not just toggling an output pin. If the latter is required, there are faster ways of doing it.