mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ATmega128RFA1


Autor: X- Rocka (x-rocka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Atmel kündigt neuen Chip an:
ATmega128RFA1 = ATmega1281 + AT86RF??

http://www.atmel.com/products/zigbee/single-chip.a...

Sieht toll aus, genau so etwas brauche ich! :-)

Das doofe: typisch Atmel, lange vor Erhältlichkeit ankündigen. :-(

Bitte hier posten, falls jemand was rausfindet wann man die Teile 
bekommt!

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist nicht typisch Atmel, das ist typisch Business. Guck dir an wie 
früh Computerspiele angekündigt und verschoben werden...

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei Dresden Elektronik gibts schon seit geraumer Zeit Eval-Boards mit 
dem Chip...

Autor: X- Rocka (x-rocka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian R. schrieb:
> Bei Dresden Elektronik gibts schon seit geraumer Zeit Eval-Boards mit
> dem Chip...

Wer wie wo was?!

Danke!

Autor: Robert S. (razer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: X- Rocka (x-rocka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
jau, hatte es auch gerade gegoogelt!
da muss man schon wohl special customer (Beta-Tester?) bei Atmel sein, 
um die Dinger so früh zu bekommen.

mal sehen, ich bräuchte es eigentlich eine Nummer kleiner, eigentlich 
nur den Chip, aber zum spielen okay.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dresden Elektronik macht ja viele (alle?) Demoboards für Atmel.

Autor: X- Rocka (x-rocka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian R. schrieb:
> Dresden Elektronik macht ja viele (alle?) Demoboards für Atmel.

DAS erklärt einiges! Danke für die Info.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wird der Chip eigendlich schon vom GCC Compiler unterstützt?

Gruss Patrick

Autor: knut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
in winavr vom märz 2009 is der RFA schon drin. readme lesen!

Autor: MainSter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hat schon jemand erfahrungen mit Atmel's Funk- Chip gesammelt? Meine 
Boards von Dresden- Elektronik sind gekommen und mit WinAVR kann ich 
direkt loslegen. Allerdings wundert es mich das der Controller im 
AVRstudio 4.18 noch nicht voll unterstützt ist (nur assembler??)

Hab ich da die falsche Datei erwischt oder hat jemand das selbe Problem?

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ankuendigen heisst bei Atmel: Falls wir die Sache nicht in mind. 2 
Jahren vergessen haben, sind erste Muster moeglicherweise lieferbar. In 
unseren Tabellen wird alles aber natuerlich schon jetzt als erhaeltlich 
markiert, immerhin will man ja Kaeufer fuer das nicht vorhandene Produkt 
bekommen. Siehe Xmega selbst, bis heute nur in mikroskopischen 
Stueckzahlen erhaeltlich und daher fast nirgendwo auf Lager.

Autor: MainSter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, mit der Xmega- reihe könnte es wirklich bald losgehen. Trotzdem 
gebe ich, was das "Businnes" angeht, Simon K. recht.

Dass allerdings ein Produkt erhältlich ist aber die Firmen- eigene 
Entwicklungsumgebung hinterherhinkt (wenn es nun stimmt) finde ich auch 
etwas schwach!

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
XMega128-A1 ist inzwischen Lagerware bei vielen Distris. Ebenso der 
..64-A1 und der ..16-A3.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MainSter schrieb:
> Allerdings wundert es mich das der Controller im
> AVRstudio 4.18 noch nicht voll unterstützt ist (nur assembler??)

Was heißt das denn?  Die Unterstützung für C kommt doch aus dem
WinAVR, nicht aus dem AVR Studio, und WinAVR kannte den Chip bereits
im letzten Jahr (wenngleich damals noch mit einem hässlichen Bug
bei der Platzierung des Datensegments, daher ist 20100111 dringend
anzuraten).

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael G. schrieb:
> Ankuendigen heisst bei Atmel: Falls wir die Sache nicht in mind. 2
> Jahren vergessen haben, sind erste Muster moeglicherweise lieferbar.

Na na.  Der ATmega128RFA1 ist kein Xmega...  Ansonsten könnte
Dresden Elektronik wohl kaum schon Module damit zum Verkauf
anbieten, oder?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MainSter schrieb:
> hat schon jemand erfahrungen mit Atmel's Funk- Chip gesammelt?

Mittlerweile hat Axel auch den Support für das Board von Dresden
Elektronik ins µracoli aufgenommen.

Autor: MainSter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Jörg Wunsch

schähm ich dachte mir doch dass das nicht sein kann. Ok hab das 
neueste WinAVR installiert, danke für den Tip für dieses "Glasklare" 
Problem.

Autor: MainSter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
>Mittlerweile hat Axel auch den Support für das Board von Dresden
>Elektronik ins µracoli aufgenommen.

Ich verwende das deRFmega128 von dresden elektronik, ich glaube das 
Board / der Controller (ATmega128RFA1) wird von Axel's µracoli noch 
nicht unterstützt

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MainSter schrieb:

> Ich verwende das deRFmega128 von dresden elektronik, ich glaube das
> Board / der Controller (ATmega128RFA1) wird von Axel's µracoli noch
> nicht unterstützt

Doch.  Aus den RELEASENOTES:

0.0.11 20100121
 New Features
  - added new hardware abstraction using board.cfg file
  - addded Zigbit Core for Arduino
  - added python serial throuput tool wuarttest.py
 New Hardware
  - MCU ATmega8, Atmega88, Atmega644P, ATmega128RFA1
                                       ^^^^^^^^^^^^^
  - Boards: littleGee V3, stkm8, rbb128rfa1, derfa1
                                             ^^^^^^
 Bugs
  - #28148: incorporate patch that simplifies aps file generation
    (xsl transformation was replaced by simple text transformation)
 Changes/Misc
  - raven usb stick uses now correct uracoli VID/PID
  - clean up of warnings in the code
  - reworked linear buffer examples
  - refactoring of wuart application
  - io data handling in ieee802154_io.py
  - continued documentation

Autor: X- Rocka (x-rocka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe mir 3 von den Dresden-Elektronik Boards zugelegt, eine Basisplatine 
mit Strom und USB_UART, und noch eine Analog/Digital Eingangsplatine 
dazu.
Ich kann jetzt mit meinen ATmega128RFA1 reden, latürnich erstmal nur 
über UART. ADC funktioniert auch, Timer auch. Programmierung janz normal 
mit ISP (AVRISP mk2).

Der ADC ist leider etwas anders als bei den kleinen ATmegas die ich 
kenne, mit maximal 1.8V externer AREF. Habe natürlich meinen Analogteil 
auf 3.3V wie den Rest auch ausgelegt, was mich vor allem beim 3-achsigen 
Accelerometer nervt... (Teilerwiderstände auf Filter-Cs gelötet.)
Nerviger ist aber, dass ich Trottel mir nen FT232RQ in QFN-32 
draufgebaut habe, weil es ja unbedingt klein sein musste. An sich kann 
ma ja auch QFNs löten, aber bei DIESEM FTDI Chip ist irgenwas anders, 
geht ganz schlecht.

ATmega128RFA1 ist registermäßig fast 100% kompatibel zum ATmega1281, die 
RF Register sind alle oberhalb der alten 1281er angesiedelt.
Ich arbeite mit Codevision, der kennt den Chip noch nicht, muss also 
demnächst die ganzen Extra-Register ins .h eindaddeln. Bei Interesse 
dann melden, wird aber noch dauern.

Und dann noch viel schlimmer: gaaaaanz viel Datenblatt lesen, weil ich 
von Wireless wenig Ahnung habe, und es noch nix offizielles zu dem Chip 
gibt.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
X- Rocka schrieb:
> Der ADC ist leider etwas anders als bei den kleinen ATmegas die ich
> kenne, mit maximal 1.8V externer AREF.

Das liegt daran, dass er intern alles auf 1,8 V regelt, auch der
ADC wird von diesen geregelten 1,8 V versorgt.  Logisch, dass er
dann nicht mehr als das messen kann.  (Die IO-Pins werden dagegen
direkt von Vcc versorgt, die haben dann Pegelwandler zum Core.)

> Und dann noch viel schlimmer: gaaaaanz viel Datenblatt lesen, weil ich
> von Wireless wenig Ahnung habe, und es noch nix offizielles zu dem Chip
> gibt.

Was erwartest du denn "offizielles" wenn nicht das Datenblatt?

Wie schon geschrieben, µracoli unterstützt die Dresden-Elektronik-
Boards.  Ist allerdings für den GCC geschrieben, aber sollte dir
zumindest erstmal Beispielcode liefern können.  Die Programmierung
des Transceivers ist im Grunde genommen nicht viel anders, als
wenn man einen AT86RF231 programmieren würde, nur dass man natürlich
das langsame SPI nicht mehr dazwischen hat, sondern die Register alle
im IO address space der CPU liegen.  Die hauptsächlichen Unterschiede
zum AT86RF231 liegen in der Interruptbehandlung, die ist beim
ATmega128RFA1 mehr "AVR like": du hast einen Vektor pro Interruptquelle,
und das Bit im IRQ-Status-Register wird beim Aufruf der ISR gelöscht
oder manuell, indem man eine 1 hineinschreibt.  Beim AT86RF231 wird
das Register gelöscht, indem man es ausliest.  Danach musste man also
die einzelnen Interrupts ggf. "verteilen gehen".

Autor: X- Rocka (x-rocka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe meine pcbs so schnell gemacht, weil ich morgen für 5 Wochen in 
die USA fliege, darunter litt dann auch die exakte Datenblatt Recherche 
-> siehe ADC...

Gerade das nette AVR Interrupt Handling macht das ganze sehr interessant 
für mich. Ich bin schon gespannt! Habe auch gerade was von uracoli 
runtergeladen.

mit "offiziellem" meinte ich noch mehr auf diesen chip bezogene ANs und 
natürlich Unterstützung durch Codevision.

Autor: X- Rocka (x-rocka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, jetzt kann ich mich endlich mit dem RF Part des Chips beschäftigen.
Dazu habe ich einige Fragen, vielleicht kann mir ein RF-Experte helfen:

- Was ist der Unterschied zwischen MPDU (MAC Payload Data Unit) und PSDU 
(PHY Service Data Unit)? Scheint mir irgendwie dasselbe zu sein, aber 
warum diese unterschiedlichen Bezeichnungen? Nur wegen unterschiedlicher 
OSI-Layers?

- MAC Header des MPDU: Den muss ich mir entsprechend und inkl. des FCF 
(Frame Control Field) selber zusammenbauen (Sender), bzw. auswerten 
(Empfänger)? Und ist Anfang des Frame Buffers?

- Was ist ein Beacon? (ja, eine große Lampe wie auf nem Leuchtturm... 
aber einem Netzwerk?)

Hoffe auf Hilfe...,
X

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
X- Rocka schrieb:

> - Was ist der Unterschied zwischen MPDU (MAC Payload Data Unit) und PSDU

MAC Protocol Data Unit

> (PHY Service Data Unit)? Scheint mir irgendwie dasselbe zu sein, aber
> warum diese unterschiedlichen Bezeichnungen? Nur wegen unterschiedlicher
> OSI-Layers?

Ja.  Das ist der Übergang zwischen beiden Schichten.  Aus Sicht des
PHY ist es die PSDU, d. h. der Dateninhalt, aus Sicht des MAC ist
es die MPDU, d. h. alles, was der MAC davon kennt.  Der streicht
dann seinen MHR und MFR raus, und übrig bleibt seine MSDU, die er
der nächsten Schicht nach oben gibt.

> - MAC Header des MPDU: Den muss ich mir entsprechend und inkl. des FCF
> (Frame Control Field) selber zusammenbauen (Sender), bzw. auswerten
> (Empfänger)? Und ist Anfang des Frame Buffers?

Ja.  Beim Empfang im RX_AACK wertet allerdings die Hardware bereits
die Adressierung aus, das musst du nicht selbst tun.

> - Was ist ein Beacon?

Eine Bake. ;-)  Ein spezieller Rahmen, der entweder auf Anforderung
(beacon request in einem Netzwerk, das sonst nicht mit beacons
arbeitet) oder periodisch (beacon-enabled network) vom örtlichen
Koordinator verschickt wird.  Er enthält Informationen über das
Netzwerk.

Autor: X- Rocka (x-rocka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke, danke, und nochmals danke! :)

Autor: X- Rocka (x-rocka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schon wieder ich...

Ich bekomme es nicht hin, den Chip in irgendeinen TRX_STATE ausser 
TRX_OFF zu bringen.
Gibt es noch irgendein PLL oder Clock Register, bei dem ich dem Ding 
irgendwas zuweisen muss?

Hier meine set / get state Funktionen:
- SLPTR und TRXRST werden vorher auf 0 gesetzt
- mit trx_get_state() überprüfe ich immer "STATE_IN_TRANSITION" und den 
neuen STATE
// in der transceiver ini nach register schreiben in TRX_OFF
  trx_set_state(TRX_CMD_RX_AACK_ON);


// ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// get set state functions
unsigned char trx_get_state(void)
{
  return( TRX_STATUS & TRX_STATE_MASK );
}

void trx_set_state(unsigned char new_trx_state)
{
  while( trx_get_state() == TRX_ST_TRANSITION );
  TRX_STATE &= ( TRAC_STATUS_MASK | new_trx_state );
  while( trx_get_state() == TRX_ST_TRANSITION );

//**********DEBUG
#ifdef DEBUG
  if( trx_get_state() != new_trx_state ) LED_RED = LED_ON;
  else LED_RED = LED_OFF;
#endif
}

Ergebnis: LED immmer an, und er gibt mir über USART0 aus, dass er in 
TRX_OFF sich befindet.

Gute Nacht - hier ist es 0:23.

X

PS: kompiliere mit Codevision und selbstgemachtem .h File für die 
Register, abgeleitet vom ATmega1281. Habe alles gecheckt, sollte 
stimmen. sollte... habe es mit dem winavr header verglichen, 
Registersaddressen und Interrupt Vektoren stimmen auch.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
X- Rocka schrieb:
void trx_set_state(unsigned char new_trx_state)
{
  while( trx_get_state() == TRX_ST_TRANSITION );
  TRX_STATE &= ( TRAC_STATUS_MASK | new_trx_state );
  while( trx_get_state() == TRX_ST_TRANSITION );
}

Da hast du einen Logico drin.  Ich habe das mal um
#include <avr/io.h>

#define TRX_STATE_MASK 0x1f
#define TRX_ST_TRANSITION 31
#define TRAC_STATUS_MASK 0xe0

erweitert und durch den GCC geschickt.  Hier das Resultat:
trx_set_state:
/* prologue: function */
/* frame size = 0 */
        mov r25,r24
.L4:
        lds r24,321
        andi r24,lo8(31)
        cpi r24,lo8(31)
        breq .L4
*** hier:
        lds r24,322
        ori r25,lo8(-32)
        and r24,r25
        sts 322,r24
*** :bis hier
.L5:
        lds r24,321
        andi r24,lo8(31)
        cpi r24,lo8(31)
        breq .L5
/* epilogue start */
        ret

Nun steht in deinem TRX_STATE noch nichts drin, also die initiale 0.
Die liest du nach r24.  Dann wird dein Kommando TRX_CMD_RX_AACK_ON =
0x16 mit 0xe0 (TRAC_STATUS_MASK) verODERt, ergibt 0xf6 in r25.
Das wird mit r24 verUNDet -- und voila, es kommt wieder 0 raus. ;-)
Die wird dann nach TRX_STATE geschrieben...  (0 ist ein NOP.)

Den ganzen Zinnober musst du aber gar nicht tun.  Die TRAC_STATUS-
Bits im oberen Teil von TRX_STATE sind read-only, damit kannst du dem
ganzen Register einfach dein Kommando aufbrummen:
TRX_STATE = new_trx_state;

new_trx_state ist leicht falsch benannt, es müsste trx_cmd heißen.  Es
gibt Kommandos wie FORCE_TRX_OFF, die nicht in einem gleichlautenden
Status enden.

Autor: X- Rocka (x-rocka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aua, "&=" ist natürlich völliger Blödsinn an dieser Stelle!
Ich dachte mir schon, dass es was ganz banales ist...
Ich verbeuge mich in Dankbarkeit!

X

Autor: X- Rocka (x-rocka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Läuft jetzt alles wunderbar, muss mir nochmal die Register anschauen ob 
ich noch ein wenig Reichweiten-Tuning betreiben kann.

Habe alles mit Codevision gemacht, als 1281 mit modifiziertem Header 
File und einer kleinen Änderung im Codevision Projekt-File.
Näheres zum Codevsision-Tuning später, falls Interesse besteht.

Nochmals danke an Jörg Wunsch für:
1. Den Tipp das Dresden Elektronik Boards mit dem Chip hat, und
2. Für die Infos und Debugging Hilfe!

X

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
X- Rocka schrieb:
> Nochmals danke an Jörg Wunsch für:
> 1. Den Tipp das Dresden Elektronik Boards mit dem Chip hat,

Die Blumen gehen aber bitte an Christian R. ;-)

Autor: X- Rocka (x-rocka)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> X- Rocka schrieb:
>> Nochmals danke an Jörg Wunsch für:
>> 1. Den Tipp das Dresden Elektronik Boards mit dem Chip hat,
>
> Die Blumen gehen aber bitte an Christian R. ;-)

Oh ja, also auch großes Danke an ihn!

Hier das Header File für den ATmega128RFA1 für Codevision User.

ACHTUNG:
Die folgenden Sachen müssen noch beachtet / eingestellt werden:

- in Codevision das ganze als ATmega1281 kompilieren

- im Codevision Projekt-File *.prj die maximale Anzahl an 
Interrupt-Vectoren auf 72 setzen (geht mit Texteditor) 
"InterruptVectorsNumber=72"

- Chip und Fuses mit aktuellem AVR Studio >=4.18 flashen.

- Datenblatt nochmal genau mit 1281 vergleichen, irgendwas war mit den 
ADC Settings anders (bin mir nicht mehr sicher)

Viel Spass!

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
X- Rocka schrieb:
> Datenblatt nochmal genau mit 1281 vergleichen, irgendwas war mit den
> ADC Settings anders (bin mir nicht mehr sicher)

Naja, es sind schon ein paar Sachen anders im Vergleich zum ATmega1281.
Aus dem Hut, ohne Anspruch auf Vollständigkeit:

. 16 KiB SRAM (statt 8)
. geringere Anzahl von IO-Ports, sollte kein Problem sein, einfach
  die fehlenden nicht benutzen
. kein Zugriff auf externen Speicher
. der interne RC-Oszillator arbeitet mit 16 MHz (statt 8 MHz); die
  clock-prescaler-Werte wurden ATmega1281-kompatibel gelassen (d.h.
  ein Prescaler von 8 wird intern automatisch zur 16, wenn mit dem
  RC-Oszillator gearbeitet wird), dafür gibt es einen neuen Wert,
  mit dem man den RC-Oszillator mit vollen 16 MHz nutzen kann
. der ADC wird intern von stabilisierten 1,8 V betrieben und kann
  daher nur maximal 1,8 V an den Eingängen und als Referenz
  benutzen; entsprechend sind die ADMUX-Einstellungen nicht identisch
  zum ATmega1281, außerdem gibt es ein paar Bits mehr zum Verstellen
  der Timing-Werte
. die Registeradressen der nicht vorhandenen USART3 sind anderweitig
  benutzt worden; für den normalen Nutzer sind da aber bestenfalls
  die Einstellungen für die Treiberstärke der Pins von Interesse
. die Behandlung des 32-kHz-Oszillators ist leicht geändert, da er
  im ATmega128RFA1 sowohl den Timer/Counter 2 als auch den MAC Symbol
  Counter speisen kann
. die ISP-Pins sind so, wie sie beim ATmega1280 oder ATmega329 & Co.
  liegen, also komplett auf dem SPI-Interface

Autor: X- Rocka (x-rocka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
...

Danke für diese Klarstellung!

Ich kenne den 1281 nicht, deswegen waren mir einige Unterschiede nicht 
bewusst. Habe natürlich nur nach denen für meine Applikation gesucht...

X

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
X- Rocka schrieb:
> Habe natürlich nur nach denen für meine Applikation gesucht...

Nun, zumindest den MAC Symbol Counter solltest du dir vielleicht mal
ansehen.  Der lässt sich mit konstanten 62,5 kHz (16 µs Symbolperiode)
antreiben, wobei zwischen einer exakten Generierung aus dem 16-MHz-
Quarz (sofern er aktiv ist) und einer Fractional-N-Generierung aus
dem 32,768-kHz-Quarz automatisch umgeschaltet wird.  Das Ganze dann
als 32-bit-Zähler, damit bekommt man irgendwas bei 18 Stunden
Umlaufzeit.

Autor: X- Rocka (x-rocka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh ja, es gibt da noch einiges für mich zu erforschen!
Was RF angeht bin ich Neuling, deswegen bin ich erstmal froh, dass ich 
überhaupt Daten durch die Luft schicken kann.

Aber sobald ich dafür wieder Zeit habe, geht's weiter.
Gerade für Synchronisation mehrerer Nodes werde ich dann auch den MAC 
Symbol Counter brauchen.

Autor: user (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi, ich habe keinen zugriff mehr auf meinen ATmega128RFA1 ich habe auf 
einer selbstentwickelten platine den internen takt umgestellt und nun 
geht nix mehr. also ich habe einen anderen internen takt 
eingestellt(quarz wurde noch nicht geliefert...).

ein ext. takt ist auch nicht eingestellt, da mittels anschluss eines 
takts an XTAL1 ich auch nicht auf den µC zugreifen kann... oder kann 
sein dass ich mit ext. takt nichts erreichen kann wenn ich auf ein quarz 
gefused habe???

oder gibts sonst noch irgendwelche möglichkeiten die via isp ein 
funktionierendes system lamlegen?

Autor: X- Rocka (x-rocka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
funktionsgenerator als externen takt anschliessen  und neu fusen.
vorsicht, pegel vorher am oszi prüfen!

Autor: user (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja, des geht ja eben nicht... (hab ich oben auch geschrieben...)

das ist ja eben auch das einige was man bei google finden kann...

und nochwas: ich habe in der vergangenheit schon mehrere verfuste avrs 
wiederbelebt...

aber bei dem....???????

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
user schrieb:
> ich habe auf
> einer selbstentwickelten platine den internen takt umgestellt und nun
> geht nix mehr.

. Was genau hast du getan?
. Was "geht nix mehr"?  JTAG?  ISP?  Das Programm selbst?

Autor: user (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
isp geht nicht mehr(also so als ob am avr-usb-lab kein target 
angeschlossen wäre; am programmer liegts nicht, da es mit anderen 
targets funktioniert)

da ich über die uart mittels cp2102 daten den pc senden wollte habe ich 
eine andere "interne" taktquelle im (Avr studio) gewählt von dort an 
konnte ich nicht mit mehr mit den rfa1 kommunizieren was allerdings 
komisch war, ist - als ich noch über isp zugreifen konnte,dass z.b. eine 
blinkende led nur nach der programmierung geblinkt hat. nach aus - 
einschalten begann sie nur in den seltensten fällen zu toggeln. das 
alles mit interner clock, da die quarze noch nicht geliefert wurden.

bitte um hilfe. -danke!

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was soll denn »eine andere "interne" Taktquelle« bitte genau sein?

Das Ding hat nur eine einzige interne Taktquelle, den RC-Oszillator,
und mit dem aktiviert wird sie ausgeliefert.  Da brauchst du nichts
zu verstellen.  (Du kannst die CKDIV8-Fuse abschalten, aber das ändert
nur den Taktteiler, davon geht nichts kaputt.  Diese Fuse gibt's beim
ATmega128RFA1 nur aus Kompatibilität zum ATmega1281, ansonsten wäre
sie gar nicht nötig.)

Bevor wir dir helfen können, wirst du uns wohl genaus sagen müssen,
welche Fuse-Einstellungen du nun hast.  U. U. würde dich bereits
eine JTAG-Programmierung wieder retten, denn die braucht keinen
laufenden CPU-Takt.

Autor: user (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gut, ich weis, dass die infos a bissl dürftig sind. die fuses kann sich 
via spi nichtmehr auslesen.

ich dachte mir auch, dass es da nur den int. 16MHz gibt, da war halt im 
avr_studio noch ein anderer int. takt wählbar was genau dahinter stand 
weiß ich nimmer, weil ich nicht damit gerechnet hab dass es solche 
folgen haben wird.

dann informiere ich mich mal über jtag und schau was ich alles dafür 
brauch...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, ich habe mir gerade das XML-File mal angesehen (in dem ja die
Texte drin stehen, die AVR Studio anzeigt), hast du eventuell den
internen 128-kHz-Oszillator (Watchdog-Oszillator) ausgewählt?

Wenn ja, dann musst du jetzt seeeeeehr laaaangsaaaam mit ihm ISP
reden, da ja die ISP-Taktfrequenz weniger als 1/4 der CPU-Taktfrequenz
sein muss.

Autor: user (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
jetzt wo ich es sehe...
...es war der 128kHz WD-timer!

allerdings kann ich mit 4.889 kHz ISP nichts aus dem uC lesen oder mit 
ihn komunizieren. auch über jtag war es erfolglos.

da wird mir wohl nix anderes übrig bleiben als wieder QFN zu löten *freu 
:-(*

was mir noch eingefallen ist:

ich habe ja auf der platine noch einen cp2102(gibt zusätzlich 3V3 
stabilisiert aus) bei dem ich mit dem uC nur TxD und RxD verbunden habe 
und natürlich masse.
wenn ich jetzt USB am PC anschließe habe ich ca. 2V5 auf der Versorgung 
des uC ohne eine andere spannungsquelle.
1. kann das sein dass es intern über den uC von der uart kommt???
2. kann die ursache auch sein dass evtl. der fusebit-schreibevorgang 
ohne richte Vcc durchgeführt wurde???

komisch war auch noch(ich habe es oben schon erwähnt), dass der uC mit 
lauffähigen programm meist erst "angelaufen" ist, nachdem ich neu 
programmiert habe...

alles noch auffälligkeiten - vllt. ist ja noch ein hinweis dabei - aber 
wiegesagt: löten!

Autor: ??? (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich wollte soeben das Programm wuart von µracoli auf eigener hw mit 
atmega128rfa1 testen. Beim 1. Board kam nach dem Flashen:

Wuart 0.2 chan=17
und bei den anderen beiden: Wuart 0.2 chan=17 RADIO DOES NOT MATCG!

liegt das dann wirklich an der Teile oder Versions-nummer?
d.h. ich kann die controller vergessen(f**k QFN)!?

haben die zahlen auf dem Gehäuse atmelextern auch was zu sagen?

kann mir jemand helfen oder hatte schon mal das selbe prob?

danke

Autor: ps-gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
X- Rocka schrieb:
>Bitte hier posten, falls jemand was rausfindet wann man die Teile
>bekommt!

Ich weiss nicht, ob ihrs schon gesehen habt, der Chip ist nun auch bei 
Mouser-Elektronik erhältlich. 
(http://de.mouser.com/ProductDetail/Atmel/ATMEGA128...) 
Zur Zeit sollen über 1800 Stück an Lager sein.

Mit freundlichen Grüssen

Autor: ps-gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich muss leider noch ein Nachtrag zu meinem vorherigen Beitrag machen. 
Aufgrund von Lieferbestimmungen können die MCUs zumindest nicht in die 
Schweiz geliefert werden, vielleicht klappts nach Deutschland, dass 
halte ich aber für eher unwahrscheinlich.

Mit freundlichen Grüssen

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ps-gast schrieb:
> Ich muss leider noch ein Nachtrag zu meinem vorherigen Beitrag machen.
> Aufgrund von Lieferbestimmungen können die MCUs zumindest nicht in die
> Schweiz geliefert werden, vielleicht klappts nach Deutschland, dass
> halte ich aber für eher unwahrscheinlich.

Das ist besonders lustig, wenn man bedenkt, dass dieser Missstand
nur dadurch entsteht, dass die MCUs zuvor erst durch Mouser in die
USA importiert worden sind.  Damit fallen sie offenbar durch den
eingebauten AES-Block nun unter die <zensiert> US-amerikanischen
Crypto-Bestimmungen.

Überzeuge also einen deutschen Distributor, dass er sie ins Programm
nimmt, der wird sie dir auch in die Schweiz exportieren dürfen.

Xmegas dürften dann eigentlich das gleiche Schicksal erleiden, denn
die haben auch eingebaute Crypto-Hardware.

Autor: PS-Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Digi-Key liefert sie mir (erstaunlicherweise) ohne Probleme aus, obwohl 
die auch aus den USA liefern. Ich musste aber bei der Bestellung den 
Verwendungszweck und den Endbenutzer detailiert angeben.

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.