Translate

12 Dezember 2013

Wieso und warum und warum nicht anders?

Wie ganz leicht zu bemerken ist, habe ich mich in den letzten Tagen endlich mal
wieder ein bisschen mit der Franzbox beschäftigt bzw. endlich mal wieder damit
beschäftigen können........
So ganz allmählich komme ich den Grenzen dieses wenn mans genau nimmt
Arduinoähnlichen Gebildes recht nahe. Es ist nicht mal der Programmspeicher,
Die Franzbox an sich braucht etwa 8k, und dann ist da ja auch noch ein
BMS-Programm mit einzelspannungs und Min-Max-Auswerung mit drauf
als eigentlich funktionsfähige Altlast bzw Demo. Derzeit stillgelegt, aber vorhanden)
Allerdings liegen die meisten Probleme in der "gewachsenen Programmstruktur"
Was ursprünglich mal als kleine Spielerei um die Ampere auf dem Drehzahlmesser anzuzeigen
begonnen hat ist nun doch schon etwas umfangreicher geworden und macht Sachen
an die ich anfangs nie und nimmer gedacht hätte.
Angefangen hat das ja als ATtiny13, und dann war aber sehr schnell klar, dass ein
10bit-Timer hier nicht ausreicht weil sich die Frequenz über die Periodendauer
der Takte im Drehzahmesser errechnet, und bei niedrigen Frequenzen
sehr viele Timer-Takte zusammenkommen.

Hier wird einfach eine Konstante durch den auf den Nullpunkt bezogenen Wert
des Stromwandlers geteilt

Ein Vierzylinder-Drehzahlmesser baucht
33,3333....Hz je 1000u/min und wenn dann die Schritte bei 6000 U/min bzw 600A
nicht allzuriesig werden sollen, dann kommt man mit den 1024 Schritten eines
10Bit-Timers nicht weit.Der idealste Prozessor war deshalb wegen seines 16Bit-Timers,
der Verfügbarkeit und der Kompatibilität mit der Bascom-Demo sowie dem STK500
ein Atmega48. Mittlerweile bin ich beim Atmega328 angekommen...........
Der 168 müsste aber auch locker reichen wenn das Programm erst mal aufgeräumt wird.
Ich nutze derzeit zwar nur einen winzigen Teil des 16Bit-Timers, aber ohne einen
16 bit -Timer gehts nicht ganz so einfach. .....oder womöglich doch, wenn man den Prescaler
während des Betriebs umschalten kann.....Man könnte auch noch anderweitig ein bisschen
tricksen, so ein 10-bit-Timer kann ja auch noch eine andere Zahl hoch oder runterzählen,
mit ein bisschen if-Then müsste er dann halt zwei- drei - mal oder noch öfter durchlaufen.
Mit etwas gutem Willen geht das dann durchaus, ich habs aber so noch nicht versucht,
das war mir dann letztendlich völlig egal, als immer mehr an Funktionalität dazu kam
und ich sowieso derart viele Ports brauchte.

