Moins, ich spiel seit kurzen mit einem STM32f103. Evtl hab Ihr eine schnelle Lösung zu folgendem Problem: Addition und Subtraktion mach der µC ohne Probleme, aber sobald ich ein << oder >> oder / einfüge, gibt er mir über den CAN unregelmäßig (jedes 100 - 500Mal bei einer 1ms Task) falsche Werte heraus. Ist egal ob ich double, float oder int nehme... Also das geht ohne Fehler: Temp=hilf1+hilf2; (datentypen alle uint16 hilf1&2 immer kleiner 30k) das hier geht nicht Temp=(hilf1+hilf2)/2 oder Temp=(hilf1+hilf2)>>1 Ich bin jetzt nicht so der Programmierer, hat einer von euch eine Idee? Für den CAN hab ich eine 1ms Task gebastelt. Meine erste Idee was es, dass mir der Interrupt die Rechnung abundan versaut, aber so eine Shift'ung' (darf man das schreiben ;D) muss der µC doch extrem fix hinbekommen, und eine Verzögerung bei der reinen Addition hat auch keinen Fehler zur Folge. Bitte um Input. Thx
Gido, möglicherweise sind 1ms-Task und Rechenvorgang nicht synchronisiert. Wie stellst du sicher, dass nur fertige Rechenergebnisse gesendet werden? Ciao, Yagan
Eine Addition (oder Subtraktion) ist eine "atomic instruction" und wird in einem einzigen Takt ausgeführt und ist nicht auftrennbar. Addition + anschliessende Division (Shift) aber schon! Du musst sicherstellen, dass keine Zwischenwerte von anderen Routinen benutzt werden können. Etwa durch disable aller Interrupts während einer Berechnung. Stichwort "Semaphoren"
Die Rechnung wird am Anfang eines 1ms Interrupts ausgeführt. Anschließend alles in eine Nachricht gepackt und ab damit. Und dieser Int hat ansich die höhste Priorisierung und kann nicht unterbrochen werden. Ich bin davon ausgegangen das er das Shiften um 1 in 1ms hinbekommt. Aber dem ist nicht so. Beim Atmel hatte ich nie solche Probleme ;-) und der ist ja um einiges langsamer. Da liegt noch etwas im Argen, was bestimmt voll abstrus ist. Na werde mal das Datasheet wälzen.
Hast Du schon mal versucht, das minimalste Programm zu schreiben und im Simulator durchzugehen? Da sollte sich zeigen, wie viel Takte zusätzlich für die Operation gebraucht werden. Dann vielleicht mal statt uint16_t die native Größe uint32_t nehmen und vergleichen, da braucht nämlich nicht erst implizit in uint16_t umgewandelt zu werden.
>Ich bin davon ausgegangen das er das Shiften um 1 in 1ms hinbekommt. >Aber dem ist nicht so. Darüber lacht der sich tot. Das ist ein Assemblerbefehl. Bei 72MHz Takt in 14 ns erledigt. Das Problem liegt mit Sicherheit ganz woanders.
Genau der Meinung bin ich auch, dachte nur evtl hat einer von euch mal ein gleichwertiges Problem mit dem STM32 gehabt. Gruß
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.