Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #191213 > unrolled thread

SPORT-Bus fuer ARM Core, CMSIS?

Back to article view | Back to de.sci.electronics

Contents

  SPORT-Bus fuer ARM Core, CMSIS? Joerg <news@analogconsultants.com> - 2015-08-24 15:06 -0700
    Re: SPORT-Bus fuer ARM Core, CMSIS? Oliver Betz <OBetz@despammed.com> - 2015-08-25 09:49 +0200
      Re: SPORT-Bus fuer ARM Core, CMSIS? Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-08-25 10:33 +0200
        Re: SPORT-Bus fuer ARM Core, CMSIS? Joerg <news@analogconsultants.com> - 2015-08-25 06:27 -0700
          Re: SPORT-Bus fuer ARM Core, CMSIS? Frank Buss <fb@frank-buss.de> - 2015-08-25 17:01 +0200
            Re: SPORT-Bus fuer ARM Core, CMSIS? Joerg <news@analogconsultants.com> - 2015-08-25 09:00 -0700
              Re: SPORT-Bus fuer ARM Core, CMSIS? Frank Buss <fb@frank-buss.de> - 2015-08-25 18:24 +0200
                Re: SPORT-Bus fuer ARM Core, CMSIS? Joerg <news@analogconsultants.com> - 2015-08-25 09:57 -0700
                  Re: SPORT-Bus fuer ARM Core, CMSIS? Frank Buss <fb@frank-buss.de> - 2015-08-25 22:50 +0200
                    Re: SPORT-Bus fuer ARM Core, CMSIS? Dieter Wiedmann <dieter.wiedmann@t-online.de> - 2015-08-26 04:14 +0200
                    Re: SPORT-Bus fuer ARM Core, CMSIS? Joerg <news@analogconsultants.com> - 2015-08-26 07:52 -0700
                Re: SPORT-Bus fuer ARM Core, CMSIS? Michael Reinck <mrreinck@googlemail.com> - 2015-08-26 17:23 +0200
                  Re: SPORT-Bus fuer ARM Core, CMSIS? Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-08-26 17:59 +0200
                    Re: SPORT-Bus fuer ARM Core, CMSIS? Joerg <news@analogconsultants.com> - 2015-08-26 09:28 -0700
                      Re: SPORT-Bus fuer ARM Core, CMSIS? "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2015-08-27 08:03 +0200
                      Re: SPORT-Bus fuer ARM Core, CMSIS? Guenther Wenninger <g!!rw@bitschubbser.org> - 2015-08-27 23:11 +0200
                        Re: SPORT-Bus fuer ARM Core, CMSIS? Frank Buss <fb@frank-buss.de> - 2015-08-27 23:36 +0200
                          Re: SPORT-Bus fuer ARM Core, CMSIS? Guenther Wenninger <g!!rw@bitschubbser.org> - 2015-08-27 23:50 +0200
                        Re: SPORT-Bus fuer ARM Core, CMSIS? Joerg <news@analogconsultants.com> - 2015-08-27 14:48 -0700
                          Re: SPORT-Bus fuer ARM Core, CMSIS? Guenther Wenninger <g!!rw@bitschubbser.org> - 2015-08-27 23:59 +0200
                            Re: SPORT-Bus fuer ARM Core, CMSIS? "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2015-08-28 08:15 +0200
                              Re: SPORT-Bus fuer ARM Core, CMSIS? Guenther Wenninger <g!!rw@bitschubbser.org> - 2015-08-28 10:02 +0200
                    Re: SPORT-Bus fuer ARM Core, CMSIS? Frank Buss <fb@frank-buss.de> - 2015-08-26 20:10 +0200
                      Re: SPORT-Bus fuer ARM Core, CMSIS? Michael Schwingen <news-1326478115@discworld.dascon.de> - 2015-08-27 18:49 +0000
                    Re: SPORT-Bus fuer ARM Core, CMSIS? "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2015-08-27 08:02 +0200
                    Re: SPORT-Bus fuer ARM Core, CMSIS? Michael Reinck <mrreinck@googlemail.com> - 2015-08-27 20:04 +0200
    Re: SPORT-Bus fuer ARM Core, CMSIS? Stefan Reuther <stefan.news@arcor.de> - 2015-08-25 13:07 +0200
      Re: SPORT-Bus fuer ARM Core, CMSIS? Joerg <news@analogconsultants.com> - 2015-08-25 06:22 -0700
    Re: SPORT-Bus fuer ARM Core, CMSIS? Joerg <news@analogconsultants.com> - 2015-08-27 11:20 -0700

Page 2 of 2 — ← Prev page 1 [2]

#191354

Guenther Wenninger <g!!rw@bitschubbser.org> wrote:

>Solange es
>ein FPGA bleibt, bleibt man auch flexibel was neue Funktionen o.ä.
>angeht.

Für kleine Serien hochpreisiger Geräte eine tolle Sache, ja. 


-ras

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

[toc] | [prev] | [next] | [standalone]

#191356

Ralph A. Schmid, dk5ras <ralph@schmid.xxx> schrieb:
> Guenther Wenninger <g!!rw@bitschubbser.org> wrote:
>
>>Solange es
>>ein FPGA bleibt, bleibt man auch flexibel was neue Funktionen o.ä.
>>angeht.
>
> Für kleine Serien hochpreisiger Geräte eine tolle Sache, ja. 

Ja, oder wenn es später doch in Richtung ASIC geht, kann man
die "alten" FPGA-Boards auch prima als Entwicklungsplattform
nutzen.

/grw

-- 
For reply: Remove the additional chars from the local part.

[toc] | [prev] | [next] | [standalone]

#191285

Am 26.08.2015 um 17:59 schrieb Johannes Bauer:
>
> Äh, das wichtigste hast du aber vergessen: Gute HW-Entwickler für VHDL
> oder Verilog zu finden ist verdammt schwierig. Und beide Sprachen halt
> auch für Software-Leute auch hochgradig unintuitiv. Die kann man nicht
> "umlernen".

Ich habe schon größere Designs in VHDL implementiert, aber hat 
wahrscheinlich auch geholfen, daß ich mich schon vorher in Elektronik 
auskannte. Mit solchen Vorkenntissen kann man das gut in einem Jahr "on 
the job" nebenbei lernen.

> Von den bekackten Entwicklungszyklen ganz zu schweigen. Eine Zeile VHDL
> geändert, 30 Minuten Synthese abwarten, testen, geht nicht. Geil. Leider
> alles schon erlebt. Ja, klar, ach so tolle Behavioral-Simulation. Bildet
> halt nur leider nicht immer die Realität ab.

Wenn man die richtigen Timing Constraints setzt und die auch bei der 
Synthese eingehalten werden, habe ich sowas noch nicht erlebt (bis auf 
wenige Ausnahmen, einmal ein Softwarefehler in der Synthesesoftware, für 
den Altera einen Hotfix erstellt hat). Ich schreibe auch für die 
Entities jeweils eigene Testbenchs (für kommerzielle Projekte), oder 
teste die auch mal in Hardware einzeln. Da braucht man eine komplette 
Synthese kaum noch.

> 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
> genügend geringem Pitch *richtig* schwer zu löten sind und ohne
> Röntgengerät kann man auch nicht kontrollieren, ob der Prozess passt.
> Das *ist* ein Argument dagegen.
>
> Vom Preis ganz zu schweigen. Völlig außer Konkurrenz, wenn man dieselbe
> Applikation in eine MCU reinpressen kann.

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 
man größere. Sinnvoll ist denke ich eine Kombination aus 
Microcontroller, wo so Sachen wie Ethernet und USB getestet als Hardware 
fertig drin ist und nur das in die FPGAs auslagern, was dort sinnvoll 
ist. Für sowas wie Realtime ein halbes dutzend TDM-Kanäle empfangen, 
auswerten und senden sind FPGAs ideal. Das in VHDL zu programmieren kann 
sogar weniger Arbeit sein, als wenn man es in C für einen 
Microcontroller machen würde, da man meist sehr gut solche 
datenflussbasierten Aufgaben in Hardware abbilden kann.

> Genau, die proprietären Toolchains habe ich voll vergessen zu erwähnen.
> Da schießt man sich auf einen Vendor ein und wenn man irgendwann mal
> wechseln will, muss man den ganzen Dreck neu lernen. Und was für ein
> Kackbloat das immer ist! Mehrere Gigabyte groß. Keine Ahnung was die da
> reinpacken. Bwäh, PFUI.

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

Der Cyclone I von Altera ist übrigens von 2002 und immer noch 
erhältlich, aber wird nicht mehr für neue Designs empfohlen. Der Cyclone 
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

[toc] | [prev] | [next] | [standalone]

#191340

