• Hi,

    ich hab es endlich geschafft!!

    Nachdem ich im Hardware-Teil meiner ersten Version total gescheitert war, ist meine zweite Version technisch einwandfrei! Das Teil lässt sich problemlos proggen, alle Ein-/Ausgänge machen was sie sollen etc!

    So konnte ich den letzten Monat damit verbringen, das entsprechende C-Programm für das Teil zu entwickeln! Und glaubt mir, das war nicht leicht. Ich und proggen halt. :D

    Alleine die letzten zwei Wochen habe ich nur mit der Behebung eines Fehlers zugebracht. Mein IR-Endschalter tat was er will. Ging ich mit dem Finger langsam Richtung Phototransistor, schaltete der Kasten entsprechend. Ging ich aber noch näher heran, so ging er wieder aus, noch näher ging er wieder an etc. o_O Eine Katastrophe!

    Und woran lag es im Endeffekt?
    Ich verwende einen 10bit-ADC, also der zerhackt die analoge Spannung in einen Wert 0-1024
    Die Variablen, in denen der gemessene Wert schließlich gespeichert wird, hab ich allerdings nur als 8bit Variablen (0-256) definiert. So überlief die Variable ständig und diese kuriosen Effekte traten auf... *ARGH!!*


    Also das Prinzip meiner Endschalter ist recht simpel:

    Per Timer-Interrupt lass ich die IR-LED regelmäßig ein- und wieder ausschalten, mit einer Frequenz von 2kHz.

    Mein ADC nimmt sich zum einen den Wert des hohen Spannungsniveaus, also wenn die IR-LED ausgeschaltet ist->Transistor (gegen Masse geschaltet) wird hochohmig->Spannung steigt an.

    Dann geht die LED an und der ADC darf sich auch diesen Wert vom Transistor schnappen (Transistor wird niederohmig, ergo sinkt auch die Spannung).
    Dann wird die Differenz der beiden Werte genommen und damit werden dann die LEDs/das Relais geschaltet.

    Das sieht dann wie folgt aus:

    (Das Bild lässt sich leider nicht hochladen, darum findet ihr es im Anhang!)

    (Die anderen beiden Bilder zeigen wann sich der ADC die Spannungen "holen" ;) )

    Gelb ist die IR-LED
    Blau ist die Spannung am Transi

    Das Signal sieht einwandfrei aus! Natürlich steigt/fällt der Wert je nachdem wie weit ich weg vom Transi bin!


    Geplant sind für die Zukunft noch diverse Sicherungsvorkehrungen:

    - Der Watchdog des uC's soll einprogrammiert werden, falls meine Software mal verrecken sollte.
    - Als Option möchte ich ein Signal der Endstufen des Reiner-Reglers an meinen uC legen damit, falls der Endschalter mal immer "was sehen" sollte, die Software nach einer bestimmten Zeit automatisch stoppt, eine Art Notabschaltung halt. Ein Pin ist zu dem Zweck schon auf der Platine reserviert!


    Die Ein oder andere Sicherheit ist natürlich schon drin:

    - Softwaremäßig: kein Auslösen durch fremdes Licht da ich stets die Differenzen der Spannungsniveaus nehme
    Wenn externes Licht (Lampe/Sonne) auf den Endschalter fällt, so sinkt nämlich insgesamt das Niveau der Spannung, die Differenz bleibt aber die selbe!
    - Hardwaremäßig: Falls ein Draht der Stromversorgung abreißt oder die Sicherung auslöst, so macht das Relais zu und ein Reiner-Regler stoppt
    (reißt allerdings ein Schaltdraht, so können meine Endschalter natürlich auch nichts machen ;) )


    Öhm, Ergänzungen sind natürlich möglich (jemand Ideen?)

    Wovon ich träume? Von dem sichersten Endschalter den es gibt!! ;) Aus Liebe zu meiner (und Eurer?) Mechanik! ;)


    Für das kommende Event werde ich die Endschalter, sofern sie zuverlässig laufen, nicht mit irgendwelchen Funktionen erweitern. "Never change a running system"! Erstmal müssen die sich so bewähren!


    Hier sind meine kleinen:
    (auf den beiden Fotos ist noch die SMD-Diode/ SMD-Transi drauf, die werden aber auch noch durch bedrahtete ersetzt)


    Und eingebaut (1 von 2):


    (Nebenbei: Bemerkt jemand den Unterschied zu meinem alten LJ-Getriebe?? ;) ;) )


    Und nicht zu vergessen, der Video-Beweis!

    http://www.youtube.com/watch?v=B8g-kSNagNE&feature=youtu.be

    3 Mal editiert, zuletzt von Replikator (5. September 2012 um 22:29)

  • Warum hast du keine Schmit Trigger Schaltung verwendet? Weniger Teile und billiger. Ein OPAmp, ein paar R´s, ein paar C´s und fettig ist. Ich hätte mich nicht solange mit einem Mikrokontroller rumgeschlagen.

    Erfahrungen sind was sehr nützliches, leider macht man sie erst kurz nachdem man sie gebraucht hätte...

    Funken: Multiplex Combi 80, Multiplex Combi 90

    Ants: Drum1 (kaputt), Drum2 (kaputt), Böse (reden wir nicht drüber)

    Bastellein: Alles so alt das die Bilder fehlen

  • So lernst du das proggen aber nie ;)
    Ich habe in den letzten Wochen eine Menge (kennen-) gelernt (z.B. die Interrupt Service Routine)! ;)

    So hab ich eine Plattform mit der ich arbeiten und üben kann, bin absolut flexibel mit dem Schalter und kann irgendwelche Funktionen hinzufuschen oder beliebig Ändern.


    Weiß jetzt nicht wie du dir das gedacht hast, aber geh mit ner Taschenlampe auf ein Phototransistor, der auf ein Schmitt Trigger geht, und du schaltest den aus 10m entfernung. ;)


    Also ich bin mehr als zufrieden mit den Dingern! Und so viele Teile sind das ja nun nicht ;)
    Hab die Orginal-Maße der Standart-Mikroschalter, also schön klein! :)

  • Nächstes Halbjahr habe ich AVR Programmierung in der Schule.

    Erfahrungen sind was sehr nützliches, leider macht man sie erst kurz nachdem man sie gebraucht hätte...

    Funken: Multiplex Combi 80, Multiplex Combi 90

    Ants: Drum1 (kaputt), Drum2 (kaputt), Böse (reden wir nicht drüber)

    Bastellein: Alles so alt das die Bilder fehlen

  • Hi, muss hier mal wieder etwas nerven. ;)

    Und zwar bin ich im Moment dabei, meine IR-Endschalter zu verbessern.

    Ansich funktionieren diese ja gut. Aber es gibt dennoch Besserungsbedarf.
    Zum einen fliegt die IR-LED und der Phototransistor raus.
    Der Grund dafür ist: Die LED und der Transi sind bedrahtete Bauteile. Also stehen mit ihren beiden Beinchen von der Platine ab. Diese lassen sich leider hin und her biegen und nur bei einer bestimmten Konstellation sehen die sich auch.

    In der nächsten Version möchte ich nun gerne einen fertigen Optokoppler verwenden. Diese hier sollen es werden. Das ich die nicht sofort gefunden habe, ist mir ein Rätsel...

    Desweiteren gibt es halt das Problem, das jeder Endschalter einzeln auf den korrekten Abstand programmiert werden muss. Liegt wohl an die leichten Differenzen der Bauteile und zum Teil auch sicher an dem oben beschriebenen Problem der Beinchen.

    Abhilfe soll da ein kleiner Taster schaffen.
    Ich Träume nämlich davon, das ich diesen Taster z.b. 3sec halten kann und dann die Weiten individuell am Endschalter einstellen kann.

    Und da stellt sich mir ebend die Frage.
    Mein Programm muss diesen ermittelten Wert ja irgendwo abspeichern, damit ich diese Einstellung nicht bei jedem Start des Bots von neuen ermitteln muss. :)

    Ist das mit meinem ATTINY24-20SSU möglich ohne das ich einen externen Speicher brauche? Es sind ja eig. nur zwei Vaiablen die gespeichert werden müssen.

    Ich weiß, ihr kennt Euch nicht so mit Atmels aus, aber ich schätze euch sagt das beschriebende mehr als mir. Ich würde sagen ja das geht.
    Hab gelesen

    Zitat

    Self-Programming Flash & EEPROM Programming Lock for

    bedeutet genau das oder?

    • Offizieller Beitrag

    Der ATtiny24 sollte 128 Byte internes EEPROM haben...

    Das EEPROM ist nicht-flüchtig (*räusper* sollte es jedenfalls sein, die Atmels haben aber seit je her immer mal wieder kleinere Probleme mit den internen EEPROM's)

    Normalerweise werden Parameter im internen EEPROM abgelegt --> such dir Beispiele wie das Programmieren des EEPROMS vonstatten geht!

    "Self programming Flash":
    Denk lieber nicht drüber nach!
    Das bedeutet, dass Teile des Programmspeichers gelöscht und dann neu beschrieben werden. Wird z.B. bei Verwendung eines Bootloaders so gemacht. Ist im allgemeinen etwas komplizierter... (vorsichtig ausgedrückt)
    :D:D:D

    • Offizieller Beitrag

    Ein paar kennen sich hier doch ganz gut mit AVRs aus...
    Nicht (!) das Flash beschreiben wenn man nicht weiß was man tut...
    Solche Parameter wie in deinem Fall gehören ins EEPROM wie UW schon sagte...
    Frei aus dem Gedächtnis: Im avr-gcc, bzw der avr-libc sind das die Funktionen eeprom_read_*() und eeprom_write_*() aus dem header <avr/eeprom.h>. Da gibts Funktionen für byte, word und block... Ausserdem in dem Zusammenhang wichtig ist das EEPROM Makro das es dir beim Deklarieren vereinfacht...

    Achja, manche klassischen AVRs hatten Probleme mit den EEPROMs. Ab ATtiny und ATmega ist mir keiner mehr untergekommen der sein EEPROM Inhalt vergessen hat. Im Zweifel steht dazu aber ein Hinweis im Errata...

    • Offizieller Beitrag
    Zitat

    Ab ATtiny und ATmega ist mir keiner mehr untergekommen der sein EEPROM Inhalt vergessen hat


    wir hatten letztens noch probleme mit zelle 0 des EEPROMS bei ATMEga168's (nagel mich jetzt nicht auf den genauen typ fest, war nicht meine baustelle *grins*).
    ab und an war der inhalt korrupt... hat meinen cheffe ne menge arbeit gekostet, das stabil und sicher zu kriegen 8)

  • Ok ok, die Info hab ich nur gebraucht. So kann ich das Layout erstmal ruhigen Gewissens machen. Bei der Programmiererei verzweifle ich dann später. ;)
    Das wird sicher... interessant... :..(


    Bissl ooT:
    Momentan verzweifle ich aber noch bei der blöden ISP-Programmierung. Hab mir ein paar Senoren (Temperatur/Distanzmesser) für meinen Nibo besorgt und hab noch nichtmal eine Zeile geschrieben. Tu mich da argh schwer mit. Und viel finden tu ich auch nicht X(

    end ooT:


    Sry. Giz das ich dich unterschlagen habe. ;) Bin ich zumindest nicht der einzige Atmel'er hier. ;)

    • Offizieller Beitrag
    Zitat

    mit zelle 0 des EEPROMS


    Hatten wir hier auch mal mit den Motorola-Prozessoren. Bei den EMV-Tests wurden stellenweise die ersten Bytes vom internen EEProm zerschossen. Nach Spannungsausfall/-wiederkehr wurden dann falsche Werte verwendet.

    Kurzfristige Abhilfe war: Die ersten Bytes von dem Sch...Ding nicht benutzen.

    Tipp an Andreas bzgl. Speichern von Variablen im EEProm: Ich benutze immer ein separates Byte als "Wegweiser", ob die nachfolgenden Bytes korrekt gespeichert wurden.

    Heißt:
    - Abspeichern von dem Wert "FF" in Zelle 1. "FF" heißt: Da wird gerade herumgebaut.
    - Abspeichern von den ganzen Nutzdaten in den darauffolgenden EEProm-Bytes.
    - Wenn das letzte Nutzbyte geschrieben worden ist: Abspeichern von dem Wert "AA" in Zelle 1. "AA" heißt, dass jetzt die Baustelle geschlossen worden ist und alles in Ordnung ist.

    Beim Starten des Prozessors also erst mal nachsehen, ob in Zelle 1 ein "AA" steht. Wenn nicht, ist vorher irgendwas beim Abspeichern schiefgegangen und die ganzen Nutzbytes sind mir vorsicht zu genießen.

    Warum "AA"? :D Schau Dir mal das Bitmuster von diesem Hexwert an. Das ist ein Schachbrettmuster. Höchst unwahrscheinlich, dass bei einem EMV-Problem ausgerechnet dieses Schachbrett in die EEProm-Zelle geschrieben wird. ;)

    Die andere Alternative wäre die Verwendung von einer Checksumme. Aber nach jeder Änderung den ganzen Summs durchrechnen, das macht keinen Spaß... .