GPZ Forum
Phase 3 : Bordcomputer - Druckversion

+- GPZ Forum (https://gpz.info)
+-- Forum: Sonstiges (https://gpz.info/forumdisplay.php?fid=7)
+--- Forum: Projekte (https://gpz.info/forumdisplay.php?fid=42)
+---- Forum: Bordcomputer (https://gpz.info/forumdisplay.php?fid=85)
+---- Thema: Phase 3 : Bordcomputer (/showthread.php?tid=4157)

Seiten: 1 2

Phase 3 : Bordcomputer - saxonfahrer - 19.11.2008

Hi liebe Forumsmitglieder und Bastelfreunde,

es ist soweit , die nächste Phase des Bordcomputers ist angebrochen und damit ein absolutes Novum was dieses Thema angeht : es gibt erste Versuche der Umsetzung, was bereits seit 2 Jahren vorgeschlagen wird. Aber lest selbst Smile

Ich habe jetzt schon ein wenig mit nem selbst entworfenem Test-Board rum probiert und so hier und da was angelesen, so dass ich jetzt mal die ersten Rahmenbedingungen vorgeben will. Das soll sicherstellen, dass bei Fehlern in neuen Komponenten (Verdrahtung) oder im Programmier-Code durch das Forum schnell geholfen werden kann.

Und schon gehts los:

1. Controller : ATMega8 --- der ist günstig (1,25€, Reichelt). den gibts überall, und der hat auch genug Ein- und Ausgänge und genug Funktionen. Falls es nach her so viel Zusätze gibt, dass er doch nciht reicht, lassen sich die Schaltpläne auch leicht auf den ATmega32 erweitern ---> hier kann aber auch noch diskutiert werden

2. Bauweise (SMD oder DIL): hier schlage ich erstmal die großen DIL-Formate für die IC's vor. Es lässt sich einfach leicht verlöten. Allerdings können ruhig einige Widerstande, Kondensatoren oder sowas in SMD-Ausführung benutzt werden (am besten 1206-Format). Da spart man sich dann Löcher-Bohren und die 2-Pins lassen sich leicht verlöten und es nimmt wenig platz weg.

3. Programmiersprache : es gibt zwar sicher einige im Forum, die in C oder C++ sehr bewandert sind. Aber es gibt auch viele, die es nich sind (z.Bsp. ich Oops ). Deshalb schlage ich BASCOM vor. Das ist eine sehr komfortable Programmier-Umgebung mit einem Basci-Dialekt, der selbst bei geringen Programmier-Kenntnissen schnell zu erlernen ist. Das Programm liegt als Demo-Version vor und bieten alles was wir brauchen (Demo-Version hat alles Features der Vollversion , lediglich Begrenzung auf 4kB Code-Größe)
Bascom-Demoversion

4. Schaltplan/Layout-Programm: Zum Schluss soll ja eine vernünftige Platine rauskommen. Das kann man mit Lochraster-Platinen oder anderen fliegenden Schaltungen nicht mehr bewerkstelligen. Deshalb soll als Endprodukt eine professionell geätzte Platine stehen, nur dafür ist ein entsprechender Schaltplan und ein Layout nötig. Als Schaltplan/Layout-Software schlage ich EAGLE vor. Eagle gibts als Light Variante (reicht völlig aus) und diese ist kostenlos : Eagle-Download

Damit ist fürs erste genug vorgeschlagen. Diskussionen über eventuelle Änderungen können bitte im Phase2 : Bordcomputer-Thread geführt werden.


Hier noch ein paar Hilfen für die Neulinge im Mikrocontroller-Gebiet (dazu zähle ich mich auch Smile ):


gute Foren (allerdings nicht annähernd mit dem GPZ.info-Forum zu vergleichen Wink ):
Mikrocontroller.net [marq=right] gutes Forum mit sehr vielen Infos und fertigem Code, extrem ausführliches Tutorial : AVR-Tutorial von Mikrocontroller.net

Roboternetz.de [marq=right] sehr schönes Forum mit extra Wissensbereich und sehr guten Tutorials :
Tutorial von Roboternetz

AVR-Freaks.com [marq=right] sehr umfangreiche Seite mit sehr vielen Projekten
Bascom-Forum.de [marq=right] gute Hilfe für Bascom-Programmierung

Beste Grüߟe
saxonfahrer

Datenblatt-Atmega8
Datenblatt-ATmega32

- saxonfahrer - 19.11.2008

Hier ist mein Grundschaltplan der mit einem ATmega8 auskommt und die Spannungsversorgungn und Taktgebung enthält. Zusätzlich ist bereits ein Modul zur Kommunikation über RS232 (serielle Schnittstelle) angehängt. Das Format ist EAGLE (braucht man also zum öffnen).

Zusätzlich hab ich noch eine Variante mit einem ATmega32 erstellt und den auch schon gleich mit einem Uhrenquarz ausgerüstet.

Bitte nicht vergessen die Dateiendungen von txt in sch zu ändern (steht für shematics)



-----------------------------------------------------------------------
Hinweis : auch wenn es einige wundern wird, dass ich hier einen so krummen
Wert für den Quarz-Kristall (also die Takt-Frequenz) verwandt haben. Das hat einen Grund.
Mit solch einem "krummen" Quarz lassen sich viel besser die Baud-Raten 9600, 19200, usw für die RS232-Terminal-Verbinung zum PC bewerkstelligen. Die geraden Taktraten wie 4,00000Mhz oder so bringen gar keinen Vorteil.
---------------------------------------------------------------------------


Beste Grüߟe
saxonfahrer

- saxonfahrer - 19.11.2008

Und weiter gehts : nach dem vielleicht einige Interessiert die Schaltpläne in EAGLE mal geöffnet haben wird man sich dann bestimmt schnell fragen : und wie ist das mit der Programmierung ???? Wie schwer ist das und hab ich ne Chance da mit zumachen?

Deshalb ist hier mal mein erster Entwurf für einen Tacho-Ersatz bzw. Zusatz.
Der Code ist für Bascom geschrieben und bewerkstelligt Geschwindigkeit, Durschschnittsgeschwindigkeit, Höchstgeschwindigkeit und Uhrzeit. Eine Ausgabe hab ich noch nicht eingefügt - aber das kommt noch Smile

Beste Grüߟe
saxonfahrer

- Marrador - 20.11.2008

Schöne Vorarbeit hast Du da geleistet.

Aus Erfahrung kann ich Dir sagen das du mit "Blut, Schweiߟ und Tränen" jede Programmiersprache erlernen kannst.
Aber unterschätze das nicht, das was Du dir da vorgenommen hast ist schon nicht ganz trivial. Da du stark an der Hardware proggen musst, musst du dich schon heftig mit Rechnerarchitektur auseinandersetzen. Im letzten Semester habe ich den Schein "Rechnerarchitektur" nach 8 Vorlesungen geknickt. War mir zu heftig für dieses mal... Smile Hatte noch 11 andere Scheine zu schreiben o.O

Hier ein paar Beispiele wie es aussehen könnte in Assembler.

Als Beispiel sei mal etwas ganz einfaches gegeben. In Java kann ich in einer einzigen Zeile dies hier sagen:

int k, j, i;
k=i+j;

Im Assembler sieht das ganze schonmal so aus...
0x0 0x9010 Lds R1, 0x0000
0x2 0x0000
0x4 0x9020 Lds R2, 0x0004
0x6 0x0004
0x8 0x0C12 ADD R1, R2
0xA 0x9210 STS R1, 0x0008
0xC 0x0008
...
0x30 0x007
0x32 0x1c12 ADC R1,R2
0x34 0x9210 STS R1, 0xB
0x36 0x000B

Du siehst direkt am AVR ist das ganze nur in Hexadezimal zahlen zu gewährleisten.

Ein weiteres Beispiel mit einigen Erklärungen:
1. Erst laden mittels LOAD
LDS R1, 300 //R1 = m[300]direkt mit Adresse
LDI R27, 1 // R27=1, "Immediate" den Wert
LDI R26,5 //das ergibt zusammen x=0x0105=261

2. Rechnen
ADD R2,R1 //R2= R2 +R1, C=(r1+r2)/256, C=Übertr.
ADC R3,R4 //R3=R3+R4+C
SUB Rd, Rr // Rd- =Rr, destination, register
SBC Rd, Rr //Rd=Rd -Rr-C
SUBI R16,0x33 //R16=R16-51
DEC Rd //Rd--, wozu? SUBI Rd,1 setzt C-Flag, DEC nicht

3. Schreiben
ST R2, X // wie LD, auch STS (direkt)

Assembler ist also eine sehr laaaaangwierige Sprache, dafür aber unwahrscheinlich genau da hier Bitweise operiert wird. Bascom dagegen... naja Rolleyes

Das Problem das ich bei Bascom sehe ist das es auf der Grundlage von Basic basiert. Basic ist (zumindest für mich) eine sehr unlogische Sprache im Vergleich zu C. Dazu kommt wie ich gerade lese das der Compiler (also das was den Code in Assembler umwandelt) nicht wirklich sauber arbeitet und häufiger mal Schrott produziert. Mein Favorit ist C. Da C sehr sauber geschrieben werden kann. Das da auch komplizierte Dinge wie Pointer sind können wir glaube ich getrost beiseite lassen, so kompliziert wird die AVR Programmierung in diesem Falle nicht.

Ich habe ein sehr geiles Tuturial für C auf AVR gefunden.

C auf AVR Tut

An den anstehenden Programmieraufgaben möchte ich mich auf jeden Fall mit beteiligen. Ist ne prima Übung Smile

Greetz
Marrador

- saxonfahrer - 20.11.2008

Ich geb dir recht : Bacom ist keine saubere Sprache. Aber sie ist einfach und verständlich und hat seeeeeeeehr viele Befehle die unglaublich viel Arbeit abnehmen. Z.Bsp. um etwas auf nem LCD auszugeben lade ich einfach mit einem Befehl die entsprechende LCD-Bibliothek (gibts nur für Bascom) und dann schreibt man LCD_Print und schon ist man fertig. In C oder gar Assembler (das ist mal kategorisch ausgeschlossen) ist das viel viel komplizierter.

Und warum soll man sich das so kompliziert machen . Ist ja nicht so, dass wir auf optimierten Code angewiesen sind. Ein Beispiel: selbst wenn man mit Bascom für eine Aufgabe wie x = t/k ca. 1000 Takte benötigt und mit C vielleicht nur 100 (nachdem man 2 Monate gebraucht hat um den Algorithmus dafür zu schreiben) und mit Assembler so gar noch weniger. Aber wozu . Der AVR macht 3,6Mio Takte pro Sekunde . Oder wenn ich will auch 16Mio. Und selbst wenn DZM, Tacho und Spritgeber inputs liefern - ist doch total schnurz, so wenig wie da kommen. Der gammelt doch eh 90% seiner Zeit ab und langweilt sich. Smile

Zitat:Da du stark an der Hardware proggen musst, musst du dich schon heftig mit Rechnerarchitektur auseinandersetzen.

Ich bin zwar kein Informatiker oder E-Techniker, aber das stimmt so nicht. Es wird ja grad deshalb so ein leistungstechnisch überdimensionierter Chip wie der ATmega8 oder ATmega32 verwendet, damit man ohne groß optimieren zu müssen Code schreiben kann wie man möchte. Und zum zweiten wird gerade deshalb auch BASCOM benutzt: hier muss ich nciht über die internen Vorgänge bescheid wissen. Das haben andere schon vor mir gemacht und entsprechend umfangreicharbeitende Befehle geschrieben - man muss das Rad ja nicht zweimal erfinden.

Aber das wichtigste noch : Ich freu mich, dass du dich beteiligen willst und uns unterstützt

- Marrador - 20.11.2008

Bin auch kein Informatiker ^^ nur Wirtschaftsinformatiker... Wink

Das mit dem Hardwarenahen programmieren stimmt dennoch. Du musst ja schliesslich wissen wann und wie und vor allem auf welchen Pins was ankommt. Da auf den Pins nur 0 oder 1 ankommt ist das schon sehr Hardwarenah... Das auszuwerten um umzusetzen ist/wird der größte Teil der Arbeit.

Das mit den LCD Befehlen habe ich überlesen, wenn es da also schon vorhandene Routinen gibt. Hast Du Recht... Neuprogrammieren ist immer anstrengender als Reprogrammieren. Da ist Bascom dann doch eine interessante Wahl...

Ich gebe zu Oops ich habe bisher nicht viel über das Projekt gelesen. Steht denn schon fest von wo die Eingabesignale kommen? Welche Werkzeuge werden da benutzt? Ich meine Woher kommt das Byte das die Tankanzeige steuern soll?

Ich könnte mir vorstellen das die Tankanzeige so aufgeteilt werden könnte...
0 -> 1/8 -> 2/8 -> 4/8 ->6/8 ->8/8
Das entspräche den Bits
0 = 0 0 0 0 0 0 0 1
(hier 1 als Funktionsüberprüfung da auf dem Board zumindest ein Lämpchen leuchten könnte)
1/8= 0 0 0 0 0 0 1 0
(Reserve?)
2/8= 0 0 0 0 0 1 0 0
4/8= 0 0 0 0 1 0 0 0
5/8= 0 0 0 1 0 0 0 0
6/8= 0 0 1 0 0 0 0 0
8/8= 0 1 0 0 0 0 0 0

Da der Tank ich glaube 18 Liter waren es sich prima durch 8 teilen lässt mit 2/8 wären wir bei 4,5 L Reserve... was ja auch ungefähr der Reservestellung am Benzinhahn entspricht, oder?

- saxonfahrer - 20.11.2008

@marrador: da du prinzipiell schon etwas bewandert bist kommt hier die ultra-kurz-Beschreibung für die Pin-Funktion

DZM, Tacho-Geber und Sprit geben auf den Pin einer Wahl (es geht nicht jeder der 23 Pins!!!) entsprechend ein Signal (5V) wenn der jeweilige Geber auslöst. Dadurch wird ein Interrupt ausgelöst (guck dir mal mein Tacho-Programm dazu an). Den Interrupt kann man leicht auswerten und erhält dann intern den jeweiligen Wert durch Zählen der Interrupts. Das wars auch schon. Jetzt sind die Geber-Daten im µC in Byte-Form.

Die Interrupts sind eins der mächtigsten Werkzeug im Mikrocontroller. Ein wirklich tolles Buch dazu ist : AVR-Buch
kann man auf der Seite auch online lesen, aber steht auch in den meisten Fach-Bibliotheken Smile Ist wirklich so super geschrieben, dass man es nachts halb 2 vor dem einschlafen lesen kann, es versteht und am nächsten tag noch fast alles weiߟ Big Grin

Beste Grüߟe
alex

- Marrador - 21.11.2008

Tja... also ich habe mir dein Prog durchgelesen und ärgere mich schon über die Sprache Smile Aber das geht vorbei Twisted .

Ich versuche mich mal an einer rekapitulation:

Zur Verfügung stehen 23 Pins. Benötigt werden pro Messeinheit, ich stelle mal eine Vermutung an:

Geschwindigkeit, Kilometerzähler = Pin#1 -> Pin#4 (4Bit)
Tageskilometer, Tourenzähler = Pin#5 -> Pin#8 (4Bit)
Tankanzeige = Pin#9 -> Pin#16 (8Bit)
Drehzahlmesser = Pin#17 -> Pin#18 (2Bit)

Da nicht jeder Pin für jede Einheit einsetzbar ist sind die Angaben natürlich Variabel.

Da du in deinem Worddokument den Befehl $regfile = "m8def.dat" verwendest gehe ich davon aus das Du schon eine Pinbelegung vorgenommen hast. Wo gibts die denn anzusehen?

Dann weiߟ ich leider immer noch nicht von welchem Gerät (in diesem Falle Tankanzeige) die Elektronischen Signale kommen. Da dieses Gerät ja festlegt wie viele Pins benötigt werden und wie ich den Interpreter aufsetzen muss.

Das mit den Interrupts ist soweit klar. Aber auch hier brauche ich die Ausgangsdefinition des Signalgebers (Tachouhr, Tankuhr,...) z.B. Gibt der Signalgeber "Tank" auf einen Pin welches Signal für "0/8", "2/8", "4/8", "6/8", "8/8", bzw. wie ist die Tankuhr überhaupt aufgeteilt? Wenn das Signal nur auf einen Pin geht, dann muss das 5V Signal ja in irgendeiner Form so variabel sein das ein Byte entsteht. Wie genau ist das definiert?

Du siehst jede Menge Unklarheiten ... Big Grin aber wenn das alles schon besprochen wurde, reicht ein hinweis wo Smile

Gruߟ vom ebenfalls Alex ^^

- saxonfahrer - 21.11.2008

Hi ebenfallsAlex Smile

also du kannst beruhigt sein : das wurde noch nirgends besprochen .

Zu den Interrupts - da denkst du zu global. In normalen PC-Prozessoren stehen die ja an der Tagesordnung . Für nen µC ganz und gar nicht. Interrupt bedeutet hier : es ändert sich was. Und mehr ist auch nicht nötig. Ich versuchs am Beispiel vom Tacho zu erklären. Da wird ein Reed-Kontakt an der Gabel angebracht und 2 oder mehr Magneten auf die Bremsscheibe geklebt. Der ReedKontakt schlieߟt oder öffnet (weiߟ ich grad nicht genau) wenn ein Magnet vorbei kommt. An diesem Kontakt sind 2 Drähte. Einer geht auf Masse, der andere geht auf Pin PD2 (die Belegung hab ich aus dem Datenblatt und ist als Bild angehängt). Intern sind im Atmega alle sogenannten Pullup-Widerstände angestellt. Das heiߟt, dass alle Pins ohne Signal auf 5V liegen. Wenn der Reed-Kontakt jetzt schlieߟt weil ein Magnet vorbei kommt, dann zieht er die Spannung an Pin runter (ist ja mit Masse verbunden). Jetzt wird der Interrupt im ATmega ausgelöst und eine Variable wird hochgezählt (wenn man das so programmiert hat Smile ). Fertig

Analog funktioniert es beim DZM und beim Durchflussmesser (der zur Tankanzeige benutzt wird - funktioniert bei Steve-O schon mit nem Fahrrad-tacho als Anzeige). Du siehst, man benötigt nur 3 Pins, da man ja keinen echten Wert aulesen kann. Das würde nen Encoder vorraussetzen, und der würde auch nix anderes machen als der ATmega - also wozu sinnlose Bauteile anschaffen. Smile

Mir fehlt grad auf, dass ja nur 2 Pins für echte Interrupts zur Verfügung stehen (PD2 und PD3) und das ist auch beim ATmega32 so. Mehr Interrupts setzen auch mehr Timer vorraus. Das ist mir vorher noch nicht aufgefallen, weil ich den DZM eigentlich nicht mit abnehmen lassen wollte, denn der bringt ja keine sinnvolle Info. Für Tacho und Sprit reicht aber offensichtlich der Atmega8

Beste Grüߟe und fragt ruhig weiter

Der saxonfahrer

- Steve-o - 21.11.2008

nur könntest du ja mit dem Drehzahlmesser ne Ganganzeige basteln...oder man bastelt sich das wenn mans braucht noch als extra bauteil...
mit wievielen eingängen kann denn der Atmega analoge werte auslesen? (z.B. für Temperatur oder für Batteriespannung)

- saxonfahrer - 21.11.2008

Hi,

ich finds auch das Beste für DZM und ne eventuelle Gang-Anzeige einen extra ATmega zu nehmen - der Aufwand ist doch relativ gering.

Was die Analogen Signale angeht. Das macht der Analog/Digital-Converter (ADC) - davon gibts am Atmega8 6 Stück (PC0-PC5). Allerdings muss man sich darüber noch mal sehr viele Gedanken machen, weil ne Messung an diesen Pins bis zu 300ms dauert - das wäre absolut inakzeptabel wenn der noch Uhrzeit und Tacho machen soll.

Die Temperaturen würde ich nicht über irgendwelche Widerstände auslesen. Auch wenn die relativ günstig sind (NTC kostet um die 30cent + Konstantstromquelle) würd ich doch der Einfachheit halber digitale 1-Wire Temperatur-Sensoren wie den DS1820 nehmen. Der kostet zwar mit 3Euro das zehnfache, aber es gibt keine zeitkritischen Probleme, man braucht nur einen Pin. Mehr als 2 Sensoren sind ja auch nicht nötig (Öl-Temp und Auߟentemp.) .

Beste Grüߟe

saxonfahrer

Tante Edith: Ich kauf eh nicht so gern bei so großen Versendern sondern unterstütze lieber die kleinen Spezialisten. Und ich hab nen Shop gefunden, der in vielen Teilen sogar noch günstiger ist als Reichelt (Conrad spielt auߟer Konkurenz mit ihren exorbitant hohen Preisen) : CSD-Electronics . Die haben ne ziemlich coole Seite mit schönen Erklärungen (im Shop gucken). Da kostet der DS1820 z.Bsp nur 1,85 - das ist denk ich okay.

- Noctunus - 26.02.2009

ok dann möchte ich auch mal kurz nen Kommentar hinterlassen. Leider komme ich zur Zeit nicht wirklich dazu was zusammen zu stecken und zu Testen was sich hoffendlich nach meinen Abschlussprüfungen ändern wird.
Aber bevor ich zu weit ausschweife zurück zum Thema:

1. Controller: Da ich mir schon den Atmega32 zugelegt habe werde ich denke ich auch dabei bleiben - ggf kommt da noch ein Zweiter oder ein Atmega8 dazu falls uns/mir mal ports oder interruptports ausgehen sollten.

2. Bauweise: DIL - lässt sich sowohl gut zusammenstecken als auch gut verlöten. Ausserdem können wir so relativ einfach platinen dafür machen welche sich dann mit nicht soviel fummelaufwand bestücken lassen.
Da wir eh nicht so massig viele komponenten haben können wir die auch mit dil bauweise gut auf ne kleine platine stopfen.

3. Programmiersprache: Da ich sowohl Hobby- als auch Berufsmäߟig viel mit C zu tun habe und die Sprache auch recht einfach zu lernen und lesen ist (wenn man nicht gerade tief in die Pointerarithmetik einsteigen möchte) würde ich vorschlagen das wir versuchen zumindest eine Kompatiblität zu erreichen. Ich weiss zumindest das man (falls jemand so selbstzerstörerisch sein sollte) Assemblercode ganz einfach in C integrieren kann - wie es mit der Anbindung von C an BASCOM aussieht weiss ich allerdings nicht.
Zur Not kann ich auch hingehen und den BASCOM code in C portieren sobald ich in die zusätzliche µC funktionalität eingestiegen bin. So wie ich das bisher überblicken konnte wurde in Phase2 auch von allen Seiten gesagt das C die bevorzugte Wahl wäre.
"In C oder gar Assembler (das ist mal kategorisch ausgeschlossen) ist das viel viel komplizierter." - Wenn sich einer dran setzt und mal eine Funktion zum gegebenen Thema schreibt und diese dann an alle verteilt (ich wäre eh für ein gemeinsames SVN-Repository welches ich gerne auf meinem Root-Server zur Verfügung stellen würde) sehe ich da kein großes Problem.
Naja da können wir uns ja auch noch später drum kümmern sobald es mal an die "richtige" Programmierung geht welche über Testprogramme hinaus geht.

4. Layout: Eagle hört sich gut an - habe zwar noch nicht wirklich damit Erfahrung sammeln können aber soweit ich weiss kann es zumindest die Leiterbahnen automatisch legen. In meiner letzten Ausbildung habe ich das noch alles händisch mit einem äuߟerst minimalistischen Programm selber machen dürfen was ziemlich nervig wäre aber auch kein größeres Problem darstellen sollte.
Daneben wäre ein vernünfiger Schaltplan wirklich von Vorteil - kann man das auch ordentlich mit Eagle machen?
Denke ich hab das schonmal erwähnt, aber ich sags einfach nochmal. Auf meiner alten Ausbildungsstelle habe ich die Möglichkeit zum Selbstkostenpreis Platinen zu ätzen was ich auch machen werde sobald ein vernünftiges Platinenlayout fertig ist.


So und nochmal ein paar allgemeine Sachen:
Da ich ursprünglich den µC mehr als Einheit angedacht hatte um die Werte von Geschwindigkeit, Drehzahl und Durchflussmesser zu erfassen und mein Cockpit dementsprechend anzupassen (LED-Drehzahlmesser, Spritverbrauchanzeige) würde ich diese Sachen auch gerne mit unterbringen. Da es sich mittlerweile herauskristalisiert hat das es besser wäre das Projekt etwas Modular aufzubauen um auf der "Hauptplatine" Stecker für Erweiterungsplatinen anzubringen würde ich vorschlagen im nächsten Schritt schonmal die Portbelegung durchzugehen mit allem was nötig und "nice-to-have" wäre um eine genaue Vorstellung zu bekommen ob die Ports überhaupt ausreichen und ob wir neben der Hauptplatine noch weitere mit µC bestückte module bräuchten um Portknappheit oder Verzögerungen in Abfragen zu umgehen.


Um die Sensoren nochmal zusammen zu fassen:
Durchflussmesser 1x Interruptport
Geschwindigkeit 1x Interruptport
Drehzahl 1x Interruptport
Temperatursensoren max 2x 1wire (Öl, Auߟen) [optional +1x 1wire für Kühlwassertemperatur]

Für die Ausgabe:
LCD Zeilen Display 7-11 Ports je nach Anschlussart
[Bei mir kämen hier jetzt noch einige Ports für den LED-Tacho und LED-DZM, mir ist allerdings gerade die Portanzahl entfallen die die Treiberbausteine verbraten also später dazu mehr]

Grüߟe

- Steve-o - 26.02.2009

Den Digitalen Drehzahlmesser können wir ja komplett ausgliedern...
Digitaler Drehzahlmesser
können ja die erzeugte Spannung auch in den BC speisen um mit der Geschwindigkeit ne Ganganzeige zu erzeugen...

- Fle>< - 26.02.2009

Eagle kann alles, nur nicht programmieren ;)
Und es ist kostenlos, für den Privatgebrauch.

- Steve-o - 26.02.2009

erstellt nur in der kostenlosen Version leider kein automatisches Layout...da muss man die Verbindungen selber malen...er zeigt einem zwar wie die sein müssen (also von welchem Beinchen welchen Bauteils zu welchem Beinchen des anderen Bauteils) aber malen muss man das Chaos selber Wink Smile