Bascom BASCOM ; Erste Schritte zum Ausprobieren

Ich würde mal sagen, das ist zu speziell.
Also Eagle auf, selber zeichnen und aus China bestellen.

Edit: weil ausversehen auf senden gekommen.
Aref und Avcc sollten nicht direkt verbunden werden. Aref schon mal nicht weil du dir damit die Möglichkeit nimmst die internen Referenzspannungen zu nutzen. Avcc deswegen nicht, weil VCC halt "noisy" sein kann, sprich nicht so stabil. Das wirkt sich negativ auf die gemessenen Werte aus.
Und 20mA pro LED sind die Maximalwerte. Abhängig davon welche LED du verwendest würdest du entweder erblinden oder dein ganzes Zimmer ausleuchten ;)
Ja, etwas übertrieben, aber so macht man die LEDs halt etwas dunkler. Netter Nebeneffekt hierbei: Die halten so länger.
 
Zuletzt bearbeitet:
Ich meine nicht Aref (gar kein Anschluss) sondern Avcc und Vcc, die sind doch alle an +5V angeschlossen siehe Schaltplan (überall so zu sehen).
 

Anhänge

  • AVR-P28-sch.gif
    AVR-P28-sch.gif
    26,1 KB · Aufrufe: 6
Ja, der braucht auch VCC*. Aber du kannst ja 2 getrennte Stromversorgungen haben, einen Last- und einen Messteil. Wie man das nun umsetzt sei dahingestellt. Manche entkoppeln das auch mit einer Spule, um Spikes zu lindern. Gibt viele Möglichkeiten. Wobei ob das bei "nur" 10 Bit Auflösung so wichtig ist sei dahin gestellt. Kommt drauf an wie sauber VCC ist und wie genau du messen willst.
 
Da kann ich ja getrost mein Atmega8 Board nehmen und eventuell eine Adapter Platine mit fertigen LED's anfertigen.
Jetzt mach ich mir erstmal ein paar Gedanken zur Ampel Schaltung.
 
Du kannst es ja auch erst mal mit Wait machen. Ist zwar unschön, aber aufräumen kann man später ja noch, wenn das geht :)
Da kommt denn nämlich noch ein neuer Schritt dazu den wir hier (glaube ich) noch nicht hatten.
 
Das wäre jetzt ein Ampel Code mit Waitms
$regfile = "m8def.dat"
$crystal = 1000000
Config Porta = Output
Rot Alias Portd.7
Gelb Alias Portd.6
Gruen Alias Portd.5
Do
Rot = 1
Gelb = 0
Gruen = 0
Wait 10
Rot = 1
Gelb = 1
Gruen = 0
Waitms 500
Rot = 0
Gelb = 0
Gruen = 1
Wait 10
Rot = 0
Gelb = 1
Gruen = 1
Waitms 500
Rot = 0
Gelb = 1
Gruen = 0
Waitms 500
Loop
End
 
Warum setzt du PortA als Output, nutzt aber PortD? ;)
Und ziemlich kurze Grünphase, wenn auch gefühlt realistisch :D
Ansonsten sieht es gut aus.

Was wir jetzt noch brauchen ist ein Timer. Die Sache mit der 1 Sekunde, was später die WaitMS "ersetzt".
 
Das ist die Sache mit dem TIFR. Also
If Tifr.tov1 = 1 Then
Set Tifr.tov1
Incr Z
Elseif Z = 245 Then
Z = 0
Toggle Gruen
End If
, welches wir auf Seite 7-8 schon hatten.
 
Nochmal ein paar Anmerkungen zu den Entwicklungsboards:
Bei einigen (zB dem STK500, dem STK600 aber auch dem von Pollin und anderen ähnlichen) ist bereits der Programmer mit drauf - bei anderen nicht.

Beim STK500 entspricht dieser einem STK200 - Boards die sich als STK500-kompatibel bezeichnen sind also eigentlich kompatibel zum STK200. Das 500er generiert aber zusätzlich eine einstellbare Versorgungsspannung, eine einstellbare Referenzspannung (die Präzision sei mal dahingestellt), und einen einstellbaren Takt (der als Takt des Targets verwendet werden kann, aber eben auch für alles mögliche andere). Einstellbar alles 'per Software - entweder aus dem AtmelStudio heraus, oder eben auch über mein Programm.

