Emus Datenstrom auswerten Versuch 3 bis 27......

Puuuuuuhhhhhhhhh!!!!!!!!!!!!
Das war eine schwere Geburt...................
Aber jetzt scheint es zu laufen!!!!!!!!!!!

Ich hätte eigentlich die Steuerung des Chargers fertig machen sollen,
aber wenn einen so was wie diese Auswertung derart nervt, und man den Fehler
einfach nicht findet, dann hat man den Kopf auch nicht für andere Dinge frei.
Das musste jetzt einfach sein..........

Was und warum das nicht klappte erzähle ich hier demnächst im Detail,
aber jetzt will ich erst mal nach Hause...........

ganz kurz:
Ich habs jetzt mit gepufferten Eingang und dem
" If Ischarwaiting() = 1 Then
Goto Onrxd "-Verfahren geschafft,

alles was so richtig per Interrupt eingelesen hat führte zu Abstürzen
denen ich noch nicht völlig auf den Grund gehen konnte.

Ich habe die Auswertung auf das allernötigste reduziert, und
die eingelesenen Strings bzw nur deren Anfang ;-) in eigenständige
Strings gespeichert und bin dann sofort in die Leseroutine zurückgekehrt

alle Berechnungen sind jetzt im Hauptprogramm, und erst wenn einige
tausend Leerdurchläufe stattfanden (geht sehr schnell) wird häppchenweise ausgewertet
und zu guter Letzt  jede Zeile einzeln ins Display geschrieben.
immer wieder mit Pausen dazwischen, diese Pausen muss ich jetzt noch reduzieren,
aber wenn in der Hauptschleifen nur ein paar If-Then stehen wo eben nichts passiert
und gerade mal ein Zählwert erhöht wird, dann geht das sehr flott mit den 16 MHz.
wieder mal nicht ganz die "feine Art" , aber der Zweck heiligt hier die Mittel

das funkioniert jetzt bis zu einer lückenlosen Übertragung des gesamten Pakets
im Abstand von 150ms (im Emus ist meines Wissens 0,5s Standard)
Da ist ja noch Luft für viel mehr anzuzeigende Dinge!!!!!!!!!

Nachtrag 3.April: Ich denke da ganz besonders an die Anzeige des Seriell
aus Curtis-Controllern gesendeten Textes der normalerweise im Curtis840
angezeigt wird. Grundsätzlich ist das machbar mit einer zusätzlichen
seriellen "Software-Schnittstelle" Dass es klappt habe ich bereits erfolgreich
getestet, aber die beiden Programme zu einem zu verwurschteln ist nicht ganz so
einfach, das hebe ich mir einfach mal auf für später!Ende des Nachtrags

Ich habe auch gleich ein Wattuino Pro mini auf das EA DIP204
draufgesetzt und als Inverter einfach einen 6N137 Optokoppler genommen,
Der passt recht gut an die Programmieranschlüsse und galv. Trennung habe ich so
auch noch nebenbei.......(OK, ist nicht ganz korrekt,so zu invertieren, aber
wenns keine Allzuwichtigen Daten sind und ein Aussetzer nicht der
Weltuntergang ist, dann kann man es so machen)

Ich habe ja kein Emus BMS hier zur Verfügung, sondern muss alles simulieren
Um so richtig schnelle Daten zu bekommen habe ich den
Freeduino serial v2.0 zum Emus-Simulator umprogrammiert.
Der sendet mir jetzt ein komplettes Datenpaket so schnell er kann
und ändert dabei die Werte von Stron und SOC damit man da auch was sieht.
........Integer-Werte als HEX-Codierte Buchstaben zu schicken.......gibts eigentlich
noch was gemeineres? das war auch mit mehreren Anläufen verbunden!

von vorn

und von hinten

 Mehr dazu demnächst!  

Auswerten des EMUS Datenstroms

Das musste ich jetzt einfach mal hier posten.........
Erste Gehversuche beim Auswerten des EMUS Datenstroms!

Das Emus BMS sendet ständig alle relevanten Werte über die serielle Schnittstelle

Ich wollte da jetzt einfach mal die Spannungen rausfiltern,
und die verstecken sich in der Zeile, die mit BV1 beginnt: (Battery Voltage Sentence)

BV1,2D,94,A0,9D,3EDA,9F9C9F9F9EA09E9E9F9D9FA0A09F9E9E9E9F9E9E9FA09FA09F9E9E9F9E9E9F9D9E9F9D9F9E9E9E9F9697979496,D2

