Hardware > Firebee
Lieferverzögerung aufgedeckt!
Mathias:
Hi SolderGirl!
Das Problem ist nicht der Code für PS/2 soweit ich das verstanden habe, sondern die Integration mit den weiteren Komponenten. Der PIC auf der FireBee ist ja für mehrere Dinge zuständig wie Du hier sehen kannst: http://firebee.org/fb-bin/page?label=Zoom_inside_the_PIC&lng=DE
Der GamePort und PS/2 sind derzeit nicht implementiert. Der Rest liegt in Assembler vor. Den Code für PS/2 selber gibt es ja schon in diverse Projekten auch als Open Source. Es haben schon ein paar Leute angefangen damit, aber irgendwie scheint es immer an der Integration mit den anderen schon laufenden Komponenten in Assembler zu scheitern, wenn ich die Entwickler richtig verstanden habe?
Börr:
Ja, die Herausforderung dabei ist für mich Assembler. Es liegt auch eine Codebasis in C vor, aber die läuft nicht. Ich habe angefangen anhand des funktionieren Assembler Codes den C Code zu debuggen, aber da der PIC einige andere Chips initialiseren muss, hing es schon beim Booten des Systems........
SolderGirl:
Oh ja, das Problem kenne ich nur zu gut. Sobald man versucht, mehrere Funktionen in einem PIC unterzubringen, wird er extrem zickig. Vor allem muß man auf sehr kurze IRQ-Handler achten, die IRQ-Flags müssen genau richtig abgefragt werden, und selbst dann ist es noch nicht sicher das es läuft.
Genau aus diesem Grund habe ich damals mein DevelOS geschrieben. Das implementiert eine Software-Pipeline, sozusagen einen FIFO für Funktionsaufrufe. Dadurch muß der IRQ-Handler selbst so gut wie nichts machen, sondern nur jeweils ein Event in die Pipeline setzen. Die Events werden dann im Main-Programm asynchron von den Interrupts verarbeitet. Auf die Art habe ich schon ein LCD, Keyboard, UART und AD-Wandler gleichzeitig zum laufen bekommen.
Börr:
--- Zitat von: SolderGirl am Do 28.07.2016, 13:23:45 ---Genau aus diesem Grund habe ich damals mein DevelOS geschrieben. Das implementiert eine Software-Pipeline, sozusagen einen FIFO für Funktionsaufrufe. Dadurch muß der IRQ-Handler selbst so gut wie nichts machen, sondern nur jeweils ein Event in die Pipeline setzen. Die Events werden dann im Main-Programm asynchron von den Interrupts verarbeitet. Auf die Art habe ich schon ein LCD, Keyboard, UART und AD-Wandler gleichzeitig zum laufen bekommen.
--- Ende Zitat ---
Nice, aber bestimmt in c?
SolderGirl:
--- Zitat von: Börr am Do 28.07.2016, 17:42:40 ---
--- Zitat von: SolderGirl am Do 28.07.2016, 13:23:45 ---Genau aus diesem Grund habe ich damals mein DevelOS geschrieben. Das implementiert eine Software-Pipeline, sozusagen einen FIFO für Funktionsaufrufe. Dadurch muß der IRQ-Handler selbst so gut wie nichts machen, sondern nur jeweils ein Event in die Pipeline setzen. Die Events werden dann im Main-Programm asynchron von den Interrupts verarbeitet. Auf die Art habe ich schon ein LCD, Keyboard, UART und AD-Wandler gleichzeitig zum laufen bekommen.
--- Ende Zitat ---
Nice, aber bestimmt in c?
--- Ende Zitat ---
Ja, komplett in MPLAB-X in C geschrieben
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln