SPORT-Bus fuer ARM Core, CMSIS?

Joerg schrieb:

[...]

kann das Dein SW-Dienstleister/Partner nicht selbst hinbekommen?

Du solltest dazu schreiben, um welches Interface es dabei gehen soll,

Es hat nicht nur Vorteile, sich fremder Software auszuliefern.

Servus

Oliver

*) Wobei die Metadaten des Datenblattes sagen, es sei schon sechs Jahre alt.

Hm, die Webseite sagt: "This product is new and engineering validation may still be underway. Quantities may be limited and design specifications may change while we ready the product for release to production."

Dreh damit noch nicht so raus...

Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt? 


Kosmologen: Die Geheim-Vorhersage.

Was stellst du dir denn unter SW-Support vor? Ich hab die SPORTs bisher nur auf dem Blackfin benutzt und da waren sie bei weitem das stress-

kniffligste war noch, den DMA gescheit mit dem Rest der Software zu verheiraten.

Da haben andere Komponenten mehr genervt: die UART mit "wir bauen die Macken vom 16550 nach und noch ein paar neue dazu". Oder der Speicher- controller, der mit einem undokumentierten Write-Buffer Zugriffe umsortiert, und damit Bankswitching kaputtmacht. Oder der SPI, der nur DMA-Send oder DMA-Receive, aber nicht beides kann.

aber benutzt hab ich das nie.

Stefan

Z.B. Driver. Und auch, dass mal jemand kompetent und "zeitnah" antwortet, was bei Analog Device in letzter Zeit arg zu wuenschen uebrig laesst. Sie meinen offenbar, das die Engineering Zone Foren reichen.

Das gibt es beim ADSP alles nicht. Da hat man die Hardware und sonst so gut wie nichts. Aehnlich ist es mit anderer Peripherie wie Ethernet oder USB. Erst wird das vollmundig beworben und spaeter heisst es, nur wenn man das Micrium RTOS benutzt, welches fuer den Seat fast den Preis einer S-Klasse hat. Sowas ist bei einem Start-up nicht mal eben aus der Portokasse machbar und wir wollen auch gar nicht dieses RTOS benutzen muessen.

SPI lief natuerlich auch nicht, hat unser SW-Mann per Bit-Banging machen muessen. Der UART ist nicht richtig interruptfaehig, und so weiter. Das ganze sieht nach einem schlappen Outsourcia-Design aus.

Danke! Habe das mal dem SW-Ing weitergeleitet. Bisher bin ich mit solchen Treiberroutinen nicht fuendig geworden, weil die Suche jedesmal bei einem teuren Compiler-Paket fuer den Blackfin endete, welches wir fuer den ARM-Cortex natuerlich nicht haben.

--
Gruesse, Joerg 

http://www.analogconsultants.com/

Hat jemand gesagt, dass wir das nicht koennen? Es gibt aber nunmal nur

24h am Tag und irgendwann muss das fertig werden. Driver sind normalerweise das mindeste, was man erwarten kann. Heutzutage wohl nicht mehr unbedingt.

Schon, aber wir haben handfeste Zusagen, dass es fertig sei und ab letzten Monat in Disti-Kanaelen auftauchen wird. Bisher sieht man vom ADSP-CM408F jedoch nur 50 Stueck bei Avnet. Digikey .. Mouser .. nix. Da haben sie den Mund vermutlich auch wieder was voll genommen. Irgendwie ist das nicht mehr die Firma, die sie vor Jahren mal war.

Ich nehme an, sie haben den IP Block gekauft und einfach in Outsourcia mit den eigenen Blackfin Peripheriemodulen zusammenkleben lassen.

--
Gruesse, Joerg 

http://www.analogconsultants.com/

Support nach Beispielcode fragen? Die haben das doch wohl zumindest mal getestet. Generell am besten immer gut abgehangene Chips verwenden, wo es schon ein paar Silizium-Revisionen von gibt.

Bit ADCs, da bietet es nur 12 Bit (aber da wirst du wahrscheinlich sowieso externe nutzen) und lief bei meinen Tests hier mit dem Discovery Board, und bei einem Custom-Board bei einem Kunden, bisher recht