On 2015-08-26, Frank Buss <fb@frank-buss.de> wrote:
>> Von den bekackten Entwicklungszyklen ganz zu schweigen. Eine Zeile VHDL
>> geändert, 30 Minuten Synthese abwarten, testen, geht nicht. Geil. Leider
>> alles schon erlebt. Ja, klar, ach so tolle Behavioral-Simulation. Bildet
>> halt nur leider nicht immer die Realität ab.
>
> Wenn man die richtigen Timing Constraints setzt und die auch bei der 
> Synthese eingehalten werden, habe ich sowas noch nicht erlebt (bis auf 
> wenige Ausnahmen, einmal ein Softwarefehler in der Synthesesoftware, für 
> den Altera einen Hotfix erstellt hat). Ich schreibe auch für die 
> Entities jeweils eigene Testbenchs (für kommerzielle Projekte), oder 
> teste die auch mal in Hardware einzeln. Da braucht man eine komplette 
> Synthese kaum noch.

Ich hatte gestern den Fall, daß der Code (eine einfache Statemachine mit
angeflanschtem synchronem Counter für ein paar States) im Aldec-Simulator
einwandfrei funktionierte, der Synthesizer (Lattise LSE und Synplify -
beide!) meinte, den Counter könnte er weglassen, und in Folge die halbe
restliche Logik, die hinten 'dran hängt.

Ein asynchroner Reset hilft ... (und macht neue Probleme, wenn man ihn nicht
sauber synchronisiert ;-)).

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

In Grenzen kann man IP-Blöcke mit Wrappern passend machen - ich habe ein
Design, das wahlweise auf einem alten Spartan 2 oder einem MachXO2 läuft.
Die Hersteller-FIFOs haben einen Wrapper bekommen, so daß die zu meinem Code
hin das gleiche Interface haben.

RAM sollte man inzwischen als normales VHDL hinschreiben können - geht auch,
gibt bei Lattice aber deutlich schlechtere Performance als wenn man den
IPExpress-Blockgenerator benutzt :-(

Abgesehen von den Tools gefallen mir die MachXO2 für kleine Anwendungen
durchaus.

cu
Michael

[toc] | [prev] | [next] | [standalone]

#191303

Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:

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

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/ 

[toc] | [prev] | [next] | [standalone]

#191337

Am 26.08.2015 um 17:59 schrieb Johannes Bauer:
> Genau, die proprietären Toolchains habe ich voll vergessen zu erwähnen.
> Da schießt man sich auf einen Vendor ein und wenn man irgendwann mal
> wechseln will, muss man den ganzen Dreck neu lernen. Und was für ein

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.

> Kackbloat das immer ist! Mehrere Gigabyte groß. Keine Ahnung was die da
> reinpacken. Bwäh, PFUI.

Ack. Das nervt. Allerdings gilt das auch für fast alle ernsthaften 
MCU-Toolchains.

Gruss,
Michael

[toc] | [prev] | [next] | [standalone]

#191236

Hallo,,

Joerg wrote:
> Bin ins kalte Wasser gesprungen und habe auch mal ARM-Core in ein
> Projekt genommen, konkret der Cortex-M4 Prozessor APSP-CM408F. Bisher
> macht sich viel Enttaeuschung breit. Zum einen ist der Support von
> Analog Devices deutlich schlechter als frueher. Zum anderen gibt es von
> denen fuer viele der toll beworbenen Features keinen Software-Support.
> Nichtmal SPI lief gescheit, mussten wir Bit-Banging machen.
> Interrupt-driven UART geht auch nicht, aber solche Macken kriegen wir
> mit selbstgestricktem Code weg. Schlimmer ist allerdings fehlender
> SW-Support fuer die SPORT Ports (Audio).

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-
ärmste Peripheral: Register einstellen, DMA einstellen, ab geht's. Das
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.

> Weiss jemand, ob man fuer andere Prozessoren SPORT-Module als Muster mal
> einsehen kann oder gar, ob es inzwischen was fuer CMSIS gibt? CMSIS
> wurde vollmundig als herstelleruebergreifende Platform fuer ARM
> Prozessoren angekuendigt. Bisher sieht das jedoch mehr nach heisser Luft
> aus.

Für den Blackfin gibt's das hier:
http://lxr.free-electrons.com/source/sound/soc/blackfin/bf5xx-sport.c
aber benutzt hab ich das nie.


  Stefan

[toc] | [prev] | [next] | [standalone]

#191241

On 2015-08-25 4:07 AM, Stefan Reuther wrote:
> Hallo,,
>
> Joerg wrote:
>> Bin ins kalte Wasser gesprungen und habe auch mal ARM-Core in ein
>> Projekt genommen, konkret der Cortex-M4 Prozessor APSP-CM408F. Bisher
>> macht sich viel Enttaeuschung breit. Zum einen ist der Support von
>> Analog Devices deutlich schlechter als frueher. Zum anderen gibt es von
>> denen fuer viele der toll beworbenen Features keinen Software-Support.
>> Nichtmal SPI lief gescheit, mussten wir Bit-Banging machen.
>> Interrupt-driven UART geht auch nicht, aber solche Macken kriegen wir
>> mit selbstgestricktem Code weg. Schlimmer ist allerdings fehlender
>> SW-Support fuer die SPORT Ports (Audio).
>
> Was stellst du dir denn unter SW-Support vor? ...


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.


>                                    ... Ich hab die SPORTs bisher
> nur auf dem Blackfin benutzt und da waren sie bei weitem das stress-
> ärmste Peripheral: Register einstellen, DMA einstellen, ab geht's. Das
> kniffligste war noch, den DMA gescheit mit dem Rest der Software zu
> verheiraten.
>

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.


> 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.
>

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.


>> Weiss jemand, ob man fuer andere Prozessoren SPORT-Module als Muster mal
>> einsehen kann oder gar, ob es inzwischen was fuer CMSIS gibt? CMSIS
>> wurde vollmundig als herstelleruebergreifende Platform fuer ARM
>> Prozessoren angekuendigt. Bisher sieht das jedoch mehr nach heisser Luft
>> aus.
>
> Für den Blackfin gibt's das hier:
> http://lxr.free-electrons.com/source/sound/soc/blackfin/bf5xx-sport.c
> aber benutzt hab ich das nie.
>

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/

[toc] | [prev] | [next] | [standalone]

#191338

On 2015-08-24 3:06 PM, Joerg wrote:
> Hallo Leute,
>
> Bin ins kalte Wasser gesprungen und habe auch mal ARM-Core in ein
> Projekt genommen, konkret der Cortex-M4 Prozessor APSP-CM408F. Bisher
> macht sich viel Enttaeuschung breit. Zum einen ist der Support von
> Analog Devices deutlich schlechter als frueher. Zum anderen gibt es von
> denen fuer viele der toll beworbenen Features keinen Software-Support.
> Nichtmal SPI lief gescheit, mussten wir Bit-Banging machen.
> Interrupt-driven UART geht auch nicht, aber solche Macken kriegen wir
> mit selbstgestricktem Code weg. Schlimmer ist allerdings fehlender
> SW-Support fuer die SPORT Ports (Audio).
>
> Weiss jemand, ob man fuer andere Prozessoren SPORT-Module als Muster mal
> einsehen kann oder gar, ob es inzwischen was fuer CMSIS gibt? CMSIS
> wurde vollmundig als herstelleruebergreifende Platform fuer ARM
> Prozessoren angekuendigt. Bisher sieht das jedoch mehr nach heisser Luft
> aus.
>
> Ich hatte im April in comp-arch.embedded gefragt. Kam aber nicht viel
> bei heraus und da Ihr Europaeer ja oefter ARM einsetzt und Heimvorteil
> habt (solange es keinen Brexit gibt ...), hoffe ich hier auf Erleuchtung
> :-)
>