Grundsätzlich empfiehlt jedes Controllerdatenblatt, alle Stromversorgungsbein-paare mit einem Keramikkondensator (100nF) zu puffern (und zwar möglichst dicht an den Beinen, die sind nicht umsonst immer nebeneinander). Warum diese bei einigen Boards eingespart werden ist mir schleierhaft - an den Kosten kann es ja eigentlich nicht liegen (Centbruchteile).
Analoge Stromversorgungsbein-Paare sind auch immer zu beschalten (also zu versorgen). Sollen die entsprechenden analogen Funktionen genutzt werden, ist ein Hardware-Tiefpaß empfohlen (L-C- oder zumindest R-C-Tiefpaß, wobei der C ja bereits im vorhergehenden Absatz steht, also lediglich noch'ne Drossel oder 'n Widerstand zwischen Vcc und AVcc planen. Muß ja nicht unbedingt bestückt werden (dann eben mit'ner Drahtbrücke oder 'nem Jumper/Dip-Schalter überbrückt), aber so hast Du die Möglichkeit, den Tiefpaß einzubauen, wenn er gebraucht werden sollte. Auf der anderen Seite kostet Dich die Drossel auch nicht wirklich mehr...

Warum der Tiefpaß? Es geht weniger um das wegpuffern von externen Störungen, als vielmehr um welche, die der Controller selbst erzeugt. Das ist ja ein getaktetes digitales Bauteil.

Aref ist grundsätzlich nicht extern mit (A)Vcc zu verbinden - wenn gegen (A)Vcc gemessen werden soll, kann das auch intern über den Referenz-Multiplexer geschehen. Auch Aref sollte mit einem 100nF-Kerko gegen Gnd gepuffert werden.
Bei kleineren Controllern ist Aref 'ne Alternativfunktion, hier sollte man sich die Verwendung der anderen Alternativen freihalten...

Beschaltung des Reset-Einganges: Meiner Meinung nach ist die Entprellung hier unnötig - der Controller selbst besitzt quasi 'n internen Software(?)tiefpaß...
Aber je nach Layout könnte der interne Pullup zu schwach sein.

LEDs: beim STK500 gibt es acht LEDs. Diese werden selbst immer über 5V versorgt. Angesteuert werden sie über eine Transistor-Treiberstufe - die Spannung des Target-Bereiches kann also auf 1,8V oder so runtergeschraubt werden, falls gewünscht.
Ähnlich ist es bei den Tastern (Pullups).
Taster und LEDs können flexibel mit den nötigen Controllerbeinen verbunden werden.

Soll ein I²C-Anschluß auf dem Board vorgesehen werden, würde ich einen Leveltranslator einplanen. Entweder als IC, oder als diskrete Schaltung (zwei MOSFETs und etwas Hühnerfutter) (Je nachdem, was da angebunden werden soll, wirst Du unterschiedliche Spannungen brauchen).

LCD: wäre ein weites Feld - 4Bit-/8Bit-parallel, über irgendein Schieberegister-IC (SPI/TWI), über UART hab ich auch schon mal was gesehen... oder Displays, die nativ TWI/SPI können (EA-Displays, oder die OLEDs zB)...
 
Im Prinzip reicht mein Atmega8 Board vollkommen aus. Mich hatte nur die Verkabelung bei einem LCD gestört, dass ich aber vorerst beiseite lege.
Der Schaltplan von mir weiter oben, hat ein 3,3V mit der ich nichts anzufangen weiß. Ebenso die rote LED mit Jamper.
Danke für die ausführliche Anweisung.
 
Richtig, das mit TIFR. Das wäre aber die Polling Variante.
Ich dachte jetzt eher an die Interrupt Variante die wir zuletzt hatten ;)
 
Ja, da haben wir es wieder. Jetzt müsste ich wieder ein bisschen abschreiben, denn aus dem stehgreif kann ich das noch nicht so.
Aber ich werde mir mal Mühe geben.
 
Glaub mir, aus dem Stehgreif kann ich das auch nicht, weder in Bascom (weil ich es zu selten nutze), noch in Assembler. Da brauche ich auch immer das Datenblatt für. In LunaAVR schreibe ich auch nicht blind ;)
 
Ich habe ja noch die vorherigen Seiten.

Ddrc = &B_11_1111
Portc = &B00_0000
Gruen Alias PortC.3
Config Timer2 = Ctc, Prescale = 256, clear_timer1 = 1

Ctc und clear_timer1=1 brauche ich noch einmal eine Erklärung.
 
Der Timer/Counter ist eigentlich ein ganz einfaches Bauteil, bzw. hier Komponente im AVR.
Prinzipiell kann er nur hoch zählen (unter manchen Konditionen auch runter).
Aber er ist sehr flexibel.
Du kannst festlegen wie er getaktet wird (extern, intern, CPU Clock), und dann auch noch ob ein Vorteiler zum verlangsamen vorgeschaltet werden soll.
Auch hast du mehrere Arten sein Verhalten zu ändern.
Normal zählt er von 0 bis zum Maximum. Das Maximum wird von der Bittiefe definiert, typisch 255 (8 Bit) oder 65535 (16 Bit). Kommt ein Tick mehr springt er wieder auf 0 -> Overflow Interrupt.
PWM kann Interrupts auslösen wenn ein gewisser Wert erreicht ist (Compare), aber auch direkt gewisse IO Pins setzen, zurücksetzen oder toggeln (nur OC?A und OC?B Pins, ? ist die Nummer des Timers). Hier gibt es jetzt noch Phasenkorrektes PWM (der Timer zählt hoch, dann wieder runter) und Fast PWM, wo er nur hoch zählt.
CTC ist eigentlich identisch zum normalem Mode, jedoch gibst du hier einen Maximalwert vor, sprich er läuft nicht bei 255 über (8 Bit) sondern beim Wert den du vorgegeben hast (OCR?). Da hier der Timer nicht wirklich überläuft hast du aber einen anderen Interrupt dafür (Compare). Trotzdem, ist der eingestellte Wert erreicht und es kommt noch ein Tick ist er wieder auf 0.

