McCoi-Forum

Es wurde nur gesagt, er wäre bei anderen Proz schwer zu implementieren

Beim Raspi! Bei allen AVR Controllern ist der Sleepmode möglich.

Das Wegschreiben ist generell keine gute Idee. 100'000 Schreibzyklen klingen zwar recht viel, aber die 15 Jahre, die Du jetzt den McCoi hast, hätten auch die 100K geknackt.

ich hab nix gegen den Sleepmodus.
Es wurde nur gesagt, er wäre bei anderen Proz schwer zu implementieren

Man kann zb auch den Zählerwert nach jedem 10 Imp oder so, wegschreiben. So hat man beim Neustart max 9 Imp verloren.
Aber nur, falls so ein anderer Prozessor sowas nicht hat

..um die Werte ins EEPROM zu schreiben, braucht der Controller Strom. Ist die Zündung die Stromversorgung schließt sich das aus. Man müßte also eine aufwendige Mimik mit PowerCap, GoldElko oder ähnliches installieren, um genügend Kapazität für den Schreibvorgang zu haben.

Ist die Zündung nur der Signalgeber (wie beim Autoradio), braucht man dennoch einen Sleepmodus.

Was hast Du gegen den Sleepmodus? Das BT-Modul schläft eh nicht, könnte also das Aufwecken des AVR für Deine Zwecke übernehmen!?

Auf den Sleep-Modus kann man verzichten, wenn man es irgendwie schafft, die bisher zurückgelegten Impulse bis zum Pumpen in einem Flash etc zu sichern. Dann darf er gern ausgehen und mit "Zündung an" wieder starten.

und meiner Meinung nach reicht ein Konfig Tool mit Blauzahn

Heute würde ich warscheinlich eher einen ESP8266 nehmen, aber da habe ich bisher noch keine fertigen Beispiele gesehen, die störungsfrei im Motorenumfeld werkeln.

ESP32 wäre aktueller!

Daher ist auch für mich klar, der McCoi wird eher ein neues Platienenlayout bekommen weil es das eine oder andere Bauteil so nicht mehr gibt, aber das jetzige Konzept wird erst einmal bleiben.

Das ist klar. Ich denke seit einiger Zeit über einen Arduino Nano als Basis nach; den steckbar auf eine neue Platine für die Schutzbeschaltungen, FET, etc. Da könnte dann auch das BlauzahnModus OPTIONAL aufgesteckt werden,... Und USB ist auch schon drauf!

Die Kinderkrankheiten bleiben natürlich bei jeder Neuentwicklung. Vorteil der Atmels gegenüber Pi ist die bekannte und wirklungsvolle SleepModus-Funktion,...

Auch das KonfigTool müßte neu geschrieben werden oder man geht nur noch auf Blauzahn!? Was meint Ihr?

Gruß Steffen

Ich bin zwar auch immer einer derjenigen, die sich das eine oder andere gut vorstellen können, habe ja auch aus dem Grund mal das ganze mit dem 4313 getestet.
Klar ist da jetzt mehr Speicher, aber ich muß Steffen recht geben, den McCoi so wie er ist umzubauen ist viel zu kritisch.
Da fängt dann alles wieder von vorn an mit den Kinderkrankheiten.
Dann lieber gleich auf eine völlig moderne Hardware, wir hatten ja schon den Pi am Öler.
Aber dann geht das ganze los.
Stromverbrauch steigt auf jeden Fall teilweise recht stark an. Der McCoi wie er heute ist liegt im Schlafmodus so niedrig, dass keiner befürchten muß nach einem Monat Standzeit das Ladegerät oder ddie Starthilfe dranhängen zu müssen.
Wie soll der denn allein aus dem Sleep wieder aufwachen, wenn das Handy gerade Bluetooth möchte.
Der USB-McCoi war da ja schon recht fotschrittlich, hatte einen wesentlich neueren Prozessor und konnte ja über USB komunizieren, aber allein der Preis, kaum noch Bausatz konnten den alten Dauerrenner nicht ablösen.
Heute würde ich warscheinlich eher einen ESP8266 nehmen, aber da habe ich bisher noch keine fertigen Beispiele gesehen, die störungsfrei im Motorenumfeld werkeln.

Daher ist auch für mich klar, der McCoi wird eher ein neues Platienenlayout bekommen weil es das eine oder andere Bauteil so nicht mehr gibt, aber das jetzige Konzept wird erst einmal bleiben.
Denn wie Steffen schon andeutete die Rx-Tx Leitungen werden schon für anderes benutzt, zur Zeit allein wegen des Sleepmodus mit Tachosignal das kann da nicht einfach weg. Wie gesagt es gibt wohl inzwischen viele Prozessoren die viel mehr könnten wenn sie dabei nicht in einem gestörten Umfeld werken müssten.

Wenn dann alle Eingaänge erst EMV-vertäglich beschaltet sind, das ganze Ding in einer HF-festen kiste schlummert möchte ich die wenigen sehen, die die "Vorteile" noch bezahlen wollen.

klar soll man Fehler vermeiden, sorry ist vllt falsch rüber gekommen.


Aber wenn jemand aus Spaß die Imp pro Radumdrehung von 8 auf 42 stellt ... ok
soll er das tun, und bitte leise heulen, wenn er zuwenig Öl auf der Kette hat.
Was aber den Support für dich auch einacher machen könnte:
MCoi per BT und Androiden auslesen mit ner Supportfunktion und die die Datei zumailen.
In der Datei muss dann eben alles drin stehen, was möglich ist und für die Fehlersuche von Interesse. Ist noch so dahingedacht, aber mal sehen.

Prozessor:
2 Byte ist echt wenig

ich hab auch nicht geschaut, was bei welchen Prozessor frei ist, Die Internet Literatur hat bei den BT-Beispielen eh immer einen Mega8 oder so dabei, keinen Tiny

Aber sooo tief bin ich noch nicht eingestiegen,
vllt machts ja auch Sinn, das Platinenlayout zu erneuern, da man die eine oder andere Fkt (zB den Hex-Schalter) dann nicht mehr brauch.

...willst Du bei dem aktuellen Controller bleiben? Da wird der Platz eng. Und ich weiß auch nicht, wofür Rx und Tx derzeit verwendet werden. Das müßte ich nachsehen. Ob virtuelle Pins generiert werden können, weiß ich nicht. Der Tiny2313 ist auch schon älter,...
Also müßte wohl was ganz Neues her!?

Ach! Moment! Wir könnten auf den Tiny4313 ausweichen. Der hätte dann noch Speicher.

Aber ich muss nicht die Anwender vor sich selbst zu schützen versuchen.

Wenn Du den Support und die Fehlersuche 16 Jahre lang betreibst, vielleicht doch?
Okay, das Forum hilft auch. Aber Du selbst warst früher auch sehr viel öfter im McCoi-Forum. Das läßt nach, klar. Aber Fehler abzufangen ist in der SoftwareEntwicklung z.B. Gang und Gäbe und zeichnet eine gute Software aus. - Du hast recht, ich will auch niemanden bevormunden. Aber Fehlerquellen zu vermeiden ist eine der Lehren, die ich sammeln durfte,...

Auf jeden Fall muß dann der pin-kompatible 4313 her. Im 2313 sind derzeit 2(!) von 2000 Byte frei, soweit ich mich erinnere.

Hi Steffen

sehe ich mittlerweile nicht ganz so
In der Praxis hast du immer mal ne abgerissene oder verknickte Kanüle , und wenns nur meim Reifenwechsel passiert ist. Also neue rein und mcTestmodus aktivieren

oder der Tank läuft leer, passiert mir gern
Also Auffüllen und entlüften , sprich Testmodus

Die HEX-Einstellungen ändere ich auch sehr selten, das stimmt.
Aber ich muss nicht die Anwender vor sich selbst zu schützen versuchen. Wenn da jemand die Einstellungen mit einem Daddelspiel verwechselt , ok.Man kann ja einen Werksreset einbauen (im Android)

Hallo Joerg!
Die Überlegung mit Bluetooth zu arbeiten habe ich schon über 10 Jahre. Allerdings fand ich den Aufwand immer zu groß und der der mögliche Schaden (wegen "Spielkindern") nicht im Verhältnis zum Nutzen. Denn ehrlich gesagt wird der McCoi nach dem korrekten Setup nie mehr angefaßt. Einmal im Jahr wird der Tank aufgefüllt und das war es dann meisten schon. Es gibt also nichts, das man permanent verstellen müßte. Und man soll es auch nicht! Viele Spielkinder nutzen das KonfigTool (ohne zu wissen, was sie da tun), einfach nur, um etwas zu verstellen und zu fummeln. - Mit einer App würde dieses Gefummel noch mehr werden und sich somit auch die Probleme vergrößern. Die Standardeinstellungen passen in 98% der Fälle. Nur wenn das nicht klappt, ist das bisherige KonfigTool mit Vorsicht und Verstand zu verwenden,...

Ansonsten aber habe ich gar nichts gegen Bluetooth. Besonders der HEX-Schalter ist ein sehr teures Bauteil, das man sicher gerne einsparen könnte,..

Soweit mein Statement

Viele Grüße
Steffen

Nur mal so .... gibts da schon irgendwelche Gedanken/Planungen in diese Richtung ?

Ich hab noch den ganz uralten mcCoi ohne Teach und Geschw. Anpassung usw. Den Tachoimp. verwerte ich mittels eines diskret vorgelötetem Transistor
Aber das Teil funktioniert, seit nunmehr 15 Jahren
Lediglich diesen blöden Modus-Hex Schalter musste ich im Laufe der Jahre mal tauschen.

Und ich denke, da wäre ne wirkliche Verbesserung des mcCoi's möglich, nicht noch n Crossmode und ne Geschwindigkeitstabelle etc. (ich hab mittlerweile sogar den Regensensor raus, weil er nicht benötigt wird)

Ich stelle mir vor, der mcCoi werkelt in seiner Kernfunktion , der Wert des Hexschalters, die Auslösung des Pumpentestes, Die Anzahl Imp pro Radumdrehung und die Anzahl der Pumphübe bei erreichen der Pumpanzahl usw liegt im Speicher , das sind nur ein paar Bytes , das geht da mit Sicherheit rein.
Und vllt noch einen 4 Byte oder gar 8-Byte -Zähler , der die Pumphübe mitzählt.
Dieser Bereich ist per BT über einen Android - Handy lesbar / änderbar.
Und der Hex Schalter kann entfallen und man hat noch ein paar Eing. frei.

Ich hab mir das für nächsten Winter mal auf die ToDo Liste geschrieben, aber gibts schon irgendwelche Überlegungen Pläne Bedenken dafür / dagegen ?
Vllt ist das ganze ja sogar von offiziellem Interesse.

Die techn. Umsetzung halte ich für machbar. SO BT-Kopplungen gibts mittlerweile fertig und blenden sich im Atmel als serielle Schnittstelle ein. Die Kommunikation damit in Assembler ist einfach. Und die Smartphone App kann ich beisteuern (das mach ich beruflich)