Posts by meigrafd

    Ganz so trivial ist dein Vorhaben nicht.


    Die 7,2V sind im RC Bereich normal und notwendig, für deinen PI brauchst du aber eine separate Stromversorgung oder zumindest stabilisierte 5.1V. Du kannst NICHT die L298N-Bridge für den Pi verwenden! Da kommen zu wenig Volt raus und auch nicht stabilisiert. Der Pi3 ist empfindlich bgl. Spannungsschwankungen.

    Normalerweise verbaut man 2 Akkus:

    1x 5V Powerbank für den Pi.

    1x 7.2V RC-Akku für Motoren und Drive-Elektronik.

    Du könntest aber auch einen Step-Down Converter zwischen 7.2V Akku und Pi verbauen, musst dann aber darauf achten dass dieser Buck-Converter (zB. KIS3R33S) genug Strom liefert. Auch läuft man dann Gefahr die SD Karte des Pi's zu schrotten wenn der eine 7.2V "Fahr"-Akku leer ist...


    Die Motoren können kurzfristig ziemlich viel Strom ziehen - weshalb man wie gesagt lieber 2 verschiedene Stromversorgungen verbaut.

    Zum ermitteln bedient man sich der Formel:

    P = U * I

    167 W = 7.2 V * ?

    Wir müssen die Formel also umstellen:

    P / U = I

    167 W / 7.2 V = 23,194 A


    Dann ist ganz wichtig das GPIO's des Pi's nicht 5V tolerant sind! Die verkraften maximal 3V3. Dh du brauchst noch einen Optokoppler oder Levelshifter zum ansteuern der 7.2V Drive-Elektronik.


    Desweiteren stellt sich mir die Frage ob du wirklich ein RC Auto basteln willst oder doch wieder ein Roboter?

    Wo ist der Unterschied zwischen Pi3B und Pi3B+?


    Beim Pi3B+ handelt es sich nicht wirklich um ein neues Modell, eher um ein Facelift des Pi3B. Auch nicht um einen Ersatz, die vorherigen Ausführungen werden weiter produziert.



    Nachfolgend eine Zusammenfassung der Neuerungen von Pi3B Vs. Pi3B+:

    • Schnelleres Netzwerk. Dank des neuen LAN7515 Controllers verfügt der Pi3B+ nun über Gigabit Ethernet, der allerdings weiterhin über USB2.0 angebunden ist (Flaschenhals).
      • Pi3B: max. 95 MBit/s
      • Pi3B+: max. 315 MBit/s
    • Höherer CPU-Takt. 17% Flotter, hat allerdings auch eine höhere Leistungsaufnahme sowie Abwärme zur Folge. Zur besseren Wärmeabführung dient ein Blechdeckel als Heatspreader.
      • Pi3B: 4x 1200 MHz
      • Pi3B+: 4x 1400 MHz
    • Leistungsaufnahme. Höherer Takt hat automatisch auch eine höhere Leistungsaufnahme zur Folge.
      • Pi3B: 1,5 Watt Idle ohne Netzwerk und Desktop. 1,7 Watt mit eth0 Netzwerk. 4,4 Watt Vollast auf allen Kernen.
      • Pi3B+: 2,5 Watt Idle ohne Netzwerk und Desktop. 3,1 Watt mit eth0 Netzwerk. 7,0 Watt Vollast auf allen Kernen.
    • 5 GHz WLAN ac. Dual-Band-ac-WLAN für das 5-GHz-Frequenzband. Allerdings ist nur eine statt zwei Antennen verbaut, sodass der Datendurchsatz im 2,4-GHz-Frequenzband nur geringfügig steigt, im 5-GHz-Frequenzband hingegen deutlicher - aber leider nicht vergleichbar mit Multi-Antennen-Systeme.
    • Verbessertes PXE- und USB- booting. ROM Firmware in der SoC wurde überarbeitet.
    • POE. Es sind 4 Pins für ein Aufsteckmodul (PoE HAT) vorbereitet, welches zwingend erforderlich ist um dieses Feature zu nutzen. PoE-HAT erscheint leider erst im Sommer 2018.
    • Verbessertes Thermals und Power Management durch neueren MaxLinear MxL7704 power management IC.
    • WLAN/BT Chip auf Oberseite der PCB verlegt. Onboard Antenne durch das Design vom PiZeroW ersetzt.
    • Es wird dringend empfohlen ein High-Quality 2.5A Netzteil zu verwenden! (KEIN Ladegerät!)



    Pi3B Pi3B+
    SoC BCM2837 BCM2837B0
    CPU ARM Cortex-A53 (ARMv8-A) ARM Cortex-A53 (ARMv8-A)
    CPU-Takt 4 x 1200 MHz 4 x 1400 MHz
    USB/LAN-Controller-Chip LAN9514 LAN7515
    WLAN-Controller-Chip CYW43143 (2,4 GHz, b/g/n) CYW43455 (Dual-Band 2,4/5 GHz, ac)
    Bluetooth 4.1, Low Energy 4.2, Low Energy
    Thermal Management > 80°C 600 MHz.
    < 70°C max MHz. > 70°C 1200 MHz. > 80°C 600 MHz.
    Power-over-Ethernet - 4 Pins für Aufsteckmodul vorbereitet (IEEE 802.af)




    Lohnt es sich den Pi3B durch den 3B+ zu ersetzen?


    Steht die CPU-Leistung im Vordergrund, wie beispielsweise in einem Mediacenter, wird der neue 3B+ der Aufgabe natürlich besser gerecht werden. Gleiches gilt bei hohen Netzwerkdurchsätzen.

    Ist hingegen ein stromsparendes, kühles System gefragt, dann gibt es keinen Grund zu wechseln.






    Quellen:

    https://de.wikipedia.org/wiki/Raspberry_Pi#Hardware

    https://www.raspberrypi.org/bl…-model-bplus-sale-now-35/

    https://elinux.org/RPi_HardwareHistory#Current_models

    https://www.heise.de/forum/c-t…en/posting-32031948/show/

    https://opensource.com/article…rry-pi-3b-model-announced

    https://www.rs-online.com/desi…pi-3-model-b-vs-3-model-b

    https://freelance.halfacree.co…s-performance-benchmarks/

    NEU: Raspberry Pi3 B+



    Die Betroffenen werden sich schon erkannt haben. Ich finde es etwas traurig, dass hier häufig Behauptungen um der Behauptung willen aufgestellt werden und es dann nur noch drum geht, Recht zu haben.

    Es ist nicht das Problem, wenn sich mal jemand irrt - aber es ist ein Problem, wenn jemand eine Aussage in den Raum stellt und auch dann noch drauf beharrt, wenn andere sie bestreiten.

    Leider keine Seltenheit hier... Sieht man ja jetzt auch wieder: raspiprojekt "bestätigt meine Behauptung" aber keiner der Beteiligten geht darauf ein.

    Konstruktive Diskussionen sind schon länger nicht mehr möglich. Nur noch ein aufeinander herumgehake.


    Ebenso könnte man fragen: Einer schlägt GET vor, ein anderer POST. Wieso wird nur eine Aussage zerlegt, die andere aber nicht?


    Wie gesagt, leider keine Seltenheit, weshalb ich mich in den letzten Monaten hier mehr und mehr zurückziehe.

    Ach Jungs, dass ihr sowas immer erstmal anzweifeln müsst... Konstruktiv wäre den Gedanken weiter zu spinnen.


    Nachdem ihr zunächst meine Aussage angezweifelt, dann laut darüber nachgedacht und letztlich vielleicht doch Zähneknirschend aber dennoch indirekt, zustimmt dass meine Aussage "via POST senden, das wäre sicherer als GET" zutrifft, denn mit dem Zusatz HTTPS geht es quasi nicht sicherer, im Gegensatz zu GET wo HTTPS quasi nichts bringt...


    So wie bei mir früher Linus dass ich vorsichtig mit Aussagen sein müsse weil ich gemäß hoher Beitragszahl mehr Beachtung kriege, solltest auch Du nun vorsichtiger mit deinen Beiträgen sein.




    PS: Es hat sich leider immer noch nichts verändert - weshalb ich meine Auszeit verlängere. Ciao.

    Der vermutlich einfachste Weg wäre: Script erstellen welches ein mal beim starten von allen URL's ein "Textabbild" erstellen und bei der nächsten Prüfung einen Vergleich durchführt.


    Allerdings stellt sich die Frage ob der Vergleich wirklich nur auf Text-Änderungen relevant ist oder ggf auch andere Elemente der Webseite wichtig sein könnten?


    Welche Webseiten willst du überwachen und wozu soll das überhaupt sein (Sinn und Zweck)?

    So, nun brauche ich manchmal die Sonderzeichen des ASCII Zeichensatzes, die ich bei Windows immer über die ALT+Ziffern eingefügt habe. Das funktioniert aber nicht hier bei Raspbian, da kommt nix.

    Eingabe und Anzeige sind 2 paar Schuhe.


    Bist du dir absolut 100% sicher dass die Eingabe nicht funktioniert?

    Oder kann es vielleicht sein dass es dir nur nicht angezeigt wird?

    Naja auch ein 4000 MHz Computer könnte "zu langsam" sein wenn das Programm schlecht programmiert wurde...


    Alle bisherigen Beiträge hier befassen sich nur mit irgendeiner zyklischen Abfrage, aber keine dieser Abfragen führt tatsächlich besondere Aktionen aus.


    Dh eigentlich hättest Du dein Anliegen von Anfang an ausführlich(er) beschreiben sollen - da das nicht der Fall ist wurde nur auf das STARTZEIT Szenario eingegangen - hilft dir bei deinem Vorhaben aber nur wenig. Alle bisher gezeigten Scripts können nur ein Befehl zugleich ausführen, keine "parallelen Prozesse". Es ginge nur "Senden und derweil den Rest blockieren" oder "Empfangen und derweil den Rest blockieren"...


    Dh solange gesendet wird kann parallel nichts anderes verarbeitet werden. Dauert das Senden aber eine halbe Sekunde kannst du deine 10-50 Hz Bedingung vergessen.


    Damit parallel mehrere Zeitkritische Aktionen stattfinden können bedarf es eines weitaus komplexeren Programmes.

    Eine Fehlermeldung aufgrund der Abänderung des brains ist nicht aufgetreten.

    Wenn Ich deinen Code, unverändert, mit python3 ausführe kommt definitiv eine Fehlermeldung. Warum also nicht bei dir?


    Eine Fehlermeldung kommt nur mit python2 nicht - das Script ist aber für python3 geschrieben.


    Verstehst du jetzt wieso ich explizit sage das Du das Script falsch ausführst?


    WENN bei Dir keine Fehlermeldung erscheint dann weil DU es mit python2 ausführst!!!!

    Naja, der Programmablauf kann auch auf einem µC schlecht sein. Mehrere Interrupt Callbacks wirken sich negativ auf die Reaktionsgeschwindigkeit aus. Deshalb sollte er zumindest mal den Code aus Beitrag#28 ausprobiert haben um einen Vergleich zu sehen.

    Du brauchst nicht für jeden Pin eine Callback - die werden wenn dann eh nur nacheinander verarbeitet, es gibt also kein Vorteil durch mehrere Callbacks.

    "global" sollte man vermeiden. In der 3.Callback wäre das aktuell sowieso überflüssig.

    Die Variable-Namen irgendwie abzukürzen oder abzuhacken bringt nur Nachteile mit sich... Was erhoffst du dir dadurch?


    Orientiere dich an meinem Code, pack das in eine Queue mit dem jeweils ausgelösten Pin des Interrupts. In der while des Scripts fragst du die dann ab und verarbeitest die Messungen - das was du zZt in der 3.Callback stehen hast.


    ...normalerweise vermischt man auch nicht Deutsch mit Englisch, sondern benennt alle Variablen einheitlich in Englisch.

    ok hängt euch nicht an der sleeptime auf, ich werde die Kontakte hardware-entprellen, und kann dann auf sleeptime ganz verzichten.

    Nochmal: Das erfassen eines Flankenwechsels hat nichts mit den time.sleep() zu tun.


    Selbst wenn du die sleeptimers auf 60 Sekunden stellst verpasst du keinen einzigen Flankenwechsel und wirst trotzdem über _alle_ exakten Zeiten informiert.

    Das erfassen der Flankenwechsel erfolgt unabhängig im Hintergrund in einem eigenen Thread. Das Script selbst ist ebenfalls ein Thread und die beiden Ausgabeprozeduren sind jeweils ebenfalls Threads. Es laufen also insg. 4 Threads. Wird einer blockiert laufen trotzdem noch drei ungehindert weiter.


    Worauf es bei Dir nur an kommt ist eine exakte Zählung der Impulse. Die Auswertung wie viele Impulse es in einer bestimmten Zeit waren kann auch später erfolgen. Genau dafür kannst du meinen Code verwenden - ohne irgendwelche "sleeptimer" raus zu werfen.


    Die time.sleep() in meinem Script dienen nur der CPU Entlastung. Nimmst du die raus rotiert die while dermaßen schnell dass die CPU zu 100% ausgelastet wird - und dann läufst du Gefahr Flankenwechsel zu verpassen. Es wäre also fatal auf "sleeptime" ganz zu verzichten.

    Man könnte den Code auch so anpassen dass die while derweil blockiert wird bis ein Eintrag im Queue erfolgt, also "if not queue.empty():" weglassen, dann wäre der "sleeptime" nahezu überflüssig - natürlich weiterhin mit der CPU-Auslastungs-Einschränkung.


    Verstehst du's jetzt?

    linusg Danke habs gelesen. Leider sehe ich nicht wie klein Time.sleep sein darf. würde time.sleep(0.0005) funktionieren?

    Warum willst du das derart klein setzen? Wie gesagt beeinträchtigt das die Erfassung in keinster Weise sondern betrifft nur die Ausgabe.

    Wird hier NUR GPIO 25 angesprochen ( was mir nichts bringt) oder 25 GPIO Ports ?? (Das wäre prima)

    Nein nur ein Pin. Wie ich bereits sagte kannst du da auch eine List angeben.

    Wie klein kann die bouncetime gesetzt werden (da Events im Abstand von 20 mS zu erwarten sind würde 200mS bouncetime Events als Tastenprellen ignorieren richtig )?

    Gegenfrage: Weißt du wofür bouncetime ist? Wenn du die Auswirkungen kennst und das ganze Hardwareseitig entprellen kannst, sollte sich diese Frage in Luft auflösen ;)

    Auch bei dir, ähnlich wie bei root, verstehe ich noch nicht WO die Event Daten abgelegt werden ?

    Im Queue. Es gibt ein Queue für steigende Flanken und ein weiteres für fallende Flanken. Beide werden unabhängig von einander verarbeitet, kann man aber auch zusammenfügen - alles ist möglich :fies:

    Die Auswertung/Verarbeitung der 20x 14 I/O Zustände und des Zeitstempel erfolgt erst NACH Event 20.

    Dann musst du noch einen (bzw zwei) Zähler einbauen.


    Das dein Input in 40ms Impulsen erfolgt haben wir soweit mitgekriegt, aber das "Wozu" fehlt noch - was letztlich darüber entscheiden würde ob dein Vorhaben zeitkritisch wäre...

    Wie wichtig ist dir die Geschwindigkeit?


    Generell ist es mit RPi.GPIO durch aus möglich alle GPIO's via Interrupt zeitnah und (nahezu) in Echtzeit zu erfassen, solange in der Interrupt-Callback nichts wildes gemacht wird, denn es wird nur ein einziger Thread für die Callback ausgeführt und wenn diese blockiert wird (wegen einer Verarbeitung oder umfangreichere Ausgabe etc.) können weitere Flankenwechsel derweil verpasst werden.


    Wenn es dir nur um die Erfassung der Flankenwechsel geht und dein Vorhaben nicht wirklich Zeitkritisch ist könntest du zB sowas verwenden:


    Ansonsten wäre es wirklich besser einen µC wie den Arduino zu verwenden, wo kein Betriebssystem ausbremst.



    //EDIT: Noch ein paar Anmerkungen zum obigen Code:

    Die Erfassung eines Flankenwechsels erfolgt unmittelbar und sofort. Die Ausgabe hinkt etwas hinterher (durch das time.sleep(0.5)), was aber in keinster Weise die Erfassung beeinflusst. Das sleep ist nur dazu dar dass die jeweilige while nicht extrem schnell rotiert und 100% CPU Auslastung verursacht. Bei Bedarf kann man die Blockade auch auf zB 0.01 reduzieren aber viel niedriger sollte es nicht sein.

    Man kann für jeden GPIO-Pin eine GPIO.add_event_detect() Zeile setzen, oder bei nur einer Zeile eine List angeben.

    Zusätzlich wird für Rising und Falling ein eigenes Queue erzeugt und jeweils in einem separaten Thread abgefragt, wo dann auch die Verarbeitung/Ausgabe unabhängig erfolgt.

    Beim Flankenwechsel wird dessen exakter Zeitpunkt ins Queue mit eingefügt.

    Die while in der main() Funktion dient nur dazu dass das Script nicht weiter verarbeitet und beendet wird. Könnte man auch durch signal.pause() ersetzen, oder andere Sachen behandeln wie zB eine GUI initialisieren usw...