BV1 die Kennung   (Zum Sortieren der Daten)
2D Anzahl der Zellen   (2D Hex   =    45 )
94 min     ( 94 Hex   =   148 Dez   ;  +Offset 200 ergibt 3,48V )
A0 max   ( A0 Hex  =  160 Dez    ;  +Offset 200 ergibt 3,60V )
9D Durchschnitt (9D Hex  = 157,  gibt 3,57V
3EDA Gesamtspannung   (3EDA  Hex = 16090 Dez = 160,90V)




















....und dann die 45 Einzelspannungen und zuletzt die Checksumme.
Das BV5 in der ersten Zeile ist einfach eine "andere" Meldung um zu schauen,
ob die verworfen wird.

Ich will nur ganz kurz die Vorgehensweise erklären
Das Programm ist in Bascom entstanden und noch weit davon entfernt,
fertig zu sein, ich zeige hier nur die entscheidenden Befehle.

Ich lese immer alles in einen String ein, bis ein LF oder CR kommt (1.Zeile)
Vorerst mal per:

If Ischarwaiting() = 1 Then
S0 = Inkey()
Gosub Onrxd
End If

...........das geht natürlich normalerweise auch noch wesentlich eleganter per
Interrupt-gesteuertem Empfang, aber irgendwas lief da nicht ganz so wie erwartet......
Ich hatte aber keine Lust, den Fehler zu suchen.
Die erste Zeile klappte,  aber wenn zu viel zu schnell  kam gabs Abstürze
und das Display zeigte wirres Zeug.
Ich vermute, dass ich irgendwo auf Daten zugegriffen habe als ich das nicht durfte,
oder das vom Interrupt gestartete Unterprogramm brauchte einfach zu lange,
oder womöglich wurde zuviel in einen zu kurzen String geschrieben???
ich werds schon noch rausfinden.........
momentan muss ich die aufgezeichneten Daten per Terminal an den
Freeduino senden, und da ist wohl so manches anders als das EMUS die
Daten normalerweise sendet. Also erstmal kein Grund zur Panik
Dieses "Polling"-Empfangsverfahren habe ich einfach mal aus einem anderen lange
erprobten Programm so übernommen weils fürs Erste schon mal den Zweck erfüllt.
Mit "Ischarwaiting" kann man hier arbeiten, weil das
hier lauter lesbare Zeichen sind, ausser CR und LF.

für binäre Daten wo auch mal ein "Nullbyte" vorkommen könnte
ist das aber unbrauchbar.

Onrxd:
If S0 = 13 Then '13=CR 10=LF
Z = Left(strx , 3)
If Z = "BV1" Then Bv1 = Strx
Cls
Locate 2 , 1
Lcd "Z=" ; Z
Locate 1 , 1
Lcd Strx
Locate 2 , 1
Lcd Bv1
Locate 3 , 1
Lcd Cells ; " " ; Cmin ; " " ; Cmax ; " " ; Cav ; " " ; Ctot
Locate 4 , 1
Lcd Valcells ; " " ; Valcmin ; " " ; Valcmax ; " " ; Valcav ; " " ; Valctot
Led = 0
Strx = ""
Return
End If

Str00 = Chr(s0)
Strx = Strx + Str00

......wieder mal gäbe es hier viele Möglichkeiten, und ein Array wäre sicher
vom Programm her die efektivere Lösung, aber ich arbeite einfach lieber mit einem
String, weil es so viel übersichtlicher ist, und auch die verschieden langen Zeichenkolonnen
besser verarbeitet werden können. Falls es zu "Performance-Problemen" kommt
kann ich immer noch nachbessern......

Nachtrag:
Natürlich kam es zu "Performance Problemen"..........
Allerdings hatte ich zwischendurch auch noch was ins Display geschrieben,
und das geht hier überhaupt nicht! Mehr ganz am Ende dieses Posts
Lesenswert:
http://www.rn-wissen.de/index.php/Bascom_UART_Input

Dann wird nachgeschaut, wie der String beginnt, und wenn da BV1 steht,
wird der String gespeichert.(2.Zeile)

Z = Left(strx , 3)
If Z = "BV1" Then Bv1 = Strx

Dann hole ich von da die wichtigsten Werte raus, auch als String (3.Zeile)


Cells = Mid(bv1 , 5 , 2)
Cmin = Mid(bv1 , 8 , 2)
Cmax = Mid(bv1 , 11 , 2)
Cav = Mid(bv1 , 14 , 2)
Ctot = Mid(bv1 , 17 , 4)


und zuletzt werden die Strings in Zahlen gewandelt.

Valcells = Hexval(cells)
Valcmin = Hexval(cmin)
Valcmax = Hexval(cmax)
Valcav = Hexval(cav)
Valctot = Hexval(ctot)

In diesem Fall: 45Zellen, min 3,48V (offset 200) max 3,60V,
Durchschnitt 3,57V und Gesamtspannung 160,9V

Die Offsets etc sind hier noch nich umgerechnet,
das war einfach mal ein erster Versuch, aber es klappt ganz gut!

Vielleicht kann ich das ja noch in die Franzbox reinpacken,
Die Anzeige dieser Werte ist ja schon drin, aber nicht aus dem EMUS
ausgelesen sondern aus meinem Versuchs-BMS.
aber andererseits ist das ja ein Widerspruch in sich......
Wer ein EMUS hat braucht ja keine Franzbox mehr, sondern nur
ein Display für die wichtigsten Werte! Die Franzbox
könnte dann nur noch die Stromstärke auf den Drehzahlmesser übertragen,
 aber alles Andere ist im EMUS bereits "drin"

Ich brauche für meine gang spezielle Anwendung nur ein paar Daten aus dem
gesamten Datenstrom, aber so als eine Art "Nebenprodukt"
fällt hier auch noch ein kleines Display für die EMUS-Daten ab,
das dann ganz dezent die wichtigsten Infos anzeigt.
Das fehlt dem EMUS noch, wunderbar grafisch per Bluetooth
auf ein Tablet gibt es schon, sogar sehr preiswert, aber das ist dann halt ein Problem,
wo baut man das hin, und will man das wirklich immer alles wissen?

Ich meine, wichtig ist vor allem, dass man bei Fehlern benachrichtigt wird,
und dann auch finden kann wo es hapert, aber wenns nicht nötig ist, dann
braucht man nicht mit Infos überschwemmt werden.
Was nutzt der schönste Zeiger, wenn man nicht hinschaut wenn er langsam auf 0 geht.
Ich ziehe eine Warnleuchte jedem Zeiger vor, aber wenn die Leuchte mich warnt,
oder bei Bedarf auch jederzeit zwischendurch will ich natürlich alle Daten abfragen können.
Aber ich will nicht ständig irgendwelche Werte beobachten müssen
um dann darauf zu reagieren. Zu überwachen und aufzupassen ist
Aufgabe des BMS und nicht des Fahrers.

Ein bisschen umformatiert schaut das gleich viel besser aus
Die oberen beiden Zeilen sind Infos für mich,
einmal der zuletzt empfangene String
und der zuletzt gespeicherte String (Datenmüll wird aussortiert ;-) )
Und dann halt die Inhalte der Daten
Zellenzahl, Gesamtspannung
Minimum, Durchschnitt, Maximum

