Wir basteln uns einen ordentlichen Bordcomputer

[Noctunus]

Genau als Unterbrecher für die Ganganzeige (die dann aus Drehzahl+Geschwindigkeit berechnet wird) könnte man den vorhandenen Schalter an dem Kupplungshebel benutzen (der, der Verhindert das man die Maschine starten kann wenn ein Gang eingelegt aber die Kupplung *nicht* gezogen ist).

Gute Idee

Achja, hab die ganzen Ideen mal in der test-wiki verewigt die Gilli freundlicherweise zur Verfügung gestellt hat. Damit soll die Verwendbarkeit einer Wiki für uns getestet werden und ob es für uns überhaupt Sinn macht eine solche zu Unterhalten.

<!-- m --><a class="postlink" href="http://www.wiki.gpz.info/tiki-index.php?page=Bordcomputer+Projekt">http://www.wiki.gpz.info/tiki-index.php ... er+Projekt</a><!-- m -->

Wenn jemandem noch etwas einfallen sollte oder ich etwas vergessen haben sollte kann er die Liste in Phase 1 gerne ergänzen.

[Edit]
Wenn diese Liste dann soweit als Vollständig angesehen wird (und jeder mit der dort dargestellten Planung soweit einverstanden ist). Würde ich dann einen neuen Thread erstellen, welcher die Auswahl der dort befindlichen Vorschläge für Phase 2 zum Ziel hat. (Dort können dann die Vorschläge, welche nicht oder nur schwer realisierbar sind auseinandergenommen werden )

Natürlich kann und soll hier bis dahin weiter darüber diskutiert werden welche Funktionen, Sensoren und evtl sogar schon Visualisierungsarten möglich bzw gewünscht sind

Alle einverstanden?

[Holle]

Wenn das ganze so sensibel ist um kleine Druckveränderungen im Reifen zu bemerken hieߟe das doch auch das die Anzeige verändert wäre wenn die Reifen warmgefahren wären (insbesondere wenn man sehr viel stark beschleunigt und der Hinterreifen sich schneller aufheizt als der Voderreifen), oder?

Stimmt, das wäre auch noch ein Problem. Sofern beide reifen gleich erhitzt werden und sich dabei auch gleich ausdehnen würde es noch gehen, aber ansonsten ist das eine Fehlerquelle, welche einen Luftdruckunterschied anzeigen würde und die Schlupfanzeige verfälschen würde.
Vielleicht sollte man auf eine Schlupfmessung verzichten, wegen den schwer zu beseitigenden Störfaktoren (Profil und Temperatur).

beschleunigungssensor kostet ca. 12€. wäre genau der aus der wii-fernbedienung .. falls die einer kennt. gibt auch günstigere modelle wo nur eine oder 2 achsen gemessen werden .. würde für unsere zwecke ja reichen

OK, 12 Euro sollten nicht das Problem sein, hast mich Überzeugt.

bei 15% schlupf bringt man die meiste kraft auf die straße ist aber mehr ein nice to have weils nicht so ultra schwer zu realisieren ist (siehe letzte beiträge)
mit dem profilunterschied ist doof, und auch die radgröße ist ja generell verschieden, was eine synchronisierung unumgänglich macht. aber da das nur einmal gemacht werden muss pro reifensatz find ichs ned soo schlimm

Ne, einmal pro Reifensatz wäre nicht ausreichend, das müsste vor jeder Fahrt geschehen, denn:
1.) Das Profil verschleiߟt vorne und hinten unterschiedlich schnell
2.) Wenn man Luft nachfüllt stimmt das auch schon wieder nicht mehr.

Und dann fällt mir noch ein Problem dazu ein. Wenn man z.B. in der Stadt unterwegs ist und oft abbiegt (bei geringer Geschwindigkeit), dann legt das Vorderrad mehr Weg zurück als das Hinterrad. Wenn man die Reifen mit Kreide bemalt (am besten in unterschiedlicher Farbe) und das Bike einmal im Kreis schiebt, dann hat man 2 Kreidekreise gezogen (auߟen vom Vorderrad). Sicher, je schneller man fährt, desto weniger Lenkeinschlag hat man und somit ist auch die Differenz geringer, aber wenn man das so genau messen will um Schlupf zu errechnen, dann hat man gerade beim Abbiegen einen enormen Schlupf