Grob war es das schon.

zu clear_timer1 = 1 kann ich nur spekulieren.
Ich vermute mal dass der ein oder andere Chip dann Timer1 zurück setzen kann wenn Timer2 überläuft, ich glaube der Mega8 gehört nicht mit dazu, die 48 Serie meine ich auch nicht. Wäre auf jeden Fall für den Frequenzzähler ein unerwünschtes Verhalten, daher müsste es =0 sein.
 
Clear_timer1 =1 hatten wir in #528 schon mal. Was passiert, wenn man dieses Clear_timer1 weg lässt? Probiert habe ich es noch nicht.
 
Weiß ich nicht, müsste ich auch ausprobieren. Im Zweifelsfall clear_timer1 = 0
 
Der Parameter ist zumindest in der Onlinehilfe nicht erklärt (taucht dort aber auf). Interessanterweise kann dort Timer2 auch nur entweder auf "Timer" oder auf "PWM" konfiguriert werden (und nicht auf CTC). Möglicherweise findet sich irgendwo in den Tiefen der eingebundenen konkreten Definitionsdatei ($regfile...) 'ne Auflistung aller zulässigen Modi (dieses konkreten Controllers - wäre zumindest logisch).

Clear_Timer scheint ein Switch zu sein, der den CTC aktiviert oder eben nicht. Die ganze Config-Timer-Geschichte stammt aus Zeiten, als nur bestimmte Timer bestimmte (wenige) modi unterstützten - inzwischen können die meisten Timer CTC, und davon sogar mehrere verschiedene.

CTC steht für Clear Timer on Compare match (Lösche/Setze den Timer auf '0' zurück bei einem Compare-Ereignis). Dieses Compare-Ereignis war früher immer das Compare Register A (also wenn TCNT=OCRA). Bei einigen Controllern kann man stattdessen aber auch das Input-Capture Register (ICR) verwenden (dadurch bleiben beide PWM-Kanäle nutzbar und man kann trotzdem die Frequenz anpassen) - bei anderen Controllern gibt es gar drei PWM-Kanäle, und ein viertes Compare-Register nur für "CTC".
Ich meine auch schon irgendwo ein Datenblatt gelesen zu haben, wo das Register dann gar nicht mehr OCRx hieß...

Wenns also spezieller werden soll, ist man auf der sicheren Seite, wenn man auf Config Timer komplett verzichtet, und stattdessen selbst die Bits für die paar Register zusammensucht - Thomas hats mit der Flexibilität in #656 ja angedeutet. Du brauchst einen bestimmten Modus für einen Timer in einem bestimmten Controller: Du schaust im Datenblatt, welche Bits in welchem Register zu beschreiben sind, und übernimmst das in den Code.

Bascom findet in der eingebundenen Definitionsdatei ($regfile) die Adressen der Registernamen und Werte der Bitnamen, Du kannst also Register- und Bitnamen aus dem Datenblatt verwenden...

P.S. @TommyB : Bascom kennt die Assembler-typische Schreibweise mit den geschobenen Bits nicht - muß man als Konstante berechnen lassen, also "(Bit1^2)+(Bit2^2)..." statt "(1<<Bit1)|(1<<Bit2)" - rein rechnerisch steckt dasselbe dahinter...

Möglicherweise wäre 'ne Subroutine/Makro interessant, mit der man Bits in einem I/O-Register löschen und/oder setzen kann. Aber da wär ja sowas wie 'ne überladene Routine (also mit variabel vielen Parametern) nötig - bei VB geht das, aber ob Bascom das kann?

Also quasi so wie auch beim Config Timer, wo eben nicht alle Parameter mit angegeben werden müssen. Dann wäre sowas wie "SetBitsInIoRegister (Register, [Bit],[Bit]...)", "ClearBitsInIoRegister(...)" und "WriteBitsToIoRegister(Register, [Bit=1/0],[Bit=1/0])" vorstellbar.

Bascom selbst bietet Peek und Poke (als äquivalent zu In bzw Out) für die ersten 32 I/Os, sowie INP und OUT zum Zugriff auf den "gesamten" SRAM (also quasi LD und ST in allen Variationen).
 
Ja, das sind so die Gründe warum ich Assembler anrate, da lernt man die Hardware besser kennen.
Schlechte und unvollständige Dokumentation der Hochsprachen und teilweise auch Programmierfehler darin... Bei Luna auch schon erlebt.
Aber das Thema hatten wir ja hier schon mal. Ich finds nur grad nicht.
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)