........vielleich wäre das mal eine Idee für einen supersimplen Ampere zu DZM-Signal-
Wandler, eigenständig und ohne irgendwelchen sonstigen Schnickschnack für diejenigen,
die gar keine Ah-Zählerei brauchen, weil sie z.B. schon ein brauchbares BMS drin haben
das diese ganzen Funktionen ohnehin schon erledigt. (z.B. Emus) sondern nur ein Amperemeter
Ein LEM HASS 200 für 600A -Anzeige, ein ATtiny25, ein 5V-Regler und noch ein paar
Kleinteile (Transistor, Elkos, Supressor-Diode etc  auf die Größe einer Briefmarke gepackt
sollten das dann schaffen. (Kein Display, keine Konfiguration,  bestenfalls 4 / 6 Zyl. )
Ich werde gelegentlich mal drüber nachdenken...müsste eigentlich machbar sein
Das sollte unter 10Euro an Material für die Platine + LEM (ca 17Euro) zu schaffen sein.


Derzeit läuft die Box mit 4MHz und der Timer mit Prescaler 64 da passen dann Werte
von ca 5800 bei fast 0A    ca 36000 bei 3A  ca 64000 bei etwa 100A
ca 65223 bei 300A  und 65379 bei 600A..... 16Bit, das geht von 0 bis 65535.
Ich zähle da übrigens aufwärts bis zum Überlauf, das hat sich mal so ergeben, obwohl es
eigentlich in dem Fall "falsch" ist weil ja die Takt-Zahl bei 0A eigentlich am größten ist.
(eine Konstante geteilt durch den Stromwert, ergibt die Periodendauer,
natürlich nicht bis geteilt durch 0 runter, da muss man aufpassen!)
Das sollte ich mal unstellen und eine Berechnung sparen
Vielleicht wird da auch klar, wieso ich 4MHz gewählt habe, wobei aber 8 oder 16 MHz
sicher auch gehen würden (Arduino.........) wobei aber ein "Baudratenquarz" mit
uhrenkompatiblerem Wert viel an Rechen und Versuchsarbeit erspart hätte.
Na ja, jetzt ists halt so!
4,0960 MHz oder 3,6864 MHz wären jedenfalls die bessere Wahl gewesen.
bzw 7,3728 für mehr Rechenleistung oder 8MHz für mehr Arduino-Kompatibilität.
Aber alle Konstanten zu überarbeiten gefällt mir jetzt auch nicht..... irgendwann mal....

Wenn man ohnehin schon den Strom misst und Timer zur Verfügung hat,
dann ist ein Ah-Zähler die logische Weiterentwicklung, und weil der Atmega48
auch ein Display treiben kann kam eins zum Anderen und schon war der erste Prototyp
fertig. Den Rest in Prozent umzurechnen und per PWM auf die Tankanzeige zu
schicken war ebenfalls selbstverständlich.Das war aber letztendlich der problematischste
Teil des ganzen Projekts!! Mit einem Drehspul- oder Hitzdrahtinstrument geht das
problemlos, aber elektronische Tachos wie neuere von VW mit all ihren  plausibilitäts-
Prüfungen, Kurzschluss- und Leitungsbruchüberwachung muss man erst mal überlisten.

Wie erfasst man Amperestunden?
 Ganz einfach! Man macht in festem zeitlichen Abstand Strommessungen, addiert die Werte
und teilt das Ergebnis durch die Zahl der Messungen je Zeiteinheit.Das Ganze wird noch
entsprechend auf Ah umgerechnet und addiert
Bei den ca. 15 Messungen je Sekunde im Fall der Franzbox kommt man so auf  ganz
brauchbare Ergebnisse

Warum habe ich jetzt so weit ausgeholt? Es ist wichtig, möglichst oft in einem festen
Zeitabstand zu messen, Diesen Takt erzeugt ein Timer. jedes Mal wenn ein Nulldurchlauf
erfolgt wird ein zugeordnetes Unterprogramm ausgeführt und der Timer darin wieder
auf den Startwert gesetzt von dem aus er dann wieder hochzählt bis zum Überlauf.

Diese Unterprogramme müssen kurz sein! Weil sie vorrangig ausgeführt werden
macht der Rechner in dieser Zeit nichts anderes, das muss alles warten bis das
Unterprogramm fertig ist.
Jetzt laufen hier aber schon zwei Timer, und jeder von denen startet je Durchlauf
einmal ein Unterprogramm. Der eine ca 15 mal je Sekunde für den Zeit-Takt
und der andere 400mal pro Sekunde wenn 600A angzuzeigen sind.
Doppelte Frequenz, weil ich da einen Ausgangspin jedes Mal umschalte um ein
Rechtecksignal zu erzeugen.
Das macht der Atmega alles ganz locker nebenbei, weil er mit 4MHz etwa
vier Millionen Befehle pro Sekunde abarbeiten kann (na ja, nicht ganz so viele,
aber es reicht locker) Das geht so lange gut wie nicht zeitintensive Sachen dabei
sind wie vor allem Schreiben in ein Display oder Datenverkehr nach "draussen"
So was muss ins Hauptprogramm wo es dann immer wieder angehalten wird
solange eines der vorrangigen Unterprogramme läuft.

Mittlerweile ist aber in den Timer-Unterprogrammen derart viel an zusätzlichen
Aktionen und Berechnungen reingepackt, dass die Grenze beim Hinzufügen der
I²C Funktionen überschritten wurde. das muss aber letztlich trotzdem da rein,
weil ich sonst nicht garantieren kann, dass die Messwerte aktuell sind.

Hier muss also unbedingt der Ablauf verbessert werden.
Ich werde es versuchen, eine Zahl ni einer Schleife hochzuzählen und
so einen Ablauf in die aufgeteilten I²C-Funktionen hineinzubekommen
also bei jedem Durchlauf nur einen Teil auszuführen.
Die Messung der Zellenspannung braucht z.B. nicht jedesmal zu erfolgen,
das reicht z.B. 1x pro Sekunde, zum Umschalten des Wandler-Kanals
sind aber ebenfalls ein paar Befehle nötig.
Konfigurieren und Auslesen des Wandlers in einem einzigen Durchlauf
ist aber nicht möglich, das hat die Störungen verursacht über die ich schon berichtete.

Es darf an dieser Stelle natürlich auch nicht vergessen werden, dass ich bisher mit
Software-I²C Arbeite, aber zumindest schon mal die "richtigen" Pins benutze.
Vielleicht ist ja alles schon besser wenn die Hardware-TWI (=I²C) aktiviert wird.
Da ist noch sehr viel zu tun und auch zu testen.........

Den Wert zu übernehmen und auch die Berechnungen sollten schnell genug klappen
Es wird sich aber nicht vermeiden lassen, bei der Wertübernahme zu tricksen.
Wenn es keinen Neuen wert gibt, dann ist es wohl am sinnvollsten, dann den zuletzt
gelesenen nochmal zu nehmen, oder aber  einfach nur die geringere Anzahl bei der
Berechnung zu berücksichtigen, Ob jetzt 15 x oder 10 x pro Sekunde gemessen wird
sollte nicht das Problem sein, und dass die Zeitabstände so nicht alle identisch sind
auch nicht. Die Zahl der Messungen je Sekunde ist aber dann auch noch konstant
und darauf kommts an. Ich will aber keinesfalls die Messwerterfassung ins
Hauptprogramm legen und nur die Werte in den Unterprogrammen übernehmen.
Das wäre dann die allerletzte Notlösung, aber dann wäre irgendwan der Sinn
der genaueren Messung über den externen AD-Wandler in Frage gestellt.

Der Jack hat im aktuellen Video sein neues Wunderkästchen sehr genau beschrieben,
 und das was da alles reingepackt ist ist der richtige Weg zu besseren Messungen
als mit der derzeitigen Version der Franzbox möglich sind.
eine ganz andere Möglichkeit wäre aber auch in der Richtung Raspberry zu
suchen, zumal es da mittlerweile ganz ernsthafte Bestrebungen gibt, die vielen
mittlerweile verfügbaren Arduino-Erweiterungen damit zu betreiben.

Stand der Dinge ist derzeit:
Die Franzbox als AH-Zähler ist in der aktuellen Version durchaus brauchbar,
wenngleich auch nur zwei Stück tatsächlich im Einsatz sind.... :-)
Ein älterer Prototyp dient Versuchszwecken, aber da sind ein paar Ports anders belegt,
da ist eine eigene Programmversion notwendig, mehr als eine Erweiterung auf
mehr als 255Ah Akkukapazität (-999 ??) werde ich da wohl nicht "nachrüsten"
Von einer "Serienfertigung" kann man daher gewiss nicht reden.
Ich habe aber zuhause ein paar Stück für vollkommen andere Aufgaben programmiert
und steuere damit Schmiervorrichtungen, Kraftwerksrechenreiniger, Ladegeräte
und auch im IGBT-Controller in meinem Prüfstand mit dem STILL-Stapler-Motor
ist so eine Platine das Kernstück. In einem ganz speziellen Fall ist die H-Brücke
bestückt, und da steuert die Box einen lernfähigen  Positionierantrieb und auch eine
Kommunikation per Modbus-Protokoll habe ich schon zum Laufen gebracht.

