Kernelmodul Zugriff auf serielle Schnittstelle

    Hallo,


    ich bin jetzt daran für meine selbstdesignte Hardware einen eigenen Treiber zu basteln - weiss schon ist vielleicht für einen "Neuling" unter Linux ein wenig weit ausgeholt - aber das krieg ich schon hin - ihr wisst nicht wie verbissen ich sein kann...


    Also zu meiner Frage ...
    Ich habe angefangen ein Character Device zum implementieren - entladen / laden - mittels insmod etc. kein Problem das geht ... einfach Read / Write / IoControl und Poll aufrufe auch ... jetzt will ich natürlich in dieses Gerüst meine Hardware einbinden - dafür benötige ich Zugriff auf die serielle Schnitstelle - im Userspace gehts ja über /dev/ttyS0 etc.. wie mache ich das in einem Modul? - kann ich da auch die POSIX Bibliotheken dafür nehmen? wohl eher nicht?


    worum es geht?
    http://eldo.gotdns.com/yard/



    Igor

    Hi Igor,


    Respekt :)


    Also, zwar vielleicht nicht die Antwort, die Du suchst, aber evtl. der Hinweis, wonach Du suchen solltest :-))


    Im LDP (Linux Documentation Project) findet man unter anderem Dokumenet wie "Howto write a kernel / devicedriver".


    Vielleicht solltest Du sowas mal durchackern...


    Wenn ich linux howto device driver google, sind die ersten 3 Links wohl das, was Du suchst.


    Hoffe, das hilft Dir.


    rael

    Hi,


    das Prinzip wie ich nen Kerneltreiber backe hab ich ja schon gelesen und geht soweit auch - d.h. ich kann mittels "echo" hinschreiben und mit "cat" auslesen ... jetzt geht es darum die Daten auch wirklich von der Hardware zu holen die am seriellen Port hängt - ich möchte aber nicht den Code von ttyS0. Devices kopieren müssen, sondern lieber mit meinem Treiber darauf aufsetzen...


    Igor

    Ich "muss" (natürlich freiwillig) für meine Hardware in naher Zukunft auch einen "Treiber" schreiben. Ich dachte eigentlich das ich im Userspace bleibe. Jetzt stellt sich für mich die Frage warum du nicht im Userspace bleibst? Gibts es Vorteile die du dir erhoffst? Bei deiner Anwendung werden doch nicht viel Resourcen benötigt.

    Aktuelle Systeme:
    VDR-Server: MSI KT6A Ultra FISR ; Athlon XP 2200+ ; GrKa Geforce 2 MX; 256MB DDR-SDRam Plugins: streamdev-server, remote
    2 x DVB-Budget Karte, Gentoo, Kernel 2.6.8 usw....

    Hallo,


    wenn ich im Userspace bleibe - muss ich neue Schnittstellen erfinden für den Zugriff auf meinen Userspace Treiber -- wenn ich es als Kernelmodul baue (ist auch spannender :rolleyes:) -- kann man viele der Funktionen via "cat" und "echo" bedienen - z.B. die LCD Schnittstellen ... (denke ich mir zumindest) --


    Damit wird natürlich die Hardware leichter integrierbar - in andere Software - ohne das ich "Berge" von Bibliotheken herausgeben muss ... die auf meine proprietären Api's aufsetzen. Das reduziert auch die Codeabhängigkeiten...


    (ich werde den Code auf meiner HP freigeben unter GPL ...)


    Das halte ich für persönlich für sauberer als "Usermode Treiber".


    Igor

    ich hab mir gerade mal dein projekt angesehen.
    in welcher sprache hast du denn die software für dem µC geschrieben? kann ich da bitte den quellcode haben? ich würde mir gerne die Fernbedienungssachen klauen, dann muss ich das nicht selber implementieren.
    ich hab auch nen PIC und glaube mit meiner hardware kompatibel zu ein (hab den tsop an nem interrupt-pin und timer hab ich auch noch frei).


    oha... sehe, du hast das alles in ASM geschrieben... aber da kann ich mir trotzdem noch ne menge abkucken, auch wenn ich das ganze wohl in C machen werde (ich benutze den mcc18 compiler von microchip).

    Hallo,


    für mein nächstes Projekt werde ich wohl auch den C18 nehmen - da ich dann einen 18F4550 als Basis nehme und via USB an den PC gehe ... das wird noch nen Zacken heftiger...
    Klar kannst du den Code nehmen - kein Problem - steht auf meiner HP zum download...
    sogar noch kommentiert - auch wenn ich die IR-Dekodierung nicht via Interrupt gemacht habe...


    Andre´

    hi,
    also es ist 'meine' hardware, aber viel selber gemacht habe ich nicht. soll heissen, ich hab mir aus dem weiten WWW viele ideen geklaut und zusammengesteckt.


    hier ist mal ein link zu meinem projekt: t6963c am microcontroller will nicht


    leider hab ich echt schon lange nix mehr dran gemacht, also fast 3 monate. aber ich denke, ich werde die nächsten wochen das ganze mal wieder ein wenig weiter vorranbringen.


    wenns fertig ist soll es unter anderem können:
    - aufwecken des rechners per RTC
    - aufwecken des rechners per FB
    - gLCD support für vdr
    - gLCD bei ausgeschaltetem rechner
    - tasten für den vdr
    - LEDs für die statusanzeige
    - ...beliebiges sonst (I2C)

    Servus Igor,


    da dein Rechner offenbar nicht mehr online ist, kann ich nur vermuten, um was für eine Schaltung es sich handelt.


    Du hast prinzipiell zwei Möglichkeiten für den Treiber: Ein eigenständiges Kernel-Modul oder einen Userspace-Daemon.


    Wenn du das im Kernel lösen möchtest, kannst du dich einfach beim Modul für die serielle Schnittstelle bedienen. Im einfachsten Fall reicht es, die passende Header-Datei zu includen -- das erspart dir die Mühe, das Rad für die serielle Kommunikation noch einmal zu erfinden. Du benutzt also quasi eine API zum serial-Modul. Der Nachteil: ändert sich irgend etwas im Kernel an der API, lässt sich dein Treiber nicht mehr compilieren. Du musst also quasi jeder Kernel-Version hinterherrennen -- nicht so toll.


    Sofern es sich um eine "normale" Kommunikation mit der seriellen Schnittstelle handelt -- deine Hinweise mit echo und cat sowie /dev/ttyS0 legen mir das nahe -- würde ich jedoch auf ein Kernel-Modul verzichten. Die Kommunikation über ein serielles Protokoll mit der Schaltung ist sehr viel universelle und flexibler, wenn du tatsächlich das Device /dev/ttyS? benutzt. Überleg mal, evtl. willst du ja irgend wann auch mal das Gerät an einem USB-Seriell-Adapter ansteuern können, dann müsstest du einen weiteren Kernel-Treiber schreiben -- im Userspace hingegen benutzt du einfach nur ein anderes Device.


    Wenn du jetzt im Userspace arbeitest, sagen wir mal mit einem Daemon der mit Root-Rechten läuft, kannst du trotzdem noch ein "Device" unter /dev/ zur Verfügung stellen, damit andere Programme mit dir kommunizieren können: Du benutzt einfach einen FIFO. Der funktioniert in zwei Richtungen, d.h. jemand kann was reinschreiben und auch was rauslesen, das Dingen verhält sich im Normalbetrieb wie ein herkömmliches Character Device.


    Mit einem herkömmlichen Daemon und einem FIFO solltest du also in der Lage sein, sehr flexibel zu arbeiten und noch dazu von der Kernel-Version völlig unabhängig.


    Viele Grüße, Mirko

    Guten Morgen,


    mmh - klingt auch logisch - dann hab ich nur noch das Problem wie stelle ich die restlichen Funktionen zur Verfügung... die Hardware ist kein reiner IR-Empfänger - sondern ähnelt dem was Slime bauen tut doch sehr - d.h. die Hardware liefert nicht nur Daten - sondern z.T. ist es eine echte zweiwege Kommunikation d.h. du schickst ein Paket und bekommst eines wieder als Antwort... allerdings müssen diese Funktionen synchronisiert werden - d.h. ich muss irgendwie sicherstellen das sich immer nur ein Aufrufer in einem solchen Request / Response Zyklus befindet - wie funktioniert das mit einem solchen Pseudo Device was ein Userspace Programm anbieten kann?


    Igor

    Hallo,
    so nach einem Ausflug zu FIFO aka. Pipes - hätte ich da noch ein Problem - wenn ich die PIPE zum schreiben öffne blockiert mein Process solange bis ein Client die selbe Pipe zum lesen öffnet - das gefällt mir nicht wirklich. -> also habe ich beim öffnen O_NONBLOCK angegeben, damit kehrt open zwar sofort zurück - aber wenn ich mit cat /dev/yardir darauf warte das was kommt passiert einfach nichts.... obwohl mein "Server"Prozess fleissig in die Pipe schreibt...??


    Damit ist erstmal der IR-Empfang geklärt - wie mache ich das aber mit den restlichen Funktionen meiner Hardware -? wo ich immer einen kompletten Request/Response Zyklus habe? -- muss ich da noch zwei FIFO machen die ich für jeden Aufruf öffnen und schliessen muss? -- oder gibts da noch einen eleganteren RemoteProcedureCall ... unter Windows habe ich einfach nen ComServer in die ROT (Running Object Table) eingetragen - den kann jeder andere Prozess unter Windows finden und die Funktionen aufrufen? -- gibt es sowas ähnliches auch für Linux? (ausser Corba - was wohl ein wenig mit Kanonen auf Spatzen schiessen wäre.)


    Igor

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden