What I did: Simple oscilloscope measurement of ATtiny speed.
I triggered the interrupt input of the ATtiny84 on pin9 externally and let the ISR switch digital output pin 7 HIGH. The Void loop pulls that output low then. And the loop adds two pulses as fast as it can.
I documented the time results in the oscillogram.
About 100µs from trigger to output HIGH.
I could not hide a tiny disappointment.
Is it plausible? Could I expect more?
ATtiny84-Test-Speed-Interrupt-2020-08-23.ino (1.13 KB)
ISR (PCINT0_vect) { // interrupt service
//digitalWrite(6,1); // 1 pulse Pin7 = 6
PORTA |= _BV(PA6);
a=0; // 0 = loop enable
}
Fuses?
ATtiny84-tools-menue.jpg: "Bootloader brennen" gedrückt?
Ich bin mir ziemlich sicher, daß nicht.
Kein Unterschied, ob ich internal 1MHz oder internal 8MHz einstelle.
Fuses geschrieben, oder alternativ, den Takt im Programm umgestellt?
Einfach nur im Menue umstellen reicht nicht.
Das weiß ich noch nicht, wie das geht.
Erst mal habe ich ein Einfachst-Programm geschrieben, das nichts weiter macht als im Loop einen Ausgang 1-0-1-0-1-0 zu schalten. Keine Interrupt, kein gar nix. Und wieder 62µs für einen positiven Puls 1-0. Das ist doch eine Zeit, in der UNO einen ganzen ADC-Zyklus abarbeitet.
Was hat es mit den Fuses auf sich? Wo kann ich mich da schlau machen?
Ah. Verstehe so langsam. Ich hatte falsch verstanden. Dachte "Bootloader brennen" muß ich vermeiden. Jetzt habe ich das vor dem Upload geklickt und siehe da: 8x schneller. Hammä! Wahnsinn! 7,8µs für einen pos Puls. Ziemlich genau ein Achtel von den 62µs vorher.
Habe noch einen Vergleich mit einem 328er @16MHz durchgeführt: 4µs. Das ist stimmig.
Ich habe zu viel erwartet. In digitalWrite() ist offenbar mehr Overhead als der kleine Sparkassenkunde so vermutet.
Combie, Sie haben mir weitergeholfen. Vielen Dank.
Auch die Interrupt-Reaktionszeit des ATtiny84@8MHz ist jetzt 8x kürzer: 11,8µs (vom Triggersignal am Interrupteingang bis Flanke am Output) . Damit läßt sich was anfangen. Danke.
Ja, so war es gemeint.
sieben:
In digitalWrite() ist offenbar mehr Overhead als der kleine Sparkassenkunde so vermutet.
Dagegen kann man was machen. Die Bibliothek CombiePin von combie hilft, allerdings weiß ich nicht, ob das auch für den ATtiny84 gilt.
Noch schneller geht es mit Assembler, hat mir eine vertrauenswürdige Person erzählt.
Noch schneller geht es mit Assembler, hat mir eine vertrauenswürdige Person erzählt.
Dazwischen ( Assembler -- Arduino digitalWrite ) liegt noch normales C/C++ für den avr-gcc Compiler.
Was man in diesem Fall praktisch genauso schnell wie Assembler machen kann.
CombiePin ist komplett in C++ geschrieben, richtig?
CombiePin ist komplett in C++ geschrieben, richtig?
Ja!
Die Bibliothek CombiePin von combie hilft, allerdings weiß ich nicht, ob das auch für den ATtiny84 gilt.
Nicht wirklich, wäre aber anpasssbar.
Ich meine, Doc_Arduino hat das schon gemacht
Auf jeden Fall ist seine Anpassung da ganz dicht dran.
Noch schneller geht es mit Assembler, hat mir eine vertrauenswürdige Person erzählt.
Noch schneller, als mit meiner Lib?
:o :o :o :o :o
combie:
Noch schneller, als mit meiner Lib?
:o :o :o :o :o
So war meine Vorstellung, in der Tat. Wenn es nicht so sein sollte, bitte ich gnädigst um Nachsicht :-[
So war meine Vorstellung, in der Tat.
Die Grundmethoden meiner in C++ geschriebenen Pin Library, liegen mit handgedengeltem Assembler gleichauf.
#include <CombiePin.h>
using Led = Combie::Pin::OutputPin<13>;
void setup()
{
Led().init();
}
void loop()
{
Led().toggle();
delay(500);
}
Die Instanzbildung wird übrigens weg optimiert.
Hier auch:
#include <CombiePin.h>
Combie::Pin::OutputPin<13> led;
void setup()
{
led.init();
}
void loop()
{
led.toggle();
delay(500);
}
Der generierte Code ist identisch mit
void setup()
{
DDRB |= _BV(PB5);
}
void loop()
{
PINB = _BV(PB5);
delay(500);
}
Wenn es nicht so sein sollte, bitte ich gnädigst um Nachsicht
Gewährt!
Natürlich können die Klassen noch ein paar andere Dinge, die etwas aufwändiger sind
z.B. led = true; // led erleuchten
Hallo,
zufällig mitgelesen. 
Die combiePin Lib habe ich um einen ATtiny841 ergänzt. Dem zu Grunde liegt die Pinnummierung von SpenceKonde.
Normalerweise benötigt man zur Codegenerierung den Ziel Controller, für die hinterlegte Tabelle. Ich lehne mich einmal aus dem Fenster. Bei Bedarf könnte man das Forumsübergreifend erstellen, falls es widererwartend zu Fuss zu fehlerträchtig ist.
Wie programmierst du den ATtiny84 überhaupt? Ist ja nicht standardmäßig in der IDE enthalten.
Oder verwendest du das Package von GitHub - SpenceKonde/ATTinyCore: Arduino core for ATtiny 1634, 828, x313, x4, x41, x5, x61, x7 and x8
Nebenbei, im Test befindet sich die combiePin Lib für einen ATmega4809, für einen Arduino Nano Every.
Die combiePin Lib habe ich um einen ATtiny841 ergänzt.
Genau, der wars...
Den habe ich jetzt auch mal eingeflochten.
Ebenso den MD-328D.
Und auch einen Fallback, so dass die Pin Sammlung mit allen nicht direkt unterstützten Plattformen arbeiten kann.
Dann zwar ohne jede besondere Optimierung.
Die müssen für jede Plattform einzeln hinzuerfunden werden.
CombiePin.zip (309 KB)
Hallo,
schön, dann muss ich den nicht jedesmal neu hinzufügen bei Updates. Mal schauen wie du die Inkluderei gelöst hast.
Ja, ein Define Grab ist es geworden.
Die Tiny841 Aspekte sind auch noch nicht getestet. Mangels Chip.
Aber ich hoffe, dass ich Raum geschaffen habe, für zukünftige Spezialisierungen.
So auch für den Tiny84 aus diesem Thread.
Hallo,
die Inkluderei ist doch okay so. Das ATtiny841.h Headerfile ist noch das Gleiche wie damals von mir, da sehe ich keine Probleme. Ich werde es bei nächster Gelegenheit testen.
Hallo,
habe kreuz und quer getestet und keine Fehler feststellen können. Da die eigentlichen Methoden und Registeradresstabelle auch nicht verändert wurden, kann ich das mit ruhigen Gewissen "absegnen".