Hallo Leute. Kennt jemand die Treiber von Atmel zum 90CAN128 und hat damit schon mal was gemacht? Ich würde gerne wissen ob es da was besonderes zu beachten gibt. fw
Es gibt mindestens zwei "Treiber" von Atmel. Code ("wie immer") fuer
IAR-Tools. Ein Treiber fuer interruptlosen/poll-Betrieb, einer mit
"CAN-Interrupts".
Habe beide vor ein paar Tagen nach avr-gcc/avr-libc portiert, aber noch
nicht ausprobiert, da Hardware nicht fertig.
- mcu.h von Atmel/IAR unterscheidet sich in ein paar Punkten von
iocan128 aus avr-libc. Laesst sich relativ leicht anpassen. Habe als
Basis die Datei aus avr-libc gewaehlt, da diese besser mit dem
aktuellen Datenblatt uebereinstimmt
- die etwas "exotischen" Namen von Integerdatentypen im IAR-Code
lassen sich mit ein paar typdefs oder defines an avr-libc/stdint
anpassen
- in den "Interrupt-Beispielen". IAR #pragma interrrupt... durch
SIGNAL ersetzen, Signalnamen anpassen. Gemeinsam genutzte Variablen mit
volatile versehen (sind einige)
- zumind. ein kleiner Fehler ist in iocan128.h, spielt aber beim
kleinen Beispiel keine Rolle
Code kommt online sobald Tests auf Hardware erfolgreich und Atmel
"abgenickt" hat (Copyrights ohne weitere Bestimmungen in einigen
Dateien).
Martin
Bei mir kommt irgendwie nur sowas dabei raus: avr-gcc -c -mmcu=at90can128 -I. -g -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=main.lst -std=gnu99 main.c -o main.o In file included from main.c:4: C:/Programme/WinAVR/bin/../lib/gcc/avr/3.4.3/../../../../avr/include/can 128/eep_drv.h:46: error: parse error before "eeprom_rd" C:/Programme/WinAVR/bin/../lib/gcc/avr/3.4.3/../../../../avr/include/can 128/eep_drv.h:46: error: parse error before "addr" make.exe: *** [main.o] Error 1
Viel weniger Information kann man wohl nicht mehr geben. Wie auch immer - vermutliche Ursache: siehe zweiter Punkt in der Aufzaehlung oben (Integertypen). Apropos AT90CAN und eeprom: zu dem Thema hat vor ein paar Wochen schonmal jemand ausgiebigst gefragt und viele Hinweise erhalten. Die Forensuche sollte die Beitraege finden. Man kann sich die Portierung der Eeprom-Komponenten also ersparen. Fuer die Forumleser, die "mitdenken wollen" und sich fragen warum es ueberhaupt geht: es handelt sich wahrscheinlich um eine Fehlermeldung aus einem Versuch, die Eeprom-Routinen aus der "AT90CAN128 Software Library" (AT90CAN128 Seite bei atmel.com, fuer IAR-Compiler) unter avr-gcc/avr-libc zu kompilieren. Martin
Die Geschichte mit dem EEprom hab ich ja dank Eurer Hilfe hinbekommen. Ich habs halt nur mal mit den Atmel Tools versucht, ob ich es damit auch hinbekomme. Dabei kommt es eben zu dem oben genannten Fehler. Es wäre halt schön rauszubekommen woran es liegt, damit ich nicht immer wieder über solche Fehler falle. Vor eine Jahr hätte ich gesagt, es muss ja funktionieren, weil niemand so ein Toll veröffnetlichen würde, ohne es vorher getestet oder wenigstens mal durch einen Compiler gejagt zu haben. Heute bin ich mir da nicht mehr so sicher.
Vielleicht zeigst Du uns mal die "angemeckerte" Zeile 46 aus Deinem Sourcecode!?
Ich mag mir aber nicht den ganzen kram runterladen und suchen, deswegen wäre es äusserst nett von Dir, die Zeile kurz per C&P hier zur Verfügung zu stellen...
Das ist es, worüber der Compiler meckert, aber ich habe so den Verdacht, dass der ursächliche Fehler woanders zu suchen ist. #define eeprom_wr(addr,b) (EEAR=addr, EEDR=b, EECR |= (1<<EEMWE),EECR |= (1<<EEWE)) "-> CompilerMeckerzeile" extern Byte eeprom_rd(uint16 addr); /*_____ D E F I N I T I O N S ______________________________________________*/ /*_____ D E C L A R A T I O N S ____________________________________________*/ #endif /* _EEPROM_H */
Ich vermute den Fehler bei der Typangabe! "Byte" wird wohl unbekannt sein...
zu Deutsch die Routinen sind für den Gebrauch mit WinAvr unbrauchbar? Kann man das Byte durch etwas sinnvolles ersetzen? Das gleiche Elend wird mich ja dann wohl bei den CAN-Routinen heimsuchen?
Wurde schon alles gesagt: [Zitat mthomas] >- die etwas "exotischen" Namen von Integerdatentypen im IAR-Code >lassen sich mit ein paar typdefs oder defines an avr-libc/stdint >anpassen Mit anderen Worten: typedef unsigned char Byte; Byte xYz = 0xAA;
Hi oder gleich ordentlich und die Typen aus inttypes.h verwenden. Mit einem sed auf alle Dateien sollte das nicht weiter schweirig sein das umzubauen. Matthias
Sorry, Matthias, wenn ich Dich korrigiere, aber mit dem aktuellen WinAVR sollte man stdint.h verwenden.
Hi ist doch OK. Ich hatte mich eben auch gewundert als ich eben diese stdint.h nicht in meiner WINAVR Installation gefunden habe. Bin noch nicht auf dem aktuellen Stand da es noch ein paar alte Projekte mit sbi() und cbi() umzubauen gilt. Matthias
@OldBug Erst mal Danke für die Hilfe. Mal schauen, ob ich rausbekomme, wo die Zeile hingehört. Was ist jetzt eigentlich schon wieder sbi() und cbi() falsch, oder nicht mehr richtig? Lass mich raten: "Lies das Manual?"
sbi()/cbi() und allerlei anderer "historischer Krempel" sind seit Jahren deprecated und sollten schon lange nicht mehr für Neuentwicklungen verwendet werden. Jetzt sind sie einfach nicht mehr da und können auch nicht mehr verwendet werden.
Sorry! Ich habs gerade mit sei() cli() verwechselt und wollte gerade einen Herzinfarkt bekommen.
Übrigens ist <inttypes.h> durchaus auch auf der sicheren Seite. Der Standard garantiert (effektiv), dass <inttypes.h> die Datei <stdint.h> includiert. <inttypes.h> ist eigentlich noch für ein paar Konvertierungen gedacht, aber so weit sind wir noch nicht.
>Das gleiche Elend wird mich ja dann wohl bei den CAN-Routinen >heimsuchen? Was die Datentypen betrifft ja - das gleiche "Elend". Der Code ist halt fuer den IAR-Compiler gemacht, die genutzen Typdefinitionen finden sich in der Datei compiler.h in der zip-Datei. Man kann wie von Matthias vorgeschlagen im ganzen Code "suchen/ersetzen" durch stdint-Typen, habe das allerdings nicht gemacht, da man sonst in der naechsten Version der lib (so es die irgendwann gibt) das Ganze nochmal machen darf (ok, mit sed auch schnell erledigt). Mit "Kompatibilitaets-Typedefs" muss jedoch nur an zweidrei Stellen ein #include fuer die typedefs eingefuegt werden. Ein paar Kleinigkeiten gibts bei der Portierung des CAN-Codes noch zu beachten, habe das oben schon aufgezaehlt, aber alles nicht dramatisch, einfach loslegen und die Compiler-Fehler der Reihe nach "abarbeiten". Zur Anpassung der CAN-Autobaud Assemblerroutine an den "avr-gnu-Assembler" muss man etwas in der Dokumentation der avr-libc und des gnu-Assemblers lesen, aber es sind auch nur ca. 10 Zeilen zu aendern/zu ergaenzen. Die Assemblerroutine ist bei bekannter CAN-Baudrate (im Beispiel 100kbps) aber nicht notwendig. > zu Deutsch die Routinen sind für den Gebrauch mit WinAvr unbrauchbar? Nein, eher nicht direkt "einsatzbereit". Der allergroesste Teil des Originalcodes kann unveraendert genutzt werden. Eine auf avr-gcc/avr-libc portierte Fassung der Atmel CAN-Lib inkl. des "echo-Beispiels" funktioniert "hier" zumindest im AVRStudio CAN-Simulator-Plugin wie erwartet. Ob auch in echter Hardware wird sich zeigen. Der Code ist - zumindest fuer mich - hilfreich, auf jeden Fall bis die CAN-Funktionalitaet des CAN128 komplett verstanden ist und man sich dann evtl. "bessere" eigene Routinen bastelt kann. Es gibt auch noch weiteren etwas aeltern Code von Atmel fuer den CAN128 mit mehr Funktionen (von der "Atmel CAN-CD"), in diesem ist etwas mehr anzupassen, da einige Register/Bits im Laufe der Entwicklung scheinbar umbenannt wurden, aber darum geht's ja hier nicht.
Ich konnte den Compiler noch immer nicht zufrieden stellen. Die Typdefs scheinen zu funktionieren aber bei dieser Zeile bit eeprom_wr_block (Byte _MemType_* src, Uint16 dest, Byte n); meckert er wieder. C:/Programme/WinAVR/bin/../lib/gcc/avr/3.4.3/../../../../avr/include/can 128/eep_lib.h:67: error: parse error before '*' token Liegt wohl daran, dass er _MemType_* nicht kennt. Hat jemand eine Idee??
Was genau meinst Du? Die Datei per include einbinden? Hab ich eigentlich gemacht. Stell ich mich mal wieder zu doof an?
Hallo, kann mir einer helfen,
muss/will CAN machen auf den 90CAN128 unter C, da ja sonst kein
Quellecode vorhanden.
C ist bei mir ein wenig her und so wollte ich mal einfach anfangen und
auf meiner Hardware mal nur ein paar led's blinken lassen.
Dazu habe ich den GCC installiert mit dem Programmers Notepad.
Kleine Routine:
#include <avr/io.h>
uint8_t test = 0;
uint8_t loop = 0;
int wait(void)
{
uint8_t count0 = 0xFF;
uint8_t count1 = 0xFF;
do
{
do
{
--count1;
}
while (count1 != 0);
count1 = 0xFF;
--count0;
}
while (count0 != 0);
return (0);
}
int main(void)
{
DDRA = 0xff;
DDRF = 0x03;
PORTA = 0xFF;
PORTF = 0x03;
do
{
++test;
PORTA = test;
PORTF &= ~(1 << 0); /* loescht Bit 0 an PortF */
PORTF |= (1 << 0); /* setzt Bit 0 an PortF auf 1 */
/*wait();*/
}
while(loop == 0);
}
mittels dwarf kann man ja im Studio schrittweise testen was passiert, dabei kann ich aber nicht die Variablen ansehen, da 'not in scope' und unter dem Dissambler treten ungereimtheiten auf wegen der Registeradressen. Im Makefile kann ma ja auch leider nicht den CAN128 sondern nur den mega128 anwählen. Den Fehler würde ich darauf zurückführen. Gibts da was Neues oder woist das .def File um das zu ergänzen? Bin ziehmlich frustriert. Wenns so weitergeht mache ich wieder in .asm Charly
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.