|
Anzeige
|
Marktlücke?
Gast
#521458
Hallo! Ich schaue mir gerade diverse µCs an und habe das Gefühl, dass es keine halbwegs modernen (SPI, JTAG, Timer, etc) und günstigen (AVR Niveau) 8-Bitter mit Von-Neumann-Architektur, externem Speicherinterface und kostenlosem C Compiler gibt. Stimmt das, oder hab ich was übersehen? MfG bad guy
Gast
#521460
Wo ist dien Problem? Die AVR sind doch bestens, und bei den größeren Prozessoren kann man externen RAM anstöbbeln....
Gast
#521463
Ist der kostenlose Compiler tatsächlich eines der Kriterien, daß die Zahl der von Dir fokussierten Controller so stark verarmt? Was wäre preisgünstig? Ich würde mal sagen, daß die, welche einen solchen ausgebauten und zugleich mickrigen 8-Bitter einsetzen, ein Massenprodukt herstellen und daher nicht auf kostenlose Compiler angewiesen sind, oder ?
Gast
#521464
AVRs haben keine Von-Neumann-Architektur -.- Es gibt doch jetzt diese mini-ARMs, die als Ersatz für die aktuellen 8-Bitter gedacht sind - wie heißen die doch gleich?
Gast
#521466
siehe : Beitrag "PIC oder AVR" zB: - Sind Daten in RAM und ROM mit dem gleichen Code benutzbar? AVR, PIC, alle übrigen Harvard-Architekturen: NEIN. Daten im ROM erfordern anderen Zugriff als Daten im RAM. Entweder versteckt das der Compiler in Runtime-Routinen für Pointerzugriffe, oder man kann Routinen nicht so schreiben, dass sie beides als Parameter verdauen können. Bei kleinen Programmen von ein paar KB kein Problem, bei grösseren jedoch schon. Bei AVR/GCC ziemlich fehlerträchtig. MSP430: saubere von-Neumann Architektur. Problemlos.
Gast
#521467
In diesen Forum werden Beiträge ja besonders sorgfältig gelesen. Der MSP430 hat kein externes Speicherinterface.
Gast
#521468
... und ist zudem ein 16Bit Controller.
Gast
#521469
Hallo Kann mir jemand den Vorteil einer Von-Neumann-Architektur (konkret für kleine Mikrocontroller) erläutern? Jedenfalls habe ich mit Harvard bei den AVRs überhaupt kein Problem. Das einzige, was ich mir allenfalls wünschen würde, wäre, dass das Programm ebenfalls in SRAM gespeichert wird, anstatt Flash. So könnte man schneller in diesen Bereich schreiben und die Chips höher Takten. Gruss Michael
Gast
#521470
NACHTRAG: AVR-Progger möchten ja meistens zumindest einige Kilobyte Programmspeicher. Würde man die Controller als Von-Neumann-Architektur ausführen, so müsste dieser samt und sonders als SRAM gehalten werden, kleine Tinys also mit 2 oder 4 kB SRAM, grössere Megas mit bis zu 128 kB - wäre das nicht sehr teuer? (Wenn ich mir so die mickrige SRAM-Ausstattung der AVRs anschaue, komme ich eindeutig zum Schluss, dass SRAM ein 'kostenintensiver' Faktor ist.) Die Ausstattung der AVR-Familie mit SRAM ist nicht mickrig, sondern an die typischen (Massen-) Anwendungen dieser µCs angepasst. Der Markt reguliert das. Wenn in einer Applikation mehr Speicher benötigt wird, kann man diesen extern anbinden (z.B. Dataflash über SPI). Für rechenintensive Applikationen, die auf einen großen Datenbereich zugreifen müssen, eignet sich dann eher ein ARM-Prozessor mit externem SDRAM oder ein DSP. Ich habe mit dem Angebot von Atmel (AVR, ARM7, ARM9) noch jedes Problem einigermaßen kostengünstig lösen können. Wo ist das Problem?
Gast
#521479
Das war implicit auch mein Ansatz. Wer braucht einen billigen 8bitter, der nicht viel billiger ist, als ein 16er, dafür aber im RAM-Zugriff limitert ist?
Gast
#521804
die compiler bei www.emcrypt.com sind doch recht günstig
Gast
#521826
@Mr.Chip Wieso müsste bei einer von Neumann Architektur der gesamte Speicher als SRAM gehalten werden? Die Technologie kanns nichts sein da beide Speicherarten eh auf dem Chips sind und Flash und RAM extern im selben Speicherbereich geht ja auch. btw. wie wäre es mit dem eZ80F91? Ich finde es reichlich vermessen, seine persönlichen Spezialwünsche gleich als "Marktlücke" zu beschreien. Wenns wirklich eine wäre, hätte sich doch auch ein Hersteller dafür gefunden. JTAG ist ja ganz lustig, um mal zu Anfang in die Innereien eines MC reinzuriechen, bei der richtigen Programmierung nützt es aber herzlich wenig. Peter Peter Dannegger wrote: > JTAG ist ja ganz lustig, um mal zu Anfang in die Innereien eines MC > reinzuriechen, bei der richtigen Programmierung nützt es aber herzlich > wenig. Naja, sag aber dazu dass du mit dieser Meinung eher alleine dastehst.
Gast
#521935
Gabs da nicht mal sowas wie boundary test? JTAG hätte damit seine berechtigung wieder! @peter: debuggen is aber dennoch eine feine sache ^^ Ganz so allein steht Peter sicherlich nicht. Habe auch noch nie JTAG genutzt. Und mich schon oft geärgert, daß die AVRs keinen Programmcode aus dem RAM ausführen können. Mit dynamisch erzeugtem Code wäre vieles so einfach, aber nicht, wenn man dafür dauernd Seiten flashen muß. Aber da gibt es schlimmere Marktlücken. Also nicht jammern, sondern das beste aus dem machen, was da ist. Andreas Schwarz wrote: > Peter Dannegger wrote: >> JTAG ist ja ganz lustig, um mal zu Anfang in die Innereien eines MC >> reinzuriechen, bei der richtigen Programmierung nützt es aber herzlich >> wenig. > > Naja, sag aber dazu dass du mit dieser Meinung eher alleine dastehst. Ist jedenfalls meine Erfahrung. In einem realen Projekt ist die CPU nicht mehr allein auf der Welt, sondern nur noch ein Rädchen im Getriebe. Und wenn sie dann mal stille steht, weil man sich nen Debugwert anguckt, ist sämtliches Timing zum Teufel, da ja alle Bauteile drumherum noch weiterlaufen. Noch lustiger wirds, wenn man 2 oder mehr MCs hat, die ständig Daten senden. Ich hab mal mit den Silabs 8051-ern rumgespielt. Solange die CPU nur auf dem Testboard war und nichts weiter zu tun hatte, konnte man mit JTAG alles ansehen. Aber sobald man ne reale Schaltung aufgebaut hat, ist Schluß mit Däumchen drehen und JTAG höchstens noch zum Proggen zu gebrauchen. Insbesondere bei Fehlern mit Interrupts ist Stillestehen absolut tödlich. Nervig war auch, daß nach jedem Reset erstmal das Programm neu gebrannt wurde, ehe man mit dem Debuggen loslegen kann. Peter Antwort schreiben |
Anzeige
|