das mit dem rfid-chip zum anlassen sollte nicht direkt die zündung schalten. nur die möglichkeit den anlasser zu betätigen soll dann dazugeschaltet werden. zündung muss dann irgendwie anders geregelt werden. (darf nich ausgehen wenns moped mal läuft)

Dann wäre das aber nur zur Diebstahlsicherung interessant. Wenn ich sowieso den Schlüssel brauche um die Zündung einzuschalten, dann gibt es ja keinen Unterschied mehr, auߟer dieser zusätzlichen "Wegfahrsperre". Als Diebstahlschutz eignet sich das aber auch nicht, denn der Anlasser kann ja durch Anschieben übergangen werden.

die lösung mit der warnblinkanlage bei vollbremsung ist zwar nett, dann sollte sie aber schneller blinken.
aber das aus der geschwindigkeit zu berechnen find ich zu fehleranfällig. der sensor ist ned so teuer, und den kann man direkt aufs board löten ... und schon hat man alles frei haus

Also diese standardmäߟigen in Autos (davon hatte ich beim "geschenkten" ADAD-Sicherheitstraining einige gesehen ...leider war der Gutschein nur für PKW gültig ) sind recht unterschiedlich. Bei einem blinkt das Bremslicht, bei einem anderen wird das Bremslicht heller und bei wieder anderen ging die "normale" Warnblinkanlage an.
Dass der Sensor Sinn macht ist mir inzwischen klar, aber bei Glätte hat man halt nicht so eine starke Verzögerung, aber dennoch sollte da auch die Notbremsung angezeigt werden, also sollten wir zusätzlich die Radumdrehungen überwachen.

Schaltblitz wäre nur n paar superhelle LED's an den MC anklemmen. Ganganzeige über 7-Segment wäre auch nicht allzu schwierig.

Stimmt, aber wie wollen wir die Ganganzeige realisieren?
Wenn wir den Gang errechnen, dann funktioniert das nicht wenn die Kupplung gezogen ist. Wenn wir einen Schalter an dem Kupplungshebel anbringen, und solange den gleichen Gang anzeigen bis die Kupplung wieder losgelassen ist könnte das funktionieren. Den Leerlauf dann zum resetten nehmen.

man könnte doch wahrscheinlich den schon vorhandenen Schalter dafür nehmen...

Stimmt eigentlich

Drehzahl und Geschwindigkeit würden meiner Meinung nach eh aufgenommen werden - und da die Maximale festzuhalten (oder ne Warnung mittels Blinken (oder ertönender Hupe *G*) zu erzeugen) ist denke ich kein Problem.
Ich dachte da eh schon an einen Schaltblitz dem man den Schwellwert fürs Blinken vorgibt.
u.A. wäre ein Schaltblitz in Abhängigkeit von der Öltemperatur sicher auch nicht verkehrt

Ein Schaltblitz wäre nicht schlecht, zumal das auch kein Aufwand wäre, wenn die Drehzahl sowieso mit überwacht wird.
Den Schaltblitz für die Öltemperatur zu benutzen finde ich nicht besonders gut, dann lieber das Display blinken lassen wenn irgend ein Wert kritisch ist (z.B. die Öltemperatur).

der schaltblitz soll ja nicht als warnlampe für z.B. die Öltemp fungieren... so wie ich das verstanden habe, soll der Schaltblitz halt bei kaltem Motor z.B. schon bei knapp unter 5000/min blitzen und nicht erst bei dem normalen Wert, damit man halt Motorschonend fährt... wenn der Motor dann Betriebstemperatur hat, sollte er beim Regulären Wert blitzen...

Achso, das hatte ich falsch verstanden. Ok, das wäre in einer Hinsicht ganz praktisch, aber andersrum kann das auch nerven.
Beispiel, ich fahre gerade erst 5km, laut Temperatur sollte der Schaltblitz nun schon bei 5.000 upm kommen. Da ich aber überholen will muss ich trotzdem (obwohl der Motor noch nicht warm ist) höher drehen, dann würde mich der Schaltblitz auf der Dauer nerven. Das Teil sollte ja nur dann angehen wenn man das Schalten gerade mal vergisst (z.B. wen ein Überholvorgang länger dauert als gedacht), da kann es schon passieren dass man die zu hohe Drehzahl erst bemerkt wenn die Beschleunigung auf einmal nachlässt.

Alle einverstanden?

Ja

[saxonfahrer]

Hi Leute,

