Translate

10 März 2010

Serielle Anzeige selbst programmiert (fast)

Tja............
die fertigen Programme haben nicht ganz so
funktioniert, wie ich das haben wollte..........
Ich musste mich also selber hinsetzen!
Das ist sowieso die befriedigendere Lösung.

Was wollte ich haben?
1. ATtiny als Basis wg. Bascom-Programmierung
2. Quarz, damit die serielle Schnittstelle läuft.
3. Baustein mit echter serieller Schnittstelle
4. ein selbstgeschriebenes Programm

Was soll das Ding letztendlich können?
....wieder mal Änderungen im Konzept....

1.Ich will ein LCD-Display für diverse Anzeigen
2.Am Display soll es mehrere Tasten geben
3.Die Funktionen sind auf mehrere ATinys verteilt
4.Die ATtinys kommunizieren seriell (vorerst(?),weil einfach!)

Was müssen die Programme können?
1. Das Display muss seriell empfangene Daten darstellen
2.Der Rechner im Display soll Befehle schicken können
3.Die Messeinheiten sollen einzelne Befehle erkennen

Was soll ablaufen?
in der "Grundstellung" werden Gesamtspannung und
"Bordnetzspannung" gemessen und angezeigt.
Ganz nebenbei werden die einzelnen Zellen der
Reihe nach abgefragt und bei Fehlern soll Alarm
ausgelöst werden.
Als Bemessungsgrundlage soll die durchschnittliche
Zellenspannung dienen! Ein Alarm bei einer bestimmten
Spannungsuntergrenze ist natürlich ebenso vorgesehen.
Ein gezieltes Abfragen einer Zelle ist auch vorgesehen.

....ganz so weit bin ich aber noch nicht......
Die Messfunktionen und Umrechnungen in "Klartext"
habe ich schon mit dem ATtiny13 getestet, das sollte
nicht mehr allzu problematisch sein, und die Funktionen
sind auf andere ATtinys bzw. Atmegas übertragbar.

Deshalb habe ich mich jetzt erst mal den Steuerfunktionen
gewidmet.
Dafür habe ich ein Testprogramm geschrieben,
das möglichst viele Steuerfunktionen abarbeitet.
Im Display / Bedieneinheit will ich einen ATtiny2313
einsetzen. (Anm. es wird wohl eher ein Atmega48,
aber für andere Zwecke würde der 2313 durchaus reichen)
Dem habe ich jetzt folgendes beigebracht:
Reaktion auf ganz bestimmte (Hex) Befehle/Bytes
1 (49h), 2 (50h), 3 (51h) und r (114h) werden erkannt
und als Reaktion darauf wird sowohl im Display
angezeigt als auch seriell als Text gesendet,dass diese
Befehle erkannt wurden (und auch welcher es war)
Undefinierte Befehle werden ebenso gemeldet und
weitergeleitet.(Hex-Wert wird angezeigt
Hex-Wert und Buchstabe im Klartextwerden sowie
eine Textmeldung werden ans Terminalprogramm
geschickt)
Die Ausgabe der Hex-Zahl als Buchstabe in der
LCD-Anzeige klappt momentan noch nicht,
aber das ist auch gar nicht nötig
und das wäre sicher noch lösbar.
Als "Klartext" geschickte Meldungen werden
derzeit einfach ignoriert, das ist gut so.
Da muss ich noch ein bisschen grübeln,
wo ich überhaupt die Meldungen generiere.
(Werte nur als Zahl (Byte, ev.Integer)übertragen und
in der Anzeige umrechnen, oder schon in den Messtellen
als Klartext generieren und im Display nur
noch anzeigen (String,16Zeichen)...mal sehen...
das wird noch interessant........)

