MODDING-FAQ FORUM

Also Leute,

Da ich nun endlich meinen neuen PC habe, kann es mit dem Modden ja los gehen.
Und da jeder weiß, dass es die inneren Werte sind die Zählen, will ich mit der Lüftersteuerung anfangen.

Aber ich will keine gewöhnliche Lüftersteuerung!
Folgende Punkte sind mir wichtig:

-(relativ) einfacher Aufbau:
  Damit jeder meine LüSteu auch mit einfachen Mitteln nachbauen kann.
  (Ich habe selbst keine Werkstat zu Verfügung, also ist das nicht ganz uneigennützig ;))

-modularer Aufbau:
  Inspiriert von der LV2 hatte ich an ein System mit Steckkarten gedacht,
  damit jeder seine Lüsteu nach seinen Bedürfnissen zusammensetzen kann.

-billige gut beschaffbare Teile:
  Der einfachste Aufbau bringt nichts, wenn die Teile ein Vermögen kosten,
  oder nur über einen Importeur aus dem fernen Osten zu beschaffen sind.

-digital:
  Bis jetzt hätte ich auch einfach eine LV2 bauen können,
  aber, da ich mir sowieso vorgenommen hab mich mit uC's zu beschäftigen,
  will ich eine digitale Lüftersteuerung auf Basis eines AVRs bauen.
  Dann kann die Lüftersteuerung auch geich die ansteuerung des LCD übernehmen

Ich habe mir gedacht das ganze auf Basis des AVR Mega 8 zu realisieren,
weil es der günstigste Mega ist den es bei Reichelt im DIP-Gehäuse gibt.
Dadurch erfülle ich auch die Punkte 1 und 3 ;)

Der Mega 8 hat 23 I/O-Pins, von denen 4 für andere Funktionen drauf gehen.
(1xReset, 2xUART, 1xexterner Takt)

Bleiben 19 I/Os mit denen ich 4 4-Bit-breite Anbindungen zu den Steckkarten(folgend ganz unromantisch Slots genannt) und 3 Steuerungs-Taster realisieren will.

Nacher soll man den AVR nur ein Mal programmieren müssen.
Dann sagt man dem AVR über den COM-Port, welche Karten in welchen Slots stecken.
Der uC lädt dann selbst mit der eindeutigen TreiberID für jeden Slot den richtigen Treiber.
(Dies habe ich mit Sprungmarken realisiert)

Jeder Treiber benötigt (bis jetzt) 3 SubRoutinen:
-Die Ini-Routine wird beim Starten der LüSteu ein Mal aufgerufen.
  Sie ist dazu gedacht die Slot-Pins zu konfigurieren (Input/Output, interner Pullup)
  und Variablen vorzuinitialisieren
-Die Loop-Routine wird immer wieder aufgerufen.
  In ihr soll der Treiber seine eigentliche Aufgabe erfüllen und z.B. die Lüfter regeln.
-Die Taster-Routine wird jedesmal aufgerufen, wenn der Treiber den Focus hat(siehe unten) und ein Taster gedrückt wird.
  Sie ist dazu gedacht, den Treiber während der Laufzeit zu beeinflussen.
  (z.B. Lüftergeschwindigkeit regeln)

Die Ausgabe auf ein LCD übernimmt ebenfalls eine Steckkarte.
Da alle Treiber auf das LCD zugreifen können müssen, befindet sich im "globalen" RAM ein Bereich in dem der aktuelle Anzeigetext abgelegt wird
und aus dem der LCD-Treiber dann die Daten ließt, die angezeigt werden sollen.

Damit der uC weiß, wer die Taster-Eingabe verarbeiten soll, gibt es ein Focus Register, das bei keinem Focus den Wert 0xFF und ansonsten die Nummer des Slots mit Focus enthält.
Außer der Taster-Verarbeitung regelt das Focus Register auch was auf dem LCD angezeigt werden soll.
Also ich habe mir gedacht, dass die Anzeige einfach in den Taster-Routinen der Treiber erledigt wird.

So ich hoffe ich habe nix wichtiges vergessen...

Ob der Nutzen den Aufwand wert ist, will ich garnicht wissen ;)
Der Weg ist das Ziel.

Natürlich würde ich mich über ein paar Tips von den uC-Erfahrenen hier im Forum freuen.
Ich progge das ganze in AVR-Studio 4.
Dies ist sowohl mein erstes uC-Projekt als auch das erste Mal, dass ich mich mit Assembler beschäftige.
Ich springe sozusagen ins kalte Wasser, also seit ein bisschen nachsichtig ;)

Ich werde gleich mal den Quelltext bis wohin ich bis jetzt gekommen bin hochladen, damit ihr euch den mal angucken könnt.

Bis jetzt ist das noch alles theoretisch.
Die Simulationen laufen ohne Probleme, aber ich glaube ohne Hardware komm ich nicht mehr viel weiter.