Für andere Werte muss ich andere Datenstrings auswerten
Ich überlege noch, was alles wichtig ist,
Wegabschätzung und SOC vor allem,
das ist aber dann eher eine
Art Fleißaufgabe und viel Schreiberei......
aber für die Chargersteuerung
brauche ich ohnehin völlig andere Werte........

.........ein bisschen habe ich noch rumgespielt, es wird allmählich......
So ginge es notfalls auch auf 2 x 16 Zeichen darzustellen wenn man
auf die Klamern und "SOC" verzichtet. Der Strom ist hier nicht so sehr
wichtig,weil der Wert nur etwa einmal pro Sekunde aktualisiert wird.

Ist das so verständlich? 56.8Vgesamt, 14Zellen Durchschnittlich 4,05V
niedrigste 4,04V höchste 4,07V SOC100%
Die Temperaturen abzufragen macht beim EMUS wenig Sinn,
da sieht man nur die Temperaturen der Balancer-Platinchen.

Die Evolution schreitet voran.......
mittlerweile sieht man auch den Strom, und ich hab auch noch einen Timeout
drin, wenn die Daten ganz ausbleiben sollten,
und auch eine fehlende Kommunikation oder
Fehler der Zellenkommunikation werden erkannt und gemeldet
Entweder sendet das EMUS dann BV1,,,,,,,,, das kann man abfragen, oder
der Offset von 2V würde gleich nach dem Einschalten angezeigt
wenn noch keine Daten angekommen sind. Das habe ich auch unterbunden.

