mikrocontroller.net

Forum: Compiler & IDEs 90CAN128-Tools von Atmel


Autor: flyingwolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: mthomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: flyingwolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: mthomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: flyingwolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht zeigst Du uns mal die "angemeckerte" Zeile 46 aus Deinem
Sourcecode!?

Autor: flyingwolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der ist ja nicht von mir, das ist ja das Zeugs aus den AVR-Drivern.

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: flyingwolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 */

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich vermute den Fehler bei der Typangabe!

"Byte" wird wohl unbekannt sein...

Autor: flyingwolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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;

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, Matthias, wenn ich Dich korrigiere, aber mit dem aktuellen WinAVR
sollte man stdint.h verwenden.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: flyingwolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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?"

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: flyingwolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry! Ich habs gerade mit sei() cli() verwechselt und wollte gerade
einen Herzinfarkt bekommen.

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ü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.

Autor: mthomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: flyingwolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@mthomas
Ich stelle mich gerne als Hardwaretester zur Verfügung ;-)

Autor: flyingwolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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??

Autor: mthomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
siehe compiler.h

Autor: flyingwolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was genau meinst Du? Die Datei per include einbinden? Hab ich eigentlich
gemacht. Stell ich mich mal wieder zu doof an?

Autor: Charly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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);
}

Autor: Charly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.