bin ja echt erstaunt wie interessiert ihr an eurem Schlupf seid. Da darüber aber schon genug diskutiert wurde hier mal ein paar andere Sachen:

Testboard zum Ausprobieren der Sensoren:
pollin nach Bestellnummer : 810 038 suchen
- preiswerter geht es kaum, dazu muss man nur noch für ATMEGA32-16 für 3,50Euro kaufen. (Bestell-Nr. : 100 916) Dieser MC arbeitet mit16MHz, hat 32 I/O und bereits EEPROM, RAM und Flash-Speicher integriert. Der Funktionsumfang dieses MC's sollte vollends ausreichen - das Datenblatt ist immerhin 317 Seiten stark.
-für den Moppedeinbau ist das Board zu groß - zum Testen allerdings bestens geeignet
- wenn man durchs Ausprobieren weiߟ was man an Funktionen braucht, können wir uns dann mit EAGLE ein eigenes Board erstellen,was eventuell direkts ans Cockpit angepasst ist


für die interessierten :tutorial für ATMEGA's - ist das beste Tutorial was ich bis jetzt gefunden hab

Ich hab mir vorallem über die Realisierung schon lange Gedanken gemacht. Gerade die unglaublich komplizierte Sache mit dem Schlupf halt ich für absolut unpraktikabel. Z.Bsp. können wir nicht hunderte Taster im Cockpit anbringen, weil das alles auch wasserdicht und langlebig sein muss. 2 oder 3 Taster müssen ausreichen. Sonst werden auch langsam die Anschlüsse knapp. Allein für Öl und Auߟentemperatur braucht man ja schon 4. Dann der Spritmesser und der Sensor am Vorderrad für die Geschwindigkeit. Nochmal 4. Dann 8 für das Display (egal wieviel Zeilen). Sind schon 16 weg.

Zur Ganganzeige: einfach mal Suche nehmen, wurde alles schon besprochen

Lest mal ruhig das Tutorial. Dann werdet ihr auch bald feststellen, dass gerade solch Sachen wie der Spritmesser und die Geschwindigkeit gar nicht so leicht zu realisieren sind, weil man das an nem MC's nur über Interrupts lösen kann. Bei 2 so hochfequenten Signalen kommt der MC aber schon langsam an seine Grenzen, dafür ist der nicht gemacht. Also muss noch n Zähler her. Und der muss auch erstmal gebaut werden und die Daten müssen dann zum MC.

Mein Vorschlag: keine weiteren Vorschläge, wie man den Herzschlag des Beifahrers bei unterschiedlichen Luftdruck kabellos messen könnte, sondern erstmal die Grundplatine löten und die dringensten Sachen als erstes machen : Öl-Temp, Spritmesser, Geschwindigkeit und Auߟentemperatur (grad im Winter um den Gefrierpunkt) wichtig.

Die Uhr gehört extra - der Aufwand steht in keiner Relation zum Nutzen. Allein die Bauteilkosten übersteigen die einer Uhr aus dem "Laden" mindestens ums doppelte.

Grüߟe
Alex

[Holle]

Der ATMEGA32-16 kostet bei Reichelt sogar nur 2,90 Euro, aber das Evaluations-Board gibt es dort nicht (lediglich ein Profi-Testbord von AMTEl für schlappe 64 Euro, oder dieses STK für knapp 80€).

Reicht dieses günstige Bord denn aus? Kann man damit alles machen was man benötigt (Programmieren, EPROM flashen,...)?

Was hälst du von den anderen ATMEGA-Controller?
Da gibt es welche, die haben 20 MHz (statt 16) und 64 Bit (statt 32). OK, die kosten das doppelte, aber auf 3 Euro mehr kommt es da auch nicht an.

[Noctunus]

Habe für die Auswahl der Sensoren und Funktionen für den ersten Prototypen mal einen neuen Thread erstellt (Phase 2).

Ich denke wenn das erstmal feststeht haben wir einen besseren Überblick über die Anforderungen und können (ein wenig größer Dimensioniert, damit man noch etwas erweitern kann) einen geeigneten Microcontroller anhand dieser auswählen.

[Holle]

