mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ATMegas 1284P


Autor: Dietmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In drei Tagen soll der ATMega1284P bei digikey verfügbar sein 
(ATMEGA1284P-AU-ND). Hat jemand mehr Informationen, ist das realistisch?

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also liefebar scheint der zu sein .... so ab 3000 stk :-S
ich bräuchte selbst nur 2-3 stück. aber die bekommt man leider noch 
nich. manno.
mal schauen wann die bei gängigen lieferanten in kleinen stückzahlen 
erhältlich sind.

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe gerade mal wieder bei Digikey geschaut da ich den Chip selbst 
gebrauchen könnte, lieferbare Menge 0
Bei Farnell und Spoerle das Gleiche, lieferbare Menge 0

Realistisch finde ich eher, dass es den Chip nie zu kaufen geben wird, 
wäre ja nichts neues.

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@thomas

ein kumpel hat vorhin bei digikey bestellt. von daher hab ich die info 
;-)

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@TheMason: Wir (unsere Abteilung) bestellen nicht mehr bei DigiKey. Wir 
haben 2 Mal bei denen bestellt und auch bezahlt, geliefert wurde einmal 
gar nicht (mit viel Ärger wurde der Auftrag dann storniert) und beim 
anderen Mal nach 5 Monaten, obwohl die Ware jeweils sofort verfügbar 
gewesen sein soll. Wir sind im übrigen eines der größten Unternehmen in 
der Elektro und IT Branche.

Bin ja mal gespannt wann dein Kumpel die Ware erhält bzw. ob er sie 
überhaupt erhält.

