hallo zusammen, ich habe zur zeit folgendes problem: im unternehmen wird ein embedded system verwendet mit einem stm32 controller und einem einfachen OS mit minimalem taskmanager. "user tasks" werden alle 100ms und "realtime tasks" alle 10ms aufgerufen. ein gleichstrommotor wird wie folgt angesteuert (als "realtime task"): 1. der erste ausgang steuert die drehrichtung 2. der zweite ausgang steuert das ein-/ausschalten 3. ein eingang misst die stromaufnahme des motors...fährt dieser gegen den block erhöht sich die stromaufnahme und die software schaltet den motor ab. ich möchte nun die ganze steuerung auf ein embedded linux system portieren und frage mich ob ich z.b. für die motoransteuerung ein kernel-treiber schreiben muss? für die applikationsebene wollte ich z.b. folgende Fkt. zur verfügung stellen: - uint8_t close(...) //motor nach links drehen - uint8_t open(...) //motor nach rechts drehen steuer ich den motor nur in der applikation, kann der ablauf durch ein interrupt unterbrochen werden und es ist somit keine garantie gegeben, dass der motor "schnell möglichst" abschaltet. bleibt somit nur noch der weg ein treiber zu schreiben und ihn in die kernelebene zu integrieren? außerdem frage ich mich ob es sinnvoll ist ein treiber zu schreiben, der dann 3 GPIO steuert/kontrolliert? hoffe ihr habt ein paar anregungen für mein problem :) gruß adam p.
Gast
#2699294
Nimm einen zweiten kleinen Controller und steuer den per IIC, SPI, etc. an. Der zweite Controller übernimmt die Fail-Safe Sachen.
Gast
#2699302
Hallo, zuerst müsstest du klären, welche Anforderungen bestehen für Endschalter und manuelles Not-Aus. Womöglich erledigt sich dann die ganze Frage, weil diese mit der Softwarelösung nicht realisierbar sind bzw. vom TÜV etc. nicht abgenommen werden. Gruss Reinhard
Uahh, Betriebssystem für tatsächlich Zeit kritische realtime tasks? Genau aus dem genannten Grund mach ich sowas nicht mehr. Der Auffwand einem Betriebssystem beizubringen, dass es bitte keine Zeitsynchronisation, daemon security updates oder usb datenbank updates durchführen soll, während ich grade IRGENDWAS wichtiges tue ist einfach viel zu groß. Jede verlässliche realtime Lösung, die ich bisher gesehen habe, ist in einen monolitischen Block geprügelt worden. Die turnaround Zeiten sind sonst nicht zu garantieren. Thor
- also die anforderungen sind da nicht so kritisch, hat so erst mal nichts mit dem tüv zu tun. - es muss sich nicht um harte echtzeit handeln! ich bin der meinung ein modultreiber der dem kernel gemeldet wird, müsste vollkommen reichen...die frage war, ob es evtl. noch andere lösungen gibt - anscheinend nicht :) ein embedded linux system wäre eine verbesserung von bestimmt 90% zu dem jetzigen bastelprodukt, da mache ich mir um die richtige real-time funktionalität die geringste sorgen.
Zwei schrieb: > Nimm einen zweiten kleinen Controller und steuer den per IIC, SPI, etc. > an. Der zweite Controller übernimmt die Fail-Safe Sachen. die idee ist gut, aber es geht bei so einer produktion auch um kosten...wenn ich schon ein teureres embedded linux board einführen will und dann noch sage da wird noch ein extra "fail-safe" µc benötigt, dann bekomme ich das nie durch.
Wenns ein Embedded Linux sein soll, ist ein Treiber jedenfalls die 'offizielle' Methode, um auf Hardware zuzugreifen. Mein kleiner uCSimm Robotor hat z.B. mit den Sensoren und den Motoren über /dev/misc devices kommuniziert und abfragen kann man in /proc. So kann jedes Userspace Programm die Peripherie benutzen. http://www.schoeldgen.de/index.php?content=robot.dir
ja super...danke matthias :) da weiß ich zumindest, dass ich nicht ganz falsch liege. ich wollte schon der eleganten lösung nachgehen, da es somit später in der app-ebene viel sortierter zugeht.
Gast
#2699406
Adam P. schrieb: > Zwei schrieb: >> Nimm einen zweiten kleinen Controller und steuer den per IIC, SPI, etc. >> an. Der zweite Controller übernimmt die Fail-Safe Sachen. > > die idee ist gut, aber es geht bei so einer produktion auch um > kosten...wenn ich schon ein teureres embedded linux board einführen will > und dann noch sage da wird noch ein extra "fail-safe" µc benötigt, dann > bekomme ich das nie durch. Das Ganze wird doch sowieso noch ein I/O Board haben? Tu den einfach mit auf das I/O Board. Oder nenne den zusätzlichen uc einfach Watchdog :-()
:-D nunja, würde ich ein fertiges embedded board nehmen, müssste noch ein I/O board (mit leistungsstufen) gebaut werden, das stimmt. würden wir jedoch ein eigenes board planen, dann würde ich halt nur den einen µc einsetzen, z.b. at91. jedoch habe ich das gefühl, dass z.b. bei einem at91sam9g45 nicht mehr viele I/O übrig bleiben würden, nach dem anschliessen von flash, ram, usb, rs232, ethernet, tft, sd card, ...etc. es werden ca. 2-4 A/D eingänge, 10 digi eingänge und 10-16 ausgänge gebraucht. stimmt, um ein externes board wird man nicht rum kommen, oder?
Moin, ich hab mal vor ner Weile nen Kerneltreiber für ne PWM-Motorensteuerung gehackt, hätte dazu folgende Tips in Stichworten: - Generische GPIO-API für den Treiber verwenden (siehe http://docs.blackfin.uclinux.org/doku.php?id=gpio) - ioctl() für "links"/"rechts" verwenden, bloss nicht open/close, das wäre ein böser Hack. - Für den "Not-Aus" einen IRQ-Handler im Kernel anmelden - Echtzeitgarantie von wenigen uS kriegt man mit der Xenomai-RT-Erweiterung gut hin. Falls der Treiber im "klassischen Linuxmodell" nicht die nötige Echtzeit bringt, portiert man ihn relativ leicht auf das Xenomai-Treibermodell. Von der Zuverlässigkeit her ist Xenomai definitiv industrietauglich. Aber klar, einige Zertifizierer würden schreien, dass das nicht in ein Flugzeug gehört... Grüsse, - Strubi
vielen dank für den link für die docu von blackfin :) das mit open/close hast du evtl. falsch verstanden - ich wollte nicht die fkt. open() close() für das schreiben auf das device nutzen! unser motor schliesst oder öffnet einen hebel, darauf war es bezogen. (da habe ich wohl nicht aussagekräftige fkt.-namen verwendet :-D mein prof. hätte mir wohl auch die ohren lang gezogen) werde den treiber erst mal so testen und evtl. je nachdem was die testläufe bringen evtl. xenomai verwenden. eine frage hätte ich noch: wie ist die vorgehensweise in der industrie - wird dort zum linux board eine weitere I/O karte (bzw. ein weiterer µc) verwendet der dann über i2c oder rs485 angesprochen wird? (bedingt durch eine größerer anzahl an ein-/ausgängen die gebraucht werden)
Gast
#2699741
Adam P. schrieb: > es werden ca. 2-4 A/D eingänge, 10 digi eingänge und 10-16 ausgänge > gebraucht. stimmt, um ein externes board wird man nicht rum kommen, > oder? Damit macht man sich auch unabhängiger von Lieferanten, und die Auswahl an entsprechenden Linux Platinen wird größer. Und Linux Platinen müssen nicht teuer sein: http://shop.8devices.com/
Realler schrieb: > Und Linux Platinen müssen > nicht teuer sein: http://shop.8devices.com/ ok, der preis ist wirklich niedrig. jedoch hat das board nur 8mb flash, was bleibt den da noch übrig, wenn das linux img geflasht wurde? irgendwo muss ja auch noch das user programm hin und das ist nicht allzu klein mit sämtlichen daten und menu-files. edit: ich denke eher, dieses board ist für bastelzwecke super geeignet, jedoch nicht für ein industriellen einsatz (maschinensteuerung)
Adam P. schrieb: > Zwei schrieb: >> Nimm einen zweiten kleinen Controller und steuer den per IIC, SPI, etc. >> an. Der zweite Controller übernimmt die Fail-Safe Sachen. > > die idee ist gut, aber es geht bei so einer produktion auch um > kosten...wenn ich schon ein teureres embedded linux board einführen will > und dann noch sage da wird noch ein extra "fail-safe" µc benötigt, dann > bekomme ich das nie durch. Ach, so ein kleiner SOT23-6 wird da wohl noch übrig sein: http://ww1.microchip.com/downloads/en/DeviceDoc/41270E.pdf Für genau solche Sachen sind die gemacht, und Safety ist dann kein Thema mehr. fchk
Gast
#2699795
Adam P. schrieb: > ok, der preis ist wirklich niedrig. jedoch hat das board nur 8mb flash, > was bleibt den da noch übrig, wenn das linux img geflasht wurde? > irgendwo muss ja auch noch das user programm hin und das ist nicht allzu > klein mit sämtlichen daten und menu-files. Openwrt ist für solche Kisten optimiert, z.b. busybox, uclibc und spezielle Filesysteme (squashfs und overlayfs). Ich bin immer wieder begeistert wie klein man doch ein lauffähiges Linux bekommt. Wie groß ist deine jetzige Applikation ? (Squashfs komprimiert sehr effizient)
wenn ich nun die kontrolle für die externe HW an einen zweiten µc abgebe und der mir nur den aktuellen status übermittelt...dann brauch ich mir doch keine mühe machen mein embedded linux mit xenomai oder ähnlichem zu versehen - oder?!
Adam P. schrieb: > wenn ich nun die kontrolle für die externe HW an einen zweiten µc abgebe > und der mir nur den aktuellen status übermittelt...dann brauch ich mir > doch keine mühe machen mein embedded linux mit xenomai oder ähnlichem zu > versehen - oder?! Ja. Mikrocontroller sind von Haus aus echtzeitfähig, vorausgesetzt man programmiert sie richtig. Gruß Oliver
Gast
#2699802
Adam P. schrieb: > ich denke eher, dieses board ist für bastelzwecke super geeignet, jedoch > nicht für ein industriellen einsatz (maschinensteuerung) Welche Boards hast du bisher im Auge ?
Realler schrieb: > Wie groß ist deine jetzige Applikation ? die momentane ist nicht so groß, mit allem ca. 512kb - 1mb. bei der verwendung von linux würde jedoch ein tft eingesetzt werden, aber da könnte man ja img files etc auf eine SD karte auslagern.
Gast
#2699820
Adam P. schrieb: > wenn ich nun die kontrolle für die externe HW an einen zweiten µc abgebe > und der mir nur den aktuellen status übermittelt...dann brauch ich mir > doch keine mühe machen mein embedded linux mit xenomai oder ähnlichem zu > versehen - oder?! Die Steuerung der Schnittstelle zum 2. uc kann komplett im Userspace erfolgen, damit kann der Unix-Part leicht portierbar gehalten werden. Sehr vorteilhaft wenn ein anderes Board genutzt werden sollte. (Weiterentwicklung, Lieferantenausfall, Board hat Bugs.)
Adam P. schrieb: > eine frage hätte ich noch: > wie ist die vorgehensweise in der industrie - wird dort zum linux board > eine weitere I/O karte (bzw. ein weiterer µc) verwendet der dann über > i2c oder rs485 angesprochen wird? (bedingt durch eine größerer anzahl an > ein-/ausgängen die gebraucht werden) Eine Strategie ist die Verwendung von Bussystemen und intelligenter Peripherie, um Verkabelungsaufwand zu vermeiden. Schau, wie es heute in einem modernen Auto gemacht wird. Da hast Du kein Blinkerrelais mehr, das links oder rechts blinkt, sondern das Steuergerät sendet ein "links blinken" auf dem CAN-Bus. In den Lampenbaugruppen sind Controller, die den Befehl empfangen, und die Baugruppen vorne links und hinten links lassen es dann blinken. Die können dann aber auch zurückmelden, wenn eine Blinkerbirne kaputt ist (Strommessung), und geben den Fehler dann an das zentrale Steuergerät zurück, das dann eine Meldung im Fahrerinformationssystem-Display anzeigt. Wenn Du große Motoren steuerst, ist es sinnvoll, die Steuerelektronik möglichst dicht an den Motor zu bringen oder sie sogar in den Motor zu integrieren. Das hat z.B. EMV-Vorteile - die PWM-Ansteuerung von Leistungshalbbrücken zB erzeugt ziemlich viel "Noise". Du hast dann also einen Antrieb mit CAN-Bus, Modbus-RTU, Profibus etc, und sowas gibts auch fertig zu kaufen. Genauso ist es mit intelligenten Sensoren mit Aktor-Sensor-Interface (ASI). Eine mögliche Strategie für Dich wäre also, die direkte Hardwareansteuerung inklusive der Safety-kritischen Sachen auf einzelne kleine 6/8/14-Pinner auszulagern (hier bieten sich die PIC10 und PIC12 Serien an, die sind klein und billig, der erwähnte PIC10F220 im SOT23-6 kostet in Volumenstückzahlen 0.34U$) und über irgendeinen Bus anzubinden. CAN ist relativ teuer, die Automobilindustrie hat als Low-End-Ergänzung LIN erfunden, und ein LIN-Slave kann auch ohne Quarz und HW-UART implementiert werden. So machen es jedenfalls andere Leute. fchk
Realler schrieb: > Welche Boards hast du bisher im Auge ? im moment suche ich erst mal nach einem entwicklungsboard. falls dann soweit alles funktioniert gäbe es mehrere möglichkeiten: 1. nur ein chipboard kaufen und das motherboard selbst entwicklen 2. ein fertiges board kaufen und nur die I/O erweiterung selbst entwickeln. bin mir bei den entwicklungsboard noch nicht so schlüssig: mit lcd unterstützung im µc: - http://www.samicc.com/product/module_board/sbc_board - http://www.ic-board.de/index.php?cat=c28_ARM-Starterkits.html ohne, jedoch gibt es ja genug tft mit integriertem controller und sd karten anschlusss: - http://www.taskit.de/produkte/index.htm - http://www.deditec.de/de/embedded/prod.html - http://www.mikroe.com/eng/categories/view/16/arm-development-tools da gibt es ja so viele...
Gast
#2699827
Adam P. schrieb: > ein tft eingesetzt Graphik, sag das doch gleich.
momentan wird ein 128x64px glcd verwendet, mit unserer schriftart können wir max 21 zeichen je zeile, bei 5 zeilen darstellen...dies ist nicht sehr kompfortabel, aber es funktioniert. die priorität liegt auf dem linux system, wie man später z.b. ein 4-5" tft anschliesst muss man mal sehen. --- bin für vorschläge bezüglich eines entwicklungsboards dankbar :)
Gast
#2699841
Adam P. schrieb: > die priorität liegt auf dem linux system, wie man später z.b. ein 4-5" > tft anschliesst muss man mal sehen. Mit Wlan können auch Tablets, Notebooks und Smartphones als Display genutzt werden.
Realler schrieb: > Mit Wlan können auch Tablets, Notebooks und Smartphones als Display > genutzt werden. das wäre sicherlich eine möglichkeit, jedoch stehen unsere geräte meistens im freien (kein wlan/ethernet). außerdem muss dem bediener die möglichkeit gegeben werden, das gerät auch ohne weiterer hardware einstellen/bedienen zu können.
Hi Adam, > vielen dank für den link für die docu von blackfin :) Bittschee, ich vergass zu erwähnen: Was da steht, gilt auch für ne Menge anderer Architekturen (ARM, MIPS, ...). Finde nur die Doku vorbildlich. > > das mit open/close hast du evtl. falsch verstanden - ich wollte nicht > die fkt. open() close() für das schreiben auf das device nutzen! > unser motor schliesst oder öffnet einen hebel, darauf war es bezogen. > (da habe ich wohl nicht aussagekräftige fkt.-namen verwendet :-D mein > prof. hätte mir wohl auch die ohren lang gezogen) > Sorry, da dachte ich wohl gleich ans Schlimmste :-) > werde den treiber erst mal so testen und evtl. je nachdem was die > testläufe bringen evtl. xenomai verwenden. > Ich hab da mal einige Tests gemacht, wenn du mit bis zu 6 ms Latenz leben kannst (abhängig von der Architektur bzw. Taktfrequenz) , brauchste kein Xenomai. Aber Prozesse, die irgendwie nebenbei aufs Flash oder i2c zugreifen, können trotzdem noch längere Hänger provozieren. Die Garantie, dass dein IRQ wirklich binnen x us abgearbeitet wird, hast du nur mit Xenomai oder den RT_PREEMPT-Erweiterungen (von denen ich nach wie vor noch nicht überzeugt bin) > eine frage hätte ich noch: > wie ist die vorgehensweise in der industrie - wird dort zum linux board > eine weitere I/O karte (bzw. ein weiterer µc) verwendet der dann über > i2c oder rs485 angesprochen wird? (bedingt durch eine größerer anzahl an > ein-/ausgängen die gebraucht werden) Also aus Bequemlichkeit/Kostengründen haben wir alles unter Linux auf dem Blackfin laufen lassen. Sobald das Zeug aber auf keinen Fall crashen oder für mehrere Sekunden ausfallen darf, ist Linux zu sehr komplexe Spatzenkanone, dann lohnen sich Softwareklimmzüge wie Watchdogs im Gegenzug zu einem weiteren MSP430 o.ä. oft nicht. Letzteren kann man prima per i2c oder SPI (simpler und sicherer) aus Linux konfigurieren, und er kann die "basic"-Steuerung übernehmen, während Linux im Powersave schläft, oder gerade wegen eines Absturzes durch den Watchdog neu gebootet wird. Sowas kriegst du sicherlich besser zertifiziert (wenn überhaupt nötig), und aufs gesamte gesehen sparst Du dann an den Test-Cases viel Zeit (somit Geld).
ich habe die idee mit linux nur aufgegriffen, da unser system meiner meinung nach zusammengewürfelt wurde. eigen hergestellte hardware mit eigen software die wiederrum auf einer älteren version basiert. "webserver" ist eine erweiterungskarte und das crashed auch immer wieder gerne. im groben und ganzen...viel programmierarbeit und hinten kommt doch nichts fertiges bei rauß. so dachte ich mir...linux hat bereits usb, ethernet, webserver etc., da muss man das rad ja nicht neu erfinden und die leistungsstufen usw. kann man ja vom alten system evtl. übernehmen. das linux sollte eigentlich nur die human/machine schnittstelle übernehmen und so aufgaben wie usb, web etc. das schnellste bei uns ist momentan 10ms taskaufruf.
Gast
#2699950
Schnapp dir einen X86 PC und hänge das bisherige Board mit irgendeiner Schnittstelle dran und mach irgendwas in Richtung Prototypen.
Dirk schrieb: > Schnapp dir einen X86 PC und hänge das bisherige Board mit irgendeiner > Schnittstelle dran und mach irgendwas in Richtung Prototypen. ??? was soll das für ein sinn haben, das ist doch schon längst passiert... das ist ja sinn der ganzen sache, dass ich das jetzige board nicht mehr nutzen möchte.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.