Der AVR-/ARDUINO-Faden
Moderatoren: Heaterman, Finger, Sven, TDI, Marsupilami72, duese
Re: Der AVR-/ARDUINO-Faden
stimmt, der hat 2 Analog pins mehr, aber kompiliert hab ich eh mit nano option.
dank euch, dann lass ich's erst mal so, bei gelegenheit bau ich mal nen 2x3 stecker für den programer.
dank euch, dann lass ich's erst mal so, bei gelegenheit bau ich mal nen 2x3 stecker für den programer.
Re: Der AVR-/ARDUINO-Faden
ich habe einen ATTINY13A, für den ich im Arduino Programm ein paar Assembler-Zeilen einfügen möchte.
wenn ich z.B. DDRB setzten möchte
kommt folgende Fehlermeldung:
"...Tiny13-button-led-ASM-Test.ino:52: undefined reference to `DDRB'"
Arduino kennt ja DDRB, aber warum nicht innerhalb vom Assembler-Schnipsel?
wenn ich z.B. DDRB setzten möchte
Code: Alles auswählen
asm volatile
(
"ldi r16, 0b00111111 \n"
"out DDRB, r16 \n")
"...Tiny13-button-led-ASM-Test.ino:52: undefined reference to `DDRB'"
Arduino kennt ja DDRB, aber warum nicht innerhalb vom Assembler-Schnipsel?
Re: Der AVR-/ARDUINO-Faden
Weil C/C++ defines nicht direkt im Assembler bekannt sind.Toni hat geschrieben: ↑So 22. Mai 2022, 00:08 ich habe einen ATTINY13A, für den ich im Arduino Programm ein paar Assembler-Zeilen einfügen möchte.
wenn ich z.B. DDRB setzten möchtekommt folgende Fehlermeldung:Code: Alles auswählen
asm volatile ( "ldi r16, 0b00111111 \n" "out DDRB, r16 \n")
"...Tiny13-button-led-ASM-Test.ino:52: undefined reference to `DDRB'"
Arduino kennt ja DDRB, aber warum nicht innerhalb vom Assembler-Schnipsel?
Und der ASM-Teil vor dem C/C++ Teil übersetz verwenden. Die genaue Reihenfolge sieht in der GCC Doku. Ich bin der Meinung das war defaultmässig ASM -> C -> C++
Im ASM gibt es dafür ein Prefix. Ich glaube du muss __DDRB schreiben.
Grüße Jan
Re: Der AVR-/ARDUINO-Faden
das mit Konstanten in ASM übernehmen habe ich nicht hinbekommen.
Die Register DDRB und PORTB direkt adressieren funktioniert aber
Hier ist ein Mischmasch mit ASM-Fetzen. LED an PB2 blinkt, solange Taster an PB4 gedrückt ist:
Die Register DDRB und PORTB direkt adressieren funktioniert aber
Hier ist ein Mischmasch mit ASM-Fetzen. LED an PB2 blinkt, solange Taster an PB4 gedrückt ist:
Code: Alles auswählen
const int buttonPin = 2; // the number of the pushbutton pin
int buttonState = 0; // variable for reading the pushbutton status
void setup() {
// initialize the pushbutton pin as an input:
pinMode(PB4, INPUT);
pinMode(PB4, INPUT_PULLUP); //configure pin 2 as an input and enable the internal pull-up resistor
// initialize the LED pin as an output:
// DDRB equ 0x17
asm
(
// alternativ: "ldi r16, 0b00001000 \n"
"ldi r16, 0x08 \n"
"out 0x17, r16 \n") // DDRB Bit 3 setzen
;
}
void loop() {
// read the state of the pushbutton value:
buttonState = digitalRead(PB4);
// check if the pushbutton is pressed. If it is, the buttonState is HIGH:
if (buttonState == LOW) {
// turn LED on:
// PORTB equ 0x18
asm (
"ldi r16, 0b00001000 \n"
"cbi 0x18, 3 \n" //clear Bit PB3
);
delay(500);
// turn LED off:
// digitalWrite(PB3, HIGH);
asm (
"ldi r16, 0b00001000 \n"
"sbi 0x18, 3 \n" //set Bit PB3
);
delay(100);
} else {
// turn LED off:
digitalWrite(PB3, LOW);
}
}
Re: Der AVR-/ARDUINO-Faden
das mit dem ATTINY habe ich hinbekommen: ich programmiere den komplett in Assembler mit Editor Gerd's AVM Simulator http://www.avr-asm-tutorial.net/avr_sim ... l#download, und schiebe es über einen USBasp https://www.fischl.de/usbasp/ mittels AVRDUDE auf den Tiny.
Aber zum Arduino Uno habe ich noch eine Frage. Ich möchte einen Drehzahlmesser bauen, und dazu diesen Code gefunden + angepasst:
Die Drehzahl sollte aus steigenden Flanken an Pin 2 berechnet, und angezeigt werden. Das Display zeigt aber immer "0" an. Evtl werden die Interrupts nicht ausgelöst??? Gibt's da noch eine extra Einstellung oder Fuses die gesetzt werden müssen?
Aber zum Arduino Uno habe ich noch eine Frage. Ich möchte einen Drehzahlmesser bauen, und dazu diesen Code gefunden + angepasst:
Code: Alles auswählen
//DIY Tachometer to Measure Accurate RPM using Arduino
//DIY Tachometer to Measure Accurate RPM using Arduino
//This code is published by https://www.circuitschools.com
//Attribution required to republish.
#include <LiquidCrystal.h>
LiquidCrystal lcd(8, 9, 4, 5, 6, 7); //Angabe der erforderlichen Pins
// Create the lcd object address 0x27(get it from i2cscanner) and 16 columns x 2 rows
// LiquidCrystal_I2C lcd (0x27, 16,2); //
float value=0;
float rev=0;
int rpm;
int oldtime=0;
int newtime;
void isr() //interrupt service routine
{
rev++;
}
void setup()
{
lcd.begin(16, 2); // Starten der Programmbibliothek.
// Turn on the backlight on LCD.
//lcd. backlight ();
attachInterrupt(digitalPinToInterrupt(2),isr,RISING); //attaching the interrupt
}
void loop()
{
delay(1000);
detachInterrupt(0); //detaches the interrupt
newtime=millis()-oldtime; //finds the time
int wings= 1; // no of wings of rotating object, for disc object use 1 with white tape on one side
int RPMnew = rev/wings; //here we used fan which has 3 wings
rpm=(RPMnew/newtime)*60000; //calculates rpm
oldtime=millis(); //saves the current time
rev=0;
lcd.clear();
lcd.setCursor(0,0);
lcd.print("Drehzahl U/Min :");
lcd.setCursor(0,1);
lcd.print( rpm);
lcd.print("");
lcd.print(" ");
attachInterrupt(digitalPinToInterrupt(2),isr,RISING);
}
-
- Beiträge: 138
- Registriert: So 9. Dez 2018, 11:30
Re: Der AVR-/ARDUINO-Faden
Ich vermisse eine Zeile die den pinMode setzt. Kann aber sein das das per Default auf Input steht und somit irrelevant ist.
Re: Der AVR-/ARDUINO-Faden
Zumindest die Variable Rev sollte "volatile" deklariert werden, ansonsten schmeißt der Compiler sie ersatzlos raus.....
Weiterhin: "detachinterrupt" scheint zumindest kein Arduino zu sein.
Ich würde das Aktivieren und deaktivieren des Interrupts über das globale SEI(); bzw CLI(); probieren, wenn das LCD nicht auch irgendwelche Interrupts benötigt.
Ansonsten Mal die Variable "Rev" in einem Timer-Interrupt hochzählen lassen zum Testen.
Vielleicht hilft's...
Weiterhin: "detachinterrupt" scheint zumindest kein Arduino zu sein.
Ich würde das Aktivieren und deaktivieren des Interrupts über das globale SEI(); bzw CLI(); probieren, wenn das LCD nicht auch irgendwelche Interrupts benötigt.
Ansonsten Mal die Variable "Rev" in einem Timer-Interrupt hochzählen lassen zum Testen.
Vielleicht hilft's...
Re: Der AVR-/ARDUINO-Faden
imho.
rev muss volatile.edit-hast ja schon geschrieben...
denn rest versteh ich wenig. was soll das ganze zeug im mainloop?
selbst mit millis (und nicht mit timer) geht das doch einfacher?:
hier nur mal grad rauskopiert der schnipsel.
edit. erst wird oldtime gesetzt, dann das zeitaufwändige lcd zeug gemacht, dann erst der interupt wieder angeschaltet?
und das soll das tun?
rev muss volatile.edit-hast ja schon geschrieben...
denn rest versteh ich wenig. was soll das ganze zeug im mainloop?
selbst mit millis (und nicht mit timer) geht das doch einfacher?:
Code: Alles auswählen
/////////MotorZustand//////////////////
tt = millis() - rpmTimeStamp;
if (tt >= 200) {
rPM = (float) rpmTicks * (float) 30000 / (float) tt;
rpmTimeStamp = millis();
rpmTicks = 0;
blabla....
edit. erst wird oldtime gesetzt, dann das zeitaufwändige lcd zeug gemacht, dann erst der interupt wieder angeschaltet?
und das soll das tun?
Re: Der AVR-/ARDUINO-Faden
Danke für euren Input. Leider kenne ich mich mit Arduino Sketch / C++ zu wenig aus -> ich hab's mit den Änderungen nicht hinbekommen
Hier habe ich ein anderes Programm gefunden https://srituhobby.com/ir-infrared-spee ... ed-sensor/, und das für meine Zwecke modifiziert (u.a. für dieses Display: https://www.berrybase.de/lcd/keypad-shi ... nlEALw_wcB ).
Das funktioniert jetzt
Die ursprünglichen Zeilen habe ich als // drin gelassen.
EDIT: Programmfehler korrigiert: ungenutzte Stellen RPM auf Display löschen, Pulses per Rev=1, Ansprechschwelle herabgesetzt
Hier habe ich ein anderes Programm gefunden https://srituhobby.com/ir-infrared-spee ... ed-sensor/, und das für meine Zwecke modifiziert (u.a. für dieses Display: https://www.berrybase.de/lcd/keypad-shi ... nlEALw_wcB ).
Das funktioniert jetzt
Die ursprünglichen Zeilen habe ich als // drin gelassen.
Code: Alles auswählen
#include <LiquidCrystal.h>
//#include <LiquidCrystal_I2C.h>
LiquidCrystal lcd(8, 9, 4, 5, 6, 7); //Angabe der erforderlichen Pins
// LiquidCrystal_I2C lcd (0x27, 16, 2);
const byte PulsesPerRevolution = 1;
const unsigned long ZeroTimeout = 1000000;
const byte numReadings = 2;
volatile unsigned long LastTimeWeMeasured;
volatile unsigned long PeriodBetweenPulses = ZeroTimeout + 1000;
volatile unsigned long PeriodAverage = ZeroTimeout + 1000;
unsigned long FrequencyRaw;
unsigned long FrequencyReal;
long Frequenz;
unsigned long RPM;
unsigned int PulseCounter = 1;
unsigned long PeriodSum;
unsigned long LastTimeCycleMeasure = LastTimeWeMeasured;
unsigned long CurrentMicros = micros();
unsigned int AmountOfReadings = 1;
unsigned int ZeroDebouncingExtra;
unsigned long readings[numReadings];
unsigned long readIndex;
unsigned long total;
unsigned long average;
void setup()
{
lcd.begin(16, 2); // Starten der Programmbibliothek.
lcd.setCursor(0,0); // Angabe des Cursorstartpunktes oben links.
//lcd.print(""); // Ausgabe des Textes "Nachricht".
attachInterrupt(digitalPinToInterrupt(2), Pulse_Event, RISING);
delay(1000);
}
void loop()
{
lcd.setCursor(12,1); // Bewegt den Cursor in Zeile 2 (Line0=Zeile1 und Line1=Zeile2) and die Stelle "12".
LastTimeCycleMeasure = LastTimeWeMeasured;
CurrentMicros = micros();
if (CurrentMicros < LastTimeCycleMeasure) {
LastTimeCycleMeasure = CurrentMicros;
}
FrequencyRaw = 10000000000 / PeriodAverage;
if (PeriodBetweenPulses > ZeroTimeout - ZeroDebouncingExtra || CurrentMicros - LastTimeCycleMeasure > ZeroTimeout - ZeroDebouncingExtra) {
FrequencyRaw = 0; // Set frequency as 0.
ZeroDebouncingExtra = 2000;
} else {
ZeroDebouncingExtra = 0;
}
FrequencyReal = FrequencyRaw / 10000;
RPM = FrequencyRaw / PulsesPerRevolution * 60 ;
RPM = RPM / 10000;
Frequenz = RPM * 1000 / 60;
// Frequenz = Frequenz * 1000;
// Frequenz = 1000000 / Frequenz;
total = total - readings[readIndex];
readings[readIndex] = RPM;
total = total + readings[readIndex];
readIndex = readIndex + 1;
if (readIndex >= numReadings) {
readIndex = 0;
}
average = total / numReadings;
lcd.setCursor(0, 1);
// lcd.print("Period: ");
// lcd.print(PeriodBetweenPulses);
// lcd.print("\tReadings: ");
// lcd.print(AmountOfReadings);
lcd.print("\Freq.: ");
// lcd.print(FrequencyReal);
lcd.print(Frequenz);
lcd.print("\mHz ");
// lcd.print("\tRPM: ");
// lcd.print(RPM);
// lcd.print("\tTachometer: ");
// lcd.println(average);
lcd.setCursor(0, 0);
lcd.print("U/Min: ");
lcd.print(RPM);
lcd.print(" ");
}
void Pulse_Event() {
PeriodBetweenPulses = micros() - LastTimeWeMeasured;
LastTimeWeMeasured = micros();
if (PulseCounter >= AmountOfReadings) {
PeriodAverage = PeriodSum / AmountOfReadings;
PulseCounter = 1;
PeriodSum = PeriodBetweenPulses;
int RemapedAmountOfReadings = map(PeriodBetweenPulses, 40000, 5000, 1, 10);
RemapedAmountOfReadings = constrain(RemapedAmountOfReadings, 1, 10);
AmountOfReadings = RemapedAmountOfReadings;
} else {
PulseCounter++;
PeriodSum = PeriodSum + PeriodBetweenPulses;
}
}
Re: Der AVR-/ARDUINO-Faden
ich habe das Problem, dass sich beim ATTINY25 nicht wie gewohnt die HEX Datei über USBasp und AVRdude hochladen lässt.
Ausgangssituation: ATTINY13A lässt sich mit dieser Befehlszeile problemlos programmieren:
beim ATTINY25 funktioniert diese Zeile nicht:
da kommt die Fehlermeldung "avrdude: error: program enable: target doesn't answer"
Habe auch schon verschiedene andere Optionen probiert...
Über Arduino und Uno als Programmer funktioniert es ein Sketch hochzuladen, sowie Bootloader zu brennen. Aber damit bekomme ich halt nicht eine HEX hochgeladen
Dachte die Tinys 13A und 25 wären fast gleich. Weiß jemand wo der Unterschied beim Programmieren über AVRdude liegt, bzw. wie die Befehlszeile aussehen muss?
Ausgangssituation: ATTINY13A lässt sich mit dieser Befehlszeile problemlos programmieren:
Code: Alles auswählen
avrdude -v -p t13 -b 1200 -c usbasp -P /dev/ttyS4 -D -F -U flash:w:/home/ich/Technik/Arduino/hex/Z-var-25.hex:i
Code: Alles auswählen
avrdude -v -p t25 -b 1200 -c usbasp -P /dev/ttyS4 -D -F -U flash:w:/home/ich/Technik/Arduino/hex/Z-var-25.hex:i
Habe auch schon verschiedene andere Optionen probiert...
Über Arduino und Uno als Programmer funktioniert es ein Sketch hochzuladen, sowie Bootloader zu brennen. Aber damit bekomme ich halt nicht eine HEX hochgeladen
Dachte die Tinys 13A und 25 wären fast gleich. Weiß jemand wo der Unterschied beim Programmieren über AVRdude liegt, bzw. wie die Befehlszeile aussehen muss?
Re: Der AVR-/ARDUINO-Faden
Die Tinys sind auch wirklich nicht arg unterschiedlich.
Verstehe ich das richtig, dass du grundsätzlich was hochladen kannst, also z.B. das Blink-Beispiel oder sowas?
Wenn ja, aktiviere doch mal in den Einstellungen die vollständige Loggingausgabe in der IDE, dann zeigt es dir beim Upload genau den AVRDUDE Befehl an, den die IDE verwendet (und der ja dann gehen muss).
Den kopierst du dir und änderst den Pfad vom HEX-File vom temporäten Arduinoordner auf den Ort ab, wo dein gewünschtes HEX-File liegt.
Edit:
Du schreibst, dass du über Arduino (du meinst vermutlich die IDE?) und einem Arduino Uno als Programmer etwas auf den Tiny packen kannst.
Geht das auch mit dem usbasp? Den kann man auch zum IDE Programmupload verwenden.
Sonst eben mal das oben Geschriebene testen, da müsste dann ein AVRDUDE Befehl bei rauskommen, der als Programmer statt dem usbasp den Arduino (heißt dann glaube ich arduinoisp oder sowas) drinstehen hat.
Verstehe ich das richtig, dass du grundsätzlich was hochladen kannst, also z.B. das Blink-Beispiel oder sowas?
Wenn ja, aktiviere doch mal in den Einstellungen die vollständige Loggingausgabe in der IDE, dann zeigt es dir beim Upload genau den AVRDUDE Befehl an, den die IDE verwendet (und der ja dann gehen muss).
Den kopierst du dir und änderst den Pfad vom HEX-File vom temporäten Arduinoordner auf den Ort ab, wo dein gewünschtes HEX-File liegt.
Edit:
Du schreibst, dass du über Arduino (du meinst vermutlich die IDE?) und einem Arduino Uno als Programmer etwas auf den Tiny packen kannst.
Geht das auch mit dem usbasp? Den kann man auch zum IDE Programmupload verwenden.
Sonst eben mal das oben Geschriebene testen, da müsste dann ein AVRDUDE Befehl bei rauskommen, der als Programmer statt dem usbasp den Arduino (heißt dann glaube ich arduinoisp oder sowas) drinstehen hat.
Re: Der AVR-/ARDUINO-Faden
Klasse Tipp, vielen Dank! Es hat funktioniert
Habe die ausführliche Ausgabe im Arduino aktiviert und die AVRdude Zeile rauskopiert und modifiziert.
Hiermit klappt es:
Das funktioniert momentan nur mit dem Uno als ISP, und (noch) nicht mit dem USBasp, macht aber nix. Hauptsache es funzt erstmal!
Habe die ausführliche Ausgabe im Arduino aktiviert und die AVRdude Zeile rauskopiert und modifiziert.
Hiermit klappt es:
Code: Alles auswählen
avrdude -v -pattiny25 -cstk500v1 -P/dev/ttyACM2 -b19200 -U flash:w:/home/ich/Technik/Arduino/hex/Z-var-25.hex:i
Re: Der AVR-/ARDUINO-Faden
ist ja eher smalltalk...
ich hab folgende Drehzahl berechnung. in diesem fall will ich die zahl in 1/min.
bei 1500 hab ich 10 pulse, bei 11 sinds 1650.
also schrittweite sind 150 u/min.
das ge-caste auf float kann ich mir doch komplett schenken oder.
ich hab folgende Drehzahl berechnung. in diesem fall will ich die zahl in 1/min.
Code: Alles auswählen
/////////MotorZustand//////////////////
tt = millis() - rpmTimeStamp;
if (tt >= 200) {
//15.000 rpm * 2pulse / 60 = 500 pulse/sec (1/500= 2 mS Puls abstand)
// 1500 rpm : 20 mS Puls abstand (tt >= 100 = 5 Pulse)
//rpmTicks ist 8bit!!!-> tt max 500 (ueberlauf) TODO 16?
//im recording tauchen nur 150er schritte auf,
//dh. einfangen bei 200 geht zuverlässig, tt wird nie >200
if (rpmTicks > 0) {
rPM = (float) rpmTicks * (float) 30000 / (float) tt;
also schrittweite sind 150 u/min.
das ge-caste auf float kann ich mir doch komplett schenken oder.
- Weisskeinen
- Beiträge: 3950
- Registriert: Di 27. Aug 2013, 16:19
Re: Der AVR-/ARDUINO-Faden
Wahrscheinlich schon, aber für die Integerarithmetik brauchst du sicher 32bit-Zahlen.
Re: Der AVR-/ARDUINO-Faden
oh, stimmt.
habs auch noch nicht angefasst,
damit nicht wieder so ein "ich dachte" fall draus wird
habs auch noch nicht angefasst,
damit nicht wieder so ein "ich dachte" fall draus wird
Re: Der AVR-/ARDUINO-Faden
einfach mal drüber zu quatschen hilft schon...
wenn ich anstatt ticks*30000/200ms,
ticks*19200/128 rechne,
kann ich das schubsen, und wenn mal 129ms draus würden, wär's scheinbar auch nicht so schlimm? ich bekäme die werte fast doppelt so schnell bzw häufig, wär auch noch genauer.(wegen der Beschleunigung)
müsste dann so:
(uint32_t)(ticks * 19200)>>7;
oder wie ist die reihenfolge?vielleicht besser so:
((uint32_t)(ticks * 19200))>>7;
so oder so muss es getestet werden, vorher.
edit. neee bullshit. da ticks ja kleiner wird mit kürzerem zählfenster muss:
ticks*30000>>7
edit. casten...herrje letzes edit.
bei 128(millis) erhalte ich drehzahlstufen von 234 etwa.
scheint mir auch der beste Kompromiss zwischen Geschwindigkeit und Genauigkeit.
wenn ich anstatt ticks*30000/200ms,
ticks*19200/128 rechne,
kann ich das schubsen, und wenn mal 129ms draus würden, wär's scheinbar auch nicht so schlimm? ich bekäme die werte fast doppelt so schnell bzw häufig, wär auch noch genauer.(wegen der Beschleunigung)
müsste dann so:
(uint32_t)(ticks * 19200)>>7;
oder wie ist die reihenfolge?vielleicht besser so:
((uint32_t)(ticks * 19200))>>7;
so oder so muss es getestet werden, vorher.
edit. neee bullshit. da ticks ja kleiner wird mit kürzerem zählfenster muss:
ticks*30000>>7
edit. casten...herrje letzes edit.
bei 128(millis) erhalte ich drehzahlstufen von 234 etwa.
scheint mir auch der beste Kompromiss zwischen Geschwindigkeit und Genauigkeit.
Re: Der AVR-/ARDUINO-Faden
ist getestet, funktioniert...
bleibt eine Frage, funktioniert der cast:
auch noch wenn mal der compiler ein update erhält, oder sonstwas..?
bleibt eine Frage, funktioniert der cast:
Code: Alles auswählen
rPM = (uint32_t) rpmTicks * 30000 >> 7;
- Alexander470815
- Beiträge: 2396
- Registriert: So 11. Aug 2013, 15:42
- Wohnort: D:\Hessen\Gießen
Re: Der AVR-/ARDUINO-Faden
Warum nicht einfach mit Interrupts und einem eigenen schneller laufenden Timer arbeiten?
Damit sollte sich eine viel feinere Auflösung erreichen lassen.
Damit sollte sich eine viel feinere Auflösung erreichen lassen.
Re: Der AVR-/ARDUINO-Faden
meinst du mit Timer Interrupt?Alexander470815 hat geschrieben: ↑Fr 1. Jul 2022, 13:22 Warum nicht einfach mit Interrupts und einem eigenen schneller laufenden Timer arbeiten?
Damit sollte sich eine viel feinere Auflösung erreichen lassen.
jetzt kommen die Impulse ja bereits von einem Interrupt.
könnt alle 10, oder so, pulse die Drehzahl rechnen lassen. dann passiert das um so öfter je schneller.
oder per Timer in fixen Zeit Intervallen, dann krieg ich ja (auch)Ungenauigkeiten durch "krumme Impulse", wenn die Zeit kurz ist.
Vielleicht geht da noch was? im Moment funktionierts halt, never touch...und so.
Kann auch schlecht abschätzen wie schnell die Drehzahländerung ist beim Moped.
Aus'm Bauch raus finde ich eine gute 10tel Sekunde schnell genug.
Die Schrittweite von 234Umin reicht auf jeden Fall hier.(durchstreich) sollte auch reichen.
- Weisskeinen
- Beiträge: 3950
- Registriert: Di 27. Aug 2013, 16:19
Re: Der AVR-/ARDUINO-Faden
Sollte, ja. rpmTicks wird in eine 32-bit-Zahl gewandelt und mit einer Konstanten multipliziert. Dafür dürfte sie der Compiler ebenfalls als 32-bit-Zahl behandeln. Das 32-bittige Ergebnis wird dann um sieben Bit nach rechts geschoben und rPM zugewiesen. Je nach dem, was für einen Datentyp rPM hat, wird hier noch mal gecasted. Wenn ein zukünftiger Compiler das anders macht, hat der da einen Fehler und sollte sowieso nicht verwendet werden.ch_ris hat geschrieben: ↑Fr 1. Jul 2022, 12:02 ist getestet, funktioniert...
bleibt eine Frage, funktioniert der cast:auch noch wenn mal der compiler ein update erhält, oder sonstwas..?Code: Alles auswählen
rPM = (uint32_t) rpmTicks * 30000 >> 7;
Re: Der AVR-/ARDUINO-Faden
gut dann bleibts so. danke sehr.
- Alexander470815
- Beiträge: 2396
- Registriert: So 11. Aug 2013, 15:42
- Wohnort: D:\Hessen\Gießen
Re: Der AVR-/ARDUINO-Faden
Ich dachte eher an einen Hardware interrupt der ausgelöst wird wenn es ein Signal gibt.
Dann schaut man einfach in das Zählregister eines Timers was drin steht und berechnet die Drehzahl.
Braucht man den Timer für sonst nichts setzt man den Zählerstand null für die nächste Messung.
Kann es dazu kommen das der Timer überläuft oder die Auflösung noch nicht reicht kann man ja über den overflow interrupt eine Variable hochzählen lassen die man dann mit einberechnet.
Über den Prescaler wählt man dann die Zählgeschwindigkeit entsprechend aus.
Dann schaut man einfach in das Zählregister eines Timers was drin steht und berechnet die Drehzahl.
Braucht man den Timer für sonst nichts setzt man den Zählerstand null für die nächste Messung.
Kann es dazu kommen das der Timer überläuft oder die Auflösung noch nicht reicht kann man ja über den overflow interrupt eine Variable hochzählen lassen die man dann mit einberechnet.
Über den Prescaler wählt man dann die Zählgeschwindigkeit entsprechend aus.
- Bastelbruder
- Beiträge: 11566
- Registriert: Mi 14. Aug 2013, 18:28
Re: Der AVR-/ARDUINO-Faden
Ich hab jetzt den Anfang der aktuellen Geschichte nicht mitverfolgt. Aber vor 30 Jahren hatte ich mal ein "professionelles" Drehzahlmesserproblem. Es war ein Display für den Gokart, das außer der Drehzahl natürlich noch andere Kinkerlitzchen darstellen und zwischenspeichern konnte. Jedenfalls so lange sich das Kleinhirn nicht mit Jogging im Wald beschäftigt hat.
Hauptproblem war die Datenleitung vom "Steuergerät" zum Display. Vier Drähte und regelmäßige Aufhänger. Das Steuerteil wurde in der Nähe der CDI montiert und hat die Zündfunken problemlos detektiert. Der Controllertakt war Interruptgesteuert und hat in festen Zeitabständen seine Ergüsse per I2C zum Display geschoben. Die Rennzubehör-Bastelbude hatte offenbar schon in der Entwicklungsphase mit EMV-Problemen dieser Datenübertragung zu kämpfen, die wurden vermutlich ohne jemals einen echten Gokart zu konsultieren, durch Einfügen kleiner Drosseln in die Datenleitung abgestellt. Natürlich waren auch Drosseln in der Versorgung und in der Masseleitung! Entfernen letzterer hat die bestimmungsgemäße Funktion einigermaßen hergestellt.
Bloß so ein Gedanke ...
Warum haben die Vollpfosten nicht den Zündfunken als Trigger zum Starten der Datenpakete genutzt? Die maximale Taktfrequenz ist in der Klasse bei 300 Hz, im Leerlauf deutlich über 20 Hz. Damit hätte man der Übertragung problemlos einen Intervall zuteilen können in dem niemand dazwischenfunkt!
Wenn der Zähler überläuft, ist mit Motor-Stillstand zu rechnen, das Kriterium kann als Reserve-Interrupt verwendet werden.
Hauptproblem war die Datenleitung vom "Steuergerät" zum Display. Vier Drähte und regelmäßige Aufhänger. Das Steuerteil wurde in der Nähe der CDI montiert und hat die Zündfunken problemlos detektiert. Der Controllertakt war Interruptgesteuert und hat in festen Zeitabständen seine Ergüsse per I2C zum Display geschoben. Die Rennzubehör-Bastelbude hatte offenbar schon in der Entwicklungsphase mit EMV-Problemen dieser Datenübertragung zu kämpfen, die wurden vermutlich ohne jemals einen echten Gokart zu konsultieren, durch Einfügen kleiner Drosseln in die Datenleitung abgestellt. Natürlich waren auch Drosseln in der Versorgung und in der Masseleitung! Entfernen letzterer hat die bestimmungsgemäße Funktion einigermaßen hergestellt.
Bloß so ein Gedanke ...
Warum haben die Vollpfosten nicht den Zündfunken als Trigger zum Starten der Datenpakete genutzt? Die maximale Taktfrequenz ist in der Klasse bei 300 Hz, im Leerlauf deutlich über 20 Hz. Damit hätte man der Übertragung problemlos einen Intervall zuteilen können in dem niemand dazwischenfunkt!
Wenn der Zähler überläuft, ist mit Motor-Stillstand zu rechnen, das Kriterium kann als Reserve-Interrupt verwendet werden.
Re: Der AVR-/ARDUINO-Faden
ach so, Alex.
ich hab ca 3ms signal abstand wegen wer weis geh ich von 1ner aus. dann muss ich einen analogen schalter pollen. dann wird eine aktion, max255 ms ausgelöst. rpm während dessen egal. innerhalb des folgenden delay 1000ms werden zuvor erzeugte structs ins eeprom geschrieben.
ich weis nicht ob mir ne quasi permanente rpm berechnung zu viel zeit klaut?
ich hab ca 3ms signal abstand wegen wer weis geh ich von 1ner aus. dann muss ich einen analogen schalter pollen. dann wird eine aktion, max255 ms ausgelöst. rpm während dessen egal. innerhalb des folgenden delay 1000ms werden zuvor erzeugte structs ins eeprom geschrieben.
ich weis nicht ob mir ne quasi permanente rpm berechnung zu viel zeit klaut?
- Alexander470815
- Beiträge: 2396
- Registriert: So 11. Aug 2013, 15:42
- Wohnort: D:\Hessen\Gießen
Re: Der AVR-/ARDUINO-Faden
So habe ich das gemacht um eine Lüfterdrehzahl zu ermitteln:
An anderer Stelle kann man dann einfach den Mittelwert mit dem entsprechenden Makro abrufen.
Den Prescaler habe ich hier auf clk/64 gestellt was damit 16MHz/64=250kHz
250k * 60 = 15.000.000
Damit kommen da am Ende direkt U/min raus.
Die langsamst messbare Drehzahl wäre in dem Fall 15M/(255+255*256)=228 U/min
Könnte man aber einfach aufbohren indem man overflow größer werden lässt.
Ein Zählwert von 1500 wären 10.000 U/min
Ein Zählwert von 1501 wären 9.993 U/min
Bei 10.000 U/min hätte man somit noch eine Auflösung von 7 U/min.
Reicht das nicht könnte man den Prescaler ja noch schneller wählen.
Ich weiß ja nicht was das ganze am Ende machen soll, Drehzahlbegrenzer am Moped?
Code: Alles auswählen
ISR(INT0_vect) // Der Hardware interrupt der ausgelöst wird wenn ein Impuls kommt
{
AddToFloatAvg(&Dreh,(15000000.0/(TCNT0+256.0*overflow))); // Drehzahlwert dem Floating Average hinzufügen
TCNT0=0; // Timer wieder null setzen
overflow=0; // Überlauf wieder null setzen
}
ISR(TIMER0_OVF_vect) // Interrupt der ausgelöst wird wenn der Timer überläuft(der hat nur 8bit also passiert das recht schnell)
{
if(overflow<255)
overflow++; // Überläufe addieren, wenn 255 mal übergelaufen dann Drehzahl von null in den Floating Average schreiben
else
AddToFloatAvg(&Dreh,0);
}
Den Prescaler habe ich hier auf clk/64 gestellt was damit 16MHz/64=250kHz
250k * 60 = 15.000.000
Damit kommen da am Ende direkt U/min raus.
Die langsamst messbare Drehzahl wäre in dem Fall 15M/(255+255*256)=228 U/min
Könnte man aber einfach aufbohren indem man overflow größer werden lässt.
Ein Zählwert von 1500 wären 10.000 U/min
Ein Zählwert von 1501 wären 9.993 U/min
Bei 10.000 U/min hätte man somit noch eine Auflösung von 7 U/min.
Reicht das nicht könnte man den Prescaler ja noch schneller wählen.
Ich weiß ja nicht was das ganze am Ende machen soll, Drehzahlbegrenzer am Moped?
Re: Der AVR-/ARDUINO-Faden
nee, ist ein schaltassistent aka kupplungsloses schalten.
danke, ich guck mir das am pc morgen mal an.
danke, ich guck mir das am pc morgen mal an.
Re: Der AVR-/ARDUINO-Faden
hab noch andere Änderungen drin die erst mal getestet werden müssen,
so ähnlich könnte ich mir das aber zukünftig vorstellen.
viel hilft natürlich viel, auch bei der zeitlichen Auflösung.
hab's mal überschlagen, der zu erwartende Drehzahl Abfall/Anstieg entspricht etwa meiner rpm Auflösung.
ich sag mal bis 2000 Umin pro sekunde, also etwa die gleiche Größenordnung.
Damit ist das ganze aber möglicherweise grenzwertig bzw. ausgereizt.
ich behalte das mal im Hinterkopf, danke nochmal.
so ähnlich könnte ich mir das aber zukünftig vorstellen.
eine Auflösung von ~250U reicht hier technisch imho.Alexander470815 hat geschrieben: ↑Fr 1. Jul 2022, 20:07 Ein Zählwert von 1500 wären 10.000 U/min
Ein Zählwert von 1501 wären 9.993 U/min
Bei 10.000 U/min hätte man somit noch eine Auflösung von 7 U/min.
Reicht das nicht könnte man den Prescaler ja noch schneller wählen.
viel hilft natürlich viel, auch bei der zeitlichen Auflösung.
hab's mal überschlagen, der zu erwartende Drehzahl Abfall/Anstieg entspricht etwa meiner rpm Auflösung.
ich sag mal bis 2000 Umin pro sekunde, also etwa die gleiche Größenordnung.
Damit ist das ganze aber möglicherweise grenzwertig bzw. ausgereizt.
ich behalte das mal im Hinterkopf, danke nochmal.
- Später Gast
- Beiträge: 1705
- Registriert: Di 5. Apr 2016, 22:03
- Wohnort: Karlsruhe
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
ich hab das an meiner Bohrmaschine mit ein mal
attachInterrupt(digitalPinToInterrupt(PinA), Berechnung, FALLING);
im Setup und dann
void Berechnung () {
Zeit_Gemessen = millis() - Letzte_Messung; // Zeit in ms
Letzte_Messung = millis();
Drehzahl = 60000 / Zeit_Gemessen; // Aktuelle Drehzahl
}
Berechnung eines Mittelwerts dann in der Ausgabe. Funktioniert wunderbar. Das ist ja das, was Alexander vorgeschlagen hatte. Die erste Iteration hatte bei mir auch erst Pulse in einem festen Zeitfenster gezählt und umgerechnet, ist aber iwie nicht so gut gelaufen. Hatte auch probleme wg digiSpark/Attiny85 und dem Bootloader und hab ewig pins vertauschen müssen, bis es irgendwann mal gelaufen ist. Wird nicht mehr angefasst.
attachInterrupt(digitalPinToInterrupt(PinA), Berechnung, FALLING);
im Setup und dann
void Berechnung () {
Zeit_Gemessen = millis() - Letzte_Messung; // Zeit in ms
Letzte_Messung = millis();
Drehzahl = 60000 / Zeit_Gemessen; // Aktuelle Drehzahl
}
Berechnung eines Mittelwerts dann in der Ausgabe. Funktioniert wunderbar. Das ist ja das, was Alexander vorgeschlagen hatte. Die erste Iteration hatte bei mir auch erst Pulse in einem festen Zeitfenster gezählt und umgerechnet, ist aber iwie nicht so gut gelaufen. Hatte auch probleme wg digiSpark/Attiny85 und dem Bootloader und hab ewig pins vertauschen müssen, bis es irgendwann mal gelaufen ist. Wird nicht mehr angefasst.
Re: Der AVR-/ARDUINO-Faden
Was mache ich falsch (ESP32)?
Ich dachte beim Arduino ist alles, was zwischen doppelten Anführungszeichen steht ein String, dann sollte man den doch auch verknüpfen können? Aber der Fehlermeldung nach sind das wohl zwei char Arrays ....
Erwartet hätte ich, dass da
---ab---ab---
rauskommt.
Ziel des ganzen soll eigentlich sein, einfach debugging-Meldungen auszugeben mit so etwas
S("blablubber ist: " + blablubber + "\n");
Code: Alles auswählen
void S(String text){
if ( settings.debug == true ) {
Serial.print(text);
}
}
S("---");
S("a");
S("b");
S("---");
S("a" + "b");
S("---");
src/main.cpp:111:11: error: invalid operands of types 'const char [2]' and 'const char [2]' to binary 'operator+'
S("a" + "b");
^
Erwartet hätte ich, dass da
---ab---ab---
rauskommt.
Ziel des ganzen soll eigentlich sein, einfach debugging-Meldungen auszugeben mit so etwas
S("blablubber ist: " + blablubber + "\n");
Re: Der AVR-/ARDUINO-Faden
nee, geht nicht. in JS ja. glaub ich.
aber type Nazis wie c , java lassen das nicht zu. oder? nochmal einklammern?
aber type Nazis wie c , java lassen das nicht zu. oder? nochmal einklammern?
-
- Beiträge: 138
- Registriert: So 9. Dez 2018, 11:30
Re: Der AVR-/ARDUINO-Faden
Nein, die Annahme mit den Anführungszeichen ist falsch. Das ist erst mal ein const char*. Dieser wird nur implizit in einen String umgewandelt da die Funktion S einen String erwartet und die Klasse String einen passenden Konstruktor bereitstellt.
Als einfache Abhilfe hier, sollte man das erste Element explizit in ein String Objekt wandeln können.
Dann wird nicht mehr probiert den operator+ auf zwei const char* auszuführen sondern auf ein String Objekt und einen const char*. Hierfür bietet die Klasse String eine geeignete Funktion und das concat kann ausgeführt werden.
Als einfache Abhilfe hier, sollte man das erste Element explizit in ein String Objekt wandeln können.
Code: Alles auswählen
S(String("a") + "b");
Re: Der AVR-/ARDUINO-Faden
Naja in mindestens PERL, PHP würde es gehen, JS meineswissens auch.
Aber selbst in ABAP, das typisiert ist, geht das. Hier werden Zeichenketten in ' eingeschlossen und Strings in |:
Code: Alles auswählen
data: lv_zahl1 type i default 4,
lv_zahl2 type p length 5 decimals 2,
lv_bla type c length 3 default 'bla'.
form S using iv_text type string.
write: /, iv_text.
endform.
perform S using |Hier steht jetzt fließtext und die Zahl 1 ist { lv_zahl1 } und Zahl 2 ist { lv_zahl2 } und bla ist { lv_bla }.|.
Danke für die ausführliche Erklärung virtexultra. So ist das verständlich warum das so ist. Die Idee, den linken Operanden erst mal zum String zu machen funktioniert einwandfrei. Deine Lösung compiliert sogar mit etwas anspruchsvolleren Aufrufen:virtexultra hat geschrieben: ↑Mi 13. Jul 2022, 16:46 Nein, die Annahme mit den Anführungszeichen ist falsch. Das ist erst mal ein const char*. Dieser wird nur implizit in einen String umgewandelt da die Funktion S einen String erwartet und die Klasse String einen passenden Konstruktor bereitstellt.
Als einfache Abhilfe hier, sollte man das erste Element explizit in ein String Objekt wandeln können.Dann wird nicht mehr probiert den operator+ auf zwei const char* auszuführen sondern auf ein String Objekt und einen const char*. Hierfür bietet die Klasse String eine geeignete Funktion und das concat kann ausgeführt werden.Code: Alles auswählen
S(String("a") + "b");
Code: Alles auswählen
S(String("a") + "b" + 5 + 'o' + String(1.23456, 2) + "\n");
Re: Der AVR-/ARDUINO-Faden
ah! wieder was gelernt.
Das mit den Nazis bitte humorig verstehen, hat auch seine Vorteile.
ich brauche mal einen watchdog im Nano.
bin mir nicht sicher ob ich den Kommentar in der wdt.h richtig verstehe.
ist's so richtig?:
Das mit den Nazis bitte humorig verstehen, hat auch seine Vorteile.
ich brauche mal einen watchdog im Nano.
bin mir nicht sicher ob ich den Kommentar in der wdt.h richtig verstehe.
ist's so richtig?:
Code: Alles auswählen
void setup() {
MCUSR = 0;
wdt_disable();
....zeug
wdt_enable(WDTO_1S);
}
loop: wdt_reset()
\code
#include <stdint.h>
#include <avr/wdt.h>
uint8_t mcusr_mirror __attribute__ ((section (".noinit")));
void get_mcusr(void) \
__attribute__((naked)) \
__attribute__((section(".init3")));
void get_mcusr(void)
{
mcusr_mirror = MCUSR;
MCUSR = 0;
wdt_disable();
}
\endcode
Saving the value of MCUSR in \c mcusr_mirror is only needed if the
application later wants to examine the reset source, but in particular,
clearing the watchdog reset flag before disabling the
watchdog is required, according to the datasheet.
Re: Der AVR-/ARDUINO-Faden
Für den watchdog noch der Hinweis, dass dieser mit dem alten Bootloader, der auf den ganzen Chinaklonen der Nanos drauf ist, nicht funktioniert.
Also zuerst den neuen Bootloader oder den vom UNO oder einen ganz anderen passenden draufpacken.
Also zuerst den neuen Bootloader oder den vom UNO oder einen ganz anderen passenden draufpacken.
Re: Der AVR-/ARDUINO-Faden
verdammt.
wie äussert sich das? geht einfach nicht?
irgendwas las ich das man den quasi bricken könnte und nur noch per isp rankommt.
wie äussert sich das? geht einfach nicht?
irgendwas las ich das man den quasi bricken könnte und nur noch per isp rankommt.
- Alexander470815
- Beiträge: 2396
- Registriert: So 11. Aug 2013, 15:42
- Wohnort: D:\Hessen\Gießen
Re: Der AVR-/ARDUINO-Faden
Naja ein USBasp kostet doch nichts, einfach darüber programmieren und das Bootloader Problem erübrigt sich.
Re: Der AVR-/ARDUINO-Faden
Und wenn kein usbasp zur hand ist kann man einfach einen zweiten Arduino als ISP verwenden, das hat man ja meistens rumliegen. Sann ist das eine Sache von wenigen Minuten.
Re: Der AVR-/ARDUINO-Faden
ja klar, muss man halt auf dem schirm haben. und grad den fraglichen uploade ich mit dem phone. wenn der dann erst mal tot ist geht im Feld nix mehr.
Re: Der AVR-/ARDUINO-Faden
ich muss noch mal nach-haken, hab jetzt so getan wie im Kommentar beschrieben:
damit sollte ja nur noch ein wdt_enable(x); am ende der setup() nötig sein.
wenn ich jetzt in setup mcusr_mirror ins eeprom logge und dann später ausgebe (Serial.print(EEPROM.read(var), 10);):
reset knopp oder per konsole =121 (0b 01111001)
kabel ziehen=91 (0b 01011011)
wenn ich mcusr_mirror nach dem loggen auf null setzte:
reset knopp oder per konsole =0
kabel ziehen=121
wieso macht das einen unterschied?
was bedeutet das überhaupt, sollte nicht 0000xxxx rauskommen?
oder 123 oder 89 kommt da raus, auf nix ist verlass
(edit, ach verdammt, das könnte eine eeprom schreib/lese schwäche sein, hängt nur am usb strom.
aber der oben beschriebene unterschied ist ja nicht nur ein falsches bit)
Code: Alles auswählen
#include <avr/wdt.h>
uint8_t mcusr_mirror __attribute__ ((section (".noinit")));
void get_mcusr(void) \
__attribute__((naked)) \
__attribute__((section(".init3")));
void get_mcusr(void)
{
mcusr_mirror = MCUSR;
MCUSR = 0;
wdt_disable();
}
wenn ich jetzt in setup mcusr_mirror ins eeprom logge und dann später ausgebe (Serial.print(EEPROM.read(var), 10);):
reset knopp oder per konsole =121 (0b 01111001)
kabel ziehen=91 (0b 01011011)
wenn ich mcusr_mirror nach dem loggen auf null setzte:
reset knopp oder per konsole =0
kabel ziehen=121
wieso macht das einen unterschied?
was bedeutet das überhaupt, sollte nicht 0000xxxx rauskommen?
oder 123 oder 89 kommt da raus, auf nix ist verlass
(edit, ach verdammt, das könnte eine eeprom schreib/lese schwäche sein, hängt nur am usb strom.
aber der oben beschriebene unterschied ist ja nicht nur ein falsches bit)
Re: Der AVR-/ARDUINO-Faden
Ich hatte mich gefragt, ob nur ich "Pech" mit Openhardware habe, letztes Problem digisparks.Später Gast hat geschrieben: ↑Mo 4. Jul 2022, 11:04 Hatte auch probleme wg digiSpark/Attiny85 und dem Bootloader und hab ewig pins vertauschen müssen, bis es irgendwann mal gelaufen ist. Wird nicht mehr angefasst.
Nach so im Mittel 10-15 programmiervorgängen schreibt sich der bootloader scheinbar seinen eigenen Speicher kaputt, und programmieren über USB geht nimmer.
Ich hatte 5 davon, zuletzt waren vier davon tot.
An einen toten hab ich ICSP Kabel angelötet und per usbasp dann ohne bootloader direkt aufgespielt, das ging sofort. Geht aber nicht bei den original digistump, wo per Fuses der reset abgeschaltet ist, aber ich hatte eh keine original.
Einer ist gestorben, als ich den an eine usb-verlangerung mit Wackelkontakt / kein Kontakt auf den stromleitungen gesteckt hab, die wird dann noch ausgesondert.
Ich bin jetzt so auf dem Trip, da den USB Kontakte Teil abzusägen und die dann von dem unzuverlässigen bootloader zu befreien
Das der beim Schreiben die geschriebenen Daten nicht zur Kontrolle zurückliest, ist schon scheiße genug, aber wenn der sich regelmäßig selber abschießt, das geht gar nicht.
Müll eigentlich.
Leider sind atmel MCU gerade Goldstaub geworden irgendwie, die STM32 und ESP32 dagegen preislich noch normal.
Re: Der AVR-/ARDUINO-Faden
In welchem Universum?
Die ganze Industrie geiert gerade nach STM32, nichts lieferbar.
Die Bluepill Boards mit STM32F103 kosten aus China 7 €, die waren mal bei unter einem Euro pro Stück. Und mit hoher Wahrscheinlichkeit bekommt man da mehr oder weniger gute Klone, ich hatte da mal ein Exemplar das soweit funktioniert, aber der UART hat sich immer mal wieder komisch verhalten, bei einem originalen STM32 ging alles einwandfrei.
Re: Der AVR-/ARDUINO-Faden
Ich hatte nur kurz bei AliExpress geguckt, da waren die STM32 Boards (vergleichbar zu arduino Mini oder sowas) bei 1,90 herum.
Und die mega328 bei 7 usd
Und die mega328 bei 7 usd
Re: Der AVR-/ARDUINO-Faden
Drei Board bei Ali bekommst du.
Willst du aber 200-300 Stück für Nullserie haben muss man schon stückeln mit verschiedenen Ratings und Ausbaustufen. 10k Stück für die Serie kannst gleich vergessen.
Grüße Jan
Re: Der AVR-/ARDUINO-Faden
Hab probiert MCUSR mit externer besaftung zu lesen.
ich kann kein System entdecken. es kommt zwar nicht jedes Mal was anderes raus,
zb. bei Reset per Konsole 5x hintereinander 0,
nach dem nächsten Kaltstart und erneuten Konsole Reset aber wieder mehrfach was anderes.
war immer 0 oder die ersten 4 bits, die 0 sein sollten, waren auch beteiligt.
Brown Out Detection?
ist standardmäßig off glaub ich.
sollte doch aber bei einem Reset nix ausmachen?
oder das ist einfach nicht zu gebrauchen.
EDIT
der bootloader könnte schuld sein.
https://www.idogendel.com/en/archives/623
je nachdem welcher, löscht der mcusr.
0 scheint also ein korrektes Ergebnis.
ich kann kein System entdecken. es kommt zwar nicht jedes Mal was anderes raus,
zb. bei Reset per Konsole 5x hintereinander 0,
nach dem nächsten Kaltstart und erneuten Konsole Reset aber wieder mehrfach was anderes.
war immer 0 oder die ersten 4 bits, die 0 sein sollten, waren auch beteiligt.
Brown Out Detection?
ist standardmäßig off glaub ich.
sollte doch aber bei einem Reset nix ausmachen?
oder das ist einfach nicht zu gebrauchen.
EDIT
der bootloader könnte schuld sein.
https://www.idogendel.com/en/archives/623
je nachdem welcher, löscht der mcusr.
0 scheint also ein korrektes Ergebnis.
Re: Der AVR-/ARDUINO-Faden
weitere versuche wurden durch mein isp adapter eingebremst.
bastelstunde.
scheint sich aber gelohnt zu haben, erste versuch hat geklappt.
bastelstunde.
scheint sich aber gelohnt zu haben, erste versuch hat geklappt.
- Dateianhänge
-
- noex_153.jpg (10.21 KiB) 1557 mal betrachtet
Re: Der AVR-/ARDUINO-Faden
Kurze Frage mal zu einem anderen Controller:
STM32 und der STM32 Cube Programmer.
Ich will ja auf meinen DPS5005 Modulen eine andere Firmware installieren:
https://hackaday.com/2022/01/22/another ... -firmware/
Eine Anleitung für dummies wie mich gibt es hier:
https://profimaxblog.ru/dps_fw_flashing/
Leider hängt es bei mir an grundlegenden Dingen:
Ich kann keine Verbindung aufbauen: Im Gerätemanager wird der Programmer (3€ China-Clone) angezeigt und wird wohl korrekt erkannt.
Ein Firmwareupdate über den CubeProgrammer hat scheinbar auch funktioniert.
Drücke ich auf "Connect" passiert nichts
Egal was ich da einstelle.
Nichtmal eine Fehlermeldung erscheint
Ich werde das morgen mal auf einem anderen Rechner testen, ich vermute das ist wieder mal so ein typisches Windows-Ding.
Der Rechner hier war jetzt mal 5 Tage aus und ohne Strom. Geht das W-Lan nicht mehr richtig. "Keine Internetverbindung" mit dem Laptop ging es aber
STM32 und der STM32 Cube Programmer.
Ich will ja auf meinen DPS5005 Modulen eine andere Firmware installieren:
https://hackaday.com/2022/01/22/another ... -firmware/
Eine Anleitung für dummies wie mich gibt es hier:
https://profimaxblog.ru/dps_fw_flashing/
Leider hängt es bei mir an grundlegenden Dingen:
Ich kann keine Verbindung aufbauen: Im Gerätemanager wird der Programmer (3€ China-Clone) angezeigt und wird wohl korrekt erkannt.
Ein Firmwareupdate über den CubeProgrammer hat scheinbar auch funktioniert.
Drücke ich auf "Connect" passiert nichts
Egal was ich da einstelle.
Nichtmal eine Fehlermeldung erscheint
Ich werde das morgen mal auf einem anderen Rechner testen, ich vermute das ist wieder mal so ein typisches Windows-Ding.
Der Rechner hier war jetzt mal 5 Tage aus und ohne Strom. Geht das W-Lan nicht mehr richtig. "Keine Internetverbindung" mit dem Laptop ging es aber
-
- Beiträge: 1663
- Registriert: So 11. Aug 2013, 13:55
Re: Der AVR-/ARDUINO-Faden
nur überflogen aber bei dir ist JTAG statt SWD eingestellt... Absicht?
- Fritzler
- Beiträge: 12604
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Jap, JTAG ist falsch, die STM32 sind meist per SWD programmiert, weil das viel weniger Pins brauch.
Und nimm nicht diesen sch**ss Cube Programmer das ist völlig dumme klickibunti SW ohne ordentliche Fehlermeldungen.
Der Vorgänger ist da besser: https://www.st.com/en/development-tools ... nk004.html
(ST Link Utility)
Und nimm nicht diesen sch**ss Cube Programmer das ist völlig dumme klickibunti SW ohne ordentliche Fehlermeldungen.
Der Vorgänger ist da besser: https://www.st.com/en/development-tools ... nk004.html
(ST Link Utility)
Re: Der AVR-/ARDUINO-Faden
Üblicherweise ist genau das daß Problem durch die FW Updates werden die China Klone unbrauchbar obwohl sie prinzipiell super laufen...
Mir auch passiert obwohl ich den Klon unwissentlich zum Original Preis erworben habe.
- Fritzler
- Beiträge: 12604
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Falls das der Fall sein sollte kann es Xana ja zum Treffen mitbringen.
Dann komm ich mitm Programmer.
(Aber vorher Bescheid sagen, sonst nehm ich den nicht mit!)
Ein Adapter von ARM 20 pol JTAG (2,54mm) auf DPS5005 musste aber selber mitbringen:
Benötigt werden:
vtref an 3,3V
SWDIO, SWDCLK, GND, reset
Dann komm ich mitm Programmer.
(Aber vorher Bescheid sagen, sonst nehm ich den nicht mit!)
Ein Adapter von ARM 20 pol JTAG (2,54mm) auf DPS5005 musste aber selber mitbringen:
Benötigt werden:
vtref an 3,3V
SWDIO, SWDCLK, GND, reset