Hallo, ich bin erst seit heute hier im Forum angemeldet. Also habt etwas nachsicht, falls meine Frage schon irgendwo hier beantwortet wurde :) Ich plane zur Zeit die Programmierung eines PICs. Ich schwanke zur Zeit zwischen der PIC16 Serie und den 18ern. Meine Frage ist nun wieviele I/Os man braucht um mind. 21 Taster und pro Taster eine LED sowie ein LCD Display über eine 8Bit Schnittstelle zu verarbeiten. Die Taster sind in der Form OFF(ON) und das Display ist ein blau/weißes von Conrad. Der Controller soll folgendes später erledigen. 1. Wird ein Taster gedrückt soll der Controller über ein Ausgabepin eine Nachricht an ein extern verbundenes Gerät schicken. 2. Es soll eine LED abwechselnd ein und ausgeschaltet werden (pro Taster eine LED) 3. Auf dem Display soll angezeigt werden welches Programm nun aufgerufen wurde. Sind Taster in der Art Aus(An) dafür geeignet und wieviele I/Os braucht der PIC für diese Aufgaben? Danke schonmal im Voraus Christoph
@Thomas Müller >Ich plane zur Zeit die Programmierung eines PICs. Ich schwanke zur Zeit >zwischen der PIC16 Serie und den 18ern. Dazu kann ich nix sagen, kenn mich mit dem PICs nicht aus. >Meine Frage ist nun wieviele I/Os man braucht um mind. 21 Taster und pro >Taster eine LED sowie ein LCD Display über eine 8Bit Schnittstelle zu >verarbeiten. Die Taster sind in der Form OFF(ON) und das Display ist ein >blau/weißes von Conrad. Das kann eigentlich jeder PIC mit ner Handvoll IOs. Denn die Taster als auch die LEDs wird man sinnvollerweise per Schieberegister lesen bzw. Steuern. Guggst du hier. http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI >Sind Taster in der Art Aus(An) dafür geeignet und wieviele I/Os braucht Ja. >der PIC für diese Aufgaben? Ein Dutzend ist mehr als genug. MFG Falk
Willkommen, Thomas Müller (oder Christoph, was jetzt?) > Ich plane zur Zeit die Programmierung eines PICs. Ich schwanke zur Zeit > zwischen der PIC16 Serie und den 18ern. In beiden Familien gibt es Typen mit genügend I/O Ports. In welcher Programmiersprache willst Du das Ding schreiben? > Meine Frage ist nun wieviele I/Os man braucht um mind. 21 Taster und pro > Taster eine LED sowie ein LCD Display über eine 8Bit Schnittstelle zu > verarbeiten. Die Taster sind in der Form OFF(ON) und das Display ist ein > blau/weißes von Conrad. Die Farbe des Displays hat einen vernachlässigbaren Einfluss auf die Anzahl I/O ;-) Wenn Du die Taster und die Leds als Matrix organisierst, brauchst Du 10 Pins für die Taster und 10 für die Leds (jeweils in 5x5 Anordnung). Das LCD braucht noch 8+3 I/O, macht Total 31, was z.B. für den verbreiteten PIC16F877A kein Problem darstellt. Es gibt bei www.microchip.com Application Notes, die zeigen, wie man Pins sparen kann. Z.B. kannst Du die 8 Datenleitungen des LCD auch für die Tasterabfrage brauchen, da sie nur während der Datenübertragung an das LCD genutzt werden, also nicht ständig. Microchip zeigt auch, wie man Tasteneingänge und LED-Ausgänge multiplexen kann (falls überhaupt nötig, denn das erhöht die komplexität der Software). > Der Controller soll folgendes später erledigen. > > 1. Wird ein Taster gedrückt soll der Controller über ein Ausgabepin eine > Nachricht an ein extern verbundenes Gerät schicken. Oh, noch ein Pin, macht 32. Wie denn? RS232 oder so? > > 2. Es soll eine LED abwechselnd ein und ausgeschaltet werden (pro Taster > eine LED) > > 3. Auf dem Display soll angezeigt werden welches Programm nun aufgerufen > wurde. > > Sind Taster in der Art Aus(An) dafür geeignet und wieviele I/Os braucht > der PIC für diese Aufgaben? > > Danke schonmal im Voraus > Christoph Gern geschehen, viel Spass Severino
Ok, das klingt ja schonmal recht gut. Wie sieht es denn bei der Technik mit Schieberegistern mit dem Zeitverhalten aus? Da ich die Umschaltung von Effektgeräten (via MIDI) plane, wäre es schon gut, wenn hier eine möglichst geringe Zeitdifferenz zwischen schalten des Tasters und senden der Nachricht vergeht.
@Thomas Müller >das klingt ja schonmal recht gut. Wie sieht es denn bei der Technik mit >Schieberegistern mit dem Zeitverhalten aus? >Da ich die Umschaltung von Effektgeräten (via MIDI) plane, wäre es schon >gut, wenn hier eine möglichst geringe Zeitdifferenz zwischen schalten >des Tasters und senden der Nachricht vergeht. Dann nenn doch mal ein paar Zeiten. 10ms Verzögerung sind problemlos erreichbar, ggf. auch weniger. MFG Falk
Also bei den Zeiten ist natürlich je weniger desto besser. Ich denke mal, dass 10ms durchaus kurz genug sind. Was mir bei diesem Projekt am liebsten wäre ist ein PIC den man über ein USB Interface mit einem PC verbinden kann (z.B. um Presets zu kopieren, etc.) Diese Presets sagen eigentlich nur, welche Nachricht via MIDI geschickt werden soll, sobald eine bestimmte Taste gedrückt wird. Später soll vielleicht auch ein Expression-Pedal (=Poti) angeschlossen werden können so dass der Controller den Wiederstandswert errechnet und diesen dann in einen Wert von 0-127 umwandelt um damit z.B. die Lautstärke oder andere Parameter in Echtzeit zu steuern. Also wären 10ms ein guter Wert für sowas, oder? Ob Assembler oder C ist mir eigentlich egal. Ich vermute, dass Assembler für zeitkritische Anwendungen vielleicht besser geeignet ist und ehrlich gesagt hätte ich auch Lust dazu mich mit der Sprache zu beschäftigen. C ist aber auch kein Problem, da ich schon viel damit programmiert habe. Achja zu Thomas. Ist der Zweitname. Mein Fehler :o)
Thomas Müller wrote: > Diese Presets sagen eigentlich nur, welche Nachricht via MIDI > geschickt werden soll, sobald eine bestimmte Taste gedrückt wird. > Später soll vielleicht auch ein Expression-Pedal (=Poti) angeschlossen > werden können so dass der Controller den Wiederstandswert errechnet und > diesen dann in einen Wert von 0-127 umwandelt um damit z.B. die > Lautstärke oder andere Parameter in Echtzeit zu steuern. > Also wären 10ms ein guter Wert für sowas, oder? > > Ich vermute, dass Assembler für zeitkritische Anwendungen > vielleicht besser geeignet ist und ehrlich > gesagt hätte ich auch Lust dazu mich mit der Sprache zu beschäftigen. Da Du nur MIDI senden willst, ist das in Assembler ne nette Programmierübung. (Damit meine ich nicht die USB-Einbindung) 10ms sind für MIDI ein akzeptabler Wert, man geht in der Theorie von 20ms aus. Ab da werden die Latenzzeiten hör- bzw. spürbar wenn man ein MIDI-Keyboard nutzt. Ich habe bei 20ms schon meine Zweifel, aber zehn sind ok. Würde über den Daumen gepeilt für 8 Controller reichen. Die Länge der MIDI-Befehle kann ja gewaltig variieren, wenn man Controller, Noten und SySEX vergleicht. Aber gut 1ms geht immer drauf. Viel Spass bei diesem Projekt, es eignet sich echt um Assembler gut zu nutzen Gruss, Edson
@Christoph > Was mir bei diesem Projekt am liebsten wäre ist ein PIC den man über ein > USB Interface mit einem PC verbinden kann (z.B. um Presets zu kopieren, > etc.) Diese Presets sagen eigentlich nur, welche Nachricht via MIDI > geschickt werden soll, sobald eine bestimmte Taste gedrückt wird. PIC18F4x5x haben USB integriert, siehe auch: http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2124¶m=en022613&page=wwwFullSpeedUSB > Später soll vielleicht auch ein Expression-Pedal (=Poti) angeschlossen > werden können so dass der Controller den Wiederstandswert errechnet und > diesen dann in einen Wert von 0-127 umwandelt um damit z.B. die > Lautstärke oder andere Parameter in Echtzeit zu steuern. Also noch ein Pin, und mit ADC. Ok ist auch integriert. Zu PIC18 gibt es von Microchip eine kostenlose Student-Version des C-Compilers C18. Und einen ganzeh Haufen Applicaton Notes. Severino
Hallo, also zuerst einmal vielen Dank für eure Hilfen. Meine Einkaufsliste würde momentan wie folgt aussehen. Da es für USB Implementierungen glaub ich nur C-Beispiele gibt werde ich wohl das komplette Projekt damit umsetzen. PIC18F2550 Zusätzlich möchte ich noch einen oder zwei 64K EEPROM a la 24LC64P verwenden um möglichst viele Presents speichern zu können. So wie ich es verstanden habe läuft das Laden und Schreiben in einen Speicher über I2C. Laut sprut.de besitzt der PIC eine SPP welche für SPI (für die Input/Output-Erweiterung) und I2C (Speicher) genutzt werden kann. Ist die Nutzung exklusiv oder kann ich je nach Anforderung hin und her schalten? Was würde z.B. mit LEDs passieren, die ich über einen 74HC595 an und ausschalte, wenn ich den SPP als I2C nutze. Würden die LEDs dann weiter leuchten oder hab ich da jetzt irgendwas falsch verstanden? Grüße Christoph
@ Thomas Müller >her schalten? Was würde z.B. mit LEDs passieren, die ich über einen >74HC595 an und ausschalte, wenn ich den SPP als I2C nutze. Würden die >LEDs dann weiter leuchten oder hab ich da jetzt irgendwas falsch >verstanden? Die leuchten weiter. Du musst nur dafür sorgen, dass dein Programm die Finger vom LATCH Signal der Schieberegiser lässt (damit werden neue Daten vom Schieberegister in das Speicherregister geladen). Viel Erfolg Falk
>>Ich plane zur Zeit die Programmierung eines PICs. Ich schwanke zur Zeit >>zwischen der PIC16 Serie und den 18ern. >Dazu kann ich nix sagen, kenn mich mit dem PICs nicht aus. Klasse, hauptsache mal was abgelassen.
Thomas Müller wrote: > Zusätzlich möchte ich noch einen oder zwei 64K EEPROM a la 24LC64P > verwenden um möglichst viele Presents speichern zu können. Warum nimmst Du dann nicht gleich nen AT24C512 ? > So wie ich es verstanden habe läuft das Laden und Schreiben in einen > Speicher über I2C. Laut sprut.de besitzt der PIC eine SPP welche für SPI > (für die Input/Output-Erweiterung) und I2C (Speicher) genutzt werden > kann. Ich würde dazu raten, das in Software zu machen. Ist kaum langsamer oder größer, aber dafür wesentlich universeller (jeder Portpin nutzbar, portabel auf andere MCs). Ist ne gute Lernmethode, um I2C und SPI zu verstehen, d.h. man hats später viel leichter, wenn man wieder sowas braucht. Wenn einem etwas unklar ist, kann man bequem nach jedem Bit ne Testausgabe einfügen. Ich kenne zwar nur SW-SPI und SW-I2C Beispiele für 8051, AVR aber C läßt sich ja relativ einfach auf andere MC-Typen anpassen. Sprut hat bestimmt auch welche für PIC. Peter
Thomas Müller wrote: > Ob Assembler oder C ist mir eigentlich egal. Ich vermute, dass Assembler > für zeitkritische Anwendungen vielleicht besser geeignet ist Das wird gerne von C-Hassern so behauptet, aber in der Realität sind C-Programme kaum größer und langsamer (etwa 20%) als Assembler. Wichtig ist eigentlich nur, es in C so zu machen, wie man es in Assembler gemacht hätte. D.h. wenn man in Assembler ein Byte nimmt, muß man in C auch unsigned char nehmen und nicht int, long oder gar double float. Es kann daher überhaupt nichts schaden, wenn man erstmal ein bischen Assembler gemacht hat. Dann kann man sich das C-Listing angucken, ob man irgendwo zu verschwenderisch war. Ich habe zuerst Assembler gelernt und dann C, indem ich in das Listing geschaut habe, um zu prüfen, ob der Compiler mich so verstanden hat, wie ich es gemeint hatte. Und man weiß dann auch, wie so ein Compiler denkt, welche Ausdrücke er mag und welche nicht. Peter
Peter Dannegger wrote: > Das wird gerne von C-Hassern so behauptet, aber in der Realität sind > C-Programme kaum größer und langsamer (etwa 20%) als Assembler. > > Wichtig ist eigentlich nur, es in C so zu machen, wie man es in > Assembler gemacht hätte. > D.h. wenn man in Assembler ein Byte nimmt, muß man in C auch unsigned > char nehmen und nicht int, long oder gar double float. > @Peter so sehe ich das auch. Es gibt ja beides C oder Assembler Hasser. Denke die Kombination des Wissen über beide Programmiersprachen ist ideal. Denke, daß man keine andere Sprache mehr benötigt. Möchte bloss auf Dein Beispiel unter GCC mit dem BUG im Compiler hinweisen. Sowas ist zwar ärgerlich aber ein wirklich fitter Programmierer in beiden Sprachen findet das. Was aber wenn dieses Basiswissen und Verständniss fehlt? Nützt auch nix, wenn man mit dem Auto liegen bleibt und nicht weiss, daß es im Kofferraum ein Erstzrad gibt. Gruß Dirk
Also ich will hier keinesfalls sagen, dass die eine oder andere Sprache besser oder schlechter ist. Es kommt wie bei allem ja auch den VErwendungszweck und die Fähigkeiten des Programmierers an. Was mich zu der Vermutung geführt hat, dass Assembler ggf. "besser" sein könnte als C ist ganz einfach die Tatsache, dass Assembler näher an der eigentlichen Hardware ist. Ich muss zugeben, dass ich von C schon beruflich mehr Erfahrung habe und das einzige, was mich so ein wenig abschreckt Assembler zu verwenden ist die Tatsache, dass die USB Anbindung quellcodetechnisch in C bereits besser vorhanden ist.
Brauche bitte möglichst schnell eine Antwort!! Bitte zurückschreiben!! Hab nur noch eine Stunde Zeit dafür!!!! DANKE!
@ KING (Gast) >Wie steuere ich die zweite Zeile des LCD Displays an? >Brauche bitte möglichst schnell eine Antwort!! >Bitte zurückschreiben!! >Hab nur noch eine Stunde Zeit dafür!!!! Das kostet was. Setz mal die DD Adresse auf 0x40 und schreib ein paar Zeichen. MfG Falk
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.