Ich werde demnächst mal bei Reichelt bestellen.
Nur damit ich nix vergesse:
Ich brauche...
1x AVR Mega8
1x Quarzoszillator
1x MAX 232
1x Com-Buchse
3x Taster
Lochraster-Platten
Buchsenleisten
Steckerleisten
IC-Sockel
ein paar Transistoren
ein paar Widerstände für LEDs
Litze
gewinkelte Stiftleisten für die Befestigung der Karten
Stabilisierte 5V Versorgungsspannung für den Tesataufbau

Ich hoffe ich hab nix vergessen.
Naja sagt mal was ihr bis jetzt davon haltet.

Edit:
hier (http://mitglied.lycos.de/kochlukas/Modding/M8/Code/20.4.05/M8.asm]Hier[/url] und [url=http://mitglied.lycos.de/kochlukas/Modding/M8/Code/20.4.05/Treiber.asm) ist der Quelltext

So,
heute sind die Bauteile von Reichelt angekommen (Montag bestellt, Mittwoch in den Händen: TOP).

Leider haben sie mir wohl das falsche D-SUB-Kabel geschickt, aber das brauch ich im Moment eh noch nicht.

Jetzt kann gelötet werden :kolben:

Vielleicht sollte man sich direkt auf einen Modding-FAQ Standard einigen was uC betrifft:
Gibt es irgendwelche Vorschläge, wie der ISP-Programmer-Stecker aussehen soll?
Also ich wollte den mit ner Stifleiste realisieren (die ist billig und im Rastermaß 2,54 ohne Probleme zu verarbeiten).
Jetzt stellt sich nur die Frage der Pinbelegung.
Evtl. sollt man die auch so wählen, dass man nicht gleich den uC zerstört, wenn man den Stecker falschherum einsteckt.
Zu verteilen währen da V+, Gnd, Rst, Miso und Mosi.
Hat da jemand ne Idee, oder gibt es da ne Verteilung, die sich bewährt hat, oder soll ich die einfach frei Schnauze verteilen.
Ist ja auch kein Problem, das nacher wieder umzulöten. [gelöscht durch Administrator]

Nettes Projekt, mal schaun, was draus wird.

Hab da aber noch Anregungen:
Für das Tastererfassen und entprellen würde ich das hier in einen Timer setzen:  http://www.mikrocontroller.net/forum/read-4-20549.html#new
Vielleicht ist es besser, mit einem m32 zu arbeiten, der hat schöne 32Pins. Zähle z.B. noch einen Pin dazu, damit du einen Quarz nehmen kannst. Warum so nen teuren Oszillator. Dann vielleicht TWI (I2C) Temperatursensoren, die wollen auch 2 Pins. Dann ein paar LEDs (Effekte, Bestätigung), da kann das doch knapp werden.
Wie das mit den IDs geht, hmm.. werden die ins EEprom gespeichert? Sonst vielleicht nen Menü, wo man das zur Laufzeit ändern kann.


==> Ich schick dir mir mal mein Lüftersteuerungchen... ist recht modular aufgebaut und hat nen schönes, allgemein gültiges, Menü. Ich bin nie dazu gekommen das fertigzustellen. Vielleicht kannste was brauchen und vielleicht hab ich irgendwann Lust dazu.
Bis jetzt ist integriert:
PWM Ausgabe der Spannungen in 20Stufen (könnte geändert werden)
Umdrehungen erfassen bis glaub 10.000U/min bei 8Mhz (oder so)
Alles für 4 Kanäle ausgelegt, könnte sicher erweitert werden
4 Tasten Bedienung (UP/DOWN/ENTER/BACK)
Am besten natürlich 4x?? Display
DS1621 Temperatursensoren sind so halb integriert
Automatisches Verändern der eingestellten Stufe mit einem Sollwert in der Temperatur (ist Temp zu hoch, geht die Stufe mit einstellbarer Zeit immer höher, zu niedrig (mit Hysterese natürlich) langsam wieder runter. Dürfte sich sicher mal einpendeln, habs net getestet)
Ontime Anzeige
Passwortschutz
Ausgabe der Daten per UART
mehr fällt mir grad nich ein *G*.

b0nze

was den standard fuer das prommer-kabel angeht, vielleicht schliesst du dich da nochma mit spunky kurz? der hat imho irgendwo schonmal was dazu gemacht oder entworfen oder so, wenn ichs nicht in falscher erinnerung habe...

haettest du Lust ein Tutorial schreiben und dies nur den µC-grundlagen und vor allem der herstellung jenes Kabels sowie der Definition besagten Standards zu widmen? das waer riesig, auf sowas draenge ich schon lange und du haettest ja direkte gelegenheit ordentlich fotos zu machen etc.

ich wuerde dich dafuer jedenfalls lieben  :zunge: ;D :knuddel:

Also ich dokumentiere meine Arbeite auf jeden Fall, alllerdings glaube ich, dass die Fotos nicht unbedingt Tutorial-Qualität haben...

Schreiben kann ich sicherlich tun, aber das ist jetzt erstmal ein Prototyp und wie gesagt mein erstes uC-Projekt, also werd ich das erst machen wenn's fertig is.
Fotos kann dan ja vieleicht jemand anderes machen.

@b0nze:
Ich werd mir deinen Code mal anschauen, wenn ich Inspiration brauche,
aber im Moment stehen erstmal mehr oder weniger stupide Lötaufgaben vor mir.
Und was den Mega32 betrifft: Der kostet bei Reichelt 5 bis 6 Euro und ich wollte ja eine möglichst Low-Cost LüSteu bauen (naja so Low-Cost wie halt geht...)
Wenn ich damit fertig bin, könnte man ja über einen Nachfolger nachdenken  ;D

Ich wollte eigentlich ein paar Fotos von meinem neuen Programmer hochladen, aber meine Cam ist überhaupt nicht für Nahaufnahmen geeignet...
Naja, ist vieleicht auch besser, wenn ihr den nicht seht.
Die Lötbrücken sehen furchtbar aus...

Was solls, ich werd mal mit spunky Kontakt aufnehemen.
Und dann frisch ans Werk!

Ich finde die Idee mit dem Oszillator gar nicht schlecht. Es ist fast unmöglich, einen Atmel einfacher mit einem sauberen Takt zu versorgen.

Hab auch den Code einmal grob überflogen und einen kapitalen Bock entdeckt - aber das heben wir uns auf, bis wir den Code sezieren. Jetzt löte erstmal fleißig  ;D

Ja, eins nach dem anderen.

Um zu zeigen, dass ich auch wirklich was mache, gibts auch ein Bild von meinem ISP und der Test-Stromversorgung.
Der ISP ist 8-polig, aber außer V+ am ersten Pin ist noch kein Pin verbunden.
Und die Stromversorgung besteht aus nem billigen unstabilisierten 6V 500mA Netzteil, das ich noch hier rumliegen hatte und nem 7805. [gelöscht durch Administrator]

Ui, da wäre ich aber sehr aufmerksam. 6V sind ein bissel knapp für einen 7805. Weiterhin würde ich auf jeden Fall die beiden 100nF-Pillen mit einbauen. Wenn der 7805er zu schwingen beginnt (besonders bei dieser niedrigen Eingangsspannung), könnte der ATMega echte Probleme bekommen und der ISP mehr oder weniger nach dem Zufallsprinzip funktionieren. Die 100nF's verhindern diese Schwinger.

Also das Netzteil liefert im Leerlauf deutlich über 6V.
So 7 bis 8 Volt.

Sollte das nicht reichen hab ich hier noch nen alten Carrerabahn-trafo.
Der kann bis zu 14V bei 1A liefern, also währe das auch kein Problem.

Und zur Schwingungsreduzierung:
Ich hatte sowieso geplant für jeden IC einen 100nF Entstör-Kondensator einzulöten.

Mal schaun, an der Stromversorgung lässt sich immer noch basteln.

So,
eigentlich müsste ich jetzt soweit sein, dass ich die ersten Tests mit dem Atmel machen kann, aber irgendwie, will PonyProg den nicht erkennen...

Wie sieht denn die minimale beschaltung für einen ersten erfolgreichen Test aus?

Ich hab jetzt Vcc und VAcc mit V+ und zwei mal Gnd mit Gnd verbunden.
Außerdem hab ich sogar noch den Oszi. eingelötet und natürlich Miso, Mosi, Sck, und Rst mit dem Programmer verbunden.

Fehlt da noch was?
Muss ich Rst mit nem Pull-Up oder -Down versehen?
Oder hab ich mich irgendwo verlötet?
Hab eigentlich alles schon ein paar mal überprüft...

Den Oszi hätteste dir sparen können. Der m8 läuft auch bei dir (da du ja nicht programmieren kannst) noch mit internem 1Mhz.

Probier mal das "Yaap" aus. Das hab ich, könnte er zwar mal weitermachen...aber funktioniert.

Ich würde eher mal deinen ISP überprüfen.. ich hab auch 3-4Tage gebraucht, Miniatur-Quetsch-Bauweise bei mir ;).

