Für meine Bachelorarbeit soll ich einen CCD-Zeilensensor auslesen und
per Netzwerk an einen PC zur Weiterverarbeitung schicken.
Gelöst habe ich die Aufgabe mit einem Pollin NetIO auf dem Ulrch Radigs
Firmware (natürlich abgewandelt) läuft.
Mit dem original Atmega 32 läuft die ganze Schaltung auch schon.
Allerdings hat der Atmega zu wenig RAM, so dass ich nicht die ganze
Zeile auf einmal auslesen kann.
Deshalb habe ich mir jetzt einen Atmege644P besorgt, der ja mehr RAM
hat.
Die Portierung von Atmega 32 zu 644 bereitet mir jedoch Probleme.
Für den Originaltimer von Herrn Radig habe ich folgendes:
Stimmen die Anpassungen für den Atmega644P?
wenn ich den Atmega32 definiere läuft wieder alles wunderbar. Beim
644P-er nichts mehr. Bzw. ist er nicht mehr per Netwerk erreichbar.
Fehler beim Compilieren werden nicht gemeldet und auch das Flashen
bereitet keine Probleme.
Stefan Foydl schrieb:> Stimmen die Anpassungen für den Atmega644P?
puh ist lange her, mein Pollin NETIO läuft schon lange auf m1284p
ob ich alle Anpassungen auf m644 / 644p noch finde weiss ich nicht, mal
suchen !
in timer.h
1
#if defined (__AVR_ATmega644__) || defined (__AVR_ATmega644P__) || defined (__AVR_ATmega1284P__)
2
3
#define TIMSK TIMSK1
4
5
#endif
in stack.h
1
#if defined (__AVR_ATmega644__) || defined (__AVR_ATmega644P__) || defined (__AVR_ATmega1284P__)
2
#define MAX_TCP_ENTRY 5
3
#define MAX_UDP_ENTRY 5
4
#define MAX_ARP_ENTRY 5
5
#define MTU_SIZE 1200
6
#endif
in timer.c
1
voidtimer_init(void)
2
{
3
#if EXTCLOCK==1
4
#if defined (__AVR_ATmega644__) || defined (__AVR_ATmega644P__) || defined (__AVR_ATmega1284P__)
5
6
//Asynchroner Modus ein, Oszillator an TOSC1 und TOSC2 aktiv
7
ASSR|=(1<<AS2);
8
TCCR2B=0x05;
9
while(ASSR&0x11);
10
//Capture/Compare-Interrupt aktiv
11
TIMSK2|=(1<<OCIE2A);
12
#else
13
//Asynchroner Modus ein, Oszillator an TOSC1 und TOSC2 aktiv
14
ASSR=(1<<AS2);
15
//CTC-Modus an (Clear Timer on Compare Match)
16
TCCR2=(1<<WGM21);
17
//dieser Wert ergibt eine Sekunde Periodendauer
18
OCR2=31;
19
//lösche Prescaler 2
20
21
SFIE=(1<<PSR2);
22
//Starte Timer 2 mit Prescaler gleich 1/1024
23
TCCR2|=(1<<CS22)|(1<<CS21)|(1<<CS20);
24
while(ASSR&0x07);
25
26
//Capture/Compare-Interrupt aktiv
27
TIMSK=(1<<OCIE2);
28
#endif
in usart.h
1
#if defined (__AVR_ATmega644__) || defined (__AVR_ATmega644P__) || defined (__AVR_ATmega1284P__)
2
#define USR UCSR0A
3
#define UCR UCSR0B
4
#define UBRR UBRR0L
5
#define EICR EICRB
6
#define TXEN TXEN0
7
#define RXEN RXEN0
8
#define RXCIE RXCIE0
9
#define UDR UDR0
10
#define UDRE UDRE0
11
#define USART_RX USART0_RX_vect
12
#endif
in enc28j60.h
1
#if defined (__AVR_ATmega644__) || defined (__AVR_ATmega644P__) || defined (__AVR_ATmega1284P__)
2
3
4
#define ETH_INT_ENABLE EIMSK |= (1<<INT2)
5
6
7
#define ETH_INT_DISABLE EIMSK &= ~(1<<INT2)
8
9
10
#endif
in rtl8019.c
1
#if defined (__AVR_ATmega644__) || defined (__AVR_ATmega1284P__)
2
//Set Addr Port Direction = Output
3
DATA_ADDR_RLT=OUTPUT;
4
#endif
in rtl8019.h
1
#if defined (__AVR_ATmega644__) || defined (__AVR_ATmega644P__) || defined (__AVR_ATmega1284P__)
Ah, stimmt. Die Tabelle (13.5) steht zwar bei TCCR1A, aber das Bit WGM12
ist trotzdem in TCCR1B
1
#if Atmega644P
2
TCCR1B|=(1<<WGM12);//CTC(compare match mode)
Danke Joachim. Am Anfang habe ich dummerweise alle für mich unnützen #if
... Anweisungen entfernt um die Übersichtlichkeit zu verbessern. Das
rächt sich jetzt.
Ich werde mal deine Hinweise alle durchgehen.
EDIT:
alle #if-Anweisungen sind sogar noch da. Es hat sich also nichts
geändert und es klappt immer noch nicht.
Allerdings habe ich noch etwas paradoxes gefunden:
Beim atmega32 leuchtet die grüne LED an der Ethernetbuchse dauerhaft und
die orangene blinkt.
Beim 644P ist es genau andersherum. Kann mir da jemand auf die Sprünge
helfen?
Stefan Foydl schrieb:> Allerdings habe ich noch etwas paradoxes gefunden:> Beim atmega32 leuchtet die grüne LED an der Ethernetbuchse dauerhaft und> die orangene blinkt.
muss irgendwo in den #defines umgeschrieben werden !
der NETIO kennt eh nur 10Mbit und welche blinkt ist eigentlich egal
vielleicht finde ich das noch im Netzwerk Source !
im enc28j60.h
1
#if defined (__AVR_ATmega32__)
2
#define ETH_INT_ENABLE GICR |= (1<<INT2)
3
#define ETH_INT_DISABLE GICR &= ~(1<<INT2)
4
#endif
5
6
#if defined (__AVR_ATmega644__) || defined (__AVR_ATmega644P__) || defined (__AVR_ATmega1284P__)
7
#define ETH_INT_ENABLE EIMSK |= (1<<INT2)
8
#define ETH_INT_DISABLE EIMSK &= ~(1<<INT2)
9
#endif
im enc28j60.c
1
#if defined (__AVR_ATmega32__)
2
#define ETH_INT_ENABLE GICR |= (1<<INT2)
3
#define ETH_INT_DISABLE GICR &= ~(1<<INT2)
4
#endif
5
6
#if defined (__AVR_ATmega644__) || defined (__AVR_ATmega644P__) || defined (__AVR_ATmega1284P__)
Joachim B. schrieb:> der NETIO kennt eh nur 10Mbit und welche blinkt ist eigentlich egal
Ja klar, aber es ist schon mal ein Anzeichen, dass ungewollt irgendwas
schief läuft. Original mit Atmega32 passt es ja.
> im enc28j60.h>
Diesen Eintrag finde ich in meiner enc28j60.c nicht. Bist du dir da
sicher? Es ist ja immerhin der gleiche Code wie in der .h
> irgendwo waren die LEDs vertauscht.....> http://home.arcor.de/chlercher/elektronik/enc28j60.htm>> Leider ist es nicht möglich die Software von Ulrich Radig direkt auf den> AVR NET IO zu laden, da eine Signalleitung zur Steuerung des ENC28J60> anders ist ! Es handelt sich hierbei um das Signal CS das einmal über> PB3 und einmal über PB4 gesteuert wird.
Irgendewo konnte man auch einstellen auf welcher Plattform es läuft. Da
wurden dann glaube ich diese Ports getauscht. Ich finde es aber auf die
Schnelle nicht im Code.
>> Um die grüne LED auch als Link-LED nutzen zu können muss in der Datei> "enc28j60.c ">> der Eintrag
Habe ich gemacht, ändert aber nichts daran, dass die LEDs nur beim 644P
vertauscht werden.
Im Anhang ist mal das gesamte Projekt für winAVR.
Eventuell hilft das ja.
Stefan Foydl schrieb:> Diesen Eintrag finde ich in meiner enc28j60.c nicht. Bist du dir da> sicher? Es ist ja immerhin der gleiche Code wie in der .hStefan Foydl schrieb:>>enc28j60_write_phy(ENC28J60_PHY_PHLCON, 0x347A) von 0x347A>> auf 0x374A verändert werden>>> Habe ich gemacht, ändert aber nichts daran, dass die LEDs nur beim 644P> vertauscht werden.
es ist mein aktuell laufender Code denke ich, kann aber zwische Server
@work und Server @home Differenzen geben
im Moment zu müde ich schaue später noch mal bezüglich der Versionen....
so was ich gepostet hatte war aktuell
besonders auch der Aufruf:
enc28j60_write_phy(ENC28J60_PHY_PHLCON, 0x374A);
allerdings hatte ich beim Umstieg auf m644 und später zum m1284p
jede einzelne Zeile vom gesamten Code verfolgt, war ne Sisyphusarbeit
aber weder sinnlos noch ohne Erfolg oder Ende, mein Code läuft ja !
Ich musste an unzähligen Stellen #defines einfügen ändern anpassen, ich
fürchte das kann ich nicht für dich leisten. Aber dir meinen Code zur
Verfügung zu stellen könnte ich zwar, aber das hilft dir vermutlich
wenig weil du dann Dinge bekommst die du evtl nicht brauchst willst oder
um die loszuwerden müsstest du dich genau Zeile für Zeile
durchackern.......
und halbe Projektcodes lassen sich auch so schwer kompilieren.
Joachim B. schrieb:> und halbe Projektcodes lassen sich auch so schwer kompilieren.
Das stimmt allerdings. Das du den Code nicht komplett durchsuchst ist
mir klar. Aber schon mal danke für die bisherigen Tipps.
Ich hatte gehofft, dass die Umrüstung relativ einfach geht, da die Radig
Firmware ja auch (anscheinend nur so halb?) für den 644P ausgelegt ist.
Zumindest kann man den µC ja z.B. im Makefile auswählen und es sind
schon einige defines drinnen.
Stefan Foydl schrieb:> für den 644P ausgelegt ist.
Das Problem, obwohl der 644 und 1284 m32 pinkompatibel ist haben die
Atmels sich alle Mühe gegeben die RegisterNamen umzuändern.
Das Ulrich seine eigenen #defines aufsetzt macht es an der Stelle auch
nicht einfacher, aber das musste wohl sein um zwischen TIMSK und TIMSK1
z.B. einen Kompromis zu finden.
Mittlerweile habe ich einige defines erstellt, aber es hat sich immer
noch nichts geändert.
Allerdings habe ich etwas anderes bemerkt:
Beim Atmega644P fängt der 16MHz Quarz nicht das schwingen an.
Laut original makefile sind lowfuse 0xff und highfuse 0xdf.
Welche werte habt ihr denn da verwendet?
>Beim Atmega644P fängt der 16MHz Quarz nicht das schwingen an.
Dann läuft der wohl noch mit dem internen RC Osci.
Ohne schwingenden Quarz könntest du sonst gar nicht mehr
ISP programmieren.
>Laut original makefile sind lowfuse 0xff und highfuse 0xdf.
Programmierst du mit AVRdude? Wenn nicht sind die Werte Schall und
Rauch.
Im Hexfile landen die Fuses nicht.
Stefan Foydl schrieb:> Laut original makefile sind lowfuse 0xff und highfuse 0xdf.
die habe ich mir nie angesehen weil ich mit einem Mk2 Clone direkt die
Fuses im Studio 4.18 setze
Dass der Atmega644 im internen Quarzmodus läuft ist klar. Aber das soll
er ja nicht. Mir fehlt aber da ein bisschen die Erfahrung und will ihn
mir nicht verfusen. Welche Einstellung brauche ich da? Das sollte doch
über SUT_CKsel gehen, oder?
Ich programmiere dann letztendlich über AVR Studio 5 mit einen AVRISP
II. Dort habe ich bisher die high/lowfuse direkt eingegeben.
Stefan Foydl schrieb:> Ich programmiere dann letztendlich über AVR Studio 5 mit einen AVRISP> II. Dort habe ich bisher die high/lowfuse direkt eingegeben.
das ist aber gefährlicher als den auf extern ab 8MHz- zu setzen und den
Haken Clock Divider 8 wegzumachen
Gerade bin ich noch mal dazugekommen meinen Atmega644P mit dem Oszi zu
kontrollieren.
Der 16 MHz Quarz schwingt wirklich nicht, die SPI Kommunikation zum
Ethernetkontroller läuft ebenfalls nicht und mein Clocksignal für den
Zeilensensor bleibt dauernd auf high.
Flashen kann ich bzw. AVR Studio 5 ihn aber ohne Probleme und
Fehlermeldungen..
Die Fuses sind aber wie oben gesetzt. Jetzt bin ich langsam ratlos.
Woran kann das noch liegen, dass der Quarz nicht schwingt und somit
keinen Takt erzeugt? Am Atmega32 funktioniert die Beschaltung ja ohne
Probleme.
Stefan F. schrieb:> Jetzt bin ich langsam ratlos.> Woran kann das noch liegen, dass der Quarz nicht schwingt
am Quarz.....(oder selten an den 22pF am Quarz)
schmeiss den raus, nimm gleich einen 20MHz und passe im Projektfile
F_CPU an
ggffs nimmst auch gleich einen m1284p
Joachim B. schrieb:> am Quarz.....(oder selten an den 22pF am Quarz)
Hätte ich auch vermutet, aber warum werkelt der Atmega32 dann
einwandfrei mit dem Quarz?
Das gleiche Verhalten tritt übrigens auch an einem zweiten NetIO auf
wenn ich diesen Atmega644P einbaue.
Und warum kann ich darauf zugreifen, wenn er doch im Externen Quarz
Modus ist, dieser aber nicht schwingt? Eine Umprogrammierung auf den
internen Quarz bringt auch keine Veränderung.
> schmeiss den raus, nimm gleich einen 20MHz und passe im Projektfile> F_CPU an
Das überlege ich im Moment auch, bringt aber erst dann was, wenn der µC
gescheit läuft.
Stefan F. schrieb:> Das überlege ich im Moment auch, bringt aber erst dann was, wenn der µC> gescheit läuft.
vielleicht hast du das Problem mit einem m1284p nicht erst.
Ich weiss grad nicht ob der Kondi am Quarz oder sogar der Quarz von der
MCU beeinflußt wird, aber bei deiner Beschreibung liest sich das fast
so.
Stefan F. schrieb:> nd warum kann ich darauf zugreifen, wenn er doch im Externen Quarz> Modus ist, dieser aber nicht schwingt? Eine Umprogrammierung auf den> internen Quarz bringt auch keine Veränderung.
wie kann man zugreifen wenn der Chip auf extern Quarz programmiert ist
aber dieser nicht schwingt ?
Joachim B. schrieb:> wie kann man zugreifen wenn der Chip auf extern Quarz programmiert ist> aber dieser nicht schwingt ?
Genau da liegt der Knackpunkt. :-P
Oben habe ich meine Fuse Konfiguration als Bild gepostet. Der Quarz
schwingt aber nicht.
Flash und eeprom kann ich aber sowohl beschreiben als auch auslesen. Die
Werte darin ändern sich auch.
Wenn ich den Controller resete ändert er den von mir programmierten Takt
für den Sensor genau einmal von low auf high und verharrt dann so.
Im Moment überlege ich mir auch noch einfach einen 644 zu holen nur um
auszuschließen, dass meiner defekt ist.
Die Sache mit den vertauschten LEDs scheint übrigens vom enc28J60 zu
kommen. Wenn gar kein µC eingebaut ist passiert das nämlich ebenfalls.
Stefan F. schrieb:> Genau da liegt der Knackpunkt. :-P> Oben habe ich meine Fuse Konfiguration als Bild gepostet. Der Quarz> schwingt aber nicht.
vielleicht ist hier die Lösung?
Beitrag "Probleme mit Atmega16 beim auschalten der Lötstation"Peter Dannegger schrieb:> When CKOPT is programmed, the Oscillator output will oscillate will a> full rail-to-rail swing on the output. This mode is suitable when> operating in a very noisy environment
Jetzt habe ich mal etwas einfacheres ausprobiert: Natürlich nicht auf
dem NetIO, sondern auf einer anderen Platine. An PD7 und PA5 hängen zwei
LEDs in low-active Verschaltung.
1
/* //fuer Atmega32
2
#define TCCR0A TCCR0
3
#define TCCR0B TCCR0
4
#define OCR0A OCR0
5
#define TIMSK0 TIMSK
6
#define OCIE0A OCIE0
7
#define TIMER2_COMPB_vect TIMER0_COMP_vect
8
*/
9
10
#include<stdlib.h>
11
#include<avr/io.h>
12
#include<avr/interrupt.h> // Für Interruptbehandlung nötig
Am Atmega32 toggelt er die eine LED schnell und die andere halt immer
wieder mal. Also so wie es soll.
Beim Atmega644P geht die eine LED dauerhaft an, die eigentlich selten
blinkende bleibt immer aus.
Habe ich da oben schon einen Schnitzer drin?
Stefan F. schrieb:> Habe ich da oben schon einen Schnitzer drin?
die ganzen Timerregister sind doch andere, entweder du machst #defines
für die passenden Register oder je nach Prozzi andere ....
hatte ich das nicht schon gezeigt ?
Joachim B. schrieb:> die ganzen Timerregister sind doch andere
Die sollten für den Atmega644P angepasst sein. Nur die Kommentare sind
nicht geändert.
Oben kann ich manuell per defines wieder auf den Atmega32 umschalten.
Danke für den Link. Ich lese ihn mir gerade durch.
Edit: ckopt gibt es beim Atmega644P leider nicht
@derElf: Laut Oszi liegt am Reset-Pin ein schönes high-Signal an.
Stefan,
der 644P verbraucht mehr RAM für Register und IO als der 328. Prüf' doch
einmal, ob die RAM-Anfangsadresse auf den richtigen Wert für den 644P
(ich glaube 0x100 statt 0x060) gesetzt wird.
Hans
RAMfresser schrieb:> 644P verbraucht mehr RAM für Register und IO als der 328
er hat ein Pollin NETIO und das wurde mit ATmega32 ausgeliefert, der
644p ist Pinkompatibel (wie der m1284p) und hat sich bei mir nicht wie
ein m328p benommen (von daher ist der Tipp wenig zielführend ?)
Im vereinfachten Beispiel oben waren es nur ein paar Tippfehler.
Mittlerweile klappt es mit der einfachen Beschaltung und dem internen
Oszilator.
Am NetIO ist mir jetzt noch folgendes aufgefallen. Der Atmega32 liefert
1,6V an den Quarz, der enc28J60 ebenfalls deutlich über 1,3V.
Der 644P dagegen aber nur 0,8V. Liegt das daran, dass ich die
"P"-Variante habe?
Gibt es dann spezielle low-Power Quarze?
Hi
>Liegt das daran, dass ich die "P"-Variante habe?
Nein. Es kommt darauf an, ob du Low Power Crystal Oscillator oder Full
Swing Crystal Oscillator mit den Fuses eingestellt hast.
MfG Spess
Die Fuses sind oben als .png sichtbar. Da kann man in AVR Studio 5
leider keinen Unterschied machen.
Die CKOPT Fuse gibt es beim 644P ja anscheinend nicht.
Wie stellt man das dann ein?
Jetzt schwingt der Quarz. Ich habe einen online fuse-calculator benutzt.
Das ändert aber leider auch nichts an den Problemen, dass anscheinend
nichts geht.
weder die Ethernet Schnittstelle noch die serielle antwortet.
Stefan F. schrieb:> Die Fuses sind oben als .png sichtbar. Da kann man in AVR Studio 5> leider keinen Unterschied machen.
Doch natürlich kann man das. Man muß dazu bloß die primitivsten
Grundlagen der Bedienung von Desktop-Oberflächen beherrschen...
Dann sieht man, daß die Liste der gezeigten Combobox eine Trackbar hat,
was bedeutet, daß die Liste mehr Einträge hat, als auf einmal angezeigt
werden können. Die Trackbar braucht man dann bloß noch benutzen, um
weitere Takt-Optionen in den sichtbaren Bereich der Liste
reinzuscrollen. Darunter sind auch einige, deren Namen mit "FULLSWING"
anfangen.
Herzlichen Dank lieber c-Hater. Jetzt bitte nicht böse sein, aber wenn
man die primitive Grundlage des Lesens beherrscht sieht man, dass ich
das fuse-Problem auch am 644P schon gelöst habe. Der Fullswing-mode lief
schon mit dem externen Quarz.
Dazu habe ich mir lediglich die Kenntnis aneignen müssen, was die
CKOPT-fuse macht und wie das bei den moderneren Atmels gelöst wurde.
"Fullswing" taucht übrigens nirgends als Klartext in diesem Menü auf,
sodass ich mich auch da erst mal kundig machen musste bevor ich etwas
falsches einstelle.
Als "Übersetzungs-"Hilfe diente mir dabei der fuse-calculator.