C++, CAN bus, flexibles Programm zum Empfangen und Senden von CAN-frames

  • Hallo Forum

    ich bin an der Entwicklung eines C++ Programms mit Raspb 3 und RS485_CAN_HAT

    Leider kann ich vom CAN-bus nicht zyklisch alle Frames empfangen weil mein C++ Programm nicht funktioniert: Folgendes habe ich gemacht:

    Ich habe ein setInterval mit 1ms programmiert, das zyklisch den can_receive.c ausführt. Ich weis nicht ob das so korrekt ist. Im can_receive.c ist ein Eingangsfilter für ID frame einzustellen. Also kann ich nur einen frame einlesen...das ist so nicht gewollt...meine Frage ist, wie kann ich mehrere frames empfangen und wie ich das alles vom timing handeln muss...auch weis ich nicht, ob ich das Empfangen über den Interrupt gestalten kann...ich konnte bisher nur Informationen von waveshare beziehen.

    Als 2. Funktion sende ich frames über den can_send.c...auch hier weis ich nicht wie ich das handeln muss...ich glaube es findet eine Kollision mit can_receive.c statt und habe deswegen die Sendebefehle auskommentiert


    könnte mir da bitte jemand helfen...oder hat jemand ein Beispielprogramm

  • Hallo Thomas,


    ich möchte nicht im Detail auf Deine Programme und Probleme eingehen.


    Nur ein paar Denkanstöße:


    Eine Interrupt-Service Routine (ISR) sollte nur kurze Zeit dauern (Staus abfragen, Status setzen, Zähler weiterzählen, ...). Wenn Dein Programm im ms-Zyklus arbeitet, sollte die ISR deutlich unter 1 micro-Sekunde (so ca. 50 ns) dauern.

    Du hast nichts geschrieben, wie lange die Übertragung bzw. Verarbeitung eines Frames dauert. Wahrscheinlich ist das der geschwindigkeitsbestimmende = langsamste Schritt.


    Du hast einen Designfehler in Deinem Ansatz, wenn Du / Deine Programme:

    - davon ausgehen, innerhalb einer Interrupt-Bearbeitung noch auf weitere Interrupts reagieren können sollen

    - die Dauer eines ISR länger als ca. 1% Deiner 1 ms Dauer dauert.


    Üblicherweise schaltet die ISR den Interrupt-Handler aus, reagiert auf den Interrupt. Erst danach wird der Interrupt wieder eingeschaltet.


    Von welchem Interrupt redest Du überhaupt?

    - Timer-Interrupt

    - Ereignisgetriebener Interrupt?


    Wenn Du das alles berücksichtigst: Wie sehen Deine Programme dann aus? Welche Probleme verschwinden - welche bleiben?


    Beste Grüße


    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    • Icon-Tutorials (IDE: Geany) - GPIO-Library - µController-Programmierung in Icon! - ser. Devices - kein Support per PM / Konversation

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • Üblicherweise schaltet die ISR den Interrupt-Handler aus, reagiert auf den Interrupt. Erst danach wird der Interrupt wieder eingeschaltet.

    man darf aber auch den ISR wieder einschalten wer genau weiss was er tut!

    Mache ich ja in meiner wordclock die alle 10ms zur Verarbeitung von Tasks einen IRQ bekommt.

    Damit mir aber in dieser Zeit kein IR Impuls entgeht schalte ich den IRQ wieder ein, das ist der Einzige der noch in meinem Programm vorhanden ist und deren Verarbeitung gemessene 1,5µs dauert was nicht stört, nur die 10ms IRQ würden sonst IR Impulse sperren, denn da kann sich der µC auch mal bis zu 1ms aufhalten.

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Hi Jar,


    eben: wer genau weiß, was er tut, kann/darf/wird alles tun, was er möchte.


    Alle anderen sollten innerhalb enger Grenzen Fortschritte machen, bevor die Grenzen erweitert werden.


    Beste Grüße


    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    • Icon-Tutorials (IDE: Geany) - GPIO-Library - µController-Programmierung in Icon! - ser. Devices - kein Support per PM / Konversation

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • tolvo das geht so alles nicht. Man dengelt keine Programme, die dann auch noch zeitkritisch laufen sollen, mittels permanent gestarteter Prozesse aneinander.


    Und wenn diese Programme dann fuer sich auch nochmal jedes mal diverse Prozesse zu spawnen und auf deren Beendigung zu warten (system calls all ueberall), dann verbringst du ewig viel Zeit damit, Prozesse zu erzeugen und wieder runter zu reissen. Alleine das ueberzieht schon dein gesamtes Zeit-Budget.


    ISR Routinen gibt es in der Linux User Space Programmierung nicht. Die kann und muss man daher auch nicht disablen oder so. Mit solchen Dingen beschaeftigt sich der Treiber im Kernel.


    Das gesamte aufsetzen mit reihenweise Konfigurationsanweisungen im Code gehoert natuerlich ins System, einmal am Anfang. ZB per systemd-Unit.


    Die Programme muessen in *ein* gemeinsames Programm ueberfuehrt werden, welches das can0-Device dauerhaft geoeffnet haelt. Und schon kannst du da einfach nacheinander die anliegenden Nachrichten aus einem kernel-internen Buffer lesen. Beschrieben en detail hier: https://www.kernel.org/doc/Documentation/networking/can.txt


    Wobei ein Programm nicht heisst eine Datei, die so unstrukturiert und wirklich aussergewoehnlich unuebersichtlich wie main.cpp ist. Da gehoert deutlich mehr Struktur rein. Ich wuerde auch gerne mehr ueber deinen eigentlichen Anwendungszweck erfahren. Das du da C++ nimmst, obwohl vieles Stringverarbeitung und JSON und so ist - da wuerde ich eher Python fuer in Anschlag bringen. Das hat sicher nicht seine Staerken, etwas 1000 mal pro Sekunde zu machen - aber das es das muss wuerde ich in Frage stellen.

  • Vielen Dank für Eure Infos


    Habe mein Programm umgeschrieben auf CAN RAW Socket


    Funktioniert sehr gut...Danke:danke_ATDE: