C-Programmierung

    • Offizieller Beitrag

    nur mal so am rande

    Zitat

    und muss nicht erst das Bit0 setzen/löschen und 5 mal shiften, bis es an der richtigen Position ist.


    das macht nicht der µC, sondern der PreProzessor des Compilers!
    Die Schiebereien kosten weder Speicherplatz, noch Rechenleistung

    ANSI-C kennt ausserdem keine "Bit-Befehle"!
    Ob Bitbefehle verwendet werden können , hängt vom jeweiligen Compiler ab.

    Wenn du den Compiler (selbst eine neuere Version des Compilers reicht manchmal aus) wechselst, können bei Verwendung von nicht-ANSI-Befehlen seeeeehr interessante Dinge passieren ...


    8)8)8)

    • Offizieller Beitrag
    Zitat

    das macht nicht der µC, sondern der PreProzessor des Compilers!


    Das war mir schon klar. ;) Aber einerseits schreibe ich mir in den Programmen einen Wolf mit vielen Kommentaren, damit ich die Funktionsweise auch nach Jahren noch verstehe und nachvollziehen kann, und dann sagt man statt "Setze Bit 5" "Nehme eine 1, setze sie auf Bit 0, shifte sie 5 mal nach links"... :rolleyes:
    Von der Definition her könnt ihr alle Recht haben, aber leserlicher ist es, wenn ich hinschreibe, was ich will.

    Ok, ich weis,... C ist ein Hochsprachen-Assembler. :D

    Zitat

    Wenn du den Compiler (selbst eine neuere Version des Compilers reicht manchmal aus) wechselst, können bei Verwendung von nicht-ANSI-Befehlen seeeeehr interessante Dinge passieren ...


    Kann bei den Atmels sein, kann ich nicht beurteilen. Bei den PICs aber absolut ausgeschlossen, weil der Prozessor mit 33 Befehlen auskommt. Und die sind so festgelegt, dass man mit einem einzigen Taktzyklus einen Port setzen oder löschen kann. Also nichts mit "&" / "|" , bevor der Port endlich wackelt. Es wäre bei dieser Prozessorfamilie völliger Quatsch, den C-Compiler so zu vergewaltigen, damit man nur noch über die ANSI-Methode den Vorteil des RISC-Prozessors ausnutzen kann.

    Ich will hier an dieser Stelle keinen Glaubenskrieg auslösen. Es gibt Leute, die haben das gelernt und andere sind eben "angelernt". => Hauptsache man kann den Code lesen, verstehen und... es funktioniert. Auch dauerhaft und in ein paar Jahren noch.

    • Offizieller Beitrag

    Replikator: Bin ich da jetzt in einer "Bringschuld" oder ist das Thema anderweitig eingeschlafen?
    => Gib bescheid, wenn Du wieder "Input" brauchst oder Fragen hast, damit Deine Software per Funk den Bot steuern kann.

    Eingeschlafen auf keinen Fall! Bin auch schon damit angefangen die look-up-Tabelle einzufügen. Die "Verknüpfung" zwischen ausgerechneten Wert und Tabelle ist mir nur noch nicht so ganz klar.

    Weil es gerade etwas ruhiger darum geworden ist liegt daran, das ich im Mom. eine ganze Menge zu pauken habe... Physik suckt...
    Lerne im Mom auch auf der Arbeit in den Pausen, in der Zeit, wo ich normalerweise progge... Und am WE kümmere ich mich um meinen Rappi. Eine Woche noch "aufgeregtist".


    Ich hoffe ja auf Montag (evt. Urlaub) und Dienstag. Da hab ich wohl Zeit. :)

    • Offizieller Beitrag

    Ich hab hier mal kurz aus meiner Studienarbeit was rauskopiert. Vielleicht hilft es ja wenn du wieder dazu kommst... :]

    Zugriff auf die LUT geht dann so:

    Hi,

    nach wiedermal langer zwangs-Programmierpause (-_-) bin ich nun wieder dabei, an den uCs zu verzweifeln. ;)

    Also bevor ich nun das Projekt Eigenbau-Fahrtregler weiter angehen kann, hab ich vorerst noch eine andere Baustelle, meine IR-Endschalter! Ist im Mom halt wichtiger. Das nächste Event rückt wieder in großen Schritten näher und im Mom baue ich meinen LJ neu zusammen! Nun fehlen mir halt wieder geeignete Endschalter. So hab ich also meine alte Version eingemottet (hab da ja so viele Fehler implementiert ;) ). Die neue Version liegt jetzt vor mir und ist schon um einiges besser geworden, sogar das ISP funzt nun, da ich jetzt einen größeren uC (Attiny 24-20SSU) verwende und die ISP-Eingänge jetzt nur für ISP genutzt werden!!

    Nun kommts, das Teil lässt sich sogar per ISP proggen!!

    ABER dann fängt es auch schon wieder an:

    Um meine Ausgänge erst einmal zu testen, hab ich ein hochkomplexes Programm entworfen:


    Sry für die doofe Darstellung, hoffe man kann es nachvollziehen.


    So, nun spiele ich das Programm per AVR-Studio und ISP in meinen Endschalter rein und dann passiert folgendes:

    Wenn das Programm drin ist leuchtet wahlweise:
    - keine LED
    - eine LED
    - die andere LED
    - beide LEDs
    - Eine LED blinkt
    - die andere LED blinkt
    - die blaue LED glimmt nur leicht
    - BEIDE BLINKEN Wuhuuu!!
    - ...

    Ich programmiere ein und das selbe Programm ein. Aktiviert ist die Option "erase Device bevor programming"

    Nun meine Frage Wieso??!?!

    Mein Bruder der, wie er selber sagt, nur die Dinge aus Software-Programmierer-Sicht sieht sagte:
    Man verschiebt ja nur ein Bit um zwei Stellen, aber was steht denn wo vorher drin."
    Irgendwo im uC steht wohl irgendwelcher Datenmüll, denn man dann verschiebt...

    Kann das sein?
    Ich meine ich habe bislang alles (bei meinem NiBo, etc) in dieser Form programmiert. Und das klappt ja... Also hat wer ne Idee was ich falsch gemacht habe??

    • Offizieller Beitrag

    Wie früher schon mal geschrieben, ist die Ansteuerung mit den Shift-Befehlen für mich zwar etwas "eigenartig", aber nach meiner Ansicht ist die Arbeitsschleife korrekt.

    Du müsstest nochmal die Initialisierung der beiden Ports anschauen. Da ist nach meiner Ansicht etwas inkonsistent.

    Zunächst mal die Gewissensfrage: Werden die Eingänge oder Ausgänge durch eine "1" im Daten-Direction-Register definiert? (Beim PIC ist eine "1" ein Eingang, beim Motorola ein Ausgang; als je nach Hersteller verschieden => wie macht's der AVR?).
    Bei den Pull-Ups hast Du wohl einen Knopf drin, denn auch die Ausgänge belegst Du mit Pull-Ups (?)

    PortA = 0x67 ; Der "7" sagt, dass Bit0, Bit1 und Bit2 einen Pullup kriegen? Aber Bit0 ist ein Ausgang, während der Rest ein Eingang ist. (?)
    Mit dem Befehl "PortA = 0x67" hätte ich eher gemeint, dass die Ausgangsports gesetzt werden, als dass hier PullUps gesetzt werden. (?)

    Wenn Du hier nicht weiterkommst, würde ich das Programm mal ganz primitiv schreiben. Also ohne, dass der Compiler hier shiften, unden und odern muss. Einfach ganz hart in der Arbeitsschleife setzen:
    PORTA = 0x00;
    _delay;
    PORTA = 0x03;
    _delay;

    Dann siehst Du ja, ob's geht. Wenn ja, dann braucht der Compiler wohl noch irgendeinen Hinweis, was er denn im RAM als temporäre Hilfsvariable benutzen darf, um die ganze Shifterei, Underei und Oderei zwischendrin ausrechnen zu können.

    Hi, vielen Dank für die Schnelle Hilfe!

    Also erstmal, hast Recht! Da hab ich einen Zahlendreher drin gehabt...! Sollte eigendlich PORTA = 0x76 heißen...

    Aber Generell mal ne Frage die ISP-Ein/Ausgänge, wie definiere ich die am besten? Eingang, Ausgang, oder ist das egal??


    Dann hab ich mal das Datenbuch gewälzt:

    Zitat

    The DDxn bit in the DDRx Register selects the direction of this pin. If DDxn is written logic one,
    Pxn is configured as an output pin. If DDxn is written logic zero, Pxn is configured as an input
    pin.


    Pullups, sowie Ports werden doch mit dem Befehl PORTx =0x.. gesetzt.
    Kommt doch nur darauf an, als was du diese Definiert hast, Ein- oder Ausgang.

    Hier von Mikrocontroller.net:

    Zitat

    PORTx:

    Datenregister für Portx.

    Dieses Register wird verwendet, um die Ausgänge eines Ports anzusteuern. Bei Pins, die mittels DDRx auf Eingang geschaltet wurden, können über PORTx die internen Pull-Up Widerstände aktiviert oder deaktiviert werden (1 = aktiv).


    Dein Tipp mit den anderen Befehlen hat leider auch keine Änderung gebracht. MENSCH voran kann sowas nun wieder liegen oO Ich und uC, da passieren immer die dollsten Sachen... :..(

    Kann Hardware-mäßig noch was Faul sein?


    Nur so Nebenbei, wo wir schonmal beim Thema sind. Hab mir meinen Lightcontroller neu Aufgebaut, diesesmal aber mit einem kleinen Step-Up-Converter für die "Lastseite". Hab den selber ausgelegt und wisst ihr was?? Der tut!!! Aaaaaaaber auf mal kann ich den sch**** uC nicht mehr proggen, da der AVRMKII nur ne Fehlermeldung ausgibt... Hatte anfangs auch einen kleinen Dreher bei den ISP-Anschlüssen *seufz* hab ich nun aber beseitig aber dennoch lässt sich das blöde Teil nicht proggen. Hab diese Schaltung mit diesem uC schon vier mal aufgebaut gehabt bislang und nun funzts nicht...

    Ich hasse uCs... (und uCs hassen mich...)

    • Offizieller Beitrag
    Zitat

    Ich hasse uCs... (und uCs hassen mich...)


    Ganz ruhig *MiezMiez* Das ist doch alles ganz normal, dass es anfangs nicht sauber läuft. Gehört zum Job. (Die Hälfte von meinem Gehalt ist schließlich auch Schmerzensgeld)

    Am Besten ist immer, wenn man mit ganz kleinen Einheiten bei der Hardware anfängt. Und die Software dann mitwachsen lässt.

    Also, woran kann es scheitern, wenn ein Programm, das immer gleich formuliert ist, herumspringt wie ein junger Geisbock:

    - Spannungsversorgung des uC
    - Spannungen an den Eingängen
    - Frequenz von dem uC: Quarz/Resonater/interner RC
    - zu wenig Angst-Kondensatoren

    Somit bitte mal checken:
    - Liegen an den Pins des uC auch wirklich die 5V an?
    - Hat der uC noch mehr Anschlüsse, die mit GND oder gar +5V belegt sein müssen und wurde das übersehen?
    - Hast Du bei den Spannungsanschlüssen auch tatsächlich einen Angst-Kondensator mit ca. 100nF dran?
    - Die Ausgangsspannung der Port von den (angeblich) gesetzten LEDs messen. Sind das wirklich 0 (bis 0.2V) bzw. mehr als 4.2V bei High?
    - Die Quarzfrequenz messen. Ist der Quarz richtig angelötet? Schwingt der Eumel auch sauber?

    Wegen Quarz:
    Ich steige jetzt ja auch auf eine andere Prozessorgeneration um. Der hat einen internen Oszillator (so wie die PIC12F629 von Deinen Ant-Minifahrtreglern).
    Ist bei der Initialisierung des AVR vielleicht irgendwas noch zu tun, damit der weis, dass er einen externen Quarz benutzen muss? Oder ist das generell der Fall und der muss per Initialisierungskommando auf einen intern RC-Oszillator umgestellt werden?
    => Vielleicht liegt da noch der Hund begraben, dass der AVR nicht sauber anläuft und deshalb mal bei 0 oder 1 an den Ausgängen stehenbleibt.

    Hi,

    hab ein wenig weiter probiert und zu deinen Fragen:
    Jo, Angstkondi ist drauf, Spannungen stimmen auch alle und der hat nur einen VCC/Gnd-Anschluss

    Hab dann mal einen Arbeitskollegen gefragt, der hat mich auf die Idee gebracht, das vlt. etwas mit der Delay-Funktion nicht stimmt. z.B. woher weiß der welche Frequenz der uC hat etc.

    Übrigens, ich nutze den Internen RC- Oszi. Der hat 8Mhz.
    Hab kein Platz für einen externen! Die Endschalter haben die gleiche Größe, wie die mechanischen Dinger, und darauf ist ein 20pin uC, ein Relais und diverse Peripherie! :)

    In den Fuses ist vom Werk aus der /8 Divider eingestellt.
    Den hab ich einfach aus Spaß mal deaktiviert und diesen Effekt gehabt:
    Ich progge das Teil und die LEDs blinken nicht mit 0,5Hz sondern im Prinzip 8 Mal schneller!
    ABER: egal wie oft ich das Teil progge, ich habe immer das gleiche Verhalten! Ich kann die Zeiten umstellen und der macht das einfach!
    Hab die IR-LED noch dazugeschaltet und siehe da, auch die kann blinken!!! :D

    Also wie ich das sehe, ist mein blöder Endschalter doch Einsatzbereit und ich kann mit dem Proggen anfangen!!

    Wie ich sagte, ich hasse uCs/proggen, solche Effekte immer... ;)


    Bei meinem Lightcontroller werde ich als nächsten Schritt mal den uC wechseln. Ich schätze durch meine vertauschten ISP-Anschlüsse hab ich dem die Bits weggesprengt... Anders kann ich mir das nicht erklären. Wie gesagt, die Schaltung hab ich ja schon öfters so verwendet.
    Wie das passieren kann? Hab die ISP-Anschlüsse nach dem Schaltplan des Open-Source-Projektes übernommen und dort hat der die Anschlüsse anders belegt... warum auch immer... Naja im Endeffekt mein Fehler, wusste das eigendlich...

    Aber Danke für deine Hilfe erstmal (weitere Probleme werden zweifelsohne dazukommen)!


    EDIT:
    So der nächste Fehler hat nicht lange auf sich warten lassen, mein Relaise hat das "Blinken" noch nicht gelernt.
    Naja, wenn man die Freilaufdiode des Relais verpolt... ;) Na gut somit sind alle meine Ausgänge getestet und es kann los gehen!

    Einmal editiert, zuletzt von Replikator (10. August 2012 um 13:00)

    Hi,

    ein sehr Erfolgreiches Wochenende liegt hinter mir!

    Ich bin angefangen meinen IR-Endschalter zu proggen und bin meiner Meinung schon recht weit voran geschritten.

    Ansich funktioniert er schon. Nur jetzt geht die eigentliche Programmiererei erst richtig los. Wie reagiert der Endschalter nur auf die IR-LED! :)

    Habe vor diese zu Pulsen und dann auf gerade diese Pulse zu warten. Nur wie genau ich das machen muss weiß ich leider noch nicht. :D Mal sehn!

    Hier erstmal ein kleines Video von der bisherigen Funktion. :)

    http://www.youtube.com/watch?v=n4ww_2IrTmc&feature=youtu.be


    Mein Lightcontroller ist auch Einsatzbereit, aber dazu mehr im anderen Tread!


    Für die die es interessiert, mein momentanes Programm findet ihr im Anhang. :)

    Einmal editiert, zuletzt von Replikator (12. August 2012 um 21:43)

    • Offizieller Beitrag
    Zitat

    Ich schätze durch meine vertauschten ISP-Anschlüsse hab ich dem die Bits weggesprengt... Anders kann ich mir das nicht erklären.


    Normalerweise geht man nicht mit "Volldampf", also den 5V auf einen Eingang, sondern benutzt immer einen Vorwiderstand.
    Der ist sinnvollerweise so dimensioniert, dass er maximal den Strom so begrenzt, wie es das Prozessorbit bei einem Ausgang gerade noch schaffen würde.
    Oder: Ganz einfach die üblichen 4.7kOHm als Pullup verwenden. Dann passiert auch nichts, wenn der Prozessorpin sagt "ich bin ein Ausgang und möchte low" und Du gibst ihm aber eine "high" an dem Pin vor. ;)

    Hi,

    es gibt Neuigkeiten von der FR-Programmier-Front!

    Letzte Woche ist es doch tatsächlich passiert, das ich meine Bee per Fernsteuerung durchs Haus jagen konnte!! ;) ;) ;) ;)

    Ich hatte noch zwei, drei Kleinigkeiten zu beheben.
    Eine Variable war wieder falsch deklariert und die Werte aus Reiners Look-Up-Tabelle passten nicht zu meinem eigestellten Timer. ;)
    Verwende den Timer als 10bit-PWM-Timer, deine Werte waren aber nur 8bit... Bis ich darauf gekommen bin, das sich vlt. deshalb nichts/nicht viel bewegt... :D

    Aber das Ergebniss nach reichlichem Kopfzerbrechen:

    http://www.youtube.com/watch?v=9cnHzj…=1&feature=plcp

    Nur als Schaukampfbot taugt der Kleine wie man sieht noch nicht ganz. :D


    Mein nächstes Elektronik-Projekt sollte somit wohl klar sein... ;)

    Wobei ich schwanke zwischen

    - einem experimentier-Fahrtregler (mir schweben da so ein paar Extras vor, für die ihr mich wohl für verrückt halten werdet..)

    - und einer NiboBee-Erweiterung, mit vielen Sensoren, unnötigen Extra-Funktionen und vor allem die Möglichkeit mal mit dem I²C-Bus zu hantieren/programmieren...


    Mal schauen, mich hats grad echt gepackt mit dem Proggen, nach den Teil- / Erfolgen meines IR-Endschalters und der Bee :D


    Auf jeden Fall hier nochmal vielen Dank für die Unterstützung, besonders an Reiner für dein "Anschauungsprogramm" ;)