Momentan ist noch eine Menuestruktur vorgesehen, aber ob die drinbleibt
ist fraglich.Aber für die Chargersteuerung brauche ich das noch.
Das Ding soll ja in etwa so primitiv werden wie das Curtis 840
Anklemmen, einschalten, Werte ablesen, sonst nichts, keine Bedienung.

..........Der soll das alles mal steuern!
Geniales Teil! Ich hab den zwar noch nicht getestet, aber das geht gewiss!

Ich lese zwar immer noch die Daten per "Polling" und großem
Eingangspuffer ein, aber da der Prozessor ansonsten sowieso
kaum was zu tun hat geht das in diesem Fall recht gut.Immerhin 16MHz!
Bevor ich hier allzuviel Zeit verschwende will ich es erst mal in der
Praxis testen. Die paar Zeichen sollten kein ernsthaftes Problem sein.
Morgen Abend bin ich dann schlauer!

Nachtrag 24.März 2013:
Tja........ganz so wie erhofft lief es dann doch nicht.........Da kommen sehr viele Zeichen,
und die kommen auch noch sehr schnell, und offenbar auch ohne Pausen zwischen den Zeilen!
Man kann zwar die Pause zwischen den Datenblöcken einstellen, aber das Datenpaket kommt
immer als Gesamtpaket. Jetzt wirds interessant, wie ich das im Programm gelöst bekomme.
Die Anzeige der Spannungen hat geklappt, aber Ampere und SOC kamen nicht
zuverlässig an, weil das Programm noch mit anderen Dingen beschäftigt war.
Zum Beispiel habe ich die empfangenen Zeichen im Display angezeigt, das dauert viel zu lang
Ich habe schon mal die ganzen Anzeigen aus dem Display entfernt, die ich für
Kontrollzwecke in den ersten Zeilen drin hatte, und damit läuft es schon um ein vielfaches
schneller, aber das konnte ich halt jetzt nicht mehr testen.
Aber ich habe eine Möglichkeit gefunden, ein weitgehend komplettes Datenpaket
zu simulieren. (ich habe kein EMUS in greifbarer Nähe, aber mit dem "COM-Terminal"
kann ich einige Zeilen "am Stück" senden) Mal schauen, eine Möglichkeit wäre,
bei jeden Durchlauf auf eine andere Zeile zu warten, aber das gefällt mir jetzt gar nicht!
Ich muss halt möglichst viel zwischenspeichern und dann in der Pause auswerten,
falls ich es nicht in "Echtzeit" schaffe, und da ist die "Polling-Methode" gar nicht sooo
schlecht. mir hat gestern leider die Zeit gefehlt, das Programm vor Ort zu ändern
und zu testen. Die andere, viel effektivere Möglichkeit ist natürlich,
die Daten ohne Umweg über einen String in ein Array zu legen und dann
in der Pause auszuwerten. Ich muss mal allles nochmal genau durchdenken........
Die ganzen Versuche, das Einlesen per Interrupt-gesteuert ablaufen zu lassen haben bis jetzt noch
in sehr seltsamen Abstürzen des Displays geendet, die ich mir noch immer nicht wirklich
erklären kann. Da kommen plötzlich Zeichen an Stellen die überhaupt nicht angesteuert wurden.
Ich habe nicht übers Ende der Strings hinausgeschrieben, und die einzelnen
Programmsegmente einzeln funktionieren, aber sobald der Empfang neuer Daten das
Schreiben ins Display unterbricht gibts Probleme, die ich bei der "Polling-Methode" nicht habe.
Ich werde also für jeden Datensatz ein Array anlegen müssen und einfach mit Berechnungen und
Anzeigen warten müssen, bis zwischen den Datenpaketen eine Pause ist.
Ins Display zu schreiben, während eingelesen wird muss unbedingt vermieden werden.
Und das Zwischenspeichern ist gar nicht so unkompliziert, wenn man bedenkt dass
ein Maximalausbau von 255 Zellen allein für die Zellenspannungen einen Satz aus etwa
550 Zeichen am Stück liefern würde...... das sprengt jeden normalen Puffer!
Da ich die Einzelspannungen aber gar nicht auswerten will, Min, Max, Durchschnitt und Gesamt
sollten reichen für unterwegs reicht mir aber der Anfang des Spannungspakets