Am ATtiny2313 sind noch vier Portpins frei,
da kommen Taster dran.Damit die Ausgabe je eines
Befehls auszulösen ist kein Problem.
Die Auswertung der Befehle funktioniert jetzt,
und wie die Messung geht ,das hat schon der ATiny13
eindrucksvoll gezeigt.Da erwarte ich keine großen
Probleme mehr, aber da brauche ich andere Bausteine.
(ATtiny24 bzw. ATtiny26 scheinen geeignet,
Leider haben die keinen UART...... der 2313 hat
UART aber keine AD-Wandler.... warum gibts keinen
ATtiny mit UART und ca. 4 AD-Wandlern?????????).
All die Funktionen, die mir Kopfzerbrechen
bereiteten laufen jetzt im Testprogramm
gleichzeitig in einem ATtiny2313 der zur Zeit
ca 55% an möglichem Code drauf hat.
Da geht noch einiges................
z.B. eine kleine Menueführung für die
Funktionen













Nachtrag 12.März 2010:


Ein Menue für die Bedienung läuft

mittlerweile auch schon mal in den
Grundzügen.


Ich kann zwischen mehreren Ebenen

(in denen dann völlig unterschiedliche
Programme ablaufen können)
hin und herspringen.


1.Ebene, gleich nach dem Einschalten.

Systemtests etc. ev. anschliessend
umschalten in die zweite Ebene
2.Ebene für ??????????
Ich denke an Überwachen von
durchschnittlicher, höchster und
niedrigster Spannung aller Zellen
sowie Anzeige der Bordbatterie (12V)
und überwachung fester Grenzen.
3.Ebene, Automatisches Messen
aller Zellen der Reihe nach
mit Einzelspannungsanzeige.
4.Ebene, manuelle Anwahl der Zellen


Das alles ist noch nicht endgültig, die
Programme sollen auch als Basis für
vollkommen andere Anwendungen
brauchbar sein.

(wer weiß, was noch kommt).

Recht unerwartete Probleme gibts beim
Einlesen von Text (ASCII)
und größerer Zahlen (mehrere Byte)
über die serielle Schnittstelle, aber das
ist ganz sicher zu schaffen. Im Prizip
geht das schon, aber da ich empfangenen
Text nicht so ohne Weiteres im Display
darstellen kann und auch der Empfang
nicht ganz einfach ist, insbesondere,
wenn mal irgend welche Fehler
auftreten sollten und deshalb die
Übertragung irgendwo stockt.
Das wird noch interessant!!!


Eigentlich wollte ich die"Rechenaufgaben"
in die Messstellen
auslagern, und das Display nur als
Anzeige, Bedieneinheit

und Zellennummerngenerator
nutzen (derzeit 65% Speicher voll)
Prinzip: Zellennummer gesendet,
die entsprechende Messstelle antwortet
in "Klartext" (Zelle 23: 3,27V)
Wenn ich jetzt die Umsetzung in
"Klartext" auch noch da reinpacken
soll, wirds hier wieder mal eng.....
..und die Messstellen langweilen sich!
Da das aber ohnehin Voraussetzung ist,
um alle Spannungen zentral zu
"bewerten" und nach Pegel und der
zugehörigen Zellennummer zu
sortieren ist das wohl nicht allzu
Problematisch.

Übrigens: 1 Byte entspricht bei
5V Messbereich ca 0,02V Auflösung.
(5V / 256 = 0,01953125)

Eine Genauigkeit von ca +- 0,1V sollte
demnach zu schaffen sein.Das müsste
eigentlich locker reichen.

Nachtrag 16.03.2010:

Das Display macht jetzt schon ganz tolle
Sachen:





















Die aktuell gemessene Zelle wird angezeigt.
(z.B.: Z060)
(Die " Messwerte", je ein Byte kommen bereits über
die serielle Schnittstelle an, aber noch aus einem
Simulierten Messumformer, einem ATtiny2313,
der auf Anfrage vorgegebene Werte von 0-255 sendet)
die "mV" sind nur "Text für die Optik")
Das Anfragen der Messwerte und die Sendung
der passenden Antwort funktioniert problemlos
und absolut zuverlässig.
Die Auswertung und Anzeige der Zellen mit
der höchsten und niedrigsten Spannung
funktioniert auch schon.

