Ahoi!
Ich steige grad in C /(für AVR) ein, und da ich das letzte Mal einen
Makefile error gehabt habe, hat mir jmd. empfohlen n neuen Order mit
ner angepassten Makefile und ner leeren c-Datei zu machen.
Ok. Hab ich getan, allerdings kommt jetzt dieser Fehler:
Linking: test.elf
avr-gcc -mmcu=atmega8 -I. -gstabs -Os -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=test.o -std=gnu99
-Wp,-M,-MP,-MT,test.o,-MF,.dep/test.elf.d test.o --output test.elf
-Wl,-Map=test.map,--cref -lm
C:/WinAVR/bin/../lib/gcc/avr/3.4.1/../../../../avr/lib/avr4/crtm8.o(.ini
t9+0x0):
undefined reference to `main'
make.exe: *** [test.elf] Error 1
Das Target = main in der Makefile wurde auf Target = test gesetzt.
Muss ich da doch eine
void main()
{
}
machen?
#grs
Juhuuu es kompiliert
Also ich hab jetzt folgenden source:
#include <avr/io.h>
#define LED PB0
#define PORTLED DDRB
int main(void)
{
PORTLED |= (1<<LED);
PORTB |= (1<<LED);
for(;;)
{
PORTB &= ~(1<<LED);
}
}
Den kann ich wunderbar compilen, doch wenn ich die .hex auf meinen
ATMEga8 laden will (ich nehme yaap) will der eine .prj
Wie bekomm ich die?
#grs
Da fehlen zwei Zeilen:
PORTLED |= (1 << LED2);
PORTLED |= (1 << LED3);
"Das geht nicht" ist aber wirklich keine gute Fehlerbeschreibung.
Bitte beschreib nächstes Mal den Fehler genauer (was erwartest du? was
passiert stattdessen? Bei Fehlermeldungen hilft Copy&Paste).
Ach, die Endlosschleife macht übrigens nichts außer alle drei LEDs für
immer abzuschalten.
Aber da du nicht geschrieben hast was du willst, geh ich mal davon aus,
dass du genau das bewusst bezweckt hast.
nene die schaltet die für "immer" an
Und den Fehler von Chris hab ich auch schon entdeckt.
Mein Fehler war das ich den chip nicht vorher "erased" habe
#grs
> nene die schaltet die für "immer" an
Ich bleibe bei meiner Meinung.
PORTB &= ~(1<<LED1);
In dem Fall bleiben alle Bits unangetastet außer dem letzten, das auf 0
gesetzt wird. Da du das mit allen 3 LED-Bits machst, sind am Ende alle
Bits auf 0.
Logisch betrachtet sind die LEDs damit "aus". Wie das in deiner
Schaltung aussieht, ist natürlich eine andere Frage (dazu hast du aber
auch keine Infos gegeben).
Bei einzelnen (lowcurrent-)LEDs ist es eh IMHO sinnvoller, die gegen
Masse zu schalten, sodass ein 1-Bit eine LED anschaltet.
Ein ATmega8 hat genau so gute source- wie sink-Fähigkeiten, deswegen
musst du keine Sorge haben den zu überlasten.
p.s.: Warum kann man hier keine Beiträge editieren? :/
also die sind auch gg. Masse geschalten.
Ups hab ich das etwa vergessen zu erwähnen?
Und es sind sogar ultrahelle LEDs und es tut trotzdem
Zu meinem endgültigen Glück fehlt mir, dass ich die Dinger jetzt noch
dimmen kann (ob mit HardwarePWM oder Software~ ist mir wurschd)
Hat da einer ne Idee?
#grs
Die Idee hast du doch schon selbst genannt? Tut mir Leid, aber ich
versteh deine Frage nicht ganz.
Eine Idee ist nunmal keine fertige, ausprogrammierte Lösung.
@Chris,
"Bei einzelnen (lowcurrent-)LEDs ist es eh IMHO sinnvoller, die gegen
Masse zu schalten, sodass ein 1-Bit eine LED anschaltet."
Und warum ?
Es ist doch nur eine Ansichtsache, welcher Pegel eine LED anschaltet.
Dagegen ist es bei vielen LEDs nötig, jeweils die eine Hälfte gegen VCC
und die andere gegen GND zu schalten, wenn man die maximale
Strombelastbarkeit des MC ausschöpfen wil.
Peter
> Es ist doch nur eine Ansichtsache, welcher Pegel eine LED anschaltet.
Natürlich. :-)
Mit "sinnvoller" meinte ich hier nur, dass es für viele Leute
logischer erscheint, wenn eine LED bei einem 1-Bit leuchtet und bei
einem 0-Bit nicht.
Das macht prinzipiell natürlich keinen Unterschied. Es gibt bestimmt
viele Personen, die 0 == Leuchten logischer finden (z.B. wg.
Vorwissen).
Eine eigene Frage?
Dieser Thread ist über 21 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.