Ethernet habe ich noch nicht ausprobiert, aber scheint es auch kostenlos zu geben und scheint gut zu laufen:

Hast du die schon alle aufgekauft? Die Webseite schreibt "No Stock, 13 Week Factory Lead Time"

--
Frank Buss, http://www.frank-buss.de 
C64 MIDI interface: http://www.frank-buss.de/kerberos/index.html

Welchen Support? :-)

Sieht so aus, dass die einiges gar nicht getestet haben.

Wenn sie ueber I2S den Datendurchsatz von 12 Kanaelen a 24bit bei 48ksps schaffen, waere das eine Moeglichkeit. Wobei der Support bei ST fuer "Non Key Accounts" IME grottenschlecht bis kaum vorhanden ist. Emails blieben unbeantwortet, deshalb habe ich ST nicht in Erwaegung gezogen. Dass Analog Devices ueber kurze Zeit derart weit absackt, haette ich allerdings nie gedacht.

:-)

Das ist aehnlich wie bei Smart Phones. Kommt ein neues raus, zelten sie vor der Tuer und 10 Minuten nach Ladenoeffnung sind alle weg. Ich hoffe, dass das Dingen nicht zu Vaporware wird. Das war auch ein Grund, dass wir ARM und CMSIS genommen haben, in der Hoffung, dann schnell umsatteln zu koennen. Wobei CMSIS sehr enttaeuscht hat. Haben wir fuer rund $6k die IAR Suite mit CMSIS Libraries gekauft und wichtige Sachen fehlen da einfach. Ich bin von der ganzen ARM Szene jedenfalls nicht mehr so angetan.

--
Gruesse, Joerg 

http://www.analogconsultants.com/

Am 25.08.2015 um 18:00 schrieb Joerg:

Sind dann aber eine Menge Daten, viel Taktzyklen pro Sample hast du dann nicht. Kann interessante Probleme geben, wenn es mit der

bei solchen Datenmengen und wahrscheinlich Realtime Anforderungen heutzutage immer FPGAs einsetzen. Ist im Endeffekt auch schneller

funktioniert. Besonders wenn du auch USB und Ethernet brauchst, dann kann es kompliziert werden. Besser in Kommunikations und Steuerchip trennen.

Man kann dann im Prinzip mit einem GCC Cross Compiler und einem Texteditor seiner Wahl arbeiten, und dann per Makefile compilieren und auch flashen, kostet alles nichts. Aber so eine IDE wie IAR oder

--
Frank Buss, http://www.frank-buss.de 
C64 MIDI interface: http://www.frank-buss.de/kerberos/index.html

Das geht schon ueber einen S-PORT ueber TDM, es sind eben nur in unserem Fall acht Ausgaengs- und vier Eingaengskanaele. Es haengt ein AD1938 dran, bei dem die alle bedient werden muessen, ob man nun jeden braucht oder nicht. Wir brauchen alle Inputs, aber nur einige wenige der Outputs. Den Rest muss man als Ballast mitschleifen.

Der ADSP-CM408F sollte das laessig packen und inklusive der Mathematik unter 50% Auslastung bleiben. Speicher haben wir derzeit etliche MB extern drauf, aber die sollen spaeter wegfallen. Denn der ADSP hat einige hundert kB auf dem Chip und wir koennen Daten recht zuegig verwerfen. Ueberschlaegig brauchen wir kaum 50kB an RAM.

Schon, aber es ist nach wie vor der Job des uC Produzenten oder des Lizenzgebers (ARM), oder beiden, fuer den Prozessor passende Routinen zur Verfuegung zu stellen.

Da wollten wir nicht kleckern und lieber was richtig professionelles anschaffen. Der Support der Design Suite ist dann auch besser. Was die fuer den Prozessor beinhalteten Libraries angeht, sind wir jedoch herbe enttaeuscht.

--
Gruesse, Joerg 

http://www.analogconsultants.com/

Am 25.08.2015 um 18:57 schrieb Joerg:

Ok, dann macht das wohl schon Sinn, diesen Microcontroller zu verwenden. Hat mich nur gewundert, da du normalerweise 8051 CPUs verwendest wo immer es geht, und dann direkt zu Preliminary-Chips wechselst :-)

