PIC oder Atmel? Aller Anfang ist schwer...

[ptlbahn]

Ich habe auch bestimmte Bausteine, die ich immer wieder nutze.
Sicher, wenn man Programme vergleicht, die die Inclueddatei nutzen, ist es leichter diese zu lesen. Aber wer nicht weiß, was in der Incluiddatei steht, der hat es dann auch schwer, bzuw muß diese erst noch zusätzlich studieren!
Und dann kommt noch dazu, das dort teilweise wahre Abkürzungsmonster drin stehen, und wenn man sich da verschreibt, läuft das Programm auch nicht (bzw der Compiler streikt).
Und wenn es dann noch an einem ungünstigen Programmpunkt ist (zB. in einem Unterprogramm oder einem Macro), dann zeigt der Fehlerlink nicht auf den Fehler direkt, sondern hinter den Rücksprung auf einern richtigen befehl. (hatte ich so auch schon einige male)
ausserdem ist mir paa lieber und bequemer zu schreiben wie PortA. Bin halt schreibfaul! (auch wenn es hier manchmal ganz anderst aus sieht)
Aber jeder so, wie er es für sich am besten kann bzw. für richtig hält! Es führen halt immer viele wege zum Ziel!

 

[E-Fan]

...ausserdem ist mir "paa" lieber und bequemer zu schreiben wie "PortA". Bin halt schreibfaul!...

Ich bins auch - deswegen schreib ich die Anweisungen auch direkt in die Register (zum Beispiel zur Konfiguration des Timer0 eines AVR: tccr0a=..., tccr0b=...)
Als Argument ist es jedoch sehr dünn - niemand ist in der Lage so schnell zu schreiben das es merkliche Unterschiede im Zeitaufwand mit sich bringen würde weil man ein paar andere Buchstaben eintippen muss zumal man bei den meisten Registern eh im Datenblatt nachschauen muss welches Bit welche Funktion bewirkt.
Die Bedienungsanleitungen sind ja nicht umsonst weit über 250 Seiten lang und in den Kurzfassungen wird nicht auf die einzelnen Modi der internen Komponenten (Hardware TWI (andere Bezeichnung für I²C), SPI, PWM und Timerfunktionen zum Beispiel) eingegangen.

 

[Per]

Der Atmel-Assembler, den ich detailliert erst vor ein paar Tagen angeschaut habe, erinnert mich auch stark an meine UB8830/8840-Erfahrungen vor 15 Jahren.

Sehe ich das richtig, das der Atmel eine (logische) Verwandschaft zu den U88X hat? Dann wäre für mich der Einstieg ja viiiiel einfacher.

 

[Hammy]

Da stimm ich E-Fan mal zu. Das Eintippen der Befehle ist das kleinste Übel, wesentlich schwieriger ist es, die richtigen Befehle in der richtigen Reihenfolge zu überlegen, die richtigen Bits hier und dort zu setzen, damit z.B. der Timer auch das macht, was er macht.

Egal aber, was für eine Programmiersprache jeder benutzt, Hauptsache das Programmieren der Controller macht Spaß.

Sehe ich das richtig, das der Atmel eine (logische) Verwandschaft zu den U88X hat? Dann wäre für mich der Einstieg ja viiiiel einfacher.

Verwechsel mal den U880 (Z80) nicht mit den Einchipmikrorechnern UB8830/8840/...

 

[E-Fan]

@Per:

Glaub ich nicht bedingt.
Vielleicht gibt es gewisse Ähnlichkeiten in der Programmierung, an sich ist die ALU aber eine komplette Neuentwicklung zweier Studenten aus Skandinavien.

 

[topla]

Sehe ich das richtig, das der Atmel eine (logische) Verwandschaft zu den U88X hat? Dann wäre für mich der Einstieg ja viiiiel einfacher.

