Ich hab mir ein Lauflicht programmiert.
Nur ist das Problem, dass er nur, dass das Licht nur in eine Richtung
läuft und nicht mehr zurück. Am PC hat die Simulation funktioniert.
Ich bin wegen dem Atmega16 verwirrt: bedeutet am PORTx: -5V -> 1
0V -> 0
oder: 5V -> 1
0V -> 0
dann nimmt i nacheinander die Werte
0, 1, 2, 3, 4, 5, 6, 7, 8
an.
i wird zwar 9, aber danach wird abgefragt ob i < 9 ist.
Das ist nicht der Fall und daher wird die Schleife
beendet.
Hast du eine Schleife
1
for(l=9;l>0;l=l-1)//Abzählen der Ports abwärts
2
{
3
PORTB=_BV(l);
4
}
dann nimmt l nacheinander die Werte
9, 8, 7, 6, 5, 4, 3, 2, 1
an.
Danach wird l durch die Subtraktion zu 0. Die darauf folgende
Abfrage l > 0 ergibt false und die Schleife wird beendet.
Aber: Es gibt kein Bit 9 am Port. Die Bits sind von 0 bis
8 durchnummeriert.
Das mit 9 war nur ein Versuch.
Das die Schleife beendet wird ist ja der sinn, dann danch soll die
Schleife beginnen, die in die andere Richtung zählt. Wenn die aus ist,
gibts ja die while(1) Schleife, die das ganze von neu laufen lässt.
Mfg Daniel
Daniel wrote:
> Das mit 9 war nur ein Versuch.>> Das die Schleife beendet wird ist ja der sinn, dann danch soll die> Schleife beginnen, die in die andere Richtung zählt. Wenn die aus ist,> gibts ja die while(1) Schleife, die das ganze von neu laufen lässt.>
Ja, ist schon klar.
Was passiert statt dessen?
Beschreibe bitte genau, was statt dessen passiert
(sonst müsste ich dein Pgm in einen Prozessor brennen
und selbst nachsehen).
Eigentlich muessten Deine "Verzögerungschleifen" sich wegoptimieren.
Wahrscheinlich wird irgenetwas passieren, aber so schnell das Du nichts
siehst.
gruß,
Bjoern
Blinder wrote:
> Eigentlich muessten Deine "Verzögerungschleifen" sich wegoptimieren.> Wahrscheinlich wird irgenetwas passieren, aber so schnell das Du nichts> siehst.>
Ist nicht ganz von der Hand zu weisen :-)
Wenn der Optimizer beim gcc aus ist, dann sollten die
Schleifen erhalten bleiben. Da Daniel noch neu ist, geh
ich mal davon aus, dass er den entsprechenden Schalter noch
nicht gefunden hat.
@ Karl heinz Buchegger
Er zählt nur in eine Richtung, das heißt, dass die Leds nur in eine
Richtung nacheinander leuchten. Dann is aus und es tut sich nichts mehr.
Mfg Daniel
Blinder wrote:
> Der Knackpunkt ist wohl, laut Tutorial:>>> PORTB |= _BV(1) SETZT PortB.1> PORTB &= ~_BV(1) LÖSCHT PortB.1>>
Nein, in dem Fall nicht.
Er weist dem Port immer komplett einen neuen Wert zu.
Das leidige Thema 'Einzelbitsetzen' ist es dadurch nicht.
Ich könnte mir höchstens vorstellen, dass beim
_BV(a)
irgendetwas Grausliches passiert, wenn a ausserhalb des
zulässigen Bereichs 0 bis 7 liegt.
Ansonsten sehe ich nichts Schlimmes in dem Pgm
(ausser dass die #includes nicht gestimmt haben, daher
die Nachfrage nach dem Cut&Paste. Wenn Daniel abgetippt
hat, dann gäbe es theoretisch noch die Möglichkeit dass
er im echten Quelltext irgendwo l mit 1 (das ist: eL mit Eins)
verwechselt hat. l ist ein schlechter Variablenname, da er oft
von 1 nicht zu unterscheiden ist).
@ Karl heinz Buchegger
Ich habe dein Programm jetzt ausprobiert. Leider kommt es aufs gleiche
hinaus. Das Licht lauft nur in eine Richtung.
Ich habe die Ausgänge jetzt nur so beschalten und mit dem Multimeter
gemessen:
1 --> 3,02V
0 --> 0,92V
Ich glaube da stimmt etwas nicht.
Mfg Daniel
Daniel wrote:
> @ Karl heinz Buchegger>> Ich habe dein Programm jetzt ausprobiert. Leider kommt es aufs gleiche> hinaus. Das Licht lauft nur in eine Richtung.
Habs grade in einen Mega16 gebrannt:
funktioniert.
>> Ich habe die Ausgänge jetzt nur so beschalten und mit dem Multimeter> gemessen:> 1 --> 3,02V> 0 --> 0,92V>> Ich glaube da stimmt etwas nicht.
Wie sind deine LED angeschlossen, bzw. welches Board hast du
überhaupt?
Welcher Compiler?
@ Karl heinz Buchegger
Die Leds wurden vor der Messung abgetrennt.
Ich verwende das STK500 Board.
Da die Leds auf dem invertiert sind, sind sie nicht zu gebrauchen.
Deswegen habe ich mir ein eigenes Led Board gebaut.
Wenn keine "Last" am Port ist, tut sich beim Lauflicht Programm nichts:
Am Multimeter werden die 0,9 V gemessen.
Mfg Daniel
Daniel wrote:
> @ Karl heinz Buchegger>> Die Leds wurden vor der Messung abgetrennt.> Ich verwende das STK500 Board.> Da die Leds auf dem invertiert sind, sind sie nicht zu gebrauchen.
Warum nicht?
Alles was du tun musst, ist die Augabe vorher binär
umdrehen:
PORTB = ~( _BV(i) );
und schon leuchtet nur die eine LED.
>> Deswegen habe ich mir ein eigenes Led Board gebaut.>> Wenn keine "Last" am Port ist, tut sich beim Lauflicht Programm nichts:> Am Multimeter werden die 0,9 V gemessen.
Das ist schlecht.
Da sollten entweder 0V oder 5V zu messen sein.
Wenn du da andere Werte hast, könntest du den Port
bereits geschossen haben.
Klemm mal deinen Aufbau ab und arbeite mit den original
STK500 LED.
Wenn du nichts am Pgm veränderst, wandert halt keine LED
sondern eine Lücke. Ist im Moment egal.
Wenns dich stört: Wie gesagt, der ~ Operator dreht sein
Argument bitmässig um: AUs 0 wird 1, aus 1 wird 0
Aus _BV(2)
also 0b00000100
wird dann 0b11111011
und damit leuchtet dann LED #2 und nur die.
Nur um sicher zu gehen:
Klemm mal deinen Zubau ab, wenn du das nächste mal
per ISP programmierst. Beim Mega16 liegen die ISP
Pins am PORTB. Wenn dein Zubau nur brutal genug ist,
dann verhindert er die Neuprogrammierung und du führst
die ganze Zeit ein altes Programm aus.
@ Karl heinz Buchegger
Ich habe den Zubau immer Abgeklemmt, wenn ich den uP Programmiert habe.
Ich habe das mit der Invertierung PORTB = ~( _BV(i) ); programmiert,
aber jetzt leuchten einfach alles Leds auf den STK500 Board.
Ich habe zu dem Board einen Atmega8515 bekommen, und der hat Problemlos
funktioniert.
Jetzt währe das der vierte Atmega16 der nicht in Ordnung ist.
2 haben einen Flashspeicher Fehler
1 hat irgendwas
und derhier hat was mit den Ausgängen.
Ich weiß echt nicht was da nicht stimmt.
Mfg Daniel
Das ist in der Tat eigenartig.
Ich kann aber nur eines sagen.
Das Pgm das ich gepostet habe, habe ich mit
gcc kompiliert und genau so in einen Mega16
der mit 8 Mhz läuft gebrannt.
Das Pgm funktioniert.
Versuch mal ein einfacheres Testprogramm
int main()
{
DDRB = 0xFF;
PORTB = 0x00;
}
jetzt sollten am STK500 alle Led ein sein.
int main()
{
DDRB = 0xFF;
PORTB = 0xFF;
}
jetzt sollten alle aus sein.
Wenn das nicht klappt, hast du entweder einen
Verschaltungsfehler am STK, oder aber der Mega
ist tatsächlich in die ewigen Jagdgründe übergetreten.
Anstatt PORTB würde ich auch mal PORTA oder PORTD
probieren.
BV steht für "Bit Value"
_BV(2) ist also ein Wert, in dem das Bit 2 gesetzt
ist. Realisiert ist das mit einem Makro.
_BV(2) ist identisch zu 0x00000100
die 'ohne Makro'-Standard C-Schreibweise dafür
würde lauten:
1<<2
Ohne jetzt das Makro zu kennen, würde ich mal
sagen, das _BV so implementiert ist
#define _BV(x) ( 1 << (x) )
Daniel wrote:
>> DDRB = 0xFF;> PORTB = 0xFF;>> haben die Leds bischen schwächer geleuchtet.
Bischen schwächer ist schlecht.
Die sollten ratzeputz aus sein.
Was ist auf einem anderen Port?
int main()
{
DDRD = 0xFF;
PORTD = 0xFF;
}
gehen sie da (am Port D) noch aus?
Hintergrund: Es scheint wohl so zu sein, dass der Mega16
nur noch Schrott ist. Um aber voreiligen Schlüssen
vorzubeugen, kannst du mal abchecken, ob nur der
PORTB hinüber ist, oder ob es auch die anderen Ports
erwischt hat.
Allerdings sollte man sich jetzt mal Gedanken darüber
machen, warum der Mega geschrottet ist. Der macht das
ja nicht weil ihm fad war.
@ Karl heinz Buchegger
Die anderen PORTs haben ja auch was, bei PORTA leuchtet eine Led einfach
nicht und bei PORTc tut sich überhaupt nichts.
Aber ich sag ja, der Atmega8515 funktioniert einwandfrei.
Den Atmega16 habe ich von Anfang an mit den board Leds betrieben, erst
vor 2 Tagen habe ich mir das eigen Led Board gebaut.
Und schon von Anfang an haben die Leds etwas gehabt.
Mfg Daniel
Daniel wrote:
> Ich habe zu dem Board einen Atmega8515 bekommen, und der hat Problemlos> funktioniert.>> Jetzt währe das der vierte Atmega16 der nicht in Ordnung ist.> 2 haben einen Flashspeicher Fehler> 1 hat irgendwas> und derhier hat was mit den Ausgängen.
Und Du bist sicher, dass Du im Brennprogramm des AVR-Studios den
richtigen Controllertyp ausgewählt hast?
Ich hatte letztens das Problem, dass sich diese Einstellung ohne mein
Zutun verändert hatte, statt des (von mir eingestellten) Mega8535 war
auf einmal ein ganz anderer Typ eingestellt. Da die Typen
unterschiedlich große Pagen haben gibt es da Ärger.
Desweiteren besteht bei Austausch des Mega8515 und Mega16 noch die
Gefahr, den falschen Sockel des STK500 zu benutzen, denn die Typen sind
nicht pinkompatibel.
...
@ Hannes Lux
Ein freund von mir hat genau das Board mit dem Atmega16 verwendet und
alles hat problemlos fuktioniert.
Bei den EInstellungen habe ich schon oft nachgeschaut, da stimmt alles.
Mfg Daniel
Daniel wrote:
> @ Hannes Lux>> Ein freund von mir hat genau das Board mit dem Atmega16 verwendet und> alles hat problemlos fuktioniert.>> Bei den EInstellungen habe ich schon oft nachgeschaut, da stimmt alles.>> Mfg Daniel
- Reden wir immer noch vom STK500?
- Ist Dir klar, dass der Mega16 nicht in den Sockel gehört, in dem der
Mega8515 war?
...
Daniel wrote:
> @ Karl heinz Buchegger>> Die anderen PORTs haben ja auch was, bei PORTA leuchtet eine Led einfach> nicht und bei PORTc tut sich überhaupt nichts.
...beim M16 sind auf Port C die JTAG-Anschlüsse per Default aktiviert.
Wenn man die per ISP nicht ausschaltet geht der halbe Port "nicht
richtig".
Daniel wrote:
> @ Hannes Lux>> Auf welchen Sockel gehört dann der Atmega16 auf dem STK500?
Auf den, der dafür vorgesehen ist. Wozu gibt es eigentlich ein Handbuch
zum STK500??? - Falls das verlegt sein sollte, findet man diese Info
auch in der Hilfe zum AVR-Studio. Warum liest Du die denn nicht???
>> Die JTAG_Anschlüsse sind abgeschaltet.>> Mfg Daniel
MfG und viel Erfolg,
Hannes
Thread beobachten
Seitenaufteilung abschalten