Die STM32-Serie scheint keinen generischen TDM-Bus zu bieten. Vielleicht

in Software vorbereitet und extern noch ein paar 7473 Flipflops

Projekt, damit den AD1938 vom Discovery Board aus anzusprechen.

ist oder Fehlerfreiheit der Chips.

Cores, wie Debugging, SysTick usw.

STM32F4xx_StdPeriph_Driver, was aber scheinbar genau den

dieselben Register und Verfahren hat, oder zumindest dasselbe API, wie

GPIO-Ports konfigurieren einfach den Hersteller wechseln kann und dann dieselben Funktionen weiterhin funktionieren?

Cypress PSoC-Creator IDE, also wo man den Prozessor sieht und alles grafisch konfigurieren kann:

Ich bin normalwerweise kein Fan von solchen Tools und programmiere das lieber alles selbst mit Funktionsaufrufen, aber nach Anfangsschwierigkeiten ist das mittlerweile auch recht ausgereift und

den Clock-Tree von modernen Microcontrollern ist das schon praktisch, wenn man das grafisch sieht, oder auch mit nur einem Mausklick USB mit

--
Frank Buss, http://www.frank-buss.de 
C64 MIDI interface: http://www.frank-buss.de/kerberos/index.html

Am 25.08.2015 22:50, schrieb Frank Buss:

Des Kugelgrillers neue Kleider!

Das war einer der wenigen, der genug Rechenleistung hat und kein stromfressender DSP ist. Wir haetten einen DSP von TI nehmen koennen, aber es ist schwierig bis unmoeglich, lokal jemanden zu finden, der das programmieren kann. In diesem Fall musste es wirklich lokal sein, weil wir an einer Versuchsanlage zusammenarbeiten muessen. Ich kann in einer halben Stunde pedalierend beim SW Ingenieur sein. Auf der Strecke ist allerdings Mountain Bike angesagt, deshalb hat meines jetzt einen kernigen Gepaecktraeger fuer hin und her geschleppte Hardware. Wenn alles fertig ist, fahre ich mit der Kiste auf dem Gepaecktraeger den kompletten Trail mit Felspisten und allem, volle Kamelle. Wenn es ueberlebt, ist die Qualitaet gut.

Es ist nicht nur das Protokoll, es muessen auch 14Mbit/sec an Daten verknusert werden. Aber STM32 ist ja auch sehr leistungsfaehig.

IME haben die manchmal Schwierigkeiten mit den mehr analogen Teilen auf den Chips. Oszillator, POR/BOR. Wobei den POR/BOR fast niemand richtig hinbekommt, muss man bei kritischen Sachen immer extern selbst zimmern.

Ein wenig schon.

Zitat "CMSIS-Driver: defines generic peripheral driver interfaces for middleware making it reusable across supported devices". Darum geht es uns, Driver fuer Standard-Peripherie wie SPORT, SPI, UARTs, et cetera.

Das muessen wir alles noch rausfinden. Heute mittag ist erstmal eine Web Konferenz. Nachdem ich gestern an den Geschaeftsfuehrer geschrieben hatte, gab es einen mittleren Erdrutsch und die Sache bekommt dort jetzt viel Aufmerksamkeit :-)

Damit koennte ja sogar jemand wie ich Software erstellen :-)

Zitat "In first, the design oscillator in any way does not release you from reading datashitov" ... Schoen!

Dass Du davon kein Fan bist, Kann ich mir gut vorstellen. Fuer Hardware gibt es aehnliche Tools. Z.B. WebBench, was in allen Faellen, wo ich das spasseshalber probiert hatte, die Antwort "cannot be designed with these parameters" oder so aehnlich kam. Also wie gehabt von Hand entwickelt und ging alles in Produktion.

--
Gruesse, Joerg 

http://www.analogconsultants.com/

Am 25.08.2015 um 18:24 schrieb Frank Buss:

doch die doppelte/vierfache Bandbreite ist so ein FPGA-Programm

von seinem STM32 ausgetauscht hat.

Aber viele haben vor FPGAs irgendwie immer noch Angst. Der