Noch eine Idee:
Wenn wir uns nun z.B. für den ATMEGA32-16 ebtscheiden und uns irgendwann die Ports ausgehen, dann können wir die Ports ja vielleicht auch doppelt belegen. Also z.B. wir geben je nach gewünschter Anzeige ein Signal (0 oder 1) mit raus, mit diesem Signal schaltet wir einen elektr. Schalter, welcher Sensor 1 oder 2 auf Eingang 1 legt, Sensor 3 oder 4 auf Eingang 2, usw.
Das würde aber nur mit Sensoren gehen die wir nicht permanent brauchen (geht also nicht mit Durchflusssensor, Geschwindigkeitssensor,...), also z.B. wenn wir die einzelnen Temperaturen "durchzappen", dass dann gleichzeitig die Sensoren dabei umgeschaltet werden. Sö könnten sich Wassertemperatur- und Aussentemperatursensor einen Port teilen (man kann diese Werte dann halt nicht gleichzeitig anzeigen lassen.

Eine Weitere Möglichkeit ist "Arbeitsteilung", sprich wenn wir z.B. ein 2 Zeiliges Display verwenden und 2 MCs, dann kann sich jeder MC um eine Zeile kümmern. So haben wir dann mehr Ports frei. Leider nicht doppelt so viele denn für das Display werden dann auf beiden MCs Ports belegt und manche Sensoren müssten (je mach Funktion) müssen auch auf beide MCs gehen, aber den einen oder anderen Sensor bräuchten wir dann nur auf einem MC, wodurch diese Ports am andern MC für andere Sensoren frei blieben.
Dazu kommt dann die Arbeitsteilung, denn wenn ein MC alles berechnen muss ist der sicher langsamer als wenn der nur einen Teil berechnen muߟ, da der andere MC den Rest übernimmt.

Sollte das ein Problem sein ein Display mit den Daten von 2 MCs zu füttern, kann man ein MC auch für Anzeigen benutzen die kein Display benötigen (LED-Anzeigen, Hupe ansteuern für Alarmanlage, Warnblinkanlage,..).

Und die Mehrkosten von rund 3 Euro sollten wir verkraften können

[saxonfahrer]

also mir scheint die ATMEGA-Reihe von ATMEL das geeignetste zu sein.

Was das Ausgehen der Ports angeht: Zur Not, falls wirklich die 32 I/O-Ports nicht reichen, kann man bei den Temp-Dioden auf etwas teurere 1-Wire Dioden ausweichen. Wie der Name schon sagt, haben die nur eine Leitung zum MC. Für normale Dioden (billig) brauchen wir 2. Bei 3 Temp-Sensoren, hätten wir so schon 3 Ports gespart. Dann gibts noch die Möglichkeit das Display (obwohl 8bit standard ist) mit nur 4 Leitung zu versorgen. Dann ist es zwar langsamer, aber es soll ja auch kein Video drüber laufen. Das sollten wir nicht merken.

Was haben wir:
Display :4
Temp-Sensoren 3x :6
Geschwindigkeit:1
Spritmesser:1
Batteriespannung: 1
3 Taster: 3
6 LED's : 6
7-Segmentanzeige : 7 (könnte man auch noch nen IC vorschalten , dann braucht man bloß 1Leitung)

macht erstmal :29 (23), bei 23 belegten Ports bleiben noch 9. Das ist mehr als genug.



Das Evaluation-Board: Das sehr günstige Board von Pollin hat keinen EEPROM. Den müsste man extern hinzufügen. Allerdings sind die Mehrkosten dafür verschwindend gering, im Gegensatz zu den originalen Boards von ATMEL. Nur das BUTTERFLY von ATMEL wäre vergleichbar günstig. Da ist mir aber schon zuviel fertig gebastelt. Das könnte sich hinterher als Falle herausstellen, weil wir dann nen eventuellen Fehler in unserem Aufbau im Mopped nie finden. Allerdings haben die ATMEGA32 ja nen (wenn auch kleinen EEPROM) integriert.

stärkerer Chip mit Taktrate: Selbst ein 4MHz MC wird sich zu Tode langweilen.
Ich hab mal überschlagen: das Rad gibt bei 200km/h ne Frequenz von ca. 77Hz. Der Spritmengenmesser ist ungefähr im selben Bereich. Es besteht zwar die gefahr, das das Signal vom Geschwindigkeitssensor und vom Spritmesser so Zeitgleich kommmen, dass der Chip dann eines von beiden nicht bemerkt, aber das sollte denk ich extrem selten vorkommen und würde auch nicht so stören. Damit ist mein Einwand von ein paar post's weiter oben zurückgezogen. Ein weiteres Problem: je höher die Taktrate umso besser muss die Spannungsversorgung sein. Deshalb denkich das 8MHz oder 16 MHz vollends ausreichen.

[Noctunus]

Was das Ausgehen der Ports angeht: Zur Not, falls wirklich die 32 I/O-Ports nicht reichen, kann man bei den Temp-Dioden auf etwas teurere 1-Wire Dioden ausweichen. Wie der Name schon sagt, haben die nur eine Leitung zum MC. Für normale Dioden (billig) brauchen wir 2. Bei 3 Temp-Sensoren, hätten wir so schon 3 Ports gespart.
[/quote]
Korrigiere mich wenn ich falsch liege, aber für die Temperaturmessung werden doch mit sicherheit temperaturabhängige Widerstände verwendet, welche sich dann mit einer Leitung an der Batterie und mit der anderen Leitung am MC angeschlossen sind (an den A/D Eingängen).
Ich zähle da nur 3 anstatt 6 Eingänge.

Dann gibts noch die Möglichkeit das Display (obwohl 8bit standard ist) mit nur 4 Leitung zu versorgen. Dann ist es zwar langsamer, aber es soll ja auch kein Video drüber laufen. Das sollten wir nicht merken.

Was verstehst du unter *etwas* langsamer?

Was haben wir:
[...]
7-Segmentanzeige : 7 (könnte man auch noch nen IC vorschalten , dann braucht man bloß 1Leitung)

Nur eine Leitung für eine 7-Segementanzeige? Also das man mit BCD die Leitungsanzahl auf 4 Reduzieren und durch Multiplexen mehrere 7-Segementanzeigen parallel betreiben kann war mir schon bewusst, aber wie man das auf eine Einzelne runter bekommt ist mir nicht bekannt - erleuchte mich!

macht erstmal :29 (23), bei 23 belegten Ports bleiben noch 9. Das ist mehr als genug.

Das denke ich auch, dass die Portanzahl ausreichen sollte. Und falls es doch mal eng werden sollte könnten wir wirklich auf den Vorschlag von Holle ausweichen und funktionen auf 2 MC's aufsplitten.
Wie sieht es in dem Zusammenhang mit Kommunikation zwischen 2 MC's aus? Da lieߟe sich sicher was machen um Daten zwischen diesen austauschen zu können damit diese z.B. nicht die gleichen Sensoren 2x auslesen müssten.
Wenn beide MC's mit dem gleichen Takt über nen Quarz versorgt sind sollte die Synchronisierung ja auch kein so großes Problem darstellen, oder?

Das Evaluation-Board: Das sehr günstige Board von Pollin hat keinen EEPROM. Den müsste man extern hinzufügen. Allerdings sind die Mehrkosten dafür verschwindend gering, im Gegensatz zu den originalen Boards von ATMEL. [...]
Allerdings haben die ATMEGA32 ja nen (wenn auch kleinen EEPROM) integriert.

Na dann kommen wir doch mit dem Board von Pollin hin, wenn der schon nen EEPROM drin hat, oder?

stärkerer Chip mit Taktrate: Selbst ein 4MHz MC wird sich zu Tode langweilen.
Ich hab mal überschlagen: das Rad gibt bei 200km/h ne Frequenz von ca. 77Hz. Der Spritmengenmesser ist ungefähr im selben Bereich. Es besteht zwar die gefahr, das das Signal vom Geschwindigkeitssensor und vom Spritmesser so Zeitgleich kommmen, dass der Chip dann eines von beiden nicht bemerkt, aber das sollte denk ich extrem selten vorkommen und würde auch nicht so stören. Damit ist mein Einwand von ein paar post's weiter oben zurückgezogen. Ein weiteres Problem: je höher die Taktrate umso besser muss die Spannungsversorgung sein. Deshalb denkich das 8MHz oder 16 MHz vollends ausreichen.

Ich denke das Fehlen eines einzelnen Impulses könnte auch Softwaremäߟig behandeln - dadurch wird die Programmlogik ein wenig komplexer aber es ist auf keinen Fall ein unlösbares Problem.
Zu der Spannungsversorgung müssen wir uns sowieso was einfallen lassen - ich denke z.B. die betätigung des Anlassers könnte ganz schöne Spannungsschwankungen verursachen, ganz abgesehen von Lichtanlage und sonstigen Spielereien.
Hab mich mal bisschen umgeschaut und das hier gefunden:
LM2676S-3.3
Datenblatt: <!-- m --><a class="postlink" href="http://pdf1.alldatasheet.com/datasheet-pdf/view/8784/NSC/LM2676S-3.3.html">http://pdf1.alldatasheet.com/datasheet- ... S-3.3.html</a><!-- m -->
Garantierte Ausgangsspannung von 3,3 , 5 oder 12V mit ner Toleranz von 2%
Denke das sollte reichen, oder?

[saxonfahrer]

Was das Ausgehen der Ports angeht: Zur Not, falls wirklich die 32 I/O-Ports nicht reichen, kann man bei den Temp-Dioden auf etwas teurere 1-Wire Dioden ausweichen. Wie der Name schon sagt, haben die nur eine Leitung zum MC. Für normale Dioden (billig) brauchen wir 2. Bei 3 Temp-Sensoren, hätten wir so schon 3 Ports gespart.

Korrigiere mich wenn ich falsch liege, aber für die Temperaturmessung werden doch mit sicherheit temperaturabhängige Widerstände verwendet, welche sich dann mit einer Leitung an der Batterie und mit der anderen Leitung am MC angeschlossen sind (an den A/D Eingängen).
Ich zähle da nur 3 anstatt 6 Eingänge.

Für ne vernünftige Temperaturmessung müsste man eigentlich ne Vierpunktmessung machen. Als ne Präzisionsstromquelle (meinetwegen mit LM317) und 2 Leitung, die den Spannungsabfall messen. Damit brauchst du für die Spannungsmessung 2 Leitungen, weil man bei den kleinen Spannungen nicht davon ausgehen, dass man das gleiche Potential an der Diode hat, wie an der Versorungsseite des MC's. Die 1-Wire-Diode (oder I2C-Bus) haben ja schon ne Logikschaltung integriert und geben schon ein digitales Signal ab. Deshalb ist auch nur ein Port nötig.

Dann gibts noch die Möglichkeit das Display (obwohl 8bit standard ist) mit nur 4 Leitung zu versorgen. Dann ist es zwar langsamer, aber es soll ja auch kein Video drüber laufen. Das sollten wir nicht merken.

Was verstehst du unter *etwas* langsamer?

Bei nur 4-Bit hat das Display quasi nur die Hälfte der Geschwindigkeit, da im ersten Schritt 4-Bit und danach im zweiten Schritt auch 4-Bit übertragen werden. Da aber trotzdem sowohl Display-Controller als auch MC im MHz-Bereich arbeiten, ist das kein Problem.

Was haben wir:
[...]
7-Segmentanzeige : 7 (könnte man auch noch nen IC vorschalten , dann braucht man bloß 1Leitung)

Nur eine Leitung für eine 7-Segementanzeige? Also das man mit BCD die Leitungsanzahl auf 4 Reduzieren und durch Multiplexen mehrere 7-Segementanzeigen parallel betreiben kann war mir schon bewusst, aber wie man das auf eine Einzelne runter bekommt ist mir nicht bekannt - erleuchte mich!

Hmm... find grad auch keinen passende IC's dafür. Allerdings wäre der MAX7219 trotzdem ein gutes Beispiel. Das ist ein LED-Treiber, der nur 3 Anschlüsse braucht um damit bis zu 8 7-Segmentanzeigen zu betreiben. Man braucht überhaupt keine anderen Bauteile, alles im MAX7219 integriert. Sogar die Helligkeit kann softwareseitig eingestellt werden. Multiplexen übernimmt der MAX allein.

Ich bin mir aber trotzdem recht sicher irgendwa mal noch nen einfachen IC gesehen zu haben, der mittels I2C-Bus einfach das digitale 8-Bit Signal auf einer oder mehreren Siebensegmentanzeigen ausgibt. Ich find aber im Moment nix.

Das Evaluation-Board: Das sehr günstige Board von Pollin hat keinen EEPROM. Den müsste man extern hinzufügen. Allerdings sind die Mehrkosten dafür verschwindend gering, im Gegensatz zu den originalen Boards von ATMEL. [...]
Allerdings haben die ATMEGA32 ja nen (wenn auch kleinen EEPROM) integriert.

Na dann kommen wir doch mit dem Board von Pollin hin, wenn der schon nen EEPROM drin hat, oder?

Das kommt auf nen Versuch an. Wenn man sich so eine Art Charakteristik für die Sensordaten speichern will reicht der eingebaute EEPROM nicht. Allerdings ist nachrüsten auch kein großes Problem. Für reine Anzeigezwecke sollte der EEPROM vom ATMEGA32 aber reichen denk ich.


Der LM2676S-3.3 klingt super. Wie würden die 5V Variante nehmen, da die Mikrocontroller alle auf 5V-Basis arbeiten.

Grüߟe
Alex

[Holle]

Nur eine Leitung für eine 7-Segementanzeige? Also das man mit BCD die Leitungsanzahl auf 4 Reduzieren und durch Multiplexen mehrere 7-Segementanzeigen parallel betreiben kann war mir schon bewusst, aber wie man das auf eine Einzelne runter bekommt ist mir nicht bekannt - erleuchte mich!

Hmm... find grad auch keinen passende IC's dafür. Allerdings wäre der MAX7219 trotzdem ein gutes Beispiel. Das ist ein LED-Treiber, der nur 3 Anschlüsse braucht um damit bis zu 8 7-Segmentanzeigen zu betreiben. Man braucht überhaupt keine anderen Bauteile, alles im MAX7219 integriert. Sogar die Helligkeit kann softwareseitig eingestellt werden. Multiplexen übernimmt der MAX allein.

Ich bin mir aber trotzdem recht sicher irgendwa mal noch nen einfachen IC gesehen zu haben, der mittels I2C-Bus einfach das digitale 8-Bit Signal auf einer oder mehreren Siebensegmentanzeigen ausgibt. Ich find aber im Moment nix.

Ich hätte da eine Idee:
Wir haben ja 12 Volt zur Verfügung. Wenn wir nun für Leerlauf 0 Volt, für den 1. Gang 2 Volt, 3. Gang = 4 Volt, usw. ausgeben, dann können wir die Spannung wieder umwandeln um die 7-Segment-Anzeige zu betreiben.
So würde man mit einem einigen Anschluss dafür auskommen.


Mal was anderes, wie wäre es wenn wir ein DOT-Matrix-Display nehmen würden? Dann könnten wie den Gang irgendwo hübsch darin integrieren, Temperaturen grafisch darstellen (Drehzahlen auch) usw.
Man hätte VIEL mehr Möglichkeiten die Ausgabe zu realisieren.
OK, solche Displays sind teurer, aber wenn man letztendlich 30 Euro mehr ausgibt, dafür aber ein geiles grafisches Display hat (evt. mit Begrüߟungsanimation, usw.) das wäre mir den Mehrpreis auf jeden Fall wert.

[Noctunus]

Mal was anderes, wie wäre es wenn wir ein DOT-Matrix-Display nehmen würden? Dann könnten wie den Gang irgendwo hübsch darin integrieren, Temperaturen grafisch darstellen (Drehzahlen auch) usw.
Man hätte VIEL mehr Möglichkeiten die Ausgabe zu realisieren.
OK, solche Displays sind teurer, aber wenn man letztendlich 30 Euro mehr ausgibt, dafür aber ein geiles grafisches Display hat (evt. mit Begrüߟungsanimation, usw.) das wäre mir den Mehrpreis auf jeden Fall wert.

Ganz so teuer wäre ein Display nicht - zumindest nicht was ich gefunden habe:
<!-- m --><a class="postlink" href="http://www.pollin.de/shop/detail.php?pg=OA==&a=MTg2OTc4OTk=&w=OTg4OTk4&ts=20">http://www.pollin.de/shop/detail.php?pg ... OTk4&ts=20</a><!-- m -->
Graustufen sollen ausreichen, nur wie es mit der Hintergrundbeleuchtung aussieht ist dort allerdings nicht beschrieben.

Mir persönlich wäre es auch lieber ein "vernünftiges" Display zu haben, nur würde das auch bedeuten, dass je nach dem einige Ports dafür draufgehen und vor allem das soetwas auch den aktuellen Rahmen der Programmlogik um einige Faktoren sprengen würde.
Es ist eine Sache ein alphanumerisches Display mit Daten zu füttern - bei Dotmatrix bzw alles punktbasierten Displays müsste die gesamte Logik geschrieben werden welcher Punkt in welchem Moment welchen Zustand hat.
Selbst wenn die Ansteuerung ansich also kein Problem darstellen sollte - so würde die Entwicklungszeit für die Bordcomputersoftware dennoch extrem ansteigen.

Wenn ich nur im geringsten den Aufwand abschätzen könnte wäre ich der Erste der Ja schreien würde.