Meine Pläne gehen hier in zwei Richtungen. Zum Einen brauche ich ein Steuergerät,
für eine Chargersteuerung. Dafür muss aber auch die Auswertung funktionieren.
und das sehe ich am schönsten durch Darstellen der Werte auf einem Display.
Zum anderen will ich eine möglichst simple, kleine und billige Anzeige
für die wichtigsten Daten schaffen. Das wird ein EA DIP204 Display sein, auf das
direkt ein Wattuino pro mini draufkommt. Das ist dann 68 x 27mm x 15mm groß
und kostet ca 30 Euro.........
Da braucht man dann nur noch einen Inverter für den seriellen Eingang.
und ein kleines Poti für den Kontrast
Aber weil ja hier nur gelesen wird, ist das Invertieren kein allzugroßes Problem,
zur Not geht da sogar ein simpler Transistor,
oder ich bin ein "wilder Hund" und nutze einen Interrupt-Eingang des Atmega
zum Invertieren des Signals (nur mal eine Idee, keine Ahnung obs klappt)
die +-12V werden ggfs. durch einen Vorwiderstand(10k) und die Dioden im Atmega auf
0-5V begrenzt. Das ist auch ein bisschen "grob", aber erfolgreich erprobt

So was in der Art habe ich schon mal irgendwo gesehen, da wurde der Komparator
eines PIC genutzt. Ein Optokoppler 6N 137 wäre natürlich auch eine Möglichkeit.
(wohl die "edelste") ein MAX232 ist hier einfach zu aufwändig, weil ich ja nichts
auf RS232 senden muss.

Franzbox meets Arduino Teil 2

 Franzbox auf Arduino-Basis... ist das dann jetzt ein Pacco Francesco oder ein Franzuino?????

Ein kleiner Zwischenbericht:
Das Franzbox-Programm läuft ohne größere Probleme auch auf einem
Freeduino Serial v2.0- Board (......oder muss ich da jetzt Shield sagen......)
Natürlich ginge auch ein Arduino Uno, aber auf dem Freeduino ist der Chip gesteckt, beim Uno
SMD aber nicht, und weil ich den Bootloader eh nicht brauche und überschreiben würde, und weil
ich ausserdem demnächst mit dem Seriellen Port des Freeduino die Daten vom EMUS BMS
auswerten möchte, habe ich es gleich mal mit dem Freeduino getestet.
Lief auf Anhieb..... die ganzen Timer und Zeit-Geschichten mussten natürlich auf die vierfach
höhere Frequenz von 16MHz angepasst werden. (ich hätte auch den Quarz tauschen können ;-) )
Aber es soll ja mit jedem Arduino gehen, also doch 16MHz. Das geht schon!
Ich denke da ja ganz besonders an den Wattuino pro mini 5V 16MHz.....fertig aufgebaut 10Euro!
(da möchte ich aber den Quarz nicht tauschen müssen, ebenso beim UNO SMD )
Der Timer für die PWM der Tankazeige lief bisher mit Prescaler 1, das sind bei 4MHz 8kHz
der ist jetzt auf 8 eingestellt, das gibt jetzt eine PWM-Frequenz von 4kHz, das ist hier unkritisch,
da hier nur eine Spannung ausgegeben wird um die Tankuhr anzusteuern.
Der Timer für die Frequenzerzeugung für den Drehzahlmesser konnte von 64 auf 256
umgestellt werden, das sollte also unverändert laufen (habs noch nicht getestet)
und der Timer zum Erzeugen des Sekundentaktes war schon auf 1024, da war nichts
zu ändern, das musste in der Berechnung berücksichtigt werden. Aber da es sich
um den Faktor vier handelt war das nicht weiter tragisch.
Nur bei der Einstellung der Timeout-Zeit für Menue und Beleuchtung gab es ein Problem.
Das wird beim Timer-Interrupt eine Zahl heruntergezählt, und da reichten jetzt ein paar
Variablen nicht mehr aus und mussten von Byte auf Word geändert werden.
Das war einfacher als die ganzen Berechnungen anzupassen. Es scheint alles zu laufen.
Die Uhr braucht womöglich noch ein wenig Feinabstimmung. Da hier einiges im
Unterprogramm mit drin ist,  incl. AD-Wandlung und Berechnung der Stromwerte
sowie die Ansteuerung des Takt-Timers für den Drehzahlmesser passt die Umrechnung
in Sekunden nicht ganz perfekt zum berechneten Wert und muss leicht korrigiert werden.
Es war aber nicht möglich, hier mit einem Uhrenquarz zu arbeiten darum blieb nur dieser Weg.
Die Ungenauigkeit von ein paar Sekunden pro Tag ist aber hier völlig bedeutungslos.