Mir und anderen Insidern scheint es nämlich so, dass Atmel die Chips nur 
einmal prozessiert hat und seit dem nur die AVR Raven damit bestückt. 
Hat dein Kumpel auch mal bei Atmel gefragt, ob sie die Chips überhaupt 
prozessieren?

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mmmh ... also ich hab selbst noch nicht bei digikey bestellt, sondern 
immer nur bei sammelbestellungen mitgemacht, und bisher kam alles immer 
an.
aber mit dem 1284p wär schon echt schitte wenns den überhaupt nicht 
geben würde, bzw der nur für die avr ravens ist ...
hab den zwar noch nicht so fest für mein selbstbau-projekt eingeplant, 
aber der 644p ist leider zu klein für das was ich noch gerne umsetzen 
möchte, und für nen anderen mega128 müsste das board geändert werden und 
ich hätte keine offiziellen 20mhz (ich weiß es dürfte auch mit den 
normalen typen kein problem geben, aber lieber ists mir trotzdem) und 
ich brauche schon 2 serielle schnittstellen (die ich bei den normalen 
typen auch nicht habe).

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
schade ... bei digikey gibts die wohl doch nicht :-(

und eine musterbestellung bei atmel blieb bisher ohne antwort.
sind die dinger denn echt so schwer zu kriegen ?
könnte son dingen im moment echt ganz gut brauchen. bei meinem projekt 
gehen mir die kB an flash aus :-( (wobei das mit dem größeren ram ein 
angenehmer nebeneffekt wäre ;-))

Autor: Hannes Jaeger (pnuebergang)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
TheMason schrieb:
> schade ... bei digikey gibts die wohl doch nicht :-(
>
> und eine musterbestellung bei atmel blieb bisher ohne antwort.
> sind die dinger denn echt so schwer zu kriegen ?

Du kannst nicht bekommen, was es nicht gibt. Es sieht so aus, als ob 
Atmel mal irgendwann eine Charge gefertigt hat, die findet sich auf den 
Ravens, das war's dann.

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
shit ... na ja ... wäre wenigstens schön wenn atmel den dann von der 
page nehmen würde. erst den mund wässrig machen und dann sagen : nö, war 
nur für ein einzelnes produkt find ich auch fürn eimer. :-(
nun muß ich zusehen wie ich an einen xmega128a4 oder einen xmega256a3b 
bekomme. :-( inkl. einer designänderung.

Autor: Bensch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Du kannst nicht bekommen, was es nicht gibt. Es sieht so aus, als ob
Atmel mal irgendwann eine Charge gefertigt hat, die findet sich auf den
Ravens, das war's dann.

Könnte sein, dass die eine Nullserie produziert haben, die aber noch 
Fehler enthielt. Daher wird die nicht allgemein zugänglich sein, sondern 
intern verbaut- da wo der Fehler keine Rolle spielt.

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hab gerade mit msc telefoniert. der mega1284p wird definitiv kommen, 
aber wohl erst im 3. quartal :-(
schade das man nicht wenigstens ein zwei muster vorab bekommen kann. na 
ja ... muß das gute board eben noch 3 monate warten :-(

Autor: Hannes Jaeger (pnuebergang)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
TheMason schrieb:
> ... der mega1284p wird definitiv kommen,
> aber wohl erst im 3. quartal :-(

Solche Aussagen gibt es immer wieder. Im Februar hieß es, sie kommen 
Ende April. Irgendwann wird mal eine Aussage stimmen. Bis dahin kann man 
sich ein Ei drauf braten, denn vernünftig kann man damit nicht planen.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich vermute mal, der Mega1284 ist den XMegas zum Opfer gefallen.

Und wenn sie die 0-Serie für die Raven aufgebraucht haben, wird der 
Raven mit dem XMega gepimmt.

5V-fest und DIP, da wird nix mehr investiert.


Peter

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@peter

mach mir doch nicht meine ganze hoffnung zunichte ;-)

wäre halt nur schön gewesen wenn ich das 2.board mit nem 1284p hätte 
bestücken können, da ich mich mit dem projekt wohl bei einem 644p etwas 
übernommen hab. hab zwar nun nen haufen schnittstellen aber nur noch 
knapp 16kB um alles zu implementieren (und da sind bestimmte 
schnittstellen immer noch nicht drin)

na ja ... ich denke ich werd bei dem projekt eh auf nen xmega umsatteln 
müssen. 3.3V und 32MHz sind dann doch ein schlagendes Argument.
und wenn ich dann auch noch nen XMega128A4 bzw XMega256A3 bekomme wäre 
ich schon zufrieden. Weiß vllt jemand wo man die Dinger (außer Digikey) 
bekommen kann ? den xmega256a3 hab ich da schon ausgemacht, aber den 
xmega128a4 noch nicht. gibts den überhaupt schon ?
bei embedit hab ich nen xmega128a1 gefunden, aber ich bräuchte eher ein 
qfp44 bzw qfp64 gehäuse, da ich nicht soviel platz habe. reichelt und 
conrad z.b. haben noch kein xmega.
was wären noch für versender da die nen xmega haben könnten ?

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Lt. Atmel 'Quick Reference Guide February 2009' befindet sich der 
ATMega1284P in der Einführungsphase. Was immer das auch heißen mag.

MfG Spess

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
TheMason schrieb:
> wäre halt nur schön gewesen wenn ich das 2.board mit nem 1284p hätte
> bestücken können, da ich mich mit dem projekt wohl bei einem 644p etwas
> übernommen hab.

Wenns in AVR-GCC (WINAVR) geschrieben ist, kannst es mir ja mal zeigen 
(hier posten oder als E-Mail), da ist bestimmt noch massig 
Optimierungspotential.

Gerade Anfänger tun sich oft schwer, alles schön in kleine Module zu 
zerlegen und produzieren dann riesige Copy&Paste-Monster 
(Spaghetticode), die leicht ein 10-faches an Flash benötigen und dadurch 
auch recht unübersichtlich und schwer wartbar sind.

Ich bin da ziemlich pingelig, ehe ich was ähnliches auch nur zweimal 
hinschreibe, mache ich ne Funktion daraus, die zweimal aufgerufen wird.
Mehr als 16kB zu benötigen fällt mir daher schon ziemlich schwer.


Peter

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@peter

kanns dir gerne mal als email zuschicken.

aber ich denke ganz so ein anfänger bin ich wohl nicht mehr. ich hab da 
schon recht viele module draus gemacht (sind knapp 30 module). ich hab 
nur das problem das ich allein an tabellen schon (grob geschätzt) ca 
16kb habe.

an funktionen sind momentan drin :

- modularsystem für einen audio-dsp
- (an)steuerung für diese module
- implementierung für ca 20 audio-module
- kommandointerpreter
- assembler für den dsp (per compilerschalter hinzucompilierbar um platz 
zu sparen)
- div. funktionen um die module per kommandointerpreter ansteuerbar zu 
machen
- glcd-gui
- glcd-high-level ansteuerung (die eigentliche darstellung und noch ein 
paar andere glcd-aufgaben laufen in hardware)
- 3 zeichensätze plus ein paar bitmaps (die habe ich aber bitseriell 
abgelegt)
- kleines mini-os (ist eigentlich nur ein scheduler für timing aufgaben)
- ein dateisystem (das kommt evtl noch raus, weil das braucht alleine 
schon 5kB reinen code, obwohl ich da nicht unbedingt drauf verzichten 
möchte, bei einem größeren avr wäre das fs auf jedenfall mit drin. das 
fs ist übrigens eeprom basiert)
- zwischencode (glue)

mit copy&paste programmierung is da nicht viel. aber vllt findest du ja 
noch was. ich sag nur direkt von vornherein : es ist viel code.
ich denke auch mal das da sicherlich noch einiges an 
optimierungspotential drin ist (könnte noch etliches an befehlen aus dem 
kommandointerpreter rausschmeißen, manche berechnungsfunktionen 
rausnehmen, tabellen verkleinern, hilfe-generierung beim 
kommandointerpreter abschalten), aber ich versuche auch immer recht 
platzsparend zu programmieren.
also der ansatz : lieber 1 funktion mehr als den selben code 2 mal zu 
schreiben ist mir geläufig ;-)
nur denke ich das von der funktion her schon recht viel drin ist.

was ich gerne noch an funktionen drin hätte wäre :
- auswertung eines touch-panels (die erfassung der touch-position 
erfolgt in einem mega8, da ich an dem 644p keine pins mehr frei habe bzw 
da nicht drankomme)
- anbindung des touch-panels an die gui
- abspeichern der modulzusammenstellung im fs
- abspeichern von presets/mappings/usw im fs

das ganze ist ein recht umfangreiches projekt. und wenn ich mich nicht 
darauf festgelegt hätte ein modulares audio-system dadraus zu machen 
käme ich sicherlich mit einem 644p bzw. einen 324p genauso hin (wobei es 
bei dem 324p wegen den tabellen schon echt knapp wird).

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiß ja nicht, was für Tabellen das sind, aber bei 16kByte sollte 
man mal über Kompimierung nachdenken. RLE ist zum beispiel recht leicht 
zu implementieren. Vielleicht bringt das ja den nötigen Flash.

Sebastian

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@sebastian

das würde an der stelle sehr viel zeit kosten, da ich die tabellen tlw 
für floatingpoint berechnungen brauche (filterkoeffizientenberechnung) 
und diese so schnell wie möglich abgearbeitet werden muß. ich brauche 
momentan 1,5ms für einen koeffzientensatz (das ist die längste 
berechnung in dem ganzen system). die anderen tabellen haben ebenfalls 
mit audio (also nicht direkt die modifikation von audio, sondern das 
füttern eines dsps damit) und ich möchte weil es eben modular ist die 
ganzen berechnungen so schnell wie möglich abgearbeitet haben (um so 
viele module wie möglich steuern zu können)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@TheMason,

wenn Du willst, kann ich mal drübergucken, ob mir was ins Auge sticht.
Tief werde ich aber nicht eindringen, scheint ja recht umfangreich zu 
sein.
Kannst mir ja ne Forum Nachricht schicken, damit ich Dir meine E-Mail 
Adresse geben kann.

Du könntest vielleicht nen AT24C512 draufpappen und da Konstanten 
auslagern. Bei 1MBit/s kriegt man den auch relativ fix gelesen.

Oder Du machst Dir nen Adapter von ATmega2561 auf DIP-40, der hat sogar 
8kB RAM, die bestimmt ganz nützlich sind.


Peter

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@peter

ok. mache ich mal. hab dir ne nachricht mit meiner email-adresse 
geschickt.
in der tat ist das projekt sehr umfangreich und es war mir von 
vornherein klar das das was ich damit machen möchte mit 64kB echt 
verdammt eng wird, und wie das bei so freilaufenden projekten so ist : 
es fallen einem immer noch mehr sachen ein ;-) ursprünglich wollte ich 
mit gui da gar nix machen, aber der reiz ist wohl doch was größer. (vor 
allem weil ich bei reichelt diese süßen touchscreens für die dog-module 
gesehen hab, hätte ich die doch mal einfach nur dezent übersehen ;-))
na ja ... es können bestimmt noch einige teile weggestrichen werden, 
aber es wär halt echt klasse gewesen den 1284p zu bekommen, vor allem 
weil der pinkompatibel zum 644p ist und nur 44 pins braucht (daher hatte 
ich mich auch für die -4p reihe entschieden, da ich wenig platz habe, 2 
schnittstellen brauche (eine für MIDI eine für den PC) und die 4p's 
offiziell 20MHz schaffen) und die 128k variante wäre mit 16k der 
absolute knüller gewesen.

die idee mit dem adapter fällt leider flach da ich keine dip variante 
sondern ne qfp variante auf dem board habe, da wirds mit dem adapter 
schwierig ;-)

aber vllt nochmal die frage zu den xmegas : gibt es schon die xmega128a4 
bzw xmega256a3 irgendwo (außer digikey) zu kaufen ?
32 MHz wären bei dem projekt mehr als sinnvoll (da kann ich noch mehr 
schindluder zwischenzeitlich treiben, bzw. mehr funktionen reinpacken) 
und 3.3V kommen meinem FPGA auch zu gute (dann kann ich die 
"schutzwiderstände" die mir meinen pegel von 5V auf 3.3V bügeln einfach 
durch 0Ohm bzw 100Ohm widerstände ersetzen, und kann per SPI die Daten 
mit voller geschwindigkeit in den FPGA reinblasen).
das wäre dann die letzte variante des boards bevor ich mich dazu 
durchringe nen ARM7 da drauf zu packen (kommt sowieso irgendwann, aber 
ich würd ganz gerne noch die AVR's was ausreizen, vor allem hätte ich 
dann schon die sw bis auf die platformanpassungen komplett durch)

nachtrag zum auslagern der tabellen :

hatte mir auch schon überlegt nen at45db161 da drauf zu setzen sodaß ich 
die ganzen filterberechnungen mir sparen kann. sind allerdings zuviele 
koeffzienten (mit den ganzen zwischenabstufungen). aber die idee hab ich 
weiterhin im kopf, zumal ich das spi vom board rausgeführt habe um 
weitere spi-slaves anschließen zu können.
werde mal schauen.

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.