Hallo Ich hatte heute mal wieder das Problem das mein Avr nicht schnellgenug war und hab mir überlegt das ein Multicore Avr nett währe. Theoretischer ansatz Ich nehme 2 oder 3 Normale Avrs m128 oder auch xmega und ein Ram. Dann mit einem Cpld jeweils einem Avr nach dem anderen ein Takt signal (Am Clock anstelle vom Quarzoszillator) und dem jeweils getaktetem Avr wird dabei der Ram zugeschaltet. Somit müsste es doch möglich sein das ein Avr daten aus dem Ram liest während ein anderer schreibt? Wie gesagt nur Theoretischer gedankengang. Das es nicht viel sinn machen würde ist mir bewust :)
>Somit müsste es doch möglich sein das ein Avr daten aus dem Ram liest >während ein anderer schreibt? Wegwerfen, funktioniert nicht.
Also sie würden ja nicht zeitgleich arbeiten sondern durch den Takt versetzt nacheinander. Wenns nicht geht woran würde es scheitern ?
holger schrieb: > funktioniert nicht Warum? Mit einem Dual-Port-RAM (DPRAM)ist das sehr wohl möglich.
Was hindert Dich dran eine leistungsfähigere Hardware zu verwenden? PIC32, intern mit 80 MHz, kosten weniger als 5 Euro.
Wenn man es richtig macht, so kann dieses Konzept sicher und stabil funktionieren. Das grösste Problem ist es, diesen Takt zu erzeugen. Natürlich ist es mit einem CPLD kein Problem, einen Takt durch zwei, drei, vier, ... zu teilen und jeweils versetzt auszugeben. Als Taktsignal taugt dieses von der Logik generierte Signal aber nicht, da man z.B. die Gefahr von Glitches hat oder die Laufzeitunterschiede Probleme machen können. Deshalb wird es in der Praxis sehr heikel sein, sowas zu implementieren. Ausser man nimmt spezielle Takterzeugungs-Schaltkreise (PLL etc.), aber das ist dann wieder ein anderes Thema... Auf jeden Fall birgt der Vorschlag auf allen Ebenen mindestens 1001 Problem, in der Praxis wird man sowas also ganz sicher nicht machen, sondern einen grösseren Controller nehmen. Selbst als einfacher Bastler macht man sowas nur, wenns Selbstzweck sein soll.
Wenn Du Probleme hast die voneinander unabhängig sind, ist schon seit Langem Multitasking in. Im Westen nix Neues. Ist aber das Resultat mehrerer Probleme mit dem Endstatus verknüpft, so müssen die Grübler querverknüpft sein. Sozusagen Demokratie auf Prozessorebene. Der Aspekt der Ressourcen steht dabei oft an zweiter, meist monetärer, Stelle.
was mich daran hindert ist auch das was mich auf diese idee gebracht hat. Mal eben schnell was ausprobieren, keinen Passenden Controller im haus, Überlegen wie man es aus teilen die man hat machen könnte. Also aus den Posts erlese ich das es im grunde mit viel aufwand schon gehen sollte. Aber ok was ich wirklich nicht bedacht hab lesen und schreiben ins ram ist ja auch auslastend, so das das ergebnis vermutlich kaum schneller währe. Trozdem danke :)
Wie hoch der Kommunikationsaufwand zwischen den CPUs für das Problem ?
Einfacher wäre ein Master-uC, der Arbeitspakete über einen Bus an die anderen uCs verteilt und die Ergebnisse wieder einsammelt.
>Es gibt Dual Port RAMs die du einfach von zwei AVRs aus gleichzeitig >nutzen könntest. dann stellen wir uns mal dumm und fragen woher weiss CPU1 von den Daten der CPU2 usw.
spontan schrieb: > Was hindert Dich dran eine leistungsfähigere Hardware zu verwenden? > PIC32, intern mit 80 MHz, kosten weniger als 5 Euro. Und leistet nicht wirklich mehr als ein AVR bei 20MHz. Nur Idioten gucken allein nach dem Takt. Kenner verstehen die Hardware.
Die AVRs sind doch hoffnungslos veraltet. Zum gleichen Preis gibt es 32bit µC mit FPU und DMA. Da hat der µC nicht mal angefangen irgendwas zu tun, da gerät der AVR schon ins Schwitzen. ;-) Atmegas werden nur noch aus Nostalgiegründen (Redesign zu teuer) oder Bequemlichkeit (Umstieg kostet Zeit und Nerven) verwendet. Das Preis/Leistungsverhältnis ist so schlecht, da gibt es einfach keinen anderen vernünftigen Grund mehr.
drt schrieb: > dann stellen wir uns mal dumm und fragen > > woher weiss CPU1 von den Daten der CPU2 usw. Jede CPU bekommt einen Speicherbereich zugewiesen, in den nur sie schreiben darf. Lesen dürfen den aber alle. Wäre eine Möglichkeit. Oder die CPUs können einen Speicherbereich für sich sperren, während sie darin schreiben. Danach geben sie ihn wieder frei für die anderen.
>Einfacher wäre ein Master-uC, der Arbeitspakete über einen Bus an die >anderen uCs verteilt und die Ergebnisse wieder einsammelt. Vorher +-----------+ | | ----+ ? +---- | | +-----------+ Nachher +-----------+ | | +----+ ? +----+ | | | | +-----------+ | +-----------+ | +-----------+ | | | | | | ----+ # +----+ +----+ ? +---- | | | | | | +-----------+ | +-----------+ | +-----------+ | | | | +----+ ? +----+ | | +-----------+ ... ich weis ja nicht
Klaus schrieb: > Ich hatte heute mal wieder das Problem das mein Avr nicht schnellgenug > war und hab mir überlegt das ein Multicore Avr nett währe. Wenn ich gemein wäre, würde ich jetzt schreiben, daß dein Programm einfach nur nichts taugt und man das mit effizientem Code ganz sicher hinbekommen würde. Aber ich bin heute nicht gemein. Ausserdem ist deine Idee kein Multicore- sondern ein Multiprozessorsystem. Der Atmega128 verfügt zwar über ein externes Speicherinterface aber mehr auch. Für ein Multiprozessorsystem braucht man aber einen gemeinsamen Bus. Somit ist Bus-Arbitration aber für den ein Fremdwort. Das ist aber das Zauberwort für Multiprocessing. mfg.
Das ist nicht nur theoretisch machbar, auch praktisch: http://www.mmk64.de Aber, nunja, ohne durchgetakteten Hardcore-Assembler-Code kannst du das vergessen, wenn du auch die volle parallele Leistung ausreizen willst. Wenn du nur mal schnell was ausprobieren möchtest, nimm besser irgend einen moderneren/schnelleren Prozessor. Grüße Mark
sfe schrieb: > Die AVRs sind doch hoffnungslos veraltet. Zum gleichen Preis gibt es > 32bit µC mit FPU und DMA. > [...] Käse. Beispiel bitte: 32bit+FPU+DMA für 1€.
Fallobst schrieb: > Beispiel bitte: 32bit+FPU+DMA für 1€. Lass es. sfe schrieb: > Die AVRs sind doch hoffnungslos veraltet. Das ist einfach nur dämliches Bla-bla von einem, der einen 32-Bitter braucht, um eine Led zum Leuchten zu bringen. Zum Blinken braucht er dann schon einen 64-Bitter. mfg.
sfe schrieb: > Die AVRs sind doch hoffnungslos veraltet. Zum gleichen Preis gibt es > 32bit µC mit FPU und DMA. Tatsächlich? Welche? Im übrigen sind sowohl 32Bit Integer-Verarbeitungsbreite als auch eine FPU alles andere als sichere Indikatoren für mehr Leistung. Das sind sie naturgemäß bestenfalls dann, wenn derartige Verarbeitungsbreiten auch tatsächlich benötigt werden, was im typischen µC-Bereich eher selten der Fall ist. Für die Verarbeitung eines Bit ist nämlich auch ein Byte schon unnötig breit. So simpel ist das eigentlich.
c-hater schrieb: > spontan schrieb: >> Was hindert Dich dran eine leistungsfähigere Hardware zu verwenden? >> PIC32, intern mit 80 MHz, kosten weniger als 5 Euro. > > Und leistet nicht wirklich mehr als ein AVR bei 20MHz. > > Nur Idioten gucken allein nach dem Takt. Kenner verstehen die Hardware. LOL. Für diese Aussage hast du bestimmt stichfeste Belege...
Habe keine Berührungsängste mit dickeren Schiffen, aber in 80% meiner Anwendungen laufen AVRs. Und die tun das, was sie sollen. Und die meiste Zeit schlafen sie sogar. Wenns ans Eingemachte geht, d.h. Rechenleistung und/oder Datendurchsatz gefordert ist, dann versuch ich nicht, dass irgendwie in einen AVR zu quetschen, der dann am Limit hangelt. Mit ein wenig Erfahrung sieht man schnell, wo es hingeht bzw. hingehen muss.
Der Wille mancher hier auf Teufel komm raus einen Controller von Atmel zu verbauen ist schon erstaunlich. Es gibt da draußen noch mehr als nur Atmel und i.d.R. gibt es für jede Anwendung schon einen passenden Controller ohne, dass man gewagte Winkelzüge vornehmen muss.
Also shared memory Multiprozessorsysteme sind immer noch in einigen Bereichen populär. Wenn Du einen Mehrkern-Prozessor hast, dann macht das das so. Das ist aber eine Sackgasse und skaliert nicht wirklich. (Speicherbandbreite zu gering) Verbinde lieber die Prozessoren über definierte Schnittstellen zwischen denen Du Botschaften austauscht. Sprich verbinde die zum Beispiel über SPI und lass sie synchron laufen. Damit kannst Du alle 18 Taktzyklen ein Byte austauschen lassen.
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.