Wenn es klappt, die I²C AD-Wandlung so richtig zum Laufen zu bekommen
um die Auflösung der Strommessung von derzeit etwa 3A auf 0,1A zu verfeinern,
und zugleich galv. zu trennen (letzteres ist offenbar kein Problem)
dann gibts dafür natürlich eine Erweiterungsplatine für I²C Strom- und Spannungsmessung.
Sollte ich es aber nicht Timer-interruptgesteuert schaffen, dann bleibt es bei der
bisherigen Strommessung und nur die galv. getrennte Spannungsmessung erfolgt
dann per I²C. Das kann nämlich auch problemlos im Hauptprogramm erfolgen,
und da klappt das wunderbar! 

Leider haben alle Atmegas nur 10bit AD-Wandler, und die Xmegas sind deutlich
aufwändiger zu programmieren. Es wäre natürlich auch denkbar, einen der vorhandenen
AD-Wandler-Eingänge anders einzulesen und schlicht und einfach unterhalb einer
bestimmten Grenze den Wert des anderen AD-Wandlers zu nehmen.
Schliesslich ist ja nur die zu grobe Auflösung bei niedrigen Strömen wirklich problematisch,
aber ganz sooooo einfach ist das trotzdem nicht, weil dadurch auch die Messung am anderen Kanal beeinträchtigt wird wegen der Last des Spannungsteilers die ja dann nicht ganz gleichmäßig ist.
..........es müsste aber durchaus machbar sein!!!!!! und auch ohne Layout-Änderung!

Es gäbe ja auch noch die etwas verwegenere Variante mit Oversampling ( und ev. Einspeisen
von "Rauschen"????) das sollte ich vielleicht auch mal ausprobieren. zumindest muss ich mal mein
Programm dahingehend überarbeiten. Ich bin mir jetzt gerade gar nicht mehr sicher,wie
ich da alles gemacht habe. Sicher ist, dass ich die Auflösung fürs Display ein bisschen umrechne
damit es nicht ständig wechselt, aber das macht ja die Auflösung nochmal schlechter.
Ich muss da also unbedingt für die Berechnung zum Auswerten alle "Korrekturen" entfernen
und fürs Display einen gesonderten Mittelwert aus einigen Messungen bilden.
Das löst aber nicht ein weiteres Problem, das ich mit dem Delta-Sigma-Wandler nicht habe,
nämlich die Drift von der Referenzspannung gegenüber dem Nullpunkt des LEM-Sensors.
Der Delta-Sigma-AD-Wandler ist auch an die Referens des Lem angeschlossen, das ist
wesentlich besser und stabiler.

....und weil ich grad am Schreiben bin..... es ist mir mittlerweile auch gelungen,
Bascom .Hex-Files per Arduino-Bootloader auf Arduino zu laden.
Auch das Brennen des Arduino-Bootloaders auf einen Atmega 328P
funktioniert mittlerweile.
Einen Arduino direkt per Bascom und Arduino-Bootloader zu beschreiben hat
aber noch nicht geklappt.
Allerdings habe ich festgestellt, dass dazu als Betriebssystem mindestens Windows XP
nötig zu sein scheint, aber mein Bascom ist auf einer Win2000-Parition installiert.
Da bin ich ständig am neu booten, und alles was mit Arduino zu tun hat baut unter
WIN2000 keine Verbindung zu den angeschlossenen Platinen auf.
.....noch nicht mal zu einem Duemillanove-Klon mit echter serieller Schnittstelle.......

Das letzte Franzbox-Programm läuft zwar auf dem Arduino-M238P wenn ich es
im Freeduino seriell per Bootloader drauflade und dann den Chip
in die Franzbox-Platine stecke, und obwohl die Fuses stimmen läuft es dann
aber lähmend langsam. Da bin ich noch nicht dahintergekommen weshalb das so ist.
Wie schon mehrfach erwähnt ist die Franzbox-Platine definitiv Arduino-kompatibel.
Die Ports passen, und sogar das EA DIP204 kann so wie es beschaltet ist auch
per Arduino betrieben werden. Das passt alles zusammen,obgleich das Display
unter Arduino eine eher harte Nuss ist, weil die Startadressen der Zeilen von der
Norm abweichen und man da sogar im Programm rumeditieren muss.
Bei echten "Industriestandard-LCDs" hat man dieses Problem nicht
und man müsste zum programmieren halt so vorgehen wie auch bei den ganzen
Arduino-mini-Versionen ohne seriellen Pegelwandler bzw USB-Anschluss.
also entweder ohne Bootloader per ISP-Programmer oder mit einem seriellen Adapter
den man sich zur Not aus einem gesockelten Arduino (Uno, 2009, oder Freeduino)
basteln könnte, was aber nicht ganz problemlos funktioniert wegen Timing-Problemen
im Zusammenhang mit dem Auto-Reset des Arduino.  Nur mal so am Rande erwähnt.
Die ISP-Variante ist die problemloseste, man muss nur erst mal die .hex-Dateien
auf dem Rechner finden..... irgendwo im temporären Ordner von Windows........

Ich bin nicht der große Arduino-Fan, aber das liegt hauptsächlich daran, dass ich
mit Bascom angefangen habe, und dass es daher nicht ganz einfach ist die Denkweise
auf Arduino umzustellen. Hinzu kommt, dass es bei Arduino nicht wirklich vorgesehen ist,
Prescaler von Timern zu verändern oder mit anderen Quarzen zu arbeiten.
Gewiss ist das auch bei Arduino machbar, aber man muss da halt leider schon in die
Trickkiste greifen, während das bei Bascom völlig unproblematisch ist.
Hier fehlt mir einfach noch die Erfahrung Das wird aber sicher noch besser im Lauf der Zeit.
Aber das ist jetzt überhaupt nicht mein Problem!

In den nächsten Tagen wird hier aber nicht viel passieren, es hat sich daheim schon wieder
eine riesige Menge an "dringendst zu erledigenden Dingen" angesammelt so dass wieder mal
eine "schöpferische Pause" nötig ist.

bis demnächst!
Franz







Kommentare:

  1. Hallo Franz,

    interessant zu lesen. womit Du so kämpfst. Da sehe ich viele parallelen. Ich bin auch immer wieder am überlegen welche Steuerungsplattform die beste wäre um Steuerungen für Elektroumrüstungen zu realisieren. Ich bin ja im Moment mit meinem EVµC-Board unterwegs (gut 5000km sind schon gefahren) und damit zufrieden. Es basiert auf ATMEGA16 und BASCOM. Die Funktionen sind: Batteriemanagement, Ah-Bilanzierung, Ladegerätsteuerung und Anzeige der relevanten Werte auf einem alphanumerischen Display. Einige Überwachungs- und Sicherheitsfeatures wie Ladekabelsteckkontrolle sind auch drauf. Ich finde viel mehr braucht es auch nicht. Trotzdem habe ich, wie Du auch über Arduino, Raspberry, XMega und Wago-SPS nachgedacht. Folgendes kann ich jetzt schon sagen: mein erster Arduino war leider werkseitig kaputt, ich bekomme aber bald eine Due, mal sehen wie der läuft. Raspberry PI habe ich getestet, das ist eine sehr mächtige Plattform, wenn man etwas Linux kann. Insbesondere grafische Ausgaben sind hier einfach. Allerdings ist die Bootzeit für ein Auto nach meinem Geschmack zu lang (10-15sec) und ich möchte das Board nicht immer laufen lassen. Ein Xmega Xplained Evaluationboard mit 128er Controller habe ich ebenfalls ausgetestet, hier aber mit Atmelstudio6 und C als Programmiersprache. Der XMega ist wegen seinen 12 Bit AD- und DA-Wandlern sehr sympathisch. Dazu kommen sehr umfangreiche Timereinheiten und Schnittstellen. Aber ich glaube ich würde ihn nicht mit BASCOM programmieren, die Community ist da noch sehr klein.
    Bleibt noch die WAGO 750-841 oder ähnlich, eine sehr robuste modulare SPS, mit der ich beruflich viel zu tun habe. Das ist dann aber auch die teuerste Lösung, da kostet schon der Controller knapp 400€. Auch das Timing im Sub-Millisekundenbereich lässt hier zu wünschen übrig. Dafür alles robust und industrietauglich.
    Also wie man es auch macht, die ideale Lösung kenne ich nicht. Für das nächste Auto (ja, es wird wieder eine Ente) welches ich gerade umrüste werde ich wieder auf das EVµC Board setzen.
    Beste Grüße
    Roland

    AntwortenLöschen
    Antworten
    1. Ja, das sind halt die ganz normalen Tücken des Objekts Im Prinzip reichen mir ja die paar Funktionen in der Franzbox. So sehr viel mehr will ich da gar nicht reinpacken.
      Das wird ja sonst wieder viel zu viel Aufwand und vor Allem gehts mir auch überhaupt nicht darum da allzuviel auszuwerten. Ich wünsche mir vorerst nur endlich mal eine ordentlich funktionierende Strom und Spannungsmessung. Irgendwie werde ich das schon noch hinbekommen. Die Richtung ADUM-Isolatoren und I²C oder SPI AD-Wandler erscheint mir
      im Augenblick sehr vielversprechend, zumindest was die galv.getrennte Spannungsmessung betrifft auch wenn die Auswertung noch nicht ganz so perfekt klappt wie erhofft.
      Ich bin da aber auch noch mitten in einem Lernprozes,
      und es geht immerhin voran. Wird schon!
      Die Franzbox ist und bleibt ein kleines Gerät und soll auf einen Blick zeigen was Stand
      der Dinge ist. Es fehlt halt noch ein genauerer (12bit?) AD-Wandler für die Strommessung,
      und da finde ich gewiss auch noch eine Lösung. Die entsprechenden AD-Wandler gibts ja,
      und Prozessoren mit mehr Ports gibts auch. Und die ganzen Spezial-Atmels eben für
      solche Messaufgaben wären ja auch noch da.... auch wenn man die nicht an jeder Ecke bekommt, und ob meine bescheidenen Programmierkenntnisse da jetzt schon
      ausreichen kann ich noch nicht sagen. Aber es macht mächtig Spass, damit zu spielen,
      und immer wieder irgend was neues auszuprobieren. Momentan ist ja auch mein
      Monstercharger in der Testphase und bis jetzt klappt alles sehr gut.

      Schön, dass es auch bei Dir immer weiter voran geht!
      Das ist nicht bei allen Projekten der Fall wie es scheint.......
      Aus manchen Blogs ist in letzter Zeit ganz schön die Luft raus!
      Ich werde an den kleinen überschaubaren Dingen weiterarbeiten
      und der rostfreie 92er Golf3 Automatik den ich mir vor einiger Zeit für
      sehr kleines Geld gekauft habe wäre eine Basis ganz nach meinem
      Geschmack vielleicht landet da ja doch irgendwann noch mein 11" Still Motor
      da drin??????? oder gleich was ordentliches ;-) aber gewiss nicht in nächster
      Zukunft!

      ....mal sehen.....

      Löschen
    2. Hallo Franz, das ist ja ein sehr interessantes Unterfangen, daß Du da angestoßen hast.
      ab Hut !!
      Ich habe da einges der Einträge gelesen. Echt super Dein Arragement.
      Ich fest der Überzeügung, daß das auch mit einem PIC auf jeden Fall zu realisieren ist.
      Vermutlich ist die "progammierung" vom PIC ein Problem oder?
      Könntest Du bitte mir eine Auflisten zu kommen lassen, welche Programmteile notwendig sind. .

      Löschen
  2. Hallo Fritz,
    Natürlich geht das auch mit einem PIC! Sogar um einiges besser, je nach Typ halt.....
    AAAAAber..... da betritt man auch eine andere "Ebene" des Programmierens!
    mit viel mehr Möglichkeiten aber auch viel mehr Programmumfang
    Genau das wollte ich vermeiden, mal ganz abgesehen davon, dass ich
    mit "C" kaum Erfahrung habe und die "Franzbox" eigentlich eines meiner ersten
    Bascom-Projekte war, wo ich mal ein größeres eigenes Programm geschrieben habe.
    Ich habe mich Schaltungstechnisch daher am Arduino orientiert um auch damit
    kompatibel zu sein.
    (Der Funktionsbeweis ist erbracht, aber genutzt habe ich es bisher nicht)

    Das Programm der Box ist eigentlich grundsätzlich total simpel.
    Vom LEM HASS200S kommt ein wunderbares Analogsignal um den Strom zu messen,
    das ohne weitere Beschaltung an den AD-Wandler geht
    Ein Timer macht ca 15 Messungen pro Sekunde, daraus die verbrauchte Energie
    in Ah abzuleiten ist kein großes Problem.
    Nach einem Reset ist der Akku "voll" und dann wird runtergezäht bis Null bzw
    bei verschiedenen Grenzwerten gewarnt.
    Unabhängig davon wird noch ein Takt erzeugt der die Stromstärke auf einem ganz normalen Drehzahlmesser anzeigt, und die Restenergie (%) wird als PWM-Signal auch noch an die
    Tankanzeige weitergeleitet.
    Diese Berechnungen sind allesamt recht simpel, und etwa 90% des Programms werden von
    der Menue-Geschichte belegt, es soll ja alles am Gerät ohne zusätzliche Ausrüstung
    einstellbar sein.

    Die "Franzbox" als solche wird wohl nicht allzusehr weiterentwickelt werden.
    Größtes Manko ist die fehlende "echte" serielle Schnittstelle, und weil sich der
    Gleichspannungsausgang als offenbar unnötig erwiesen hat werde ich an dessen Stelle
    beim nächsten Layout einen MAX232 und eventuell auch noch einen RS485-Baustein
    vorsehen. Viel mehr ist auf der Basis des Atmega 48 bis 328 derzeit nicht geplant,
    ausser natürlich der I²C-Erweiterung für galv. getrennte Messungen.
    Aber das ist ja eine externe Komponente, die ich dann auch "später" als Option
    nutzen möchte.

    unter 135-15 (at) freakmail.de kannst Du mich per Mail erreichen.

    mfG
    Franz

    AntwortenLöschen