Die Ausgänge für DZM und Tankuhr müssten sich auch mit einfachen Transistoren
(N-Mosfet nach GND) realisieren lassen. Da muss ich noch ein paar Versuche machen.
Hier sind ein paar Problemchen aufgetaucht, weil die Spannungen für einen älteren
VW Golf sowohl beim Drehzahlmesser als auch bei der Tankuhr nicht ganz reichen.
Das krieg ich aber auch noch hin. Hier gibt es einige Lösungsansätze,
auch ohne Redesign der Franzbox ist das zu machen, nur halt anders bestücken.
Die höhere Impulsspannung könnte durch Schalten einer Spule erzeugt werden,
und auf 12V Spannungshub statt 5V für die Tankuhr käme man, wenn die PWM
nicht vom Atmega direkt mit 5V käme, sondern aus dem im Layout schon vorgesehenen
TC4431, wenn an dieser Stelle nicht sogar schon ein einfacher Transistor reicht,
mit dem man das Gebersignal nach GND taktet. (das geht aber ganz sicher nicht
für "moderne" VW- Tankanzeigen ab dem Golf 4 etc.)
Mehr dazu aber ein andermal.





























Man sieht hier meinen 14poligen Stecker auf dem ich Display und Drehencoder
zusammengefasst habe und der bei mir zugleich als Programmierport dient.
Das ist entstanden, weil ich das Display beim STK500 direkt am 10-pol-Stecker
von PortB betreibe, (PortB.0 bis B.5 auf Pin 1-6 ;  Gnd und 5V auf Pin 9 und 10)
das habe ich hier einfach übernommen und an Pin 7 und 8 noch um je eine Leitung für
Reset und Beleuchtung ergänzt. Die vier Leitungen des Drehencoders kamen
später auch noch dazu auf Pin 11 bis 14. Diesen Stecker gibt es bei der "echten"
Franzbox zwei mal, einmal innen und einmal aussen, so dass man das Display + Encoder
auch mal wo anders hinbauen kann.....und weil da auch alle Pins des ICSP-Ports
drauf sind kann man hier auch die Box umprogrammieren.
Man braucht halt noch einen Adapter, aber das ist ja kein Problem.

Andererseits müsste es doch sogar möglich sein, Hex-Files mit dem Arduino-Bootloader
zu flashen. Ich habe da ein Programm gefunden das das angeblich kann:  Xloader
aber ich konnte es noch nicht testen, weil ich mal wieder an meinem alten WIN2000-PC
sitze und Xloader will Dotnet V4 installiert haben, und das geht hier nicht.....
Aber Arduino benutzt doch eigentlich auch das STK500-Protokoll, also muss doch Bascom
normalerweise ohne größere Probleme darauf zugreifen können ODER ETWA NICHT ?????
So was wäre aber eine feine Sache, wenn man damit BASCOM-Programme auf
einen Arduino laden könnte ohne einen ICSP-Programmer zu verwenden, der ja dann auch
den Bootloader des Arduino überschreibt. Der umgekehrte Weg, also Arduino-Hex
per ICSP ohne Bootloader auf Atmegas zu laden klappt ohne Probleme, also sollte
es so rum eigentlich auch funktionieren. Xloader nutzt auch nur die Funktionen von
AVRDUDE, aber mit dessen Kommandozeile kann ich mich nicht recht anfreunden.

Nachtrag 25.03.2013:
Es scheint so, dass es wirklich klappt, den Arduino-Bootloader zu nutzen.
Mehr dazu hier:
http://avrhelp.mcselec.com/arduino.htm
Ich habe es aber noch nicht selber versucht, es so zu machen wie es hier beschrieben ist.

Ich werde mir nicht die Mühe machen, das Programm vollständig auf Arduino zu übertragen.
Die Arduino-Umgebung ist gerade für PWM-Geschichten nicht ideal, weil man da ziemlich
tricksen muss um mit anderen Frequenzen und Prescalern zu arbeiten als vorgegeben.
Das ist schade, zumal das nicht an der Hardware liegt sondern am guten Willen der Entwickler
und an der Philosophie von Arduino überhaupt. Das Programmieren durch Weglassen
unnötiger Dinge zu vereinfachen ist ja lobenswert, aber wenn man dann für grundlegende Dinge
wie das Einstellen einer PWM-Frequenz oder die Verwendung eines anderen Quarzes
so richtig "von Hand" in irgendwelchen Registern herumschreiben muss um Sachen zu ändern
die in Bascom ganz nebenbei einzustellen sind, dann ist das doch ein wenig übers Ziel
hinausgeschossen! Aber egal, Arduino hat auch seine guten Seiten, vor allem da, wo man die
fertige Hardware nutzen kann, und bereits existierende Libs verwendet werden können.

