Atmel kündigt neuen Chip an: ATmega128RFA1 = ATmega1281 + AT86RF?? http://www.atmel.com/products/zigbee/single-chip.asp?source=home 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!
Das ist nicht typisch Atmel, das ist typisch Business. Guck dir an wie früh Computerspiele angekündigt und verschoben werden...
Christian R. schrieb: > Bei Dresden Elektronik gibts schon seit geraumer Zeit Eval-Boards mit > dem Chip... Wer wie wo was?! Danke!
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.
Christian R. schrieb:
> Dresden Elektronik macht ja viele (alle?) Demoboards für Atmel.
DAS erklärt einiges! Danke für die Info.
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?
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.
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!
XMega128-A1 ist inzwischen Lagerware bei vielen Distris. Ebenso der ..64-A1 und der ..16-A3.
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).
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?
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.
@ 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.
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
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
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.
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".
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.
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
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.
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
1 | // in der transceiver ini nach register schreiben in TRX_OFF
|
2 | trx_set_state(TRX_CMD_RX_AACK_ON); |
3 | |
4 | |
5 | // ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
6 | // get set state functions
|
7 | unsigned char trx_get_state(void) |
8 | {
|
9 | return( TRX_STATUS & TRX_STATE_MASK ); |
10 | }
|
11 | |
12 | void trx_set_state(unsigned char new_trx_state) |
13 | {
|
14 | while( trx_get_state() == TRX_ST_TRANSITION ); |
15 | TRX_STATE &= ( TRAC_STATUS_MASK | new_trx_state ); |
16 | while( trx_get_state() == TRX_ST_TRANSITION ); |
17 | |
18 | //**********DEBUG
|
19 | #ifdef DEBUG
|
20 | if( trx_get_state() != new_trx_state ) LED_RED = LED_ON; |
21 | else LED_RED = LED_OFF; |
22 | #endif
|
23 | }
|
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.
X- Rocka schrieb:
1 | void trx_set_state(unsigned char new_trx_state) |
2 | {
|
3 | while( trx_get_state() == TRX_ST_TRANSITION ); |
4 | TRX_STATE &= ( TRAC_STATUS_MASK | new_trx_state ); |
5 | while( trx_get_state() == TRX_ST_TRANSITION ); |
6 | }
|
Da hast du einen Logico drin. Ich habe das mal um
1 | #include <avr/io.h> |
2 | |
3 | #define TRX_STATE_MASK 0x1f
|
4 | #define TRX_ST_TRANSITION 31
|
5 | #define TRAC_STATUS_MASK 0xe0
|
erweitert und durch den GCC geschickt. Hier das Resultat:
1 | trx_set_state: |
2 | /* prologue: function */ |
3 | /* frame size = 0 */ |
4 | mov r25,r24 |
5 | .L4: |
6 | lds r24,321 |
7 | andi r24,lo8(31) |
8 | cpi r24,lo8(31) |
9 | breq .L4 |
10 | *** hier: |
11 | lds r24,322 |
12 | ori r25,lo8(-32) |
13 | and r24,r25 |
14 | sts 322,r24 |
15 | *** :bis hier |
16 | .L5: |
17 | lds r24,321 |
18 | andi r24,lo8(31) |
19 | cpi r24,lo8(31) |
20 | breq .L5 |
21 | /* epilogue start */ |
22 | 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:
1 | 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.
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
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
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. ;-)
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!
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
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
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.
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.
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?
funktionsgenerator als externen takt anschliessen und neu fusen. vorsicht, pegel vorher am oszi prüfen!
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....???????
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?
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!
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.
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...
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.
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!
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
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/ATMEGA128RFA1-ZU/?qs=sGAEpiMZZMvu0Nwh4cA1wQaNlrdOOs3qfckiqTkXGh4%3d) Zur Zeit sollen über 1800 Stück an Lager sein. Mit freundlichen Grüssen
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
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.
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.
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.