Nö, der U88xx hat eher viele Ähnlichkeiten zum Z8.
Mir sind die Befehlssätze und der Aufbau von PIC und den RISC-Atmels sowieso zu "RISC" und ich bleibe aus lieber Gewohnheit bei 8051-kompatiblen (z.B. AT89C4051).

Gruß
Thomas

 

[Per]

Verwechsel mal den U880 (Z80) nicht mit den Einchipmikrorechnern UB8830/8840/...

Ich meine schon letztere, nur das B stand doch für ne bestimmte Spezifikation und 30/40 waren nicht alle Varianten. Wobei ich sie halt noch als U883 und so kannte (danach lange nichts mehr von gehört).

 

[topla]

Der zweite Buchstabe steht für die Taktfrequenz B=8, C=5 und D=3,5?MHz.
882x und 884x waren Typen mit herausgeführtem Speicherport für einen externen EPROM, die 881x mit internem ROM und die 886x ohne ROM. Dann gab es auch noch welche mit eingebautem Basic-Interpreten, könnten die 3er gewesen sein.

Gruß
Thomas

 

[Hammy]

Ja, der 8830er war der mit Tiny-Basic - also der im dem JU+TE-Computer. Ansonsten sehe ich folgende wichtige Unterschiede (wenn erforderlich, Korrektur erwünscht):
- Atmels adressieren den Programmspeicher in 16-bit Blöcken (aka 2 Byte), die Befehlslänge beträgt also immer ein Vielfaches von 2 Byte
- bei der Ux88y0-Serie waren die Ports ganz normale Register, die man auch über das 4-bit Kürzel ansprechen konnte (r2 konnte das Register 0x02, also der Port 2 sein, wenn die Registergruppe 0x0* ausgewählt war) - bei den Atmels kann man offenbar die Ports nicht wie Register ansprechen (z.B. LDI), sondern muss IN/OUT-Befehle benutzen (IN...Port->Register, OUT...Register->Port)
- (Gemeinsamkeit bei den Atmels und den Ux88y0 gibt es am Anfang des Programmspeichers Sprungverteiler für das Hauptprogramm und die Interrupts
- Atmels haben noch viele Zusatzfeatures, z.B.
-- "Fuses", um z.B. den Reset-Pin als normalen Portpin benutzen zu können
-- A/D-Wandler
-- I2C-Schnittstelle
-- und vieles mehr
- die Assembler-Befehle heißen etwas anders (bei der Ux88y0-Serie konnte man LD r4,#12 schreiben, um den Register r4 den Wert 12 zu setzen, beim Atmel heißt der Befehl dann LDI)
- ich kenne keinen guten Hochsprachencompiler für Ux88y0, für den Atmel gibt es einige und sei es nur der C-Compiler aus dem WinAVR-Projekt

 

[ateshci]

Guckt mal unter wikipedia die Unterschied zwischen von-Neumann- und Harvard-Archiutektur nach. Da habt Ihr den Unterschied zwischen einem Z80 und einem Atmel oder PIC. Für eine Operation benötigt ein Z80 8..10 Taktzyklen und muß zweimal auf den Bus zugreifen, der Pic benötigt 4 und der Atmel 1..2 und sie greifen nur einmal auf den internen Bus zu. Ähnlichkeiten in den mnemonischen Abkürzungen des Assemblers und der Speicherorganisation sind KEINE Ähnlichkeiten der Maschinen!
Gruß vom Heizer

 

[ptlbahn]

Sicher gibt es gewaltige unterschiede zwischen Z80/U880 und Atmel!
Der Z80 ist imm inneren eher dem 8086 und nachfolgern ähnlich.
Es gibt nur wenige fest zugeordnete Register wie A =akku, über den alles läuft, B,C und D im Z80/8086, während Atmel, wie schon geschrieben, 32 relativ frei verfügbahre register hat. Auch die Arbeitsbreite (Z80= alles 8 Bit, Atmel (meines wissens ) 8 Bit Arbeitsbreite, aber 16 Bit Befehlsbreite.
Dennoch bin ich der Ansicht, das das mir das Wissen aus der Z80-Zeit sehr viel geholfen hat, da viele Mechanismen sich ähneln (nicht in der inneren Ausführung, sondern in dem auftreten gegenüber dem Programierer)
Die Atmel sind da eher ein Z80-Komplettsystem, da es hier neben der CPU auch viele Bausteine "on Board" gibt, die beim Z80 noch eigene Chips oder gar komplette Baugruppen (zB. AD-Wandler)erforderte.
Man muß halt beim Vergleich der Prozessoren unterscheiden, wie der Prozessor wirklich arbeitet (beim Z80 8-10 Takte für die abarbeitung eines Befehls, bei Atmel nur 1-2 Takte), und wie die Bausteine aufgeteilt und an zu sprechen sind (und hier ähneln sich für mich beide Familien sehr schön).
Der Vergleich Z80-Atmel ähnelt (für mich) dem Vergleich Trabbi-Mercedes.
Dem Nutzer zeigen sich stark ähnliche Grundbedienelemente, so das der umstig relativ einfach ist, auch wenn im inneren beim Mercedes zigfach mehr technik steckt und mahn etliche zusätzliche Möglichkeiten hat!
Dagegen ist ein Pic für mich irgend wie wie ein Kettenfahrzeug ein zu ordnen. Man weiß im Prinzip zwar, was da passiert, aber man hat keine vergleichbahren Bedienelemente.
Wohlgemerkt, das ist mein Persönliches Empfinden, und muß nicht der Weißheit letzter schluß sein!

 

[Hammy]

Ateshci, Du scheinst ja informatikmäßig mehr Grundbildung zu haben als wir meisten hier. Wie wirken sich Deines Wissens nach die Unterschiede der beiden Prozessorarchitekturen auf den Programmierer aus - mal von der Ausführungszeit für einen Befehl abgesehen? Bitte nicht als Provokation auffassen, ich weiß es schlicht nicht, da ich bisher "nur" die Programmierseite kannte.

 

[Gordon]

Bevor ich mit den Atmel angefangen habe bin ich, bedingt durch die sehr gute Seite von Sprut, fast dem PIC erlegen. Ich habe mich allerdings nicht sehr intensic mit den PICs beschäftigt um ein eindeutiges Urteil bilden zu können. Hier mal meine Argumente die mich persöhnlich zum Atmel geführt haben. Punkt 1 ist der Preis. Die Atmels sind bei gleicher Ausstattung meist günstiger. Punkt zwei der mich gestört hat ist die Aufteilung in Speicherbänke und das viele Operationen wohl nur über das W-Register laufen. Und dann hat mir an den Atmel gefallen das vom kleinen Atiny bis zum großen Atmega der Befehlssatz weitgehend gleich ist. Sollten seitens der Ausführungen über die PICs Fehler enthalten sein, so bitte ich um Nachsicht aber ich habe mich nicht intensiv damit beschäftigt und diese Ausagen stellen meine Erkenntnisse dar. Und als letztes, als ehemaliger Z80 Hobbyprogrammierer fühlte ich mich rein vom Bauchgefühl bei den Atmels am wohlsten.
Ansonsten ist die Diskussion Atmel oder PIC mit jemandem zu vergleichen der ein neues Auto sucht und Opel und VW zur Auswahl hat. Jedes Lager wird ihm Tips geben können welches das bessere Auto ist entscheiden muss er letztendlich selber.

 

[ptlbahn]

Ich bin zwar nicht gefragt, aber dennoch meine Bescheidene Meinung dazu (oder Ignoriere bitte einfach das Folgende):
Am meisten dürfte es sich in einer einfacheren Programierung äussern.
So stehen im Z80 nur 4 Register zur verfügung, auf die die "Aragmetische Logigeinheit" (=ALU) im Prozessor zu greifen kann, und nur das A-Register (=akku) ist mit den Registern R15-R31 im Atmel vergleichbar.
Damit muß für jede Opperation ( Add, Sub, And, Exor, Or, Vergleich)eine Variable in den Akku gebracht werden.
Damit muß die Befehlsfolge im Atmel:
Andi r16, 0x12 ;Undverknüpfung register 16 mir 12hexa
ori r20, r25 ;oderverknüpfung register 20 mit register 25
andi r31, 0x16 ;Undverknüpfung Register 31 mit 16 Hexa
für den Z80 in etwa wie folgt geändert werden:
ldi adresse, r16 ;Lade Adresse der Speicherzelle R16
ld inhalt adresse in Akku ;Lade R16 in Akku
andi akku,0x12 ;Undverknüpfung akku mit 12 hexa
ld akku in inhalt Adresse ;Rückspeichern des ergebnisses in R16
ldi adresse r25 ;Lade adresse der Speicherzelle R25
ld inhalt adresse in B ;Vergleichswert laden
ldi adresse r20
ld inhalt adresse in akku
or akku, B
ld akku in inhalt von adresse
...
und so weiter.
Also kann mit dem Atmel schon mal bei diesen operationen 3 befehle eingespart werden, da hier 32 Register für die wichtigsten Variablen voll so genutzt werden können, wie nur der Akku im Z80.

2. entscheidener unterschied ist, das man nicht nur die einzelnen Register komplet ansprechen kann, sondern auch einzelne Bits in diesen registern direkt manipulieren kann.
So muß für den Befehl:
sbic porta,0 ; überspringe nächsen Befehl wenn im Ausgangsregister A bit 0 gelöscht
im Z80
In Port A in Akku
ori akku, 11111110
cpi akku, 0xFF
Springe bei Gleichheit relativ 2 befehle.
Das bedeutet wieder wesentlich höheren Programmieraufwand.

Da der Atmel intern zB. ein I²C-Port hat, der erst im fall eines Empfangenen für ihn bestimmten Datenwertes einen Interüpt auslöst, was der Z80 nicht hat, so muß diese I²C-Bus beim Z80 entweder getrennt aufgebaut werden, der dann einen interupt auslöst oder aber der Proßessor muß ständig die Leitungen des I²C-Busses überwachen, und alles mit lesen und auswerten, was dann den Prozessor ganz schön belastet und viel Programieraufwand oder viel Hartware erfordert.
Ähnlich sieht es mit Countern, I/O-Funktionen oder dem AD-Wandler aus.
Der Z80 hat ja keine Direkten I/O-Ports, sondern hat nur die Adressleitungen und 8 Datenleitungen sowie die Steuerleitungen. Für die Ein-/Ausgänge ist dann ein Extra Schaltkreis (zB Z80PIO, U855 oder 8255) nötig, der über die Adresse ausgewählt wird, und dann die Daten über den Datenbus erhält.

Von daher nimmt Die Risc-Architektur im Atmel (und sicherlich auch die Strucktur im Pic) dem Nutzer sehr viel Aufwand ( sowohl Hardwaremäßig als auch Programiertechnisch) ab.


PS:
(Achtung: bei sbr/cbr = Setze/Lösche bit im register arbeitet der Atmel nicht mit der Bitadresse 0-7 sondern mit der Wertigkeit des Bits, also 1-126. Das hat zwar den Vorteil, das gleichzeitig mehrere Bits des Registers verändert werden können, aber hier (wie bei der Dekoderprogramierung) dann die werte der Bits für diesen Befehl Addirt werden müssen!
Die Befehle sbi/cbi = Setze/lösche Eingangsbit und sbrc/sbrs/sbic/sbic = Überspringe nächsten befehl, wenn Register/ Eingangsbit gesetzt/gelöscht arbeiten mit der Bitadresse 0-7)

 

[ateshci]

Die Auswirkungen auf den Programmierer - puh, das kann man nicht so leicht beantworten. Ich beschreibe es mal unter Assembler-Gesichtspunkten.
Zuerst muß man beim PIC 35, beim ATMEL 118 Befehle lernen. Der PIC hat einen allerdings nur 8 Plätze umfassenden Stack, der in der hardware realisiert ist, beim ATMEL muß man den mitttels RAMEND-pointer initialisieren. Dafür ist der Stack aber beliebig tief, kann aber theoretisch mit Daten überschrieben werden. Der PIC hat im PCON register eine Möglichkeit nachzusehen, welches Ereignis den Reset ausgelöst hat, ob Watchdog, Brown-Out, Power-On oder MCLR. Das ist für die Programme in Lok-Decodern sehr wichtig, denn damit die Loks ein vernünftiges Fahrverhalten zeigen, dürfen sie ja nicht immer von vorne loslegen. Also erleichtert das die Programmierung. Der A. mit seinen 32 Registern, die mit der ALU zusammenarbeiten, läßt oft ein einfachere Codierung mit weniger Befehlen zu als der PIC mit einem W-Register. Der Interrupt ist beim PIC komplizierter zu realiseren, da man alles außer dem Programmzähler in extra definierte RAM-Plätze speichern muß, während beim A. das mit push/pop wesentlich einfacher zu erledigen ist. Diese Unterschiede fallen aber fast alle weg, wenn man in C++ oder C# programmiert, da die Compiler natürlich für den jeweiligen Controller optimiert sind und eine entsprechende Untermenge des C-Instruktionssatzes zur Verfügung stellen. Ich habe mit beiden µCs Steuerungen gebaut und für mich ist es reine Geschmackssache, welchen von beiden man nimmt. Es hängt schlicht und einfach vom Preis und davon ab, in welchem Gehäuse man welche Funktionen bekommt. Da hatte in letzter Zeit allerdings der A. die Nase vorn.
Gruß vom Heizer

 

[Per]

Naja, da ich ausser dem Z80 auch den Z8000 kenne, bin ich nicht auf Register A festgelegt . Denke, dass ich mich auch dem ATMEL zuwenden werde.

 

[Gordon]

Da ja im Forum schon für die unmöglichsten Dinge Umfragen gebastelt wurden wäre es sicherlich mal interressant auch für dieses Thema so was zu machen. Vielleicht dann nicht nur PIC und Atmel sondern gleich auch wer kann schon programmieren wer möchte es lernen usw.
Ist nur ne Anregung

 

[flicflac]

Help...!!!

So, nun muss ich mal um Hilfe schreien.

Ich hab nun das Pollin-Board zusammengebaut und krampfhaft versucht seriell damit zu kommunizieren. Weder AVR-Studio noch Ponyprog will. Getestet mit 2 Kabeln, 2 PC >> daher 4 COM. In meiner Verzweiflung habe ich dann noch angefangen den Adapter für die parallele Schnittstelle (LPT) zu löten, aber da mache ich nach dem Aufstehen weiter, fehlt nur noch die parallele Strippe. Evtl. ist nur der MAX232 defekt und es geht über die LPT/ISP.
Lötstellen sind alle überprüft, auch auf Brücken usw.


Vielleicht hat ja jemand Mitleid und heute zum Feiertag etwas Zeit und kann mir verbal am Tele über so ein paar Hürden helfen? Es quälen mich noch ein paar spezielle Fragen.


flic
(der verzweifelte)

 

[ptlbahn]

Wenn es das weiter oben schon genannte board ist, dann ist der Com-Port mit dem Max erst nutzbar, wenn der Atmel Programiert ist.
(Er diehnt der Comunikation Atmelprogramm-PC-Programm.
Der ander Com-Port mit den Z-Dioden dran ist zum Lesen/schreiben der Atmel. Sind die Z-Dioden richtig rumm drin?
Mit dem Ponv hat es weiter oben ja schon bei Tsinger geklapt, also hast du es mit dem Progrmm versucht? Oder direkt aus dem AVR-Studio?
Ich muß heute "leider" unsere N-Anlage Testen, so das ich nur bis ca 10:30 und erst ab ca. 16:00 erreichbar bin.

 

[Hammy]

@flicflac: der MAX232 wird zum Programmieren NICHT benötigt, da zum Programmieren die ISP-Sub-D-Buchse benutzt wird. Versuch mal folgendes:
- alles ICs raus aus dem Board und Betriebsspannung messen
- serielles Kabel prüfen (Pin x muss mit Pin x verbunden sein, die Bezeichnung der Pins ist allerdings spiegelverkehrt!)
- mit echter serieller Schnittstelle probieren (später evtl. mit USB-Seriell-Adapter)
- neues Ponyprog (2.0.*) benutzen und kalibrieren
- Ponyprog der Test im Setup muss erfolgreich sein
- mit Ponyprog versuchen, den uC zu lesen

und natürlich die ganz primitiven Dinge vorher:
- Sichtkontrolle aller Bauelemente (richtige Werte, richtige Orientierung) und Lötstellen
- aufpassen, dass beim Einsetzen der ICs nicht doch ein Beinchen verbogen wurde

 

[flicflac]

Uahhh, da hab ich mich voll am falschen Ende verbissen, auf die Idee das Kabel mal umzustecken bin ich absolut nicht gekommen. Das 232 gehörte für mich bei seriell in die Kette und da mus das Kabel ran... Aber jetzt hab ich's geschnallt, der 232 ist ganauso eine programmierbare Komponente wie die Leuchdioden usw.

Besten Dank für den simplen Hinweis

In Ponyprog klappt jetzt jedenfalls der Test. Dann Device eingestellt (2313) und habe mal versucht auzulesen zwecks Kommunikationstest. Das hat auch funktioniert, nachdem ich die Fehlermeldung: "Device missing or unknown device (-24)" umschifft habe.

Im mfile hab ich dann den CPU type und das main-file geändert.
Nun hab ich mir folgendes Progrämmchen aus dem Web "genommen" und im WinAVR getestet:

#include <avr/io.h>
// Sollte normalerweise schon im Makefile definiert sein.
// In dem Fall hier einfach löschen.

#define F_CPU 7372800
void ioinit(void);
void delay_ms(unsigned int ms);

// Hauptprogramm
int main(void) {
unsigned char i;

ioinit();

// Endlosschleife
while (1) {
PORTD = i;
i++;

// Eine Sekunde warten
delay_ms(1000);
}

return 0;
}

// Initialisierung
void ioinit(void)
{
DDRD = 0xff; // PortD als Ausgang deklarieren
PORTD = 0x00; // Ports auf LOW schalten
}

// Warteschleife
void delay_ms(unsigned int ms)
{
unsigned int zaehler;

while (ms) {
zaehler = F_CPU / 5000;

while (zaehler) {
asm volatile("nop");
zaehler--;
}
ms--;
}
}


Da kommt bei make all folgender Fehler mit dem ich nix anfangen kann:
> "make.exe" all
AllocationBase 0x0, BaseAddress 0x71590000, RegionSize 0x470000, State 0x10000
C:\WinAVR-20070525\utils\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 487
AllocationBase 0x0, BaseAddress 0x71590000, RegionSize 0x470000, State 0x10000
C:\WinAVR-20070525\utils\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 487

-------- begin --------
avr-gcc (GCC) 4.1.2 (WinAVR 20070525)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

AllocationBase 0x0, BaseAddress 0x71590000, RegionSize 0x470000, State 0x10000
C:\WinAVR-20070525\utils\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 487
make.exe: *** [sizebefore] Error


Analog dazu im AVR-Studio:
../test_a.c:49: fatal error: opening dependency file dep/test_a.o.d: No such file or directory
compilation terminated.
make: *** [test_a.o] Error 1




Ich denke mal das irgendwelche Einstellungen nicht korrekt sind, aber welche? Das ist wohl mein größtes Problem, diese dösigen Einstellungen usw.
Aber ein Progrämmchen muss erstmal funktionieren bevor ich weiterkomme


Ne andere Frage, im mfile und im AVR-Studio kann man das programmer board angeben. Welches ist mit dem Pollin kompatibel oder ist das egal. Spielt ja für das beschreiben eigentlich keine Rolle.

flic

 

[Hammy]

Bist Du dir sicher, die neueste WinAVR-Version zu nutzen? Ansonsten bin ich bei meiner Fehlersuche über diese Fehlermeldung schon gestolpert. Such bitte mal, irgendwo gibt es eine Schritt-für-Schritt-Anleitung.

 

[ptlbahn]

Also meine ersten Experimente waren in Assembler eine Schleife, bei der 2 Eingänge beobachtet wurden, und dann 4 LED verschiedene verknüpfungen anzeigten (Also A1 = E1; A2 = E2; A3 = E1 oder E2; A4 = E1 und E2; A5 = E1 Exor E2; A6=Nicht E1 und nicht E2)
Das sieht dann etwa so aus:
.def akku = r16 ;register R16 als Akku definieren (Da merkt man meine Z80-Abstammung)
.def porta = 0x..
.def portb = 0x..
.def pbd = 0x..
init:
ldi akku,0xFF
out porta,akku ;Aktivierun Pull-Up-Wiederstände für Eingangsport
out pbd,akku ;Port B als Ausgang schalten
out portb, akku ;alle ausgänge aus
Start:
sbis pina,0 ;E1=0?
rjmp Sprung1
sbis pina,1 ;E2=0?
rjmp Sprung2
cbi portb,1
cbi portb,2
cbi portb,3
cbi portb,4
cbi portb,5
sbi portb,6
rjmp Start
Sprung1:
sbis pina,1 ;E2=0?
rjmp Sprung3
sbi portb,1
cbi portb,2
sbi portb,3
cbi portb,4
sbi portb,5
cbi portb,6
rjmp Start
sprung2:
cbi portb,1
sbi portb,2
sbi portb,3
cbi portb,4
sbi portb,5
cbi portb,6
rjmp Start
sprung3:
sbi portb,1
sbi portb,2
sbi portb,3
sbi portb,4
cbi portb,5
cbi portb,6
rjmp Start

oder:
.def akku = r16 ;register R16 als Akku definieren
.def porta = 0x..
.def portb = 0x..
.def pbd = 0x..
init:
ldi akku,0xFF
out porta,akku ;Aktivierun Pull-Up-Wiederstände für Eingangsport
out pbd,akku ;Port B als Ausgang schalten
out portb, akku ;alle ausgänge aus
Start:
sbis pina,0 ;E1=0?
rjmp Sprung1
sbis pina,1 ;E2=0?
rjmp Sprung2
ldi akku,0b01000000
out portb.akku
rjmp Start
Sprung1:
sbis pina,1 ;E2=0?
rjmp Sprung3
ldi akku,0b00101010
out portb.akku
rjmp Start
sprung2:
ldi akku,0b00101100
out portb.akku
rjmp Start
sprung3:
ldi akku,0b00011110
out portb.akku
rjmp Start


Beide Programme bewirken eigendlich das Gleiche!
Dabei sind bit 0 und bit 1 von port A die Eingänge und Bit 1-6 von port B die Ausgänge.
Mein nächster Schritt war dann schon, den Timer zu Programmieren und eine LED blinken zu lassen. (zB Portb bit7)

Dazu wurden nur die Timerregister im Init-teil entsprechend eingestellt und der Timerüberlaufinterrupt mit folgendem Programm belegt:
Timerüberlauf:
sbis portb,7 ;A8 gesetzt?
rjmp blink1 ;nein, springe Blinken
cbi portb,7 ;A8 Rücksetzen
reti ;Überlaufinterupt abgearbeitet, rücksprung
Blink1:
sbi portb,7 ;A8 Setzen
reti ;Überlaufinterupt abgearbeitet, rücksprung

Im Hauptprogramm muß dann nur noch im Init-Teil
sei ; Interupts freigeben
eingetragen werden.

 

[flicflac]

17:00

so, nun tut sich was.
Ich habe von http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/winarmtests/ die WinARM_utils_testing_20060719.zip geladen und in WinAVR\Utilsbin die Dateien ersetzt. Die Krux war wohl sh.exe. jetzt ist da zwar eine ältere (2003/10/02) aber sie tut es.

1h später...
WinAVR hat compiliert und *.elf in Studio getestet. geht
Studio hat compiliert (incl. run) geht auch
Nun das Übertragen mit Ponyprog. Schönes Tutorial mit :
• Klicken Sie „File“ an
• Klicken Sie „Open Device File“ an. In dieser Datei müssen sowohl das Programm, als auch die EEPROM – Daten enthalten sein.
• Navigieren Sie zu dem Speicherort der Datei und klicken Sie die Datei an. Die Datei wird nun geladen.

Schön, schön, aber welche Datei?
Ich hab es mal mit der *.hex probiert. Wurde auch geladen, aber wenn ich übertragen will kommt wieder der Fehler "Device missing or unknown device (-24)"...


3h später
So, alles was hier stand habe ich wieder gelöscht. Wenn ihr zum Himmel schaut und da eine zweite Raumstation entdeckt, das bin ich der zwischen Minden, Hannover und Bielefeld im Parabelflug hin und her springt!
Der Tiny war wohl durch die ersten Versuche "verfust" wie ihr so sagt. Ich hab 5 Stück davon hier, aber auf die Idee mal einen Anderen zu versuchen bin ich als letztes gekommen. Anderen Chip, read >> write >> alles Grün >> PILS!

Nun sieht die Welt schon viel besser aus. Jetzt muss ich mein Bsp nur noch so umprogrammieren das PB Eingang und PD Ausgang ist. Hat aber bis jetzt noch nicht funktioniert :-(

flic

 

[ptlbahn]

Wenn Port B eingang sein soll, braucht eigendlich nur der Pin von port B gelesen werden. Die Ports sind im urzustand/Reset im Direktionregister auf eingang geschaltet. Es empfielt sich, auf Portb ein 0xFF aus zu geben, damit die Eingänge einen Pull-up-Widerstand gegen plus geschaltet haben.
Um Port D auf Ausgang zu schalten mus auf das direktionsregister 0xFF ausgegeben werden.
In meinem Programm der Init-teil, im deinem Beispiel der folgende abschnitt:
// Initialisierung
void ioinit(void)
{
DDRD = 0xff; // PortD als Ausgang deklarieren
PORTD = 0x00; // Ports auf LOW schalten
}

Dazu muß man wissen, das jedes Port 3 hintereinander liegende Registeradressen hat.
Register 1 ist das Ausgangsregister, in das die ausgabedaten geschrieben werden, oder wenn der Port auf eingang gestellt ist, der Pull-up-wiederstand zugeschaltet derden kann.
Register 2 gibt die Richtung an, also ob eingang oder ausgang.
Register 3 sind direkt die Anschlußpins, so das hier bei eingängen der Wert vom pin gelesen werden kann.
Interessant ist, das jedes Bit eines Ports einzeln als Eingabe oder ausgabe deklariert werden kann. Also zB. Bit 1,2,5 und 7 Eingänge, der rest ausgänge.
Wie gesagt, ich arbeite ausschließlich in Assembler, da weiß ich nicht, wie man enzelne bits in Basic oder C ansprechen kann, in Assambler ist es in meinem oberen Einstiegsbeispiel in der 1. Version dargestellt, während in der 2. Version die ansprache Bytweise erfolgt.