Feedback, falls dies ein potenzieller ADSP Interessent liest oder findet:

Nach einem geharnischten Donnerwetter bei AD an hoechster Stelle ist der 
Support erstmal schlagartig sehr gut geworden. So wie ich das von 
frueher gewohnt bin. Es stellte sich heraus, dass die Tool Chain 
mangelhaft ist und mit dem gerade erfolgten Release 2.1.0. soll das 
bereinigt sein. Wir koennen dies jedoch fruehestens naechste Woche 
testen, weil auch der Prozessor selbst korrigiert werden musste, also 
"New Silicon". Das ist jetzt per Eilfracht unterwegs, muss ich aber dann 
einbauen bei mir und beim SW Ingenieur. Nach vielen unnoetig in den Sand 
gesetzten Stunden ist jetzt Licht am Ende des Tunnels.

Einen gesundheitlichen Nebeneffekt hat das auch, denn die Hardware wird 
natuerlich mit dem Mountain Bike zum SW Ingenieur gefahren :-)

Achtung: Die frueher gekauften ADSP-CM40x ("Old Silicon") und auch die 
Eval Kits mit Old Silicon funktionieren ab Release 2.1.0 _nicht_ mehr. 
Neben einer neuen Prozessorvariante ist auf den Eval Boards auch einiges 
andere geaendert worden, sodass man das ganze Kit austauschen sollte. AD 
hat ein Austauschprogramm dazu aufgesetzt, sollte man mit ihnen Kontakt 
aufnehmen.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | de.sci.electronics

csiph-web