Brauchst nix Pulldown etc. Na vielleicht Pullup am RESET.

b0nze

Jo, den Oszi hab ich auch nur aus verzweiflung eingelötet  ;D

Ich werds mal mit Yaap versuchen...

Edit:

Mit Yaap scheint es zu funktionieren.
Wenn ich es jetzt testweise hinkriege ne LED zum leuchten zu bringen, kann ich die  restliche schaltung aufbauen und dann kanns richtig losgehn.

Edit²:

Juchuu

Es funktioniert alles wunderbar.
Hab Slot0 fertig verlötet und ein Testprogramm erfolgreich ausgeführt.
Jetzt muss ich nur noch die anderen Slots verlöten und die Fuse-Bits richtig setzen.
Ihr könnt ja schonmal anfangen den Code zu sezieren ;D

So dann mach doch mal nen Doppelpost,
denn ich habe ein kleines Problem:

hier (http://mitglied.lycos.de/kochlukas/Modding/M8/Code/1.5.05/M8.asm]Hier[/url] und [url=http://mitglied.lycos.de/kochlukas/Modding/M8/Code/1.5.05/Treiber.asm) habt ihr den aktuellen Quellcode.

Ich möchte eigentlich nur bei jedem Hauptschleifendurchlauf einen festen Wert über den UART schicken.

Empfangen tu ich das ganze über das Terminal Programm von Rowalt.de

Auch die Verdrahtung ist wie auf rowalt.de, außer dass ich RX und TX vertauscht habe, weil ich kein Nullmodemkabel, sondern 1:1 Kabel benutze.

Jetzt empfange ich aber leider nicht den Wert, den ich im Code angebe!




Was mach ich falsch?

Und um zu zeigen, dass es im Großen und Ganzen eigentlich ganz gut läuft hab ich hier auch noch zwei bilder vom Aufbau: [gelöscht durch Administrator]

Mein Zimmer ist ja aufgeräumt im Gegensatz zu deinem Code (so schlimm siehts hier eigenlich garnich aus.. bis auf die Klamotten überall).

Wie wärs, wenn du mal ne Schleife irgendwo reinmachst? Z.B. am Anfang, wo du aus dem EEprom die Treiber lädst.. kann man schön und einfach mit
LD temp1, Z+
ST X+, temp1
machen. Also allgemein versuchen, eine Schleife zu erzeugen, das is ja grauenhaft *G*, wirste später merken, alles was man vereinfachen kann (auch wenns 5% Takte mehr kostet) ist GUT.

Für nen gescheites Terminalprogramm:
http://realterm.sourceforge.net/    (thx to Olaf, my redda)

Ich wüsste nicht, was da jetzt falsch sein könnte bei dem Serial... nimm doch einfach mal "ldi fin, 'x'", dann siehste mit jedem Programm, dass was kommt. 15 ist nämlich ASCII Steuercode, mögen nicht alle... und Tipp, Yaap ist bei seinem Serial Terminal etwas lahm, also, wenn du volle Pulle ohne Delay sendest.. gute Nacht *G*.

Also resumé: mach den Code noch etwas leserlicher, und ich freu mich auf das weitere.


b0nze

PS. Haddu kein ICQ?

Also ich habs mal mit dem anderen Terminalprogramm versucht, aber da ist auch keine Besserung in Sicht.

Wenn ich den Port schließe und dann wieder öffne, kommen manchmal andere Signale an.
Heißt das, ich hab ein Problem mit den Einstellungen des UARTs?
So wie der Code momentan ist müsste ich doch eigentlich eine Baudrate von 9600, 8 Bits, keine Parität, und ein Stopbit haben, oder?

Achja: UBBRVAL berechne ich 16000000/(16*9600) - 1

Irgendwie fuchst mich das jetzt...

Zum Spaghetticode:  :zunge:
Ist mein erster ASM-Code und optimiert wird später.
Aber keine Angst: Sobald der UART funktioniert, werd ich den Code ein bisschen übersichtlicher machen.

Also ich hatte mal das Problem, dass ich am UART nur zufällige Zeichen empfangen habe, das hat sich dann als ein Baudratenproblem herausgestellt. Wenn die eingestellte Baudrate am PC und die vom µC nicht recht genau (so zwischen 1-2%) übereinstimmen, kann man also so nette Effekte bekommen.
Zu deinem Code selbst kann ich leider nix sagen, da ich von Assembler keinerlei Ahnung habe (was die Leute bloß immer gegen C haben).
Für die Bits im UBBRL/H gibts auch im Datenblatt am Ende des USART-Kapitels eine Tabelle, du solltest auch drauf achten dass du nicht versehentlich das U2X-Bit setzt (da bin ich mal reingefallen).

@TzA: Niemand hat was gegen C-Code. Aber
- das Kompilat, das (zumindes WinAVR) produziert, ist derart ineffizient, das man weinen muß. Auch mit allen Optimizer-Stufen ändert sich das kaum. Sicherlich kann ein Compiler niemals optimalen Code produzieren, aber ich habe auch schon deutlich bessere Kompilate gesehen.
- Weiterhin ist der Weg, bis WinAVR vernünftig läuft und flasht, sehr steinig - verglichen mit dem AVRStudio.
- Bis im AVRStudio richtig ein C-Kompilat simuliert werden kann, ist es noch einmal sehr steinig.
- Ach ja: AVR-Assembler ist leichter zu lernen als C, wenn man keine Vorkenntnisse hat  ;D

@Ast:
Wie @TzA schon bemerkte, würde ich als erstes das U2X-Bit überprüfen. Ist zwar standardmäßig abgeschaltet, aber man weiß ja nie...

Weiterhin würde ich ein richtiges ASCII-Zeichen senden (0x41 z.B.), kein 0x0F - das könnte auf der PC-Seite fehlinterpretiert werden.

Ansonsten ist dein 16MHz-Oszillator denkbar ungeeignet für jedwede Form von serieller Kommunikation, da man die Baudrate schlicht nicht exakt genug eingestellt bekommt. Die Toleranzen sind zwar nicht besonders eng gefaßt, aber bei dem extremen Sparzwang, der im PC-Sektor herrscht, kann auch 1% Abweichung schon zuviel sein.

Aus diesem Grunde benutze ich persönlich die 14.7456 MHz-Quarze - höchstmögliches Tempo im Atmel bei exakten Baudraten. Brauche ich keine SIO, brauche ich eigentlich auch kein rasendes Rechentempo und weiche auf Energieparende (weniger Takt=weniger Strom) und günstigere 11MHz-Oszis aus.

Falls das zu langsam erscheint: Ich hab an einem Gerät mitentwickelt, das einen GPS-Receiver per SIO, ein GSM-Modem per SIO, zwei Digital-IN, zwei Digital-OUT, einen Erschütterungssensor und einen Berg interner Funktionen in Echtzeit bedient. Takt des ATMega: 3.6MHz...

Also wegen dem Takt mach ich mir nicht so große Sorgen:
Laut dem Baudratenrechner von Rowalt.de beträgt die Abweichung weit unter 1%.
Ich glaub sie liegt eher im bereich von 0,1%.

Könnte es daran liegen, dass was mit der Verkabelung nicht stimmt?
Was passiert, wenn ich RX und TX vertauscht habe?
Dann dürfte garnix mehr empfangen werden, oder?

Wie gesagt: Ich habe das ganze so verkabelt wie hier beschrieben, nur dass ich RX und TX am Stecker vertauscht hab, weil ich eben kein Nullmodem-kabel einsetze.
Ist das so korrekt?

Und wegen dem gesendeten Zeichen:
Ich habe natürlich auch versucht gut anzeigbare Zeichen zu versenden.
Ich hab mehrere Sachen ausprobiert und dann halt nen Code hochgeladen, bei dem es grade kein anzeigbares Zeichen war.

Hmm, wenn du einen Verkabelungsfehelr hast, dürfte eigentlich garnichts ankommen. Schreib doch mal dein Programm so, dass er kontinuierlich das gleiche Zeichen sendet, dann kann man sehr leicht feststellen, auf welcher Letiung sich was tut, denn da sollte ein Multimeter ca. 2,5V (TTL) bzw 0V(RS232) anzeigen. Wie hast du die Umsetzung  TTL<->RS232-Pegel gemacht, mit einem MAX232 ?

:headcrash: :headcrash: :headcrash: :headcrash: :headcrash: :headcrash: :headcrash:

Leute ich könnt heuelen!

Es tut mir Leid!

Der Fehler ist so banal, dass es mir schon fast zu peinlich ist, den hier zu posten.

Aber ihr habt es euch verdient.

Der Max232 war nicht mit Vcc verbunden!

Da war einfach kein Kabel zur Stromversorgung.
Ich habs schlicht und ergreifend vergessen.  :'( :'(

Es tut mir Leid und trotzdem danke, an alle, die mir mit einem echten Problem helfen wollten.

Ich glaub ich setzt mich jetzt erstmal in die Ecke und schäm mich und dann wird erstmal der Code ein bisschen übersichtlicher gemacht.

Kabel vergessen... Ich könnt mir in den Arsch beißen...

Putz deinen Arsch, ich will auch reinbeißen ! ;D

@Quarz: Naja, man sollte bei SIO wirklich nen UART Quarz nehmen, aber:
Wie heißt das Forum? Es gibt doch auch einen mit 18,xx Mhz, das halten die meisten AVR noch aus und gibt noch mal Performance. Solang es keine Serienproduktion (wie wahrscheinlich) bei Olaf ist, kannste das scho machen. Musste halt testen: Eeprom und Flash spielen dann nicht mehr so mit.

@Olaf: unter deinen "Anforderungen" des Geräts kann ich mir z.B. keinen Schwierigkeitsgrad vorstellen.. also ich weiß ja nicht, was ihr da für arithmetisches Zeugs reingepackt habt.. aber in ASM kann man glaub garnicht so viel langsam machen. Wenn man dann einmal als "Optimierer" rübergeht kann man schon viel Zeug ausbügeln und vereinfachen. Ist ja euer Job ;D

@Ast: hoffentlich vergisste nicht den AVR in die Fassung einzusetzen *G*

b0nze

So ich hab den Code ein wenig übersichtlicher gemacht.
Hoffe ich zumindest...

klick Treibern (http://mitglied.lycos.de/kochlukas/Modding/M8/Code/2.5.05/M8.asm]mich[/url]

An den [url=http://mitglied.lycos.de/kochlukas/Modding/M8/Code/2.5.05/Treiber.asm) hat sich nicht geändert.

Hab die Treiber-ID-Ladung in ne Schleife gepackt, die ich so hingematscht habe und sonst versucht alles in Macros zu packen.
Das lässt sich bestimm auch über echte Funktionen regeln, aber das machen wir, wenn der Speicher knapp wird  ;D

Als nächstes muss ich dann noch ne Grafikkarte basteln, mit der ich über den 4-Bit-Bus das LCD betreiben kann (Jaha aufgepasst Ati und Nvidia  ;)),
ne Test Treiber-Karte löten (einfach eine Transistorverstärkung der 4 Ausgänge) die entsprechenden Treiber programmieren und noch irgendwie das Zusammenspiel von LCD, Treiber-Karte, Betriebssystem (nennen wir es M8-OS ?  ;D ;D) und User einprogrammieren.

Natürlich darf die kommunikation über den COM-Port nicht fehlen und das ganze muss allgemeingültig sein, damit sich jeder möglichst einfach seine eigenen Treiber für seine Hardware schreiben kann.

Uff...

So nächstes Problem:

Hab die Grafikkarte zusammengelötet und bin gerade dabei den Treiber zu schreiben: Hier der Code (http://mitglied.lycos.de/kochlukas/Modding/M8/Code/3.5.05/Treiber.asm]Klick mich[/url]

Ich weiß, ich weiß: Sieht bestimmt furchtbar aus.
Aber Schleifen kommen rein, wenn's funktioniert.

Im Moment gibt das LCD aber garnichts aus.
Es ist nur, je nach Kontrast-Einstellung, ein schwarzer Balken zu sehen.

Es handelt sich um ein 16x2 Display von Reichelt.

Über die Slot-Pins 0 und 1 können Daten in das Schieberegister geladen werden (Das habe ich bereits überprüft: Es funktioniert wunderbar).

Pin 3 ist mit E verbunden und 4 mit RS.

Da ich auch mit LCDs null Erfahrung habe, währe es nett, wenn mir da jemand helfen könnte.

Edit:

So ich habs jetzt den schwarzen Balken weg bekommen (das ist doch ein gutes Zeichen, oder?), aber angezeigt wird immernoch nix.
[url=http://mitglied.lycos.de/kochlukas/Modding/M8/Code/4.5.05/Treiber.asm) [gelöscht durch Administrator]

Ich habs hingekriegt.

Es lag daran, dass ich das Schieberegister zu schnell angesprochen habe.

Ich habs jetzt soweit, dass das LCD bei jedem Aufruf der TextLCD_Loop Routine die daten aus dem RAM lädt und entsprechend der LCD-Größe anzeigt.

Hier (http://mitglied.lycos.de/kochlukas/Modding/M8/Code/5.5.05/M8.asm]Hier[/url] und [url=http://mitglied.lycos.de/kochlukas/Modding/M8/Code/5.5.05/Treiber.asm) gibts den passenden Code.

Und natürlich ein Foto zum Beweis: [gelöscht durch Administrator]

Soderle

Die Interaktion zwischen User und Treiber sollte jetzt funktionieren.

Sobald Taster1 gedrückt wird betritt man das Menü.

Mit Taster0 und Taster1 kann man dann zwischen den Einträgen durchschalten.

Mit Taster2 wird der Focus dann auf den jeweiligen Slot gelenkt und die Tasterfunktion des Treibers aufgerufen.

Nun muss der Treiber die Taster und den Screen verwalten.

Jedes Mal, wenn ein Taster gedrückt wird, wird die Taster-Funktion des Treibers aufgerufen.

Im X-Register befindet sich die, dem Treiber zugewiesene RAM-Position und im Y-Register die EEPROM-Position.

Wird das Menü des Treibers verlassen, muss dieser den Focus wieder auf 0xFF setzen, womit er die Taster und Screen-Verwaltung wieder an das Betriebssystem übergibt.

Video (http://mitglied.lycos.de/kochlukas/Modding/M8/Code/7.5.05/M8.asm]Hier[/url] und [url=http://mitglied.lycos.de/kochlukas/Modding/M8/Code/7.5.05/Treiber.asm]hier[/url] gibts den Code (warscheinlich wieder Spaghett²)

Und diesmal gibts kein Pic, aber ein [url=http://mitglied.lycos.de/kochlukas/Modding/M8/Temp.00.avi), das (in miserabler Qualität), zeigt, wie die Menüeinträge durchgeschaltet werden und schließlich das LCD-Menü betreten wird, das aber nur aus einem Text besteht.
(Zu sehen auch meine selbstgedrehten Taster-Verbindungskabel in modischem Schwarz-Gelb ;D)

Ich kann den Film nich laden, ich soll mich als Mitglied anmelden oder so...

b0nze




Klappt immer noch nicht...

Nagut hier (http://mitglied.lycos.de/kochlukas/Modding/M8/) ist der Link zum Ordner in dem das Video gespeichert ist.

Kleiner Tip: Anstelle der Makros (die Idee ist nicht schlecht, aber am Zweck von Makros vorbei) würde ich Subroutinen machen. Ansonsten mußt du zwar wenig tippen - aber es wird trotzdem massenhaft Code generiert.

Ansonsten:  :respekt: für diese Leistung. Mich schauderts, weil das alles auch noch auf mich zukommt...  :o

Die Makros habe ich ja auch nicht da eingebaut, um den Code zu verkleiner, sondern um ihn lesbarer zu machen  ;D

Ich hätte lieber Funktionen genommen, aber da der Großteil der "Funktion" nur aus dem Laden von Speicheradressen besteht hab ich es als Makro realisiert.

Und wieso kommt das noch auf dich zu?

Auf mich kommt jetzt erstmal eine einfache Treiberkarte zu, dann die konkrete kommunikation zwischen PC und M8 und ich muss die PC-Software schreiben, mit der die M8 letztendlich gesteuert wird.

Wenn das alles fertig ist erstell ich noch ne pdf-Datei, die engagierten Moddern die Entwicklung von eigenen Karten und Treibern erleichtern soll.  :headshot:

Allerdings müssten die Treiber dann auch in die PC-Software integriert werden...
hmm...
Vielleicht kann man sich da ja ne eigene Skriptsprache ausdenken...
Mal schaun  :bestens:

So

Es hat zwar etwas länger gedauert (ich bin in den letzten Tagen irgenwie nie zum Coden gekommen), aber es gibt mal ein Update.

Ich habe die Kommunikation zwischen M8 und PC zur Hälfte fertig.
Senden von Daten vom PC zur M8 scheint problemlos zu funktionieren.
Zuerst sendet der PC ein Byte welches den Befehl an die M8 enthällt.
Die M8 quittiert das mit einem OK-Byte und ruft die entsprechende Funktion auf.
Wird der Befehl nicht erkannt schickt die M8 ein Fehler-Byte.

Die Kommunikation funktioniert also immer:

PC --- Befehl ---> M8
PC <--- OK ------- M8
PC --- Daten ---> M8
PC <--- OK ------- M8
PC --- Daten ---> M8
PC <--- OK ------- M8
usw...

Für das Auslesen von Daten habe ich mir das so gedacht:

PC --- Befehl ---> M8
PC <--- OK ------- M8
PC --- OK -------> M8
PC <--- Daten --- M8
PC --- OK -------> M8
PC <--- Daten --- M8
PC --- OK -------> M8
PC <--- Daten --- M8
usw...

Es wird jeweils nur ein Byte übermittelt.
Um das ganze nicht immer mit dem Terminalprogramm schreiben zu müssen habe ich ein kleines Programm geschrieben, dass mir vorallem beim entwickeln erstmal helfen soll (siehe Anhanhg).
Für den "Endverbraucher" werde ich ein komfortableres Programm schreiben.
Vielleicht sogar mit einem "Wizzard" ;)

hier (http://mitglied.lycos.de/kochlukas/Modding/M8/Code/18.5.05/M8.asm]Hier[/url] und [url=http://mitglied.lycos.de/kochlukas/Modding/M8/Code/18.5.05/Treiber.asm) könnt ihr euch auch den neuen Quelltext anschaun.
Falls es jemanden interessiert, könnte ich auch den Quelltext meines Setuprogramms hier posten.
Geschrieben hab ich es in Visual Basic 6.0. [gelöscht durch Administrator]

Hmmm...

Ich hab mal geprüft wie lange das Übermitteln der Daten vom PC zum uC dauert.
Am Anfang der Senderoutine hab ich Timer() in der Variable StopUhr abgespeichert und gebe am ende des Aufrufs Timer()-StopUHR in ner Messagebox aus.

Anscheinend dauert eine Übertragung von 80 Nutzbytes (ca. 160 Bytes, wenn man die OK-Bytes hinzurechnet) ca 0,5 bis 0,75 Sekunden.

Die Baudrate beträgt 9600 @ 8N1

Ist das so akzeptabel?
Das kommt mir irgendwie zu langsam vor...
Ist mein Code uneffektiv?
(Abgesehen von den Endlosschleifen bis zum Empfangen/Fertig-gesendet-haben)

Später will ich ja z.B. CPU-Auslastung und Temps auf die M8 übertragen
und da wäre es unschön, wenn jedesmal ne halbe Sekunde für drauf geht...

naja, wenn du ne Temperatur überträgst ist das ja auch 1 byte. das gleiche gilt für Auslastungen (wenn mans richtig macht sogar nur 1/2 byte, dann eben 2 werte in einem byte). Und ich glaub kaum, dass du die sachen 20 mal pro sekunde refreshen willst, oder?

Andererseits kommt mir 9600 baud trotzdem recht langsamm vor, wenn man bedenkt, dass allein ein DMX-signal (wird auch gerne mit ATmegas ausgewärtet) schon 250.000 baud hat... (oder irre ich mich da? ;))

Ja, natürlich werde ich nicht jedes Mal 80 Byte übertragen.
Und die 9600 Baud sind ja von mir so eingestellt.
Mir kommt die Zeit, die benötigt wird, um 80 (bzw. 160) Byte zu versenden, nur zu lange vor...
Selbst für 9600 Baud.

Du solltest nicht das Protokoll außer acht lassen - denn Deines frißt 30% der verfügbaren Baudrate.

Nach jedem Byte ein ACK-Byte zurückzusenden ist eigentlich Blödsinn. Es ist effektiver, das en bloc zu machen:

PC ----> Befehl, Data, Data ----> M8
PC <-------------- OK <------------- M8

So laufen 4 Bytes durch die SIO, anstelle deiner 6 Bytes. Ist obendrein einfacher zu programmieren  ;D

Bei Deinem Protokoll wird ein Fehler im Befehlsbyte schneller erkannt - aber wird das tatsächlich so oft passieren ? IMHO, nach allen meinen seriellen Basteleien sage ich: Nein.

Bei 9600 Baud 8N1 sind maximal 960Bytes/Sekunde möglich, bei Deinem Protokoll also max. 160 Befehle, bei meinem 240. Gerade bei so niedrigen Baudraten spielt das Protokoll zwischen Sender und Empfänger eine wesentliche Rolle.

Also ich hab das Protokoll jetzt etwas geändert.

Jetzt werden immer 2 Daten-Bytes pro OK-Byte gesendet.
Bei EEPROM zugriffen ist das nicht wesentlich schneller, aber egal.

Außerdem hab ich jetzt Funktionen eingebaut mit denen einzelne Bytes in den RAM, das EEPROM oder den Screen geschrieben werden können.
(Screen ist die Stelle im RAM, an der der aktuelle LCD-Text gespeichert wird).

Im Moment arbeite ich daran, dass ganze auch umgekehrt auslesen zu können.

Wenn das erledigt ist, ist der Kern der M8 eigentlich fertig.
Dann muss ich nur noch den Wizzard schreiben und ne Dokumentation machen, damit ihr auch zusätzliche Erweiterungskarten entwickeln könnt.
Ihr glaubt doch nicht etwa, dass ich hier die ganze Arbeit alleine machen werde ;)

Nach dem Wizzard wird wohl auch eine Tray-Anwendung nötig, weil ich auch gerne PC-Statusanzeigen auf das LCD ausgeben möchte.
Aber wozu das Rad neu erfinden?
Wie wäre es mit einer M8 Unterstützung für STLCD, OlafSt?  ;D

Why not... Ein Gerät zum ausprobieren her, geht los. Kalteinbauten (soll heißen, implementieren ohne Testmöglichkeit) mache ich nicht.

Ach ja: Läuft das ganze über eine echte serielle oder per USB/RS232-Wandler ? In der neuen Elektor war da ein höchst interessanter Artikel drin.

Das läuft alles direkt über den COM-Port.

Die Elektor krieg ich nicht, aber vielleicht sollte ich die mal abbonieren...

Wegen dem Testgerät: Das kann ich dir leider im Moment nicht zukommen lassen,
da ich ja selber noch entwickle und dieser Prototyp wahrscheinlich auch in meinem PC verschwinden wird.

Aber sobald ich fertig bin mach ich ein ausführliches Datasheet, so dass jeder, der selbst eine Platine layouten kann in der Lage sein sollte die M8 nachzubauen.

Auch ein Tutorial würde ich schreiben, allerdings hab ich keine gute Digicam, so dass jemand anderes die Fotos machen müsste...

Wärst du denn bereit die M8 selbst zusammenzulöten, oder muss ich dir dann meinen kostbaren Prototypen schicken?

Das Problem bei USB/RS232 Adaptern ist der USB. Die Latenz fuer ein einzelnes Datenpaket ist 1 ms.
Damit dauert es 3 ms wenn man ein einzelnes Byte sendet. 1 ms senden, 1 ms fuers ACK und 1 ms bis man wieder drankommen kann.
Bei groesseren Datenpaketen ebnet sich das natuerlich ein, da die Latenz pro Paket gilt.

Also,

das Grundgerüst für die M8 ist soweit fertig.

Alle Lese- und Schreibzugriffe vom PC funktionieren und das "Betriebssystem" ist somit fertig.
Den Code bekommt ihr hier (http://mitglied.lycos.de/kochlukas/Modding/M8/Code/30.5.05/M8.asm).