25+ Jahren! :-)

Gruss, Michael

oder Verilog zu finden ist verdammt schwierig. Und beide Sprachen halt

"umlernen".

Von den bekackten Entwicklungszyklen ganz zu schweigen. Eine Zeile VHDL

alles schon erlebt. Ja, klar, ach so tolle Behavioral-Simulation. Bildet

Und dass es viele FPGAs nur noch als BGA gibt stellst du so als Vorwand hin, warum man die nicht nehmen will. Fakt ist aber, dass die bei

Das *ist* ein Argument dagegen.

Applikation in eine MCU reinpressen kann.

Nee, neee, FPGA nimmt man echt nur, wenn nix anderes geht.

Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt? 


Kosmologen: Die Geheim-Vorhersage.

Das ist der Hauptgrund, warum ich oft 89C51 und aehnliches einsetzte. Man findet ueberall SW-Leute, die damit umgehen koennen. Der zweite Grund ist 2nd Source, das es sonst bei Prozessoren fast nirgends gibt und bei FPGA schon gar nicht. Verfuegbarkeit in 25 Jahren muss nicht unbedingt sein, 20 Jahre jedoch schon. Auch dabei sehen viele FPGA Familien recht alt aus.

Grosse BGA sind bei den meisten meiner Design der Killer. Mache ich nicht. Ein in der Loetverbidung voellig starres Produkt auf eine in sich leicht biegsame FR-4 Platine zu loeten, empfand ich noch nie als gute Idee und mache das wenn moeglich nicht mit.

Sobald der Preis zweistellig wird, isses meist aus, geht nicht.

Sehe ich auch so.

--
Gruesse, Joerg 

http://www.analogconsultants.com/

Am 26.08.2015 um 17:59 schrieb Johannes Bauer:

auskannte. Mit solchen Vorkenntissen kann man das gut in einem Jahr "on the job" nebenbei lernen.

Wenn man die richtigen Timing Constraints setzt und die auch bei der Synthese eingehalten werden, habe ich sowas noch nicht erlebt (bis auf

teste die auch mal in Hardware einzeln. Da braucht man eine komplette Synthese kaum noch.

Viele FPGAs gibt es auch als TQFP, und sind auch nicht allzu teuer. Klar, wenn man da eine Soft-CPU mit rein synthesisiert usw. dann braucht

Microcontroller, wo so Sachen wie Ethernet und USB getestet als Hardware fertig drin ist und nur das in die FPGAs auslagern, was dort sinnvoll

auswerten und senden sind FPGAs ideal. Das in VHDL zu programmieren kann

datenflussbasierten Aufgaben in Hardware abbilden kann.

Wenn man nicht die herstellerspezifischen Entities verwendet, dann ist VHDL sehr portabel, wenn man aufpasst und auch nur die Standard-Libraries verwendet.

II von 2004 wird immer noch empfohlen. Aber stimmt schon, Preis ist so ab 14 Euro. Aber Lattice und Xilinx haben auch nicht ganz kleine FPGAs im einstelligen Preisbereich.

--
Frank Buss, http://www.frank-buss.de 
C64 MIDI interface: http://www.frank-buss.de/kerberos/index.html

Hrrhrr, ja, so kenne ich das auch :) Allerdings sind die Dinger schon cool, bei so Universal-SDRs wird teilweise damit gezaubert.

-ras

--
Ralph A. Schmid 
http://www.schmid.xxx/ http://www.db0fue.de/ 
http://www.bclog.de/ http://www.kabuliyan.de/

Die richtig coolen FPGA kosten dreistellig.

-ras

--
Ralph A. Schmid 
http://www.schmid.xxx/ http://www.db0fue.de/ 
http://www.bclog.de/ http://www.kabuliyan.de/

Am 26.08.2015 um 17:59 schrieb Johannes Bauer:

Naja, das ist sehr schnell portiert. Schneller als ein (entsprechend komplexes) C-Programm was u.U. noch die Errata des Ursprungs-Controllers umschifft. Gerade bei den hier angesprochenen Anwendungen mit Silizium-Erratas in den Peripherie-Modulen.

MCU-Toolchains.

Gruss, Michael