Hallo zusammen, ich bin auf der suche nach einem schönem Mikrocontroller der folgendes unterstüzt: USART CAN ETHERNERT LCD support USB SD Card Dabei bin ich auf folgenden Controller gekommen: AT91SAM9263 http://www.atmel.com/dyn/products/product_card.asp?part_id=4056 was mich hier etwas abschreckt ist diese riesige Errata-Liste :D Ich hab mal geschaut was die anderen Hersteller (ST, NXP, Samsung) alles anbieten und habe dort geschaut wo dieser ARM9263-EJ verbaut ist. Wenn ich da richtig geschaut habe hatte keiner nen CAN support :( Also meine Frage ist nun eigentlich, hat jemand Erfahrungen mit dem ATSAM9263 und kann diesen empfehlen. Oder hat eventuell jemand eine alternative für mich. Vorher hatte ich ein ARM7 Controller, mit der Zeit gewöhnt man sich an diese ARM dinger aber als vollprofi würde ich mich noch nicht bezeichnen. Als Entwicklungsumgebung käme wieder KEIL µVision zum einsatz. Ich hoffe mal ihr könnt mir ein bissel Input zu dem Thema geben. Achja so interesse halber, wo ist denn der große unterschied zwischen ARM9, ARM11 und den Cortex Varianten? Gibs da mal ne ordentliche Gegenüberstellung? Solangsam fühle ich mich von der Produktpallete der Hersteller erschlagen :D
Erfahrung habe ich mit dem '9261. Die Errata-Liste ist ein wirkliches Manko, in meinem Fall insbesondere wegen der Verrenkung, von einem parallelen Flash starten zu müssen. Ansonsten funktioniert alles, was ich brauche. Gerüchteweise sollen die anderen Anbieter aber genauso "verbuggte" Chips anbieten. Wenn du CAN on Chip haben willst, mußt du glaube ich eher bei NXP schauen, ansonsten halt einen CAN Phy dranforschen. Ich denke, gerade bei ARM7 wirst du da aber einiges mit CAN finden. Muß es unbedingt ARM9 sein? Brauchst du ein USB-Device oder einen USB-Host? Falls der Host nicht gebraucht wird, könntest du dich auch beim AVR32 umschauen, der ist in einigen Punkten besser gemacht als die AT90SAMs. Ansonsten kann ich nur sagen, mit einem Embedded Linux wird das Leben echt einfach. Kostenlose Entwicklungsumgebung und alle Treiber "uot of the box" vorhanden, das spart echt Nerven.
Also USB wäre ne nette spätere Weiterentwicklung. Dies gibt einem schon einigemöglichkeiten wie z.b. nen USB Stick als speichermedium oder das Gerät als USB Slave vom PC zu konfigurieren. Beide Varianten wären also schon wünschenswert. Was meinst du mit "verrenkungen vom parallelen Flash starten zu müssen" ? Wie kann ich mir das alles vorstellen? In der Revision B steht nicht mehr der Fehler drin das man von SD Card z.b. nicht booten können soll. Ich hatte mir ja fast vorgestellt ich würde dann nen Programm auf die SD Card speichern und dieses wird gestartet. Ist sowas möglich oder tierisch schwer? Gibt es nen kostenloses RTX Embedded Linux? Unterstützt das dann alles wie Ethernet, USB, CAN? Wäre echt mal ne interessante Sache :) Und dann wird einfach C Code wie für jedes andere Linux Derivat geschrieben? Klingt einfach :D Wie gesagt, bei den anderen Anbietern hab ich keine so ausführliche und umfangreiche Errata gefunden. Einerseits berückt es, weil man sich denkt es würde da laufen, andererseits find ichs schon gut das Atmel so eine umfangreiche hat. Das scheint dann wenigstens schon bekannt zu sein und man wird nicht von vielen fehlern überrascht. Mit welcher Entwicklungsumgebung arbeitest du dann beim Embedded Linux? Eclipse? Wie ist das mitm Debugging? Bei nem RTX wünsch ich mir doch ne ordentliche Debugging Möglichkeit wo man sich z.B. die einzelnen Tasks anschauen kann und auch nur einzelne stopt zum debuggen und der rest weiter läuft. Womit würde so etwas gehen?
@josef, unter www.linux4sam.org findest du mehr infos zu linux auf dem at91sam9263. zu deinen anderen fragen: welcher arm core? aufgrund deiner anforderungen würde ich mind. einen arm9 einsetzen. einen prozessor mit arm11 wirst du kaum bekommen, ich glaub freescale setzt die in frei verfügbaren prozessoren ein. zur cortex familie findest du unter http://www.arm.com/products/CPUs/families/CortexFamily.html einige hinweise zum einsatzgebiet. gruss gerhard
@josef, unter http://www.ronetix.at/pm9263.html findest du ein eval board mit entspr. unterstützung. gruss gerhard
Also beim ARM9 fand ich das Evulationboard von Atmel sehr itneressant, dort ist wirklich alles. Ethernet, USB, SD Card, 1/4" VGA Touch :), CAN. Also alle Sachen die ich benötige. Das Eval-Board was du gezeigt hattest war ja dann nur für ne OS Entwicklung gedacht ohne die ganze Peripherie. Also nen ARM7 wird sicher nicht mehr für die Anforderungen reichen. Bei den Cortex M3 habe ich mich nun ein bisschen umgeschaut. Dort hab ich aber bei NXP und ST noch keinen mit LCD, CAN, Ethernet, USB gefunden. Ich find die Seiten auch recht unübersichtlich. Bei Atmel gibs so ne tolle Produktübersicht wo man alle Schnittstellen, die der Controller hat direkt sieht. Gibs die bei den beiden nicht? Oder bin ich zu blöde die zu finden :( Die Seite linux4sam werde ich mir nun mal genauer anschauen. Bei TI hatte ich gerade noch so nen MCU Selecter gefunden, kaum klicke ich LCD an sind alle mit CAN weg :) und Ethernet stand garnicht zur auswahl, also fallen die auch alle weg. Ich find nun immer wieder Controller die "nur" mit 70 oder 100 MHz laufen und auch Ethernet, CAN, USB anbieten (nicht immer auch LCD). Der ARM9263 hatte ja 240 MHz, ist das nun brachial viel oder sind die anderen etwas "untermotorisiert"? Hattest du schon mit einem Cortex M zutun? Von der Beschreibung liest es sich ja wiedermal echt traumhaft; Schneller, Weniger Speicher, einfach besser :D Stimmt das denn auch? :) Wobei ich beim Cortex auch noch keinen gefunden habe der alle Schnittstellen vereint.(LCD Fehlte immer) Vielen Dank schonmal für die Hinweise, ich werd noch etwas weiter suchen aber ich würde mich auch über deine persönlichen Erfahrungswerte freuen :)
push :D gerhard ... bitte melde dich! oder auch alle anderen
Josef wrote: > ich bin auf der suche nach einem schönem Mikrocontroller der folgendes > unterstüzt: Nach nem schönen MC habe ich noch nie gesucht. Ich baue sie üblicher Weise in ein Gehäuse und dann sieht man nicht mehr, ob sie schön sind. Außerdem mache ich die Wahl eines MC an der konkret zu lösenden Aufgabe fest und das klappt immer sehr gut. Irgendwelche Schnittstellen-Gier oder MIPS-Paranoia hat mir noch nie etwas genützt. Ich versuche aber immer, mir das Layouten möglichst einfach zu machen. D.h. ich bevorzuge MCs, die die Aufgabe mit möglichst wenig Außenbeschaltung lösen (idealer Weise nur der MC selber). Externen RAM/Flash mag ich daher nicht bzw. nur seriellen Flash. Peter
Josef wrote: > Hattest du schon mit einem Cortex M zutun? Von der Beschreibung liest es > sich ja wiedermal echt traumhaft; Schneller, Weniger Speicher, einfach > besser :D Stimmt das denn auch? :) Wenn ich die Wahl hätte zwischen einem ARM7 und einem Cortex-M3, würde ich letzteren vorziehen. > Wobei ich beim Cortex auch noch keinen gefunden habe der alle > Schnittstellen vereint.(LCD Fehlte immer) Nein. Die Hersteller wollen ja auch noch ihre anderen Chips verkaufen. Da wird meiner Meinung nach der Markt gesteuert. Viele ARM9 MCU werden vermutlich wegen Ihrer Peripherieausstattung gekauft und nicht unbedingt wegen der zusätzlichen Leistung. Gruß Marcus http://www.doulos.com/arm/
@josef unter http://www.sevensandnines.com => chip selector kannst du mal nach etwas passendem suchen. gruss gerhard
Danke Peter für den Hinweis das der µC nicht unbedingt schön sein muss :D Ja bei der suche nach dem Controller ist dies auch keine Schnittstellen-Gier sondern die ganzen genannten Schnittstellen werden wirklich genutzt! Zwar nicht alle im Schritt 1 aber sicher direkt danach. Bei solchen MC's die LCD, Ethernet, CAN, USB unterstützten wir der interne SRAM meistens viel zu klein, da benötigt man ja irgendwann externen SRAM, da komme ich wohl nicht dran vorbei. @marcus harnisch: wenn du die wahl zwischen einem ARM9 und Cortex M3 hättest würdest du dann auch den Cortex nehmen? Leider habe ich immer noch keinen M3 gefunden der Etheret+LCD unterstützt. Also die, die CAN und USB hatten, hatten dann entweder noch Ethernet oder LCD aber nicht beides. Da ich auch auf zusätzliche Peripheriebausteine verzichten möchte suchte ich halt einen der alle Anschlüsse unterstüzt. Nur so nebenbei: Gibts eigentlich auch ein Deutschsprachiges Buch über die Programmierung von ARM's ? ARM7/9 oder Cortex-M3?
Josef wrote: > Gibts eigentlich auch ein Deutschsprachiges Buch über die Programmierung > von ARM's ? ARM7/9 oder Cortex-M3? Auch wenn ich dich damit vielleicht nerve: Wenn du dich wirklich ernsthaft mit den Thematik beschäftigen willst, dann ist das einzig dafür brauchbare Buch ein Wörterbuch Englisch-Deutsch. Im Bastelsektor AVR/PIC findet man vereinzelt deutsche Literatur. Bei ARM7 und ARM9 wird man sicherlich auch fündig, die sind alt genug dazu. Aber je neuer (C-M3), desto schwieriger wird es, dazu was in Deutsch zu finden. Und in dieser Grössenordnung, zusammen mit allerlei Schnittstellen, wird Englisch schlichtweg vorausgesetzt.
English ist ansich kein Ding, jedes Datenblatt ist ja auch nur in English und die ganzen anderne Dokus auch, aber falls es was gegeben hätte wäre es ganz praktisch gewesen. So nen deutsches Buch liest sich doch noch flüssiger als alles in English. Wobei meistens die Sachen dann nur Blindübersetzt wurden und unverständlich sind. Du sagst ja selbst der C-M3 ist neuer. Ist es denn lohneneswert nun noch ein ARM9 zu nutzen (falls ich auch ein C-M3 finde der alles unterstützt) anstatt ein C-M3? Oder ist der ARM9 schon "veraltet"?
Josef wrote: > Bei den Cortex M3 habe ich mich nun ein bisschen umgeschaut. Dort hab > ich aber bei NXP und ST noch keinen mit LCD, CAN, Ethernet, USB > gefunden. Die Luminary Cortex haben z.Z. nur entweder Ethernet+CAN oder USB+CAN. Was meinst Du mit LCD? Hast Du sone große Stückzahl oder sonst irgendwie Zugriff auf nackte LCDs? Für kleine Stückzahlen ist ein LCD mit eingebautem Controller sinnvoller. Die Luminary-Boards haben ein kleines OLED mit drauf. Peter
Der erste PIC erblickte Mitte der 70er Jahre das Licht der Welt und die PIC10/12 sehen diesem heute noch verdächtig ähnlich. Intels 8051 ist ein paar Jahre jünger und noch immer weit verbreitet. Keine Sorge, die ARMs sterben so schnell nicht weg. ARM7+9 haben den Vorteil, dass jedes Tool damit klarkommt. Von den C-M3 kann man das noch nicht behaupten.
Als Entwicklungsumgebung hab ich das Keil µVision, das sollte mit dem ARM9 aufjedenfall klar kommen. Ja an nen Display sollte ich kommen. Ich werd mir nochmal die ERRATA vom AT91SAM9263 genauer anschauen, ich befürchte der MC wird es, wenn dort nichts steht was ein K.O.-Kriterium ist. Vielen Dank schonmal für die Infos. Vielleicht werd ich auch mal ne Schulung im Bereich KEIL+ARM9 besuchen, aber wenn man die Angebote liest gibs meistens viele interessante Schulungen, da könnte man direkt alle mit machen :D . Ich hoffe nur das die Trainings auch ihr Geld Wert sind und man sich danach nicht ärgert das es doch raus egschmissenes Geld war.
Josef wrote: > Gibts eigentlich auch ein Deutschsprachiges Buch über die Programmierung > von ARM's ? ARM7/9 oder Cortex-M3? http://www.doulos.com/knowhow/arm/C_und_Cxx_fuer_Embedded_Systems/ Diese Buch enthält unter anderem eine deutschsprachige Einführung zum Cortex-M3. Den Rest bekommst Du quasi umsonst dazu :-) > Du sagst ja selbst der C-M3 ist neuer. Ist es denn lohneneswert nun noch > ein ARM9 zu nutzen (falls ich auch ein C-M3 finde der alles unterstützt) > anstatt ein C-M3? Oder ist der ARM9 schon "veraltet"? Der Cortex-M3 kann als Nachfolger des ARM7 angesehen werdenund hat gar nicht den Anspruch ARM9 abzulösen. ARM9 spielt in einer anderen Liga. Mehr Leistung (bis >400MHz), umfangreicherer Befehlssatz, oft mit MMU und Cache anzutreffen (ARM92x), einige sogar mit FPU. ARM7 mit MMU gibt's zwar auch, ist aber eher exotisch. Das Businterface gibt das auch nicht her. Gruß Marcus http://www.doulos.com/arm/
@Josef: ARM9 ist super, ich will dich da nicht von abbringen. AVR32 ist auch toll, bringt zum Beispiel mehr Leistung pro MHz und Watt, hat aber dafür andere Nachteile. Was willst du denn genau machen? Noch größere Prozessoren würde ich mir für den "Bastelbereich" sehr genau überlegen. Auf ARM9 und AVR32 ist Linux portiert und die Peripherie ziemlich komplett ansprechbar. Es gibt auch Foren und andere Bastler. Bei dem '9261 kann man nicht vom seriellen Flash starten. Und zwar deshalb, weil das interne ROM mit dem Bootprogramm unterhalb von -20°C nicht mehr funktioniert (Errata). Bei meiner Anwendung brauchte ich den ganzen Temperaturbereich. Deshalb brauchte ich alleine zum Booten ein paralleles Flash, welches das Platinenlayout deutlich verkompliziert und entweder den Platzbedarf oder die Fertigungskosten (Bestückung auf Platinenunterseite) erhöht. So gibt es halt einige Errata bei diesen Prozessoren, die auf den ersten Blick nicht dramatisch klingen, in der Praxis aber Kopfzerbrechen machen. Da gibt es schon einige Fallen, die ein Projekt verzögern können. Denke auch daran, daß alle ARM9 mit LCD-Controller nur im BGA-Gehäuse angeboten werden. Hier gibt es auch eine Falle: Bei 0,8mm Pitch zwischen den Balls und mehr als vier "Reihen" mußt du zwischen die Balls jeweils Durchkontaktierungen setzen, sonst bekommst du deine Signale nicht nach draußen geroutet. Und da ist man schon schnell am Limit dessen, was die "günstigen" Platinenbutzen fertigen können. Microvias und Feinstleitertechnik sind teuer. Da hat der AVR32 Vorteile, mit seinem 1mm-Pitch gibt es dieses Problem schon einmal nicht. Das Problem CAN und LCD hast du schon angesprochen - das gibt es nicht auf einem Chip. Du kannst entweder CAN extern machen oder LCD. Ich bin für CAN. LCD-Controller gibt es auch, beispielsweise von Epson, aber sie sind schwer erhältlich und schaffen nicht die gleiche Leistung. Die Onboard-LCD-Controller sind schon super. Auch hier gibt es Fallstricke. Eine Falle, in die ich selber mal gefallen bin: Der AVR32 hat die "falsche" Endianess und vertauscht bei normalem Anschluß des LCD rot und blau. Das kann man in Software zurücktauschen (die Framerate sinkt in den Keller) oder auf der Platine - sprich auf der zweiten, korrigierten Platine :) @Peter Danegger: Wir reden hier über Farb-TFTs, zum Beispiel 240x320 @ 60 Hz bei 24 Bit Farbe. Die gibt es ohne Controller für 30 Euro oder mit für... das Zehnfache?! Da nehme ich doch lieber den "kostenlosen" LCD-Controller auf meinem preiswerten ARM9. P.S.: Gerhard (ich) und gerhard sind zwei verschiedene User.
>Als Entwicklungsumgebung käme wieder KEIL µVision zum einsatz.
Das ist, glaube ich, ein falscher Ansatz. Um die Eigenschaften des 9263
mit vertretbarem Aufwand nutzen zu können, kommt man nicht mehr ohne
Betriebssystem aus. Da landet man dann u.a. auch bei Win-CE. Das hat
viele Vorteile, aber auch Eigenheiten, die man vielleicht garnicht haben
möchte.
Viel Erfolg!
Zustimmung. Habe ich überlesen. Linux, GCC und eine Entwicklungsumgebung deiner Wahl sind hier angesagt. Es sei denn, du willst unbedingt selbst den Prozessor initialisieren, die PLLs konfigurieren, den SDRAM-Controller aufsetzen, selbst ein Dateisystem schreiben, selbst einen USB-Treiber schreiben, einen TCP/IP-Stack implementieren, Bibliotheken für Bilder, Graphik und Text anpassen oder selbst schreiben... Da bist du schnell für Jahre beschäftigt. Windows CE. Naja. Für Massenware vielleicht, für die dann auch Drittanbieter Software schreiben wollen. Wenn es denn sein muß. Ansonsten würde ich da die Finger von lassen.
Gerhard wrote: > Wir reden hier über Farb-TFTs, zum Beispiel 240x320 @ 60 Hz bei 24 Bit > Farbe. Die gibt es ohne Controller für 30 Euro oder mit für... das > Zehnfache?! Da nehme ich doch lieber den "kostenlosen" LCD-Controller > auf meinem preiswerten ARM9. Mein Frage war an Josef gerichtet, d.h. es würde mich doch seine eigene Meinung interessieren. Und daß er genau so ein LCD meint, wie Du es angibst, muß ich wohl überlesen haben. Kann sein, daß man LCDs aus älteren ausgelaufenen Serien sehr günstig kriegt. Ich hatte jedenfalls mal Angebote eingeholt und nicht den Eindruck, daß der Controller viel Unterschied macht. Nennenswerte Preisunterschiede machte die Größe und das Backlight aus. Peter
@Gast: Windows CE wollte ich eher nicht. Wenn schon nen Realtime Linux. Windows und Realtime ist in meinem Kopf einfach ein Widerspruch. Ausserdem hatte ein Kollege mal Windows CE und dies war doch recht Fehleranfaellig und das will ich vermeiden. Dieses RTX was es von Keil gibt ist auch kein richtiges Betriebssystem oder? So richtig komfortabel scheint das dingen nicht zu sein :( @Gerhard erst einmal vielen Dank für die ausführliche Beschreibung! Du meinst beim 9261 kann man nciht vom Flashstarten. Beim 9263 steht dies aber nicht in der Errata (wenn ichs nicht überlesen habe) ich hoffe mal das dies dann klappt und mir das kein Problem bereitet. Zu den Erratas die Kopfzerbrechen bescheren: Lieber ne Errata woman weiß das es nen Fehler ist, als ein Fehler den man erst noch finden muss bevor man ne Lösung suchen muss :) Das mit BGA Gehäuse sollte lösbar sein. Du meinst sowas ist teuer, um was für eine Preisregion reden wir hier bei so ner platine die dann auch alle Anschlüsse drauf hat(CAN, LCD, USB, Ethernet, RS232) ganz grob geschätzt? Wenn etwas extern gemacht werden müsste dann würde ich auch zum CAN tendieren da dieser ja relativ einfach ist und so nen SJA1000 nen alt bewärtes teil ist. Aber der AT91SAM9623 hat doch alles "onboard". CAN, LCD, Ethernet und USB. Nur eine alternative habe ich nicht gefunden und da es wohl auch keine gibt und die Errata verträglich scheint werde ich mir das dingen mal bestellen. Vielen Dank schon einmal für die Hilfe. Wenn das EV-Kit da ist werde ich sicher noch mit vielen Fragen kommen :D Zur LCD Sache: Ja so nen VGA dingen in 800*640 wirds wohl werden, natürlich in Farbe. So wie ich es mitbekommen habe sind die Displays mit Logik doch deutlich teurer als die ohne. Nochmal zur Betriebssystem-Wahl: Das dingen soll hinterher extrem Stabil und ausfallsicher arbeiten und nicht nur nen reines Bastelspielzeug sein wo es keinen stört wenn es mal abstürzt. Wenn es sich eventuell nicht vermeiden lässt muss auch nen kommerzielles OS her welches mir auch Support bietet.
Ich arbeite momentan mit dem ARM9 (AT91SAM9263) und wenn man ein RTOS haben möchte sollte man doch ehr zu QNX Neutrino greifen als zu Linux oder WinCE. Als Evolationboard kannst mal nach Rontix und dem PM9263 gucken, wurde auch weiter oben im Forum gepostet. Wenn du das PM9263 nimmt musst du dir um Speicher keine Sorgen machen, das Board hat alles drauf und läßt sich auch leicht in in eine Hardware integrieren. QNX bekommt man als Hobbyanwender kostenlos bzw als 60-Day-Trial für den kommerzielen Gebrauch.
@Stefan, Ich war nun auf der Seite von QNX....kann es sein das die den Controller garnicht komplett unterstützen? 1. steht da noch überall "Comming Soon" und auch bei einer Liste wo angeblich die Sachen eingebaut sind fehlt noch CAN. Bzw. in der anderen Übersichtstabelle sind nur: USB, Ethernet und Serielle Schnittstelle als verfügbar angezeigt. Das PM9263 Board sieht echt gut aufgebaut aus. Die Sache mit dem CPUBoard ist wirklich schick. Aber ich befürchte bei sowas gibs wieder wenig Examples. Bei der KEIL Umgebung sind auch schon Examples für das Atmel Board dabei, für das PM9263 nicht. Für den ersten Schritt wäre so nen Atmel ding eventuell einfacher. Hat sonst noch jemand gute RTX-OS im Angebot zur Auswahl? Ich hab noch 2 Fragen zu der ERRATA des 9263. 1. Was sagt mir das hier? 50.3.4 Bus Matrix 50.3.4.1 Problem with Locked Transfers Locked transfers are not correctly handled by the Bus Matrix and can lead to a system freezeup. This does not concern ARM locked transfers. Problem Fix/Workaround Avoid other Bus Matrix masters locked transfers. Heißt es das kein anderer ausser der ARM Controller sagen darf wer schreibt? Gibt das nicht eine riesige Performancebremse? Wie muss ich mir das vorstellen? (Sorry ist das erste mal das ich mitm Controller arbeiter der so etwas hat, aber jeder fängt irgendwann mal an) Und Zweitens: 50.3.7 EMACB 50.3.7.1 Transmit Underrun Errors EMACB FIFO internal arbitration scheme is: 1. Receive buffer manager write 2. Receive buffer manager read 3. Transmit data DMA read 4. Receive data DMA write 5. Transmit buffer manager read 6. Transmit buffer manager write EMACB master interface releases the AHB bus between two transfers. EMACB has the highest priority. If we are in a state where EMACB RX and TX FIFOs have requests pending, the following sequence occurs: 1. EMACB RX FIFO write (burst 4) 2. EMACB release the AHB bus 3. The AHB matrix can grant an another master (ARM I or D for example) 4. AHB matrix re-arbitration (finish at least the current word/halfword/byte) 5. The AHB matrix grants the EMACB 6. The EMACB TX FIFO read (burst 4) In a case of a slow memory and/or a special operation such as SDRAM refresh or SDRAM bank opening /closing, there may be TX underrun (latency min 960 ns). Problem Fix/Workaround Reduce re-arbitration time between RX and TX EMACB transfer by using internal SRAM (or another slave with a short access time) for transmit buffers and descriptors. Heißt das ich kann nur mit dem SRAM Arbeiten beim Datenverschicken und empfangen über Ethernet? Also den internen 80 kB? Mit "another slave with a short access time" meinen die dann ich soll ein externen Ethernet Controller anschliessen? Was für Probleme wird mir dieser Fehler bereiten?Externen Ethernetbaustein wollet ich ja eigentlich vermeiden. Ich hoffe mir kann das nochmal jemand erklären. Vielen Dank!
Zu den Erratas kann ich auf die schnelle nichts sagen, außer halt dich an das Desigen des Evulationboards oder des PM9263. Solltest du ein RTOS benutzen, dass mit fertigen Treibern geliefert wird, wird sich dieses um die in der Errata gekümmert haben. Wenn du dich bei QNX anmeldest und eine E-mail an den Verantwortlichen schreibst bekommst du auch zugang zu dem BSP für das AT91SAM9263-EK(PM9263 ist baugleich mit dem EK). Beim BSP fehlt der CAN-Treiber, den man mit ein wenig Fleis selbst hinbekommt, da QNX eine sehr gute Dokumentation hat. Die Beispiele dürften auf dem PM9263 genauso gut laufen wie auf dem EK von Atmel da beide baugleich sind. Das PM9263 hat auch einen Vorteil gegenüber des EK und zwar das PM9263 wird mir NOR-Flash geliefert ebenso kann man das PM9263 über USB mit SAM-BA flashen.
Josef wrote: > Ich hab noch 2 Fragen zu der ERRATA des 9263. > > 1. Was sagt mir das hier? > > 50.3.4 Bus Matrix > 50.3.4.1 Problem with Locked Transfers > Locked transfers are not correctly handled by the Bus Matrix and can > lead to a system freezeup. > This does not concern ARM locked transfers. > Problem Fix/Workaround > Avoid other Bus Matrix masters locked transfers. > > Heißt es das kein anderer ausser der ARM Controller sagen darf wer > schreibt? Gibt das nicht eine riesige Performancebremse? Wie muss ich > mir das vorstellen? (Sorry ist das erste mal das ich mitm Controller > arbeiter der so etwas hat, aber jeder fängt irgendwann mal an) Der Prozessor verwendet einen AHB (AMBA High Performance Bus). Genauer gesagt, er teilt sich diesen Bus mit anderen Mastern (z.B. DMA). Das AHB Protokoll definiert sogenannte "locked transfers", die der Bus Matrix (Crossbar switch) sagen, dass diese Transaktionen nicht durch einen anderen Master unterbrochen werden dürfen. Stichwort: Atomare Speicherzugriffe. Aus irgendeinem Grund scheint die Bus Matrix diese locked transfers nicht richtig zu behandeln, falls sie von anderen Mastern als dem Prozessor selbst kommen. Ich würde die Wichtigkeit als vergleichsweise gering einstufen, was wohl auch der Grund dafür war, dass man das nicht ausreichend getestet hat :-) Gruß Marcus http://www.doulos.com/arm/
Was interessant wäre zu wissen in welchen Bereich du den einsetzen möchtest.
@Marcus: Das hatte ich mir so auch vorgestellt, aber dieser Workaround, den kann ich mir nicht vorstellen. Wie kann ich den anderen denn verbieten das sie den zugriff NICHT verbieten dürfen :D Die machen sowas doch automatisch oder irre ich mich da? Der LCD Controller wird doch automatisch den Speicher sperren wenn er da rein schreibt oder liest. Bzw. ein Gerät über DMA wird dies auch tun. Ich finde das klingt doch total verherrend wenn dadurch so ein System einfriert, da man sowas doch garnicht verhindern kann oder wie hab ich mir das Workaround vorzustellen? @Stefan: Das Gerät wird hinterher kommerziell eingesetzt (hoffen wir mal :D). In der Industrie um Daten zu empfangen, anzuzeigen und Daten senden. Ungefähre Preisregionen für Lizensen bei QNX kennst du nicht oder?
Ja die kenne ich so ungefähr kann da natürlich keine Gewähr drauf geben, aber so um die 10k für den Platz + 70€ pro Modul, aber das müßte man dann alles mit QNX aushandeln, da sind sicher noch bessere(niedrigere) Preise möglich. Müssen die Daten noch aufbereitet werden? Das Projekt wo ich dran arbeite ist ähnlich Daten einlesen, verarbeiten und dann ausgeben über CAN-Bus. ^^ und ich knappse da an jeder Nanosekunde. Hoffe der Preis schreckt nicht zu sehr ab. Ich muss zugeben, obwohl ich kein Fan von Betriebssystemen bin im Embedded Bereich,das QNX sein Geld wert ist. Aber beantrage am besten auch gleich die entsprechenden Schulungen dazu beantragen.
Noch mal ein Wort zu dem "Realtime OS". Das ist ja so ein Schlagwort, denn "realtime" wird es ja nie, man kommt halt nur näher ran. Bist du dir sicher, daß du wirklich ganz extrem geringe und vorhersehbare Latenz-Zeiten brauchst für ein Gerät, das Daten sammelt und anzeigt? Mit der Linux-Kernel-Konfiguration kann man den Kernel schon ziemlich gut tunen, und durch Herumpfuschen in den Quellen, beispielsweise Timer-Interrupt über GPS-Zeitbasis, kann man die Kernelzeit auch hochgenau synchronisieren, um Meßdaten einen Zeitstempel aufzudrücken. Das würde ich mir bei 10k und 70€ pro Gerät für eine kommerzielle Lösung sehr genau überlegen! Bei Linux gibt's das alles "umsonst" und eine riesige Bastler-Community mit dazu.
Wow! Stolze Preise :)! Das Gerät soll ein LowCost Gerät werden, die 70 Euro fürs Betriebssystem als Lizensgebühren könnten haarig werden, aber das hab ich eh nicht zu entscheiden :) 10k Einzelplatzlizens erinnert mich an das neue CAD Programm vom Kollegen :/ Dort warens auch solche Summen. Da ist man bei KEIL mit den 3400 ja richtig günstig für ihre RTX. Alles über CAN Bus? Sonst kein anderer Bus? Wieso ist jede Nanosekunde so wichtig bei dir? CAN ist doch garnicht soooo schnell, geht doch maximal mit 1MBaud also alle aehm 44 µs kann ein Telegram kommen. Die Verarbeitung sollte biem ARM9 mit den 200MHz doch recht flott sein das er nen software Fifo schnell genug abarbeiten kann. Ausserdem hat der doch 16 Messageboxen. Da QNX kein CAN Unterstützt haste doch ne eigene Routine. Die arbeitet doch dann mit allen 16 Stück und das gibt dir auch noch ein bissel Puffer. Wieso ist das denn so Zeitkritisch bei dir? Oh so ne Schulung ist wirklich sinnvoll. Ich merk das immer wieder, rein arbeiten klappt zwar auch aber so ne Schulung gibt einem doch einige Hintergrundinformationen die man sonst nur sehr schwer findet. So nun hoffe ich nur noch das der Marcus etwas zum Matrix workaround sagen kann.
zu der Realtime OS Sache: Ich hab bei der Linux Community einfach angst, dass wenn etwas wirklich nicht mehr geht ich zu wenig Support möglichkeiten habe. Ja erst einmal wird das Gerät nur Daten per Ethernet empfangen und anzeigen, hinterher wird es auch über CAN und USB oder Seriell noch Daten verarbeiten müssen und parallel etwas Visualisieren. Das wird schon einiges sein, was das Gerät machen muss. Geloggt werden muss auch und das auch am besten per Zeitstempel. Da hatte ich aber an ein Abgleich per PC over Ethernet gedacht. Wenn ich erst einmal ein Evaluation Kit habe kann ich ja verschiedene OS's testen und mir etwas genauer anschauen.
Josef wrote: > Wie kann ich den anderen denn verbieten das sie den zugriff NICHT > verbieten dürfen :D Die machen sowas doch automatisch oder irre ich > mich da? Hoffentlich! Im Ernst, locked transfers sollte man so sparsam verwenden wie möglich, da sie den ganzen Bus blockieren. Der DMA Controller kann beispielsweise optional so programmiert werden, dass Lese- und Schreibvorgang atomar sind. Das sollte man bei dieser MCU offenbar vermeiden. > Der LCD Controller wird doch automatisch den Speicher sperren wenn > er da rein schreibt oder liest. Bzw. ein Gerät über DMA wird dies > auch tun. Wie gesagt, ist optional und in den wenigsten Fällen notwendig -- oft sogar schädlich, wenn man darüber nachdenkt. Während mein DMA Daten schaufelt, soll mein Prozessor doch trotzem an Variablen kommen, die in dem selben physikalischen Speicher liegen. Mit einem locked transfer geht das nicht. Der ARM926 core generiert nur dann locked transfers, wenn er die SWP Instruktion ausführt. Gruß Marcus http://www.doulos.com/arm/
Nur das der QNX Microkernal im Gegensatz zu Linux vollkommen Autonom zu allen Treibern ist und daher beim Absturz eines Treibers noch voll funktionsfähig ist. Daneben bekommt man für die 10k natürlich auch Support und eine gute IDE, die auch etwas mehr leistet als ein Debugger. Würde etwas länger dauern das näher auszuführen. Es ist halt eine Frage was man braucht und was man ausgeben möchte. Für kommerzielle Projekte würd ich weniger auf eine "Bastler"-Community bauen, allein aus rechtlichen Gründen wenn es mal zu einer Schuld-Frage kommen könnte. Ich könnte mich auch über die Definition von "Realtime" auslassen. Aber dafür gibt es ja Google.
Daten über Ethernet empfangen und auf dem TFT darstellen würde ich schon fast "trivial" nennen. Unter Linux. Alles, was du dazu brauchst, ist da. Zu den Platinenpreisen: Rechne mit saftigen Einrichtungspreisen, die Platine selbst kostet dann in Stückzahlen (> 500) auch nur noch ein paar Euro (halbe Eurokarte, 4 Lagen, Microvias, 100µ feinste Struktur und Restring).
> Für kommerzielle Projekte würd ich weniger auf eine "Bastler"-Community > bauen, allein aus rechtlichen Gründen wenn es mal zu einer Schuld-Frage > kommen könnte. Tut mir leid, aber das ist doch blabla. Arbeitest du für die Firma? Einen Coredump habe ich schon sehr lange nicht mehr erlebt. Und das, obwohl ich auf allen meinen Systemen, ob Desktop oder embedded, Linux laufen habe. Die Treiber einer ausgereiften Kernelversion (drei, vier minor Versionen zurück) laufen extrem zuverlässig, weil die Anzahl installierter Systeme sehr hoch ist im Vergleich zu kleinen speziellen und kommerziellen Lösungen. Die Wahrscheinlichkeit, daß ein Bug schnell gefunden wird, ist groß. Da prinzipiell jeder Zugang zu den Kernelsourcen hat und einen Patch einreichen kann, werden Probleme sehr schnell gelöst. Auch am Samstag abend, wenn man gerade "bastelt". Die Community hat mich da bisher noch nicht enttäuscht.
@marcus: Danke, ok, wenn man das wohl ausstellen kann wird das kein Problem sein. Auf anhieb wüsste ich nichts wo er wirklich Daten blockieren sollte. Solange er komplette DWORDS komplett liest ist das ok, oder ist dies auch nicht der fall? Wobei eigentlich schreiben ja nie 2 Perihperie Geräte gleichzeitig in den gleichen Speicher, eigentlich schreibt jeder in sein eigenen und der ARM intern verarbeitet die Daten und ändert die einzelnen Dann wieder. aber direkt schreiben keine 2 in den gleichen...würde ich mal so behaupten. Und der ARM darf doch anscheinend blockieren soviel er will. Aber was heißt SWP? :D Diese Sache das bei QNX alles andere weiter läuft wenn etwas abstürzt ist wirklich fein. Hatte ich auch schon kurz was von gelesen. Für die Geschichte, Daten per Ethernet und auf TFT, werde ich das Keil RTX nehmen. Nur die spätere Sache finde ich zu umfangreich für das KEIL RTX. Wie meinst du das bei Platinenpreisen mit Einrichtungskosten? Ich befürchte das die Platine deutlich teurer wird. Der ARM9 wird doch mehr als 4 Layer benötigen.
@Joses Ich lese einen 1MS ADC ein und verarbeite jeden neuen Sample und das bevor ein neuer verfügbar ist. Zu den Evulationbords: Wenn du mehre OSs testen willst nimm das PM9263 dazu gibts auch gleich eine fertige Platine zum raufstecken mit allem möglichen drumherum. Denn für das Board gibt es Linux (standartmässig mitgeliefert), Windows CE 6.0 und QNX, wobei du da dann das BSP vom AT91SAM9263-EK nimmst.
@Gerhard Ja ich arbeite für eine Firma und wir haben uns bewusst gegen Linux entschieden. Davonab ist QNX auch für jeden zugänglich. Auch wenn es nicht 100% Open-Source ist. @Joses Das AT91SAM9263-EK hat 12 Layer das PM9263 hat 8.
Na ich hatte mit 9-10 Layer gerechnet. bewusst gegen Linux entschieden? Für welches denn sonst? Oder ohne OS? QNX ist für jeden zugänglich? Wie meinste das? Aber nicht im kommerziellen bereich oder? Du liest ein ADC im 1 ms Takt aus? wieso so schnell? Da haste doch dann auch das 50 Hz brummen drin. Den ADC steuerste über SPI an? Werden die Daten noch aufbereitet? Ansich ist doch so nen CAN Telgram schnell gesendet. Klingt ansich relativ einfach was du machst, aber das klingts bei mir. Liegt halt immer dadran was noch alles drum her rum passieren soll/muss :D @gerhard: ansich ist eine Bastler Community super weil viele dran arbeiten und viel passiert. Aber wenn man ein riesiges Problem hat und die Bastler gerade doch keine lust haben dann steht man alleien da und diese Gefahr will ich auch einfach vermeiden. Wobei so ne investition in nen neues Betriebssystem ne stolze Summe ist zu Zeiten von Finanzkriese.
@Joses Für Hobbyanwender ist QNX + IDE kostenlos. ich lese den ADC nicht in 1ms Takt aus sondern 1us Takt. 1 000 000 pro Sekunde. Beim schnellsten CAN dauert 1 Bit ja 1us. Störungen werden alle rausgefiltert, wie genau darf ich hier nun nicht sagen, versteht sich ja von selbst da das Produkt verkauft wird. Na ja kommt auf dem Markt an in dem man sich bewegt. Ich kann nur soviel sagen, dass wir die Finanzkriese weniger spüren. Außerdem sind 10k Einmalkosten für eine Firma defenetiv zu verkraften, was weh tut, da muss ich Gerhard recht geben, sind die 70€ pro Modul.
Ich frage jetzt einmal etwas ganz Böses: "würde nicht auch ein fertiges mini-ATX-board mit einem Atom-Prozessor das Problem lösen?" Bei kleineren Stückzahlen wäre das doch überlegenswert. Es spart viel, viel Arbeitszeit bei der Entwicklung. "Kritische Echtzeit" könnte auf einem PCI-Modul dazugebaut werden.
Preislich ist so nen Atom auf mini-ATX doch sicher teurer als nen 8,50 ARM9+sagen wir mal 50 Euro platine mit allem druff. 1µs? wow, ok :D da hatte ich mich verlesen. In dem Falle kann ich dein Zeitproblem verstehen. Darfst du die Branche sagen in der du tätig bist? Würde mich gerne interessieren :) Bzw. wobei brauch man einen so schnellen Analogwert? Achja, hatte ich schon gesagt das für das Atmelboard auch Win CE, Linux und QNX verfügbar ist? Ausserdem hat das Atmelboard das Display dran :)
http://www.cyantechnology.com du hattest ein o vergessen. Der sieht mir etwas schwach auf der Brust aus. Ausserdem ein 16bitter. Dann hat er noch kein CAN welches noch dran müsste und was soll mir das hier sagen? 4x32 segment LCD controller 4 Zeilen, je 32 Zeichen? Etwas wenig oder interpretier ich das gerade falsch.
@Gasst Hatten wir auch überlegt ABER leider passt ein Intel Atom schlecht in ein Hutschienenmodul. @Joesf Werkzeugüberwachung, wobei 1MS/s schon fast zu niedrieg ist, jedenfals für einen bestimmten Typ eines Sensoren die wir einsetzen. ^^ Das die drei OSs auch für das Atmelboard zu haben sind ist ja klar. Sagte ja dass das PM9263 und das EK gleich sind. Nur wenn du das Atmel EK bestellst bestell gleich noch DataFlash von Atmel mit, weil der NOR-Flash nicht auf dem EK ist. http://www.ronetix.at/starter_kit_9263.html Das Starterkit von Rontix gabs auch irgendwo mit Bildschirm, weiß nur nicht mehr wo. Beim EK von Atmel kommt man leider nicht so schick an den Parralelbus. Das Atmel EK hab ich auch noch rumliegen damit hatten wir auf Angefangen bis es unhandlicher wurde für unsere Zwecke.
hmm das Atmel EK hat doch 64MB SDRAM, 4MB PSRAM und 256MB NAND Flash. wofür brauch ich denn noch NOR-Flash ? Ich speicher doch das Programm in den NAND Flash und der code der ausgeführt wird laeuft im SDRAM oder? Und Variablen die ich netzausfall sicher speichern möchte kann ich doch in den EEPROM legen(den gabs doch auch noch odeR?) ansonsten auf ne SD Card oder in den NAND-Flash(?). Also früher hatte ich doch nur mein SRAM und mein EEPROM und Flash, da war noch alles easy :D wie ist das alles denn nun bei so nem ARM9 mit externen speicher? Oder laedt der dann auch nur daten vom externen SDRAM in den internen sram und arbeitet den dort ab? Was für Begrenzungen hat das für mich zur Folge? Nie mehr als 80kb Daten aufeinmal? Wie ist das VGA Display eigentlich beim Atmel EK angeschlossen? kann man da auch testweise nen anderes Displayanschliessen? Eventuell einfach nen Monitor um mal ne größere Auflösung zu testen? dieser JTAG/BDM Kasten von ronetix sieht ja lustig aus :) aber ich befürchte ich bleibe beim Atmel EK weil ich bei denen recht zufrieden mit dem komplett Support bin und mit der Keil Umgebung sollte das doch auch alles gehen. Bzw. die Software die beim rontix dabei ist ist doch eh Free, also Eclipse und das Linux. Weißte noch wie teuer das EK von Rontix war?
Du solltest mit 6 Lagen auskommen, 4 wenn du gut bist. Es kommt ein wenig darauf an, wie kompakt das ganze werden soll. Bei einseitiger Bestückung und etwas mehr Bauraum brauchst du weniger Layer, als wenn alles auf die beidseitige bestückte Briefmarke passen muß. Eine Strategie zur Kostenersparnis ist, die "leitungsintensiven" parallel angebundenen Speicher zusammen mit dem Prozessor auf eine kleine Karte zu bringen und den Rest auf einer etwas großzügigeren 2- oder 4-Layer-Platine zu verdrahten. Dann wird die Fläche, auf der Microvias und Feinstleiter benötigt werden, kleiner. Ich habe Layoutbeispiele mit dem AT91RM9200 im PQFP auf 2 Lagen und den AT91SAM9261 auf 4 Lagen. Das muß kein Pfusch sein. Mit Einrichtungskosten meine ich die Kosten, die beim Leiterplattenhersteller anfallen für das Konvertieren und Prüfen der CAM-Daten, Erstellen der Filme und das Einplanen in die laufende Produktion. Das kann bei Multilayern schon mal ein paar Tausender ausmachen. Die Platinen selbst kosten im Vergleich fast nichts. Ich glaube kaum, daß man da irgendwie mutwillig über 10 Euro für eine halbe Eurokarte kommen kann. Bei den Pool-Anbietern sieht die Kalkulation völlig anders aus, die sind auf kleine Stückzahlen eingerichtet und verteilen ihre Einrichtungskosten auf die einzelnen Platinen. Deshalb bezahlt man dort pro Platine gefühlt so viel. Noch ein Gedanke zu dem Microkernel, dessen Treiber unabhängig voneinander abstürzen können. Frage: Was bringt dir das? Du wirst kaum sinnlose Softwarebausteine (Treiber) auf deinem Embedded System im Produktiveinsatz laufen haben. Wenn ein Kernel-Treiber abstürzt, dann kann das Teil seine vorgesehene Funktion nicht mehr erfüllen. Was macht es da für einen Unterschied, ob der Display-Treiber noch läuft, wenn keine Daten mehr über Ethernet reinkommen? Mit einem Flugzeug, wo _nur ein_ Flügel abgefallen ist, fliegst du ja auch nicht mehr nach Hause. Ganz davon abgesehen sollten kommerziell verkaufte Geräte am besten gar nicht abstürzen. Damit zu werben, daß der Rest des Systems dann noch weiterläuft, hat fast Redmond-Qualitäten. (Ich komme aus der Luftfahrt, da sind die Maßstäbe an Softwarequalität recht hoch.)
@Josef: Denk dran, daß du ein Boot-ROM brauchst. Kann der 9263 vom Nand-Flash booten? Ich habe es nicht im Kopf. Die meisten Development-Boards sehen ein kleines Dataflash oder ein paralleles NOR für den Bootloader vor. Natürlich ist das externe SDRAM voll funktionsfähig in dem Sinne, daß deine Programme dorthin kopiert werden und auch von dort laufen. Das interne SRAM ist halt nur noch etwas schneller, könnte man für Caches nutzen. Das gleiche gilt für alle parallelen Speicher am EBI. Der Prozessor kann diese voll adressieren und muß keine Daten in das interne SRAM kopieren. Was natürlich nicht geht, ist von "gepagten" Speichern Programme direkt auszuführen. Es gibt halt keinen "random access".
@Gerhard: Diese Fähigkeit macht das Debuggen eventuell einfacher. Wenn ich weiß das die EthernetTask abgeschmiert ist dann weiß ich das dort ein Fehler ist und nichts mit den anderen Task zu tun hat, wobei man das pauschal auch nicht immer sagen kann. Keine Angst, damit zu werben, dass der Rest weiter laeuft wenn etwas abstürzt wird man eh nicht :D Zumindest ich nicht. hmmm Da das Atmel EK kein NOR drauf hat haette ich fast geglaubt das man einfach von dem was zur verfügung steht gebootet werden kann. Das interne SRAM werde ich wohl für Ethernet brauchen weil das anscheinend sonst probleme geben kann ... Wird denn bei dem Speicher mit Pages gearbeitet? Ich dachte das ist alles schnurstraks hintereinander adressiert ohne paging. Muss ich eigentlich irgendwas beachten bei den unterschiedlichen Speicherquellen? Also beim AVR musste man Variablen im Flash extra mit dem PGM zeug ansprechen. Ist sowas beim ARM auch nötig oder ist dort Variable=Variable und der Zugriff benötigt keine Extra-Funktion? In der Errata steht noch was, dass beim MCI bestimmte Commands nicht genutzt werden können bzw. in bestimmten fällen zu fehlern führen. 50.3.9 MCI 50.3.9.1 Busy signal of R1b responses is not taken in account The busy status of the card during the response (R1b) is ignored for the commands CMD7, CMD28, CMD29, CMD38, CMD42, CMD56. Additionally, for commands CMD42 and CMD56, a conflict can occur on data line 0 if the MCI sends data to the card while the card is still busy. The behavior is correct for CMD12 command (STOP_TRANSFER). Problem Fix/Workaround None Werden bei der SD Card auch diese Commandsbenutzt? Die einzige SDCard die ich mal angesprochen habe war dann mit dem KEIL RTX. Theoretisch müsste sich um so ein Fehler ja das OS kümmern oder? Puh so nen ARM9 dingen ist echt riesig in der Funktionalität. Da gibs noch soviel neues für mich zu lernen und soviel spannendes :) Ach ich freu mich schon wenn ich endlich nen EK habe :D
3.1.3 Evaluation Kit 3.1.3.1 Booting The AT91SAM9263 features an internal 80 KB SRAM. In addition, it also provides an External Bus Interface (EBI), enabling the connection of external memories; a 64 MB SDRAM chip is present on the AT91SAM9263 Evaluation Kit. The Getting Started example can be compiled and loaded on both memories. Würde doch bedeuten das er ohne probleme vom SDRAM Booten kann.
Vom SDRAM booten, naja. Das merkt sich ja ohne Strom nichts. Es gibt ja die JTAG-Schnittstelle und das SAMBA-Programm im ROM. Mit beidem kann man Progrämmchen von externen Schnittstellen laden und im RAM ausführen. Aber was ist bei einem "Kaltstart" des fertigen Produkts, wenn kein Debugger mehr angeschlossen ist? Da brauchst du eben einen nicht-flüchtigen Speicher (Flash), von dem der Prozessor von sich aus starten kann. Wenn du bisher hauptsächlich AVR kennst, da brauchtest du dir keine Gedanken machen, denn die haben ja Flash on chip. Der Speicher am EBI und das interne SRAM sind linear adressierbar. Was ich meinte, sind Flash-Bausteine, die Pages haben, die man nur komplett löschen kann (Dataflash, NAND). Aus solchen kann man wegen des fehlenden echten "Random Access" keine Programme direkt ausführen. Zum Debuggen eines abgestürzten Treibers: Das ist beim Linux-Kernel auch leicht möglich, der Coredump hinterlässt genug Informationen um zu sehen, woran es lag.
hmmmm und das, dass programm im nanflash gespeichert wird und dann beim boot vorgang in den sdram kopiert wird ist nicht moeglich? so nen minikernel hat der quasi auch nicht? ja ich hatte nur mit den avrs und mit dem arm7 zu tun aber dort war auch der komplette speicher "on board" also im chip. da hab ich das programm runter geschickt und es war im flash und wurde dann beim start ins sram kopiert und dort ausgeführt wenn ich das so richtig verstanden habe. das war beim at91sam7x. na wenn es nicht anders geht dann muss da halt noch nen nor dran aber wieso machen die sowas dann nicht mit drauf...tse was ein kaese
Guten Morgen zusammen @Gerhard Hast schon recht das es einem nichts nützt wenn etwas abschmiert und das andere funkioniert. Aber es bietet die Möglichkeit, dass abgestürzte Programm neu zu starten(wenn man die entsprechenden vorkehrungen geschaffen hat). Du hast natürlich recht das sowas nicht vorkommen darf, besonders nicht in der Flugzeugindustrie. Aber ich vermute mal das es bei Josef um ein weniger sicherheitskritisches Projekt handelt. Wegen dem Layout für die beiden Prozessoren, wir reden hier ja vom AT91SAM9263 der nur im BGA Gehäuse kommt. Unter 6 Lagen geht da nichts, wenn man Speicher mit anklemmen will. @Josef Zum Booten brauchst du beim 9263 externen Flash (kein Nand). Außer du programmierst dir deinen eigenen Bootloader, der aus dem Nand das Programm in den SDRAM läd. Mit dieser Voreinstellung wird das AT91SAM9263-EK geliefert. Daher wenn du dir das EK bestellst, bestell gleich eine "ATMEL DataFlash Card" mit. Das wird dir den einstieg mit dem EK vereinfachen. Am besten benutzt du noch U-boot damit du dich nicht um die ganze Initialisierung kümmern musst. Uboot bietet auch die Option das Programm aus dem Nand in den SDRAM zu kopieren. Man muss das Rad nicht immer neu erfinden. Wenn du willst kannst du den NOR noch auf dem EK bestücken.
Guten Morgen erst einmal! ATMEL DataFlash Card? Also im Grunde eine SD Card? Da hab ich doch ne 2GB Toshiba Card hier liegen (die läuft auch im SAM7X-EK). Kann ich die nicht nehmen? Dieses U-Boot macht die initialisierung? Also das alles was ich vorher in diesem Startup.s gemacht habe? diese Startup Datei ist sonst die Initialisierung, wo man angibt wie schnell der MC läuft und das der Code umkopiert werden soll. Das würde alles das U-Boot für mich machen? Wie teuer ist so ne "ATMEL DataFlash Card" und welche würde ich brauchen? Diese AT45DB642D? oder eher diese: AT45DCB008D? Also auf der Card liegt dann das Programm und U-Boot lädt es von da? Erst sagst du ich müsste nen Bootloader selbst schreiben und dann sagste ich brauch es doch nicht :D Wie verwirrend! Also ich könnte auch so mit dem Board arbeiten wie es kommt, dass heißt ich lade den Code in den NAND Flash und U-Boot lädt es beim boot in den SRAM. Die andere Variante wäre ich schliesse NOR Flash an und schreibe das Programm dort hinein und dann startet der MC ganz normal und lädt dort mein Startup File und macht alles weitere? ODER ich nutze so eine Atmel DataFlash Card die ich in diesen SDSlot stecke und dort schreibe ich mein Programm drauf und U-Boot(?) bootet das programm was sich dort auf der Card befindet? Habe ich das nun so richtig verstanden? Ich versteh noch nciht so ganz wieso so ne Card nun so wichtig ist bzw. der NOR-Flash. Mal so nebenbei, nutzt du den LCD Port für ne Grafische Anzeige? Wie lange brauch der denn für ein Bild in 800*600?
@ Josef Die Atmel Dataflash card ist ein NOR-Flash nur im SD gehäuse, ich hab das EK nicht dazu bewegen können von der SD-Karte zu Booten(auch wenn es gehen soll). "Das U-Boot" muss in einem bootfähigen Speicher(NOR-Flash) hinterlegt werden und ja es macht das was sonst deine Startup-Datei machen würde. U-Boot kannst du dir auch runterladen, einfach mal danach suchen, bekommst auch den ganzen Quellcode mit. Du musst nur selbst einen Bootloader schreiben, wenn du nur NAND und SDRAM an den 9263 ranpacken würdest. http://de.farnell.com/atmel/at45dcb002d/data-flash-card-2mb/dp/1362667 Die Karte gibt es auch noch in anderen größen. Vom NOR-Flash bootet der 9263 problemlos und daher für den Anfang die schnellste Methode wenn du das EK von Atmel kaufst. Zum LCD kann ich dir nix sagen, dass war einfach zu unwichtig.
Hast du eventuell die Revision A vom MC? Dort steht in der Errata das dies auch nicht geht, also das booten von SD-Card. Na wenn es ne Card wird dann schon das maximale was geht, fürs Entwicklungskit nehm ich meistens die größte Variante damit ich mir keine Einschränkung einbaue. Später kann man ja überlegen kleinere Sachen zu nutzen. Bei der FlashCard von Atmel steht auf der Atmel-Page das es nicht empfohlen wir für Neuentwicklungen (Not recommended for new designs) ... na das ist ja aufbauend :D Gibt es auch NOR-Speicher der nicht Bootfähig ist? Haste da mal einen Link zu einem den ich verwenden kann? Ich werde dann wahrscheinlich die Variante mit NOR Speicher nehmen. Das EK hat ja schon ein footprint drauf also die Anschlussmöglichkeit. Im Schaltplan wird dieser hier als Beispiel genannt: AT49BV642D. Mal schauen ob man an so einen einzelnen dran kommt.
Du solltest die Speicherkarte ja nicht mit integrieren. Welcher Speicher bootfähig ist wird vom Mikrocontroller vorgegebe. Momentan nicht, da wir ja die Komplettlösung genommen haben mit allen Speichern drauf, aber beim NOR gibt es nicht so gravierende Unterschiede(dafür leg ich aber nicht meine Hand ins Feuer). Im Manuel vom AT91SAM9263 findest du aber sicher genug Hinweise, ansonsten such einfach bei Farnell nach NOR-Flash
Ich benutze seit einiger Zeit den AT91SAM9263 Revision A und die Boardrevision A. Bis jetzt ist es mir nicht gelungen meinen Code vom Flash zu booten. Ich benutze den IAR-Compiler. Mit diesem Programm schreibe ich meinen Code und Debugge ihn. Wenn ich auf den Schalter Debug klicke, dann lade ich mit dem ATMEL-SAM-ICE (von Segger)meinen Code in den SRAM des AT91SAM9263. Dann läuft mein Programm auch. Wenn ich diesen jedoch in den NAND-Flash schreibe geht nicht mehr. Nun habe ich vor kurzem gelesen, das dies eh nicht mit der Boardrevision A gehen sollen, da dort ein Fehler vorhanden ist. 1. Geht dies denn jetzt bei der Boardrevision B?
@Johann: Also im ERRATA des Datenblattes steht bei Revision A folgendes: 50.2.12 ROM Code 50.2.12.1 SDCard Boot is Not Functional SDCard Boot is not functional in this revision. Problem Fix/Workaround None. 50.2.12.2 NAND Flash Boot is Not Functional NAND Flash Boot is not functional in this revision. Problem Fix/Workaround None. Bei Revision B ist dies nicht mehr der Fall.Ich gehe mal davon aus das dies klappt. Habe die Bestellung heute abgegeben und extra auf Revision B hingewiesen. Mal schauen wann es kommt und ob es wirklich Rev. B ist und ob es klappt. Zum NOR Flash: Da habe ich im Datenblatt vom EK geschaut. Beim Schaltplan steht ein bestimmter Atmel NOR Flash drin der Optional ist. Diesen habe ich nun einfach mit bestellen lassen. Montag oder Dienstag könnte das Kit da sein. UI wie aufregend :)
1. Wo hast Du denn die Revision B bestellt? Die EKs sind ja momentan sehr schlecht zu bekommen. Im dem AT91SAM9263 Datenblatt steht ja drin das bereits ein Bootloader auf dem µC vorhanden ist. Dieser sucht die externen NAND-Flash, Or-Flash und die SD-Karte nach Programm ab. Falls ein Programm gefunden wurde, wird diese in den SDRAM geladen und ausgeführt. 2. Ist dies auch wirklich der Fall oder muss ich den Bootloader selber schreiben?
Tschuldigung, muss mal kurz stören. @Stefan Kunz: Was sind denn das für Sensoren und was machst du da an Signalverarbeitung?
@Josef 1.Das Board hab ich bei Farnell bestellt hat nen wenig gedauert so 2 Wochen. Welche Revision ich habe kann ih nicht sagen dazu müßt ich das Board erst rauskramen. 2. Also die Kombination mit NOR und Uboot als zweiter Bootloader funktioniert tadelos. Wirst sicher nicht ein Bootloader schreiben müssen. @Volker Darf ich beides nicht sagen.
Ein Nor-Flash ist doch nicht auf dem Board drauf sondern nur ein Nand-Flash oder habe ich das falsch in Errinnerung.
Also das Board (Atmel Board) war letzte woche "lagernd" also wird es keine 2 Wochen dauern wobei ich nicht weiß ob das lagernde wirklich Rev. B. war. Ich hoffe mal schon. @Johann auf dem Board müsste aber extra platz sein und die anschlussmöglichkeit für NOR-Flash. Sollte also nicht wirklich schwer sein den dort drauf zu kriegen :) Aehm bei Farnell kostet das dingen 1.557,57 € ... ist da noch ein Goldbarren bei? Bei MSC kostet das Kit 450 € (mit JTAG Gerät). Ich hoffe ihr hattet nicht das dingen bei Farnell zu diesem Preis gekauft, ist ja unheimlich. Fährt einer von euch auf die embedded World? Bzw. war schon öfters dort? Ein Kollege meinte er kriegt da manchmal auch Developmentkits geschenkt :) Habt ihr sowas auch schon erlebt?
Bei digikey hat kostet es so 750€. Steht aber auch leider keine Revision dabei. Ich denke mal ich warte noch auf die Revision C. ^^ 1. Hat denn schon einer einen Nor-Flash auf das Board gelötet? Wenn ka welchen? 2. Hat jemand von Euch schon mal das Kamera Interface benutzt um dort ein Kamerabild auf das Display auszugeben? 3. Benutzt von Euch jemand den IAR-Compiler? Wenn ja gibt es dafür auch Schulungen?
Doch das Board haben wir bei Farnell bestellt aber das war nun über nen halbes Jahr her. Wenn du glück hast ist das bei MSC eine Aktion das es so billig ist. Und ich kann da wohl meinen Teamleiter rezetieren "Geld spielt keine Rolle" Die Bestellung musste schnell gehen und mit Farnell hatten wir nie Probleme. Viele fahren auf die Embedded World, besonders weil der Eintritt für einen Tag kostenlos ist, selbst als Privatperson, als Firmenmitglied bekommt man dann auch schon mal alle 3 Tage Eintritt kostenlos. Wenn verschenken die nur kleine Developmentkits. Nichts großartiges.
Hier der Link von MSC. http://www.msc-toolguide.com/atmel/tool-family/evaluation-kits/atmel-evaluation-kit-for-arm9-at91sam9263-devices.html Dort kostet es aber 630€ wo bekommt man es denn für 450? Kann man seine alte Revision eigentlich gegen eine neue umtasuschen?
http://www.msc-toolguide.com/atmel/tool-family/msc-startup-bundles/atmel-at91sam9263-startup-paket.html Hier kostet es nur 450€ aber wo liegt denn der Unterschied zwischen Startup Kit und dem Evaluation Kit? Außer das das Startup Kit günstiger ist und dann noch das Downloadtool dabei hat?
Wie ich oben schon erwähnt habe könnte das eine Sonderaktion von denen sein und daher ist das Paket so günstig
deine Hausaufgaben bzw. Arbeitsaufgaben alleine erledigen, statt einen Haufen anderer Leute dazu einzuspannen? Ist ja echt peinlich. Ein Unwirscher
450€ finde ich einen fairen Preis hatte vor einem Jahr 1000€ bezahlt. Habe heute mal nachgefragt bei MSC gibt es die Revision B. Nur leider wollten die mein Revision A Board nicht gegen ein Revision B Board umtauschen. Ich meinte da gibt es Fehler auf dem Board wodurch einiges was im Datenblatt versprochen wird nicht möglich ist. Das ist genauso als wenn man ein Auto kauft und der Verkäufer sagt damit kann man auch fahren. Wenn man jedoch losfahren will geht der Motor nicht.
Ich finde nur das bei diesem µC der DMA Controller sehr schwer zu handhaben ist. Ich bin aus der Beschreibung im Datenblatt nicht schlau geworden. Ich kann zwar ein Kamerabild von Kamerainterface auf das Display ausgeben, jedoch ist mir dieser DMA-Kontroller ein Rätzel ^^
Zitat: "Autor: Kannst du mal (Gast) Datum: 13.02.2009 15:39 deine Hausaufgaben bzw. Arbeitsaufgaben alleine erledigen, statt einen Haufen anderer Leute dazu einzuspannen? Ist ja echt peinlich. Ein Unwirscher" Wen meinst du denn damit? Mich? Ich finde irgendwie muss jeder mal anfangen und finde es nicht schlimm mit anderen Leuten über Probleme zu reden und Ansätze ob diese Gut sind oder nicht. Du wirst ja sicher schon ein riesiges Fachwissen in dem Bereich haben und den totalen Marktüberblick behalten um zu wissen welcher Controller wo seine Stärken und Schwächen hat. Bzw. wirst mal jeden antesten und gucken was für tücken dort auf dich zu kommen. Irgendwie schaffe ich so etwas zeitlich garnicht und wenn man sich nur die Informationen auf der HP der Hersteller anschaut sind alle MC's super und haben keine Fehler... DMA Controller sind doch wirklich sehr einfach. Man gibt Den Speicherplatz an wo er lesen soll und sagt wieviele Bytes und der macht das nebenbei. Schulungen findeste sicher irgendwo im Netz oder schreib IAR einfach an. Wieso sollte MSC auch dein Board umtauschen nur weil du ne alte Version hast? Anscheinend hattest du es ja auch noch nichtmals dort gekauft und auch wenn würde ich keinen Grund sehen dies zu machen, an stelle von MSC. Natürlich wäre es schön für dich abner wenn die das überall machen dann sind das doch riesige umkosten für die.
Gerhard wrote: > Erfahrung habe ich mit dem '9261. Die Errata-Liste ist ein wirkliches > Manko, in meinem Fall insbesondere wegen der Verrenkung, von einem > parallelen Flash starten zu müssen. Ansonsten funktioniert alles, was > ich brauche. Gerüchteweise sollen die anderen Anbieter aber genauso > "verbuggte" Chips anbieten. > Hallo Gerhard ich habe gerade genau das gleiche Problem am 9260. Ich muss von einem parallelen Flsh booten und das funktioniert nicht so richtig. Kannst du etwas mehr von deinen Verrenkungen erklären?
Ich meinte damit, überhaupt von einem parallelen Flash starten zu müssen (weil NAND nicht geht), ist die Verrenkung. Die Teile haben wenig Speicherplatz und sind dafür anständig teuer. Der parallele Bus erhöht den Aufwand auf der Platine. Ansonsten gab es kein Problem mit dem parallelen Flash. Was ist denn bei dir das Problem?
Ich kann mit dem Debugger openocd resume 0x10000000 u-boot starten. Von selber startet u-boot sehr langsam bis garn nicht. Dreimal Spannung anlegen, dass es einmal bootet. In den Foren habe ich gefunden das, das Umhängen der PLL nicht aus dem Flash geht. Ich vermute hier liegt das Problem.
>Autor: Stefan Kunz (Gast) > Vom NOR-Flash bootet der 9263 problemlos und daher für den Anfang die > schnellste Methode wenn du das EK von Atmel kaufst. > Hier gab es doch Probleme, http://www.at91.com/samphpbb/viewtopic.php?f=9&t=4554&p=13704 In welchem Clock Mode bootest du?
@ René D. Da mußt du leider bei der Firma anfragen, die das U-Boot dafür geschrieben haben(da ich ein fauler unterbezahlter Praktikant bin ^^) hab ich mir nur am Rande damit beschäfftigt, was das U-boot genau beim starten macht. Das U-boot kannst du dir unter ronetix.at angucken und runterladen. Ich kann halt defenetiv sagen, dass das Booten aus dem NOR und der Dataflash von Atmel problemlos und immer funktionierte, vorausgesetzt man hat den Speicher richtig beschrieben. Mit freundlichen Grüßen Stefan Kunz
Es ist kein Softwareschalter. Esist abhängig was für ein Pegel am Pin OSCSEL liegt. Ist es auf GND gezogen oder VDDBU angelegt?
Da ich keinen Schaltplan von Ronetix bekommen habe und nur das Board hier liegt kann ich dir das nicht beantworten.
Bitte 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.