Enhanced processtime #73
Conversation
Variablen Überlauf in compress_pattern behoben #71 Laufzeit von compress_pattern etwas optimiert
| calcHisto(); | ||
| for (uint8_t idx = 0; idx<patternLen-1; idx++) | ||
|
|
||
| //calcHisto(); |
There was a problem hiding this comment.
erst mal calchisto entfernt, da ich es nicht mehr vor dem compress brauche. Sollte sich nichts komprimieren lassen, wird erin calchisto noch am Ende aufgerufen
| @@ -265,29 +276,38 @@ void SignalDetectorClass::compress_pattern() | |||
|
|
|||
| if (inTol(pattern[idx2], pattern[idx], tol)) // Pattern are very equal, so we can combine them | |||
| { | |||
| idx_a[count] = idx; | |||
There was a problem hiding this comment.
Hier wird sich nur gemerkt, welche pattern zusammengefasst werden können
compiler Fehler behoben
|
Durch meine Anpassungen kommt es nun manchmal zu so einer Ausgabe: Das war ja vorher bestimmt nicht :( |
|
die BAUDRATE 115200 ist zu hoch. Habe ich auch schon versucht, es aber nicht stabil hinbekommen. |
mend Berechnung korrigiert
Suche nach validem sync in getSync() durch eine schnellere Variante ersetzt
|
Bei einem 8 Mhz oder 16 Mhz Arduino. Der läuft eigentlich auch mit 1 Megabaud ganz gut. Das Problem ist auch eher die Taktrate vom FTDI Chip, die muss gut passen, sonst gibt es Übertragungsfehler |
|
@Ralf9 Ich habe mir das mit der Baudrate noch mal genauer angesehen. Wenn man das mal so nimmt wie es steht, kann man auf 1 Megabaud gehen und hat weniger Fehler. |
|
Ja, 76.8K würde für 8 und 16 MHz passen, aber ob diese krumme Baudrate von den USB seriell Wandlern oder dem USR TCP232 unterstützt wird? 250 kBaud habe ich auch schon getestet, ich habe es aber nicht fehlerfrei hinbekommen, |
|
Ich lass mal meinen auf 500k laufen :) Die gängigen USB Chips können das. Jaja ich weiss, ich hab auch schon mal behauptet das gibt nur Probleme... Aber ich weiss nicht wieso überhaupt. |
|
@Ralf9 |
|
Ob man die Suchfunktion vielleicht in die Bitstore Klasse einbaut. Hmm |
@Ralf9
Ich habe ein paar Sachen angepasst