STM32G030K6T / CRC / endianess / Was bewirkt REV_OUT/REV_IN?
Ich verwende CRC16/KERMIT (also POLY=0x1021 und POLYSIZE=16bit)...
Also wenn im Speicher steht u8 D[4]={'b','i','r','d'}, dann wird durch einen cast daraus: *(u32*)D==0x64726962 ('b' ist 0x62) --- wenn ich das word (4 Byte) dann in das CRC_DR schreibe, dann nimmt die CRC unit sich das von links nach rechts vor... Also 'd', 'r', 'i' und zuletzt 'b'... (also „drib“, obwohl „bird“ die Eingabe ist...) Aber ich will es na klar umgekehrt...
Bisher benutze ich als workaround den „rev rT, rS“ Befehl durch __builtin_bswap32...
Geht das iwi auch schneller mit CRC_CR.REV_OUT/REV_IN? Ich krieg's iwi nich hin...
1 Antwort
Der Cast selbst dreht die Bytorder nicht um, aber es kann sein, dass die CRC Unit das macht.
Du kannst die CRC dann entweder byteweise errechnen und dann zusammensentzen oder du kannst die Arm Funktion REV verwenden, dafür sollte es Intrinsics geben die genau das machen.
Siehe auch STM32 CRC Array.
Naja ist eben die Implementierung der CRC und eigentlich am Ende auch egal solange du auf beiden Seiten die Prüfsumme nur gleich bildest.
Wozu brauchst du übrigens so eine schnelle CRC bist du dir sicher, dass diese zum Bottleneck wird?
Btw der wechsel zwischen Big und Little Endian auf Arm ist glaub ich nur ein CPU Zyklus.
Ist es dabei dann wirklich so wichtig dass du die Performance hast?
Wenn ja du kannst die Byteorder umdrehen bevor du es der CRC übergibst.
Generell ist das CRC Modul der STM32 etwas eigenartig. Also ich habe in solchen Fällen einfach eine Software CRC verwendet und die ist mit LUT auch nicht sonderlich langsam. Da gabs oft einige Bottlenecks vorher bevor das wirlklich zum Problem wurde.
ich will versuchen, mit 8MHz auszukommen... die Studis haben immer mit ihrer Durchschnitts-Leistungsaufnahme angegeben... unter 1mW soll es sein... die hörten immer nur das erste Byte einer Nachricht auf dem Bus und wenn das nicht die DeviceNr war, dann haben sie erstmal pauschal ne halbe Sekunde nicht mehr auf den Bus gehört...
CRC geht auch, wenn die CPU schläft...
Ja das verfahren passt ja auch so. Wenn das erste Byte der Nachricht falsch ist kann die CRC ja nicht mehr stimmen.
Natürlich kannst du per DMA in den Speicher und dann per DMA auf die CRC und prüfen, aber ich bin mir nicht sicher ob das dann Stromsparender ist. Das müsstest du am Ende auch mal nachmessen, denn am Ende kann hier maximal die CPU ohne Clock sein, RAM, DMA usw brauchen auch da eine Clock.
Wenn du die ersten Byte der Nachricht aktiv auf Framingfehler im Header prüfst und bei einem Framingerror den Receive abbrichst wird das denke ich mal Stromsparender sein als eine Lange Nachricht zu empfangen.
Die CRC brauchst du dann nur um Fehler in der Payload zu erkennen.
ok... das mit dem Receive-Abbruch äffe ich einfach mal nach... also wenn die Nachricht nicht für meine 72W(peak) Lava Lampe ist, dann schläft das Ding bei 125kHz...
durch den massiven Einsatz von DMA (1. Kopieren von Buffern in den Ring Buffer für ausgehende Nachrichten) (2. CRC) (3. ADC) hoffe ich mit 8MHz als maximale Taktfrequenz auszukommen...
Schon klar was du vor hast aber das musst du dir durchrechnen bzw einfach mal messen....
Wir hatten in einem Projekt mal mehr Energieersparnis dadurch, dass der Prozessor mit höherer Taktrate gelaufen ist und dafür mehr geschlafen hat. Das ist insbesondere bei den Energiesparenden Geräten mehr der Fall.
Was meinst du mit das Ding schläft bei 125kHz? Wenn der DMA aktiv ists schläft da eben fast gar nichts in dem System.
Je früher du den Receiver abschaltest und wenn möglich Clock Gatest und dann einfach gar nichts mehr machst desto mehr Energie sparst du am Ende.
Das hängt jetzt natürlich von dem Bus ab der da auf der anderen Seite hängt aber idR bringt schlafen mehr Energieersparnis als langsames arbeiten. Niedrigere Taktraten verwendet man idR dann wenn man oft etwas machen muss bei Event Driven Systemen kann das aber wie gesagt auch nach hinten los gehen.
Was meinst du mit STK?
Wenn der DMA läuft läuft jedenfalls die CoreClock denn da hängt ja der Speicherbus oben und den braucht der DMA.
Welche Clocks abgeschalten werden liegt aber jetzt nicht direkt an der Peripherie sondern am Sleep Level.
Im von ST als Sleep bezeichneten Level ist nur der Core deaktiviert, der Speicherbus und jegliche Peripherie läuft.
Im Stop Mode ist der komplette Bus und die Peripherie abgeschalten. Aber der SRAM bleibt erhalten. Davon gibt es dann noch mehrere Stufen mit Settings für die Spannungsregler um hier die Leckströme zu senken.
Im Stanby Mode ist der Micrcontroller quasi wie abgeschalten.
Wenn du auch im Idle mehr Energie sparen willst musst du die Clock für nicht benötigte Module abschalten sowie die Ausgangstreiber für die GPIOs deaktivieren wenn du die nicht brauchst.
ja... die CRC unit fängt beim high byte an... unnötig... eigentlich... ich mach es jetzt mit byte-wise DMA... dann spart die CPU 458 cycles pro 128 bytes... dafür braucht DMA 835 cycles...