Ich habe vor, demnächst diverse Files   HIER  zum Download anzubieten.
.......mal schaun ob das so klappt.....

Ich habe aber gerade so viel anderes am Hals, dass mir schlicht und einfach die Zeit und Lust
fehlt, jetzt auch noch ein paar Franzboxen zu bauen. Die Platinen als Prototypen fertigen zu
lassen ist ausserdem einfach zu teuer, (ca 30Euro pro Stück) wenns dafür auch schon fertige
Arduinos gibt, und deshalb werde ich das Programm soweit anpassen, dass es sich mit
handelsüblichen Arduinos und deren Clones verträgt, dann kann sie sich jeder bei
Bedarf selber basteln. Wie schon weiter oben erwähnt will ich als "Zentrale" am liebsten
den Wattuino pro mini verwenden, und da spricht bis jetzt noch nichts dagegen.
Als Display bleibt zunächst das EA DIP204 vorgesehen.
(das ist leider ein kleines bisschen anders als der Standard, da ist die Zeilenadresse anders,
deshalb klappt es nicht mit anderen Displays, aber die Anpassung im Programm ist
überhaupt kein Aufwand, wer also was anderes haben will mit 4 x 20 Zeichen aber HD44780
kompatiblem Controller, das ist machbar, und da denke ich gerade an die EA W204-XLG
Oled-Displays........und weil die Franzbox eigentlich auch mit 2x20 Zeichen auskommt,
die oberen Zeilen sind schon fürs BMS reserviert..... sollte einer zweizeiligen Version
auch nichts im Wege stehen. Aber ich muss das alles erst noch testen.

Wenn jemand noch einen Wunsch hat, bitte melden! vielleicht gehts ja noch einzubauen oder
anzupassen.Am BMS mache ich wohl so schnell nicht weiter, da versuche ich lieber, die Daten
aus dem EMUS BMS auszuwerten, das macht momentan aus meiner Sicht mehr Sinn.

Ein TFT-Monitor an einer DIALOG11bzw DIALOG12 Steuerung

Ich hatte schon fast aufgegeben bzw seit Monaten hier nichts mehr gemacht.......
Mein Bruder hat in seiner Firma mehrere Deckel CNC-Fräsmaschinen mit
der nicht mehr ganz neuen aber sehr bewährten DIALOG11 bzw. DIALOG12 Steuerung.
Bei diesen Steuerungen werden mittlerweile die CRT-Monitore immer schlechter,
und man wird auch von der neueren Technik verwöhnt und somit anspruchsvoller.
Aber nachdem neulich ein Monitor komplett ausfiel und zwei andere kaum noch
zu gebrauchen sind mangels Helligkeit und Kontrast musste eine Lösung gefunden werden.
Eine Reparatur  (so richtig mit Monteur, weiter Anfahrt und natürlich Übernachtung etc .......)
ist in diesem Fall viel zu teuer und liegt preislich irgendwo bei 5000 Euro pro Maschine
und passende TFT-Monitore zum Umrüsten werden auch mit ca 1500Euro veranschlagt.
Direkt aus China gäbs mittlerweile was Günstigeres, aber muss das überhaupt sein?
Nach genauerer Betrachtung der Anschlüsse kam ich zu dem Ergebnis, dass da gar kein
sooooo großes Geheimnis dahintersteckt als wir zunächst befürchteten.
Die originalen Monitore bekommen ein ganz "normales"  RGB H V -Signal wie jeder
standard VGA-Monitor nur eben nicht über einen 15poligen sondern über einen 25poligen
Stecker.

Beim  Adapter habe ich mich an der Beschaltung eines VGA-Kabels mit fünf BNC-Steckern
orientiert, weil bei der 25pol Buchse an der Dialog11/12 jedes Signal eine eigene Masse hat,

25Pol Stift   zu      VGA 15Pol Buchse

1+2           R-GND            6

3+4           G-GND            7

5+6           B-GND            8

7+8           H-GND           4  +  10        

9+10         V-GND          11

14             R-SIG              1

16             G-SIG              2

18             B-SIG              3

20             H-SIG            13

22             V-SIG            14

Ob es wirklich nötig ist, die Masseleitungen so getrennt zu führen weiss ich jetzt nicht,
aber so ist es bei VGA-Kabeln üblich und es funktioniert. Sollte also so passen.

Das eigentliche Problem ist aber die Bildfrequenz, und da gilt es, einen passenden
Monitor zu finden, der das kann........ Das sind irgendwas bei 57-59 Hz, Die haben das wohl
nur ein bisschen neben der Norm betrieben um so Leute wie mich zu ärgern!
Die Bildfrequenz ist einfach noch ein bisschen niedriger als bei VGA etc normalerweise üblich,
und es gilt deshalb, einen Monitor zu finden, der das ohne zu Meckern darstellt
Ich hab mir bisher noch nicht die Mühe gemacht, rauszufinden, was für ein Bild da
tatsächlich übertragen wird. Rein vom Baujahr her wäre eher 800x600 oder so wahrscheinlich....
Da muss ich mal schauen, ob vielleicht einer der Monitore das ein bisschen besser anzeigt.
Wir haben erst mal alles ausprobiert, was noch irgendwo auf die Schnelle aufzutreiben war
oder in irgendwelchen Ecken herumstand.
Vom alten Röhrenmonitor bis zum neuen 22-Zöller aus dem Büro!
Die meisten zeigen gar nichts an oder eine Fehlermeldung wegen falscher Frequenz und so.....
Das gemeinste war einer, der das Bild wunderbar darstellte, aber einen Text darüberlegte,
der aussagte er könne das nicht darstellen. Immerhin war damit die Funktion meines
Adapters und die Richtigkeit meiner Vermutung schon mal bewiesen.
Mehrere Dell bzw auch IBM-Monitore zeigten nichts an, bzw hatten ein verzerrtes Bild,
16:9 ist sowieso unbrauchbar, wenn da das Bild gedehnt wird.
Wir hätten da jetzt etliche 15" Monitore übrig...........  ;-)
Ein heisser Tip waren Monitore von NEOVO, aber die 14" und 15" der F-4XX -Reihe sind
sehr schwer zu finden! So einer war natürlich nicht dabei
Wir haben einen neueren 15" und einen F-419 19" besorgt, und die zeigen das Bild auch an,
aber die beiden sind wie erwartet leider "zu gut", weil beide für 1280 x 1024 ausgelegt sind.
das gibt dann unschöne Effekte bei Schrift und schrägen Linien.
(immerhin aber schon mal ein brauchbares Bild und das ohne Fehlermeldung!)
aber dann war da noch einer,
den ich fast übersehen hätte, weil er in meiner Firma rumstand... BINGO!!!
Der hat ein 1024 x 768 Display, und damit passt die Darstellung bisher mit Abstand am besten!
Es ist aber nicht wirklich perfekt, also passt 1024 x 768 definitiv nicht wirklich, aber das Bild
ist schon sehr viel besser als der Originalmonitor das wohl jemals darstellen konnte.
Wie schon erwähnt denke ich, dass das Bild höchstwahrscheinlich 800 x 600 Pixel haben dürfte.

So wie es scheint braucht man da gar keine exotischen Monitore, sondern offenbar klappt es mit
vielen alten Fujitsu-Siemens 15" Monitoren womöglich dann auch mit entsprechenden 14"-Typen.
Die werden derzeit reihenweise entsorgt bzw. kosten bei Ebay etwa 5-10 Euro....... wer braucht schon noch 15" Monitore, und dann überhaupt noch dazu einen älteren mit 1024 x 768 er Display
Davon muss ich mir jetzt erst noch einige sichern, Ersatz und überhaupt....und dann nenne ich hier
auch den genauen Typ.Eigentlich müsste da sogar eine ganze Baureihe gehen. Es gibt da verschiedene
sehr ähnliche, und vielleicht passt ja eines der verschiedenen Gehäuse besonders gut!
Eigentlich würde ein 14"er besser passen, rein vom Platz her, aber den 15er bringt man da auch rein,
aber nicht ohne Nacharbeit am Gehäuse. Ist aber überschaubar vom Aufwand her.
Das größere Bild ist aber einfach angenehmer, und den kleinen Mehraufwand wert, abgesehen davon
dass 14-Zöller nochmal ein bisschen älter sind und meist auch kein kleineres Gehäuse haben
Bei den Kosten kann man schon noch ein bisschen durchprobieren.........das muss drin sein ;-)