Allerdings zeichnet sich schon jetzt ab,
dass der ATtiny 2313 doch überfordert ist.
(eigentlich wollte ich die Messstellen rechnen
lassen und das Display sollte nur den Text darstellen)
Die 2k Speicher sind fast voll,weil die
Formatierung der Zahlen z.B. führende
Nullen bei Bascom den Speicher geradezu "frisst"
(Das Problem hatte ich schon beim 13er)
Daran solls aber gewiss nicht scheitern!
Die 4k der Freien Bascom-Version reichen
allemal, ich muss nur noch die Messwerte
in Klartext umrechnen etc. das ist nicht
allzu tragisch.
Einen passenden Prozessor finde ich sicher!
(Atmega 48 à 1,30 € )

Das Programm gefällt mir schon ganz gut.
Ich führe die Berechnungen nun doch
im Steuerrechner des Displays durch,
weil ich so viel problemloser die
Min- und Max-Werte
ausrechnen und anzeigen kann.
Das wurde doch wieder mal ganz anders
als ursprünglich geplant!
So macht das einfach mehr Sinn!

Prinzip der Maximalwertanzeige:
Kommt ein höherer oder niedrigerer Wert
als die angezeigten Grenzwerte, werden die Werte
(Zellennummer und Spannug) ins Display
geschrieben, und auch als Referenz abgelegt.
Kommt die entsprechende Zelle erneut an die
Reihe, so wird der neue Messwert übernommen.
So bleibt die Anzeige immer aktuell und eventuelle
Fehlmessungen werden wieder entfernt.
Das lief auf Anhieb perfekt.



Nachtrag 17.03.2010:

Ich habs nun doch noch geschafft, alle
wichtigen Teilfunktionen in den 2313
rein zu programmieren!!!!
Vor Allem die Formatierung der Zahlen.

Anzeige von Zellennummer Spannung;
Anzeige von MAX. und MIN.

sowie eine Störmeldung bei Unterspannung
einer einzelnen Zelle. (fester Wert)

Die Meldung bei Unterschreitung des
Durchschnittswertes aller Zellen ist
kein Problem mehr, aber das macht
erst Sinn, wenn ich entsprechende
Messwerte aufnehmen kann.

Ich habe den "Dummy-Geber", der einfach
fest vorgegebene Werte lieferte
(je nach Anfrage, zum Test der Decodierung)
durch einen ATtiny 13 ersetzt,
der auf jede Anfrage reagiert, aber dafür
tatsächlich misst.
Das Ergebnis ist beeindruckend!

Da die Berechnungen im Display-Rechner
stattfinden, werden sich die Messstellen
eher langweilen.........

Was hab ich da vor?

Ich will je fünf (4 ????) Zellen zugleich
messen. das geht mit einem Baustein
über die Zwischenwerte der Reihenschaltung
von 4 x 5V ; 0-5V-10V-15V-20V.
Die Auflösung beträgt da immer noch
ca. 0,025V bei fünf Zellen bzw.
0,02V bei vier Zellen.
Die AD-Wandler arbeiten mit 10Bit (1024)
Der Wert müsste also ohnehin durch 4 geteilt
werden damit es ein Byte pro Wert wird.
Das ist nicht die Messgenauigkeit!
aber die sollte dann immer noch bei ca +- 0,1V
oder besser liegen

Es drängt sich geradezu auf, die Balancer-
Funktion auch in die Messstellen zu packen!

.....mal durchkalkulieren, obs Sinn macht.

Ich spare ATtinys à 1€ je Zelle ein, brauche dafür
aber je einen Optokoppler .....und der Abgleich
wird schwieriger....und der Balancer bräuchte
eine eigene Spannungsversorgung...............

Hmmmmmmmm...............

Nachtrag 06.April 2010

.......und wieder einen Riesenschritt weiter!!!!!

Das Display läuft schon mal gut genug für erste Tests.
Da ist noch einiges zu tun, aber das eilt jetzt nicht.
Die Befehle gehen richtig raus und die Rückmeldungen
werden korrekt angezeigt. Das reicht vorerst.
Der Prozessor wird sicher noch ein anderer.
Vermutlich ein Atmega 48!
Der hat als einzigen "echten" Nachteil sehr viele Pins (28).
Mit 1,30€ eine Super-Sache.
Wenn der nur nicht so riesig wäre.........
Beim Display ist das kein Problem, aber bei den
Mess-Modulen muss ich Platz sparen.Da sind die
14Pins des ATtiny24 schon angenehmer.

Ich habe in der Zwischenzeit ein wenig an den
Messstellen weitergearbeitet.

Mittlerweile messen vier ATtiny24 jeweils vier
Spannungen.Leider haben die 24er wie auch die
26er keine wirklich echte serielle Schnittstelle.
Deshalb laufen die mit "Software-UART"
Zumindest aber mit Quarz und so funktioniert
das schon ganz zufriedenstellend.
Womöglich werde ich hier auch auf den
Atmega 48 umstellen - mal sehen.......
Der wäre völlig "unterfordert", aber die
Datenübertragung wäre dank UART besser.

Die Kommunikation läuft noch nicht galvanisch
getrennt, aber immerhin klappt die Kopplung.
Alle Messstellen kriegen das selbe serielle Signal.
(bei wesentlich mehr Messstellen ist hier natürlich
noch eine Treiberstufe für viele Optokoppler nötig)


Die Rückmeldung wird per Dioden und Pull-Up auf
eine Leitung zusammengeführt.
Da alles nach dem Master-Slave-Prinzip arbeitet
gibt es hierbei bisher keine Probleme.
(jede Messstelle sendet nur, wenn sie vorher
aufgefordert wurde, so gibt es kein Durcheinander)

Wie gehts weiter?
Nächstes "Etappenziel" ist die galvanische Trennung
der seriellen Kommunikation.Insbesondere die
Treiberstufe für bis zu 50 Optokoppler.Ich will
Versuche mit Treiberbausteinen für Mosfet machen.
Die Dinger setzen die 5V-Signale auf 12V oder 24V
um und sind sehr schnell und preiswert.Bei 12V
könnten schon mal je vier Optokoppler in Reihe
betrieben werden.Wieviele dieser Gruppen an einem
Ausgang betrieben werden können muss noch
getestet werden.Schon der kleine TC4431/32
kann 1,5A Peak und mindestens 100mA
Dauerstrom bei 24V schalten, was an 12V
für mindestens 24 Optokoppler reichen sollte.

2 * 24 * 4 = 192 Da sollten mit zwei TC4432
192 Spannungen keine Utopie sein!
(Das gilt es aber noch zu bestätigen)
Ansonsten gibt es ja auch richtige Treiber-ICs.
Um einen Frequenzumrichter für
380V-Motoren an Gleichspannung zu betreiben
sind ca 160-170 Zellen nötig.

Da ich ohne großes Protokoll nur ein Byte sende
und pro Meßstelle vier Zellen messe möchte ich die
Werte 201 - 250 für Statusabfragen freihalten.

mit 251 (?) bis 254 könnten dann z.B.die
Bordbatterie und die Gesamtspannung erfasst
werden.

Bei den Rückmeldungen mache ich mir weniger
Sorgen.Ein ATtiny oder Atmega kann locker
einen Optokoppler ansteuern.
Dass ich wohl nicht die Ausgänge von fast 50
Optokopplern einfach parallelschalten sollte
ist auch klar, aber das muss ich ja ohnehin
grüppchenweise machen. Die Anlage soll ja
aus Standardbaugruppen bestehen,
Display = Master und Slaves je nach
Anzahl der überwachten Zellen
Eventuell wird die Kommunikation auch
mit etwas mehr als 5V erfolgen.
Da fällt mir schon noch was ein!

I²C oder ein ähnliches Bussystem stünde auch noch
im Raum, aber das ist auch nicht so viel besser,
vor Allem wenns galvanisch getrennt sein soll
wird der Aufwand schnell größer.
Ich werde deshalb wohl bei meiner primitiven
seriellen Kommunikation bleiben, wenngleich
da wohl an mancher Stelle mit 12V gearbeitet
werden wird.
Mir reichen übrigens sogar 300Baud wenns denn
sein müsste, derzeit läufts mit 1200Bd.
(9600Bd machten aber auch keine Probleme)

Noch ein ganz wichtiger Punkt auf der
"To Do -Liste": die Variablen wie
Zellenanzahl, oberer und unterer Grenzwert
etc....... sollen unbedingt im Menue einstellbar
werden; momentan sind sie noch fest
im Programm abgelegt; aber wozu haben
die ATtinys und Atmegas schliesslich
ihr EEprom........ Die paar Variablen
lassen sich sicher noch wo unterbringen!
Im 2313 fehlt allerdings der nötige Platz.



Update 9.April 2010:

noch ein paar Verbesserungen:




grundsätzlich ist das System schon fast verwendbar!

es fehlen noch folgende Funktionen:
Galvanische Trennung der Meßstellen
Messen mehrerer Zellen in Reihe
Einstellen der Parameter im Menue

ferner:
gezieltes Anzeigen bestimmter Zellen
(aus Platzgründen derzeit entfernt)

Steuerung eines Ladegerätes bzw.
Integration eines Ladegerätes ins System.
(Das wird wohl etwas schwieriger!)
Voraussetzung hierfür ist eine Rückmeldung der
Balancer-Funktion bzw eine Steuerung der Balancer
vom Display aus.Sobald eine Zelle mehr als
z.B. 50% der Balancerleistung braucht,
muss die Ladestromstärke reduziert werden.

Ob jetzt "oben" oder "unten" balanziert wird
(Jack Rickard...) ist doch letztendlich egal!
Die schwächste Zelle macht immer den vollen
Spannungshub. "Oben" balanzieren ist
wesentlich einfacher, da für jede Zelle die selben
Werte gelten.
Dafür ist eine Spannungsüberwachung
jeder einzelnen Zelle Voraussetzung.
Wird "unten" balanziert, dann sieht man an
der Gesamtspannung wann Schluss ist.
Ein Balanziervorgang kann aber nur bei
fast völlig leeren Akkus stattfinden.
Aufgrund ihrer flachen Kennlinie sagt die
Spannung bei LIPOs fast nichts über den
Ladezustand aus.
Ich wills mal so sagen:
Werden LIPOs ohne Batteriemanagement
betrieben, dann ist "unten" die bessere
Lösung bzw sogar die einzige Möglichkeit.
Hat man aber ein Monitoring oder
Management, so sollte eher "oben" balanziert
werden.Die Steuerung des Ladevorganges ist so viel
einfacher zu beherrschen.
Man sollte sich aber im Klaren sein, dass die
praktikabelste Lösung wohl eine Art
Mittelweg sein wird. Es ist nicht nötig alle
Zellen randvoll zu laden und eine Menge
Energie in den Balancern zu verheizen.
Sobald die schwächste Zelle zuerst voll ist
und auch zuerst leer wird ist die Balanzierung
in Ordnung, ganz egal, auf welche Spannung sich die
Zellen letztendlich einpegeln.
Die Shunt -Widerstände brauchen daher gar nicht so
stark ausgelegt sein wie üblich.
Es reicht also, wenn sie nur korrigiernd eingreifen.
(Das setzt aber eine Rückmeldung voraus)
Eigentlich kann mit dem Laden aufgehört werden
sobald die erste Zelle ihre volle
Spannung erreicht hat.
genauso muss aber erkannt werden wann die erste
Zelle leer ist. (es sollte dann aber die selbe sein,
die als Erste voll war!!!!)
Ein "fertigbalanzieren bis 4,2V" bringt jedenfalls
überhaupt nichts.

mfG
Franz