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 1 of 2  [1] 2  Next page →

#191213 — SPORT-Bus fuer ARM Core, CMSIS?

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 :-)

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [next] | [standalone]

#191226

Joerg schrieb:

>Bin ins kalte Wasser gesprungen und habe auch mal ARM-Core in ein 
>Projekt genommen, konkret der Cortex-M4 Prozessor APSP-CM408F. Bisher 

"Preliminary" *) Silizum ist m.E. nur für Leute, die sich im Zweifel
auch mal selbst helfen können.

[...]

>mit selbstgestricktem Code weg. Schlimmer ist allerdings fehlender 
>SW-Support fuer die SPORT Ports (Audio).

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

>Weiss jemand, ob man fuer andere Prozessoren SPORT-Module als Muster mal 
>einsehen kann oder gar, ob es inzwischen was fuer CMSIS gibt? CMSIS 

Du solltest dazu schreiben, um welches Interface es dabei gehen soll,
z.B. I²S.

>wurde vollmundig als herstelleruebergreifende Platform fuer ARM 
>Prozessoren angekuendigt. Bisher sieht das jedoch mehr nach heisser Luft 
>aus.

Es hat nicht nur Vorteile, sich fremder Software auszuliefern.

>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 

Was nimmt man denn heutzutage außerhalb Europas, 8051?

Servus

Oliver

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

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

#191229

On 25.08.2015 09:49, Oliver Betz wrote:
> Joerg schrieb:
> 
>> Bin ins kalte Wasser gesprungen und habe auch mal ARM-Core in ein 
>> Projekt genommen, konkret der Cortex-M4 Prozessor APSP-CM408F. Bisher 
> 
> "Preliminary" *) Silizum ist m.E. nur für Leute, die sich im Zweifel
> auch mal selbst helfen können.

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

Wußte gar nicht, dass AD überhaupt Cortex-M hat. Offenbar haben sie den
Dreh damit noch nicht so raus...

Gruß,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

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

#191242

On 2015-08-25 1:33 AM, Johannes Bauer wrote:
> On 25.08.2015 09:49, Oliver Betz wrote:
>> Joerg schrieb:
>>
>>> Bin ins kalte Wasser gesprungen und habe auch mal ARM-Core in ein
>>> Projekt genommen, konkret der Cortex-M4 Prozessor APSP-CM408F. Bisher
>>
>> "Preliminary" *) Silizum ist m.E. nur für Leute, die sich im Zweifel
>> auch mal selbst helfen können.
>

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.


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

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.


> Wußte gar nicht, dass AD überhaupt Cortex-M hat. Offenbar haben sie den
> Dreh damit noch nicht so raus...
>

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/

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

#191248

Am 25.08.2015 um 15:27 schrieb Joerg:
> On 2015-08-25 1:33 AM, Johannes Bauer wrote:
>
>> 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."
>>
>
> Schon, aber wir haben handfeste Zusagen, dass es fertig sei

Bei so komplexen Chips habe ich noch nie erlebt, daß die von Anfang an 
fehlerfrei wären, egal von welchem Hersteller. Das SPI aber einfach 
nicht läuft, ist schon ein ziemlicher Hammer. Vielleicht nochmal den 
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.

Die STM32F4-Serie hat übrigens vergleichbare Features, bis auf die 16 
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 
problemlos. Auch USB ist ohne Betriebssystem kostenlos verfügbar und 
läuft prima (mittlerweile, nach ein paar Library Updates).

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

http://stm32f4-discovery.com/2015/02/library-52-ethernet-peripheral-on-stm32f4xx/

> Bisher sieht man vom
> ADSP-CM408F jedoch nur 50 Stueck bei Avnet.

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

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

#191250

On 2015-08-25 8:01 AM, Frank Buss wrote:
> Am 25.08.2015 um 15:27 schrieb Joerg:
>> On 2015-08-25 1:33 AM, Johannes Bauer wrote:
>>
>>> 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."
>>>
>>
>> Schon, aber wir haben handfeste Zusagen, dass es fertig sei
>
> Bei so komplexen Chips habe ich noch nie erlebt, daß die von Anfang an
> fehlerfrei wären, egal von welchem Hersteller. Das SPI aber einfach
> nicht läuft, ist schon ein ziemlicher Hammer. Vielleicht nochmal den
> Support nach Beispielcode fragen?


Welchen Support? :-)


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

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


> Die STM32F4-Serie hat übrigens vergleichbare Features, bis auf die 16
> 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
> problemlos. Auch USB ist ohne Betriebssystem kostenlos verfügbar und
> läuft prima (mittlerweile, nach ein paar Library Updates).
>
> Ethernet habe ich noch nicht ausprobiert, aber scheint es auch kostenlos
> zu geben und scheint gut zu laufen:
>
> http://stm32f4-discovery.com/2015/02/library-52-ethernet-peripheral-on-stm32f4xx/
>

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.

>
>> Bisher sieht man vom
>> ADSP-CM408F jedoch nur 50 Stueck bei Avnet.
>
> Hast du die schon alle aufgekauft? Die Webseite schreibt "No Stock, 13
> Week Factory Lead Time"
>

:-)

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/

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

#191251

Am 25.08.2015 um 18:00 schrieb Joerg:
>
> 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.

Der Chip auf dem Discovery Board hat nur zwei I2S Kanäle. Glaube nicht, 
daß es von ST einen mit 12 Kanälen gibt.

Sind dann aber eine Menge Daten, viel Taktzyklen pro Sample hast du dann 
nicht. Kann interessante Probleme geben, wenn es mit der 
Speicherbandbreite knapp wird. Da muß man dann ggf. die Prioritäten für 
den AHB Arbiter umprogrammieren, je nach FIFO-Größen und restlicher 
Auslastung des Microcontrollers, da sonst Samples verlorengehen können. 
Bei 1,8 MB/s aber vielleicht noch nicht so das Problem. Ich würde aber 
bei solchen Datenmengen und wahrscheinlich Realtime Anforderungen 
heutzutage immer FPGAs einsetzen. Ist im Endeffekt auch schneller 
programmiert, bevor man all die Klippen und Einschränkungen der 
Microcontroller umschifft hat und man hat die Garantie, daß es 
funktioniert. Besonders wenn du auch USB und Ethernet brauchst, dann 
kann es kompliziert werden. Besser in Kommunikations und Steuerchip trennen.

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

CMSIS ist schon seit längerem Open Source:

https://developer.mbed.org/blog/entry/CMSIS-Components-BSD-Licensed/

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 
CrossWorks ist zugegebenermaßen manchmal schon nützlich fürs Debuggen.

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

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

#191254

On 2015-08-25 9:24 AM, Frank Buss wrote:
> Am 25.08.2015 um 18:00 schrieb Joerg:
>>
>> 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.
>
> Der Chip auf dem Discovery Board hat nur zwei I2S Kanäle. Glaube nicht,
> daß es von ST einen mit 12 Kanälen gibt.
>

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.


> Sind dann aber eine Menge Daten, viel Taktzyklen pro Sample hast du dann
> nicht. Kann interessante Probleme geben, wenn es mit der
> Speicherbandbreite knapp wird. Da muß man dann ggf. die Prioritäten für
> den AHB Arbiter umprogrammieren, je nach FIFO-Größen und restlicher
> Auslastung des Microcontrollers, da sonst Samples verlorengehen können.
> Bei 1,8 MB/s aber vielleicht noch nicht so das Problem. Ich würde aber
> bei solchen Datenmengen und wahrscheinlich Realtime Anforderungen
> heutzutage immer FPGAs einsetzen. Ist im Endeffekt auch schneller
> programmiert, bevor man all die Klippen und Einschränkungen der
> Microcontroller umschifft hat und man hat die Garantie, daß es
> funktioniert. Besonders wenn du auch USB und Ethernet brauchst, dann
> kann es kompliziert werden. Besser in Kommunikations und Steuerchip
> trennen.
>

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.


>> 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.
>
> CMSIS ist schon seit längerem Open Source:
>
> https://developer.mbed.org/blog/entry/CMSIS-Components-BSD-Licensed/
>

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.


> 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
> CrossWorks ist zugegebenermaßen manchmal schon nützlich fürs Debuggen.
>

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/

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

#191262

Am 25.08.2015 um 18:57 schrieb Joerg:
>
> 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.

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 
könnte man die I2S-Module nehmen, wenn man das Interleave der Daten dann 
in Software vorbereitet und extern noch ein paar 7473 Flipflops 
vorsieht, um das Frame-Signal zu teilen. Wäre mal ein interessantes 
Projekt, damit den AD1938 vom Discovery Board aus anzusprechen.

Ein paar Atmel Chips könnten den S-PORT Bus wahrscheinlich über das 
SSC-Interface emulieren, was recht flexibel konfigurierbar ist, für fast 
beliebige TDM-Formate und dann hättest du verfügbare Chips, wo auch SPI 
läuft. Wobei Atmel aber auch nicht immer bekannt für gute Lieferbarkeit 
ist oder Fehlerfreiheit der Chips.

>> CMSIS ist schon seit längerem Open Source:
>>
>> https://developer.mbed.org/blog/entry/CMSIS-Components-BSD-Licensed/
>>
>
> 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.

Wusste gar nicht, daß damit auch die Hardware abstrahiert werden soll. 
Bisher hatte ich in der Library nur Funktionen für ARM generell 
gefunden, also mathematische Funktionen und spezielle Dinger für die 
Cores, wie Debugging, SysTick usw.

Für die hardwarespezifischen Sachen, wie SPI ansprechen, gibt es von ST 
STM32F4xx_StdPeriph_Driver, was aber scheinbar genau den 
hardwarespezifischen Teil von CMSIS implementiert. Aber weiß nicht, wie 
plattformübergreifend das ist, da die Hardwaremodule selbst ja für jeden 
Chip meist anders sind. Das wäre wirklich sinnvoll, wenn sich die 
Hersteller da mal einigen könnten und z.B. für I2C auf jedem Chip immer 
dieselben Register und Verfahren hat, oder zumindest dasselbe API, wie 
unter Linux gewohnt. Schreibt daß das CMSIS auch vor, also das man für 
GPIO-Ports konfigurieren einfach den Hersteller wechseln kann und dann 
dieselben Funktionen weiterhin funktionieren?

ST hat auch das STM32CubeMX-System, was sowas ähnliches ist, wie die 
Cypress PSoC-Creator IDE, also wo man den Prozessor sieht und alles 
grafisch konfigurieren kann:

http://sysmagazine.com/posts/213561/

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 
beschleunigt das Aufsetzen neuer Projekt schon erheblich. Besonders für 
den Clock-Tree von modernen Microcontrollern ist das schon praktisch, 
wenn man das grafisch sieht, oder auch mit nur einem Mausklick USB mit 
Beispielaufrufen einbinden zu können.

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

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

#191263

Am 25.08.2015 22:50, schrieb Frank Buss:

> 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 :-)

Des Kugelgrillers neue Kleider!



Gruß Dieter

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

#191277

On 2015-08-25 1:50 PM, Frank Buss wrote:
> Am 25.08.2015 um 18:57 schrieb Joerg:
>>
>> 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.
>
> 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 :-)
>

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.


> Die STM32-Serie scheint keinen generischen TDM-Bus zu bieten. Vielleicht
> könnte man die I2S-Module nehmen, wenn man das Interleave der Daten dann
> in Software vorbereitet und extern noch ein paar 7473 Flipflops
> vorsieht, um das Frame-Signal zu teilen. Wäre mal ein interessantes
> Projekt, damit den AD1938 vom Discovery Board aus anzusprechen.
>

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


> Ein paar Atmel Chips könnten den S-PORT Bus wahrscheinlich über das
> SSC-Interface emulieren, was recht flexibel konfigurierbar ist, für fast
> beliebige TDM-Formate und dann hättest du verfügbare Chips, wo auch SPI
> läuft. Wobei Atmel aber auch nicht immer bekannt für gute Lieferbarkeit
> ist oder Fehlerfreiheit der Chips.
>

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.


>>> CMSIS ist schon seit längerem Open Source:
>>>
>>> https://developer.mbed.org/blog/entry/CMSIS-Components-BSD-Licensed/
>>>
>>
>> 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.
>
> Wusste gar nicht, daß damit auch die Hardware abstrahiert werden soll.


Ein wenig schon.

http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php

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.


> Bisher hatte ich in der Library nur Funktionen für ARM generell
> gefunden, also mathematische Funktionen und spezielle Dinger für die
> Cores, wie Debugging, SysTick usw.
>
> Für die hardwarespezifischen Sachen, wie SPI ansprechen, gibt es von ST
> STM32F4xx_StdPeriph_Driver, was aber scheinbar genau den
> hardwarespezifischen Teil von CMSIS implementiert. Aber weiß nicht, wie
> plattformübergreifend das ist, da die Hardwaremodule selbst ja für jeden
> Chip meist anders sind. Das wäre wirklich sinnvoll, wenn sich die
> Hersteller da mal einigen könnten und z.B. für I2C auf jedem Chip immer
> dieselben Register und Verfahren hat, oder zumindest dasselbe API, wie
> unter Linux gewohnt. Schreibt daß das CMSIS auch vor, also das man für
> GPIO-Ports konfigurieren einfach den Hersteller wechseln kann und dann
> dieselben Funktionen weiterhin funktionieren?
>

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 :-)


> ST hat auch das STM32CubeMX-System, was sowas ähnliches ist, wie die
> Cypress PSoC-Creator IDE, also wo man den Prozessor sieht und alles
> grafisch konfigurieren kann:
>
> http://sysmagazine.com/posts/213561/
>

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!


> 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
> beschleunigt das Aufsetzen neuer Projekt schon erheblich. Besonders für
> den Clock-Tree von modernen Microcontrollern ist das schon praktisch,
> wenn man das grafisch sieht, oder auch mit nur einem Mausklick USB mit
> Beispielaufrufen einbinden zu können.
>

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/

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

#191279

Am 25.08.2015 um 18:24 schrieb Frank Buss:
> Bei 1,8 MB/s aber vielleicht noch nicht so das Problem. Ich würde aber
> bei solchen Datenmengen und wahrscheinlich Realtime Anforderungen
> heutzutage immer FPGAs einsetzen. Ist im Endeffekt auch schneller
> programmiert, bevor man all die Klippen und Einschränkungen der
> Microcontroller umschifft hat und man hat die Garantie, daß es

Vor allem wenn es dann nach der Hälfte des Projektes heisst wir brauchen 
doch die doppelte/vierfache Bandbreite ist so ein FPGA-Programm 
schneller skaliert (Auf einen evtl. größeren FPGA) als Jörg den Quarz 
von seinem STM32 ausgetauscht hat.

Aber viele haben vor FPGAs irgendwie immer noch Angst. Der 
Stromverbrauch! Die Gehäuse mit den vielen Pins! Die Verfügbarkeit in 
25+ Jahren! :-)

Gruss,
Michael

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

#191280

On 26.08.2015 17:23, Michael Reinck wrote:

> Aber viele haben vor FPGAs irgendwie immer noch Angst. Der
> Stromverbrauch! Die Gehäuse mit den vielen Pins! Die Verfügbarkeit in
> 25+ Jahren! :-)

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

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.

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.

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.

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

Viele Grüße,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

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

#191281

On 2015-08-26 8:59 AM, Johannes Bauer wrote:
> On 26.08.2015 17:23, Michael Reinck wrote:
>
>> Aber viele haben vor FPGAs irgendwie immer noch Angst. Der
>> Stromverbrauch! Die Gehäuse mit den vielen Pins! Die Verfügbarkeit in
>> 25+ Jahren! :-)
>
> Ä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".
>

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.


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

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.


> Vom Preis ganz zu schweigen. Völlig außer Konkurrenz, wenn man dieselbe
> Applikation in eine MCU reinpressen kann.
>

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


> 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.
>
> Nee, neee, FPGA nimmt man echt nur, wenn nix anderes geht.
>

Sehe ich auch so.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

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

#191304

Joerg <news@analogconsultants.com> wrote:

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

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/ 

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

#191346

Joerg <news@analogconsultants.com> schrieb:
> On 2015-08-26 8:59 AM, Johannes Bauer wrote:
>> On 26.08.2015 17:23, Michael Reinck wrote:
[...]
>> 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.
>>
>
> 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.

Die multilayer PCB, die du für den FPGA brauchst, ist durch die
vielen Lagen in sich so starr, dass das als Argument gegen große
BGAs quasi wegfällt. Allerdings sollten man auch eine Lötbude nehmen,
die das nicht - wie in den USA vielleicht üblich - im Hinterhof
zusammenklöppelt.

>> Vom Preis ganz zu schweigen. Völlig außer Konkurrenz, wenn man dieselbe
>> Applikation in eine MCU reinpressen kann.

Klar. Niemand wird einen 400,- EUR FPGA verbauen, wenn es auch mit einem
uC für 2,50 EUR geht. Wir machen auch Medizinprodukte und nutzen einen
1156er BGA. 's geht halt nicht anders.

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

Wadd mudd, dadd mudd.

>> 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 du wüsstest, was die Tools leisten müssen, würde dich das wohl
nicht wirklich wundern.

Grüßke,
grw

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

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

#191347

Am 27.08.2015 um 23:11 schrieb Guenther Wenninger:
>
>>> 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 du wüsstest, was die Tools leisten müssen, würde dich das wohl
> nicht wirklich wundern.

Die sind aber schon recht wild zusammengewürfelt, mit Ziel minimale 
Kosten, nicht elegantes Programm. Wir brauchen ein make-Prozess. Kein 
Problem, cygwin mit ins Paket packen. Und wir haben da was ganz neues 
für das SoC, jetzt in Java statt C++ wie der meiste Rest programmiert. 
Kein Problem, packen wir noch eine JVM dazu. Unser Praktikant hat aber 
den Memory-Generator mit einem kryptischen Perl-Script geschrieben, wäre 
zuviel Arbeit den in Java umzusetzen. Und schwupps, ist Perl mit allen 
dazugehörigen Bibliotheken auch noch mit drin. Ach ja, die 
Simulationstools arbeiten mit Tcl/Tk, nochmal ein dickes Packet mit drin 
usw. Und natürlich brauchen wir noch für SoC eine komplette 
Cross-Compiler Toolchain und dann kommen die ganzen zugekauften 
Programme für die eigentliche Synthese noch hinzu, mit viel 
Klebersoftware zusammengeklebt. Langfristig ist Wartung, Fehlerbehebung 
usw. wohl mehr Aufwand, als das sauber neu aus einem Guß aufzusezten.

Es geht auch anders: Forth und OKAD (ein vollständiges System zum 
Entwerfen und simulieren von ASICs) in 290 kB:

http://www.colorforth.com

Der Chip der damit entworfen wurde funktioniert. OKAD kann allerdings 
kein VHDL.

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

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

#191349

Frank Buss <fb@frank-buss.de> schrieb:
> Am 27.08.2015 um 23:11 schrieb Guenther Wenninger:
>>
>>>> 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 du wüsstest, was die Tools leisten müssen, würde dich das wohl
>> nicht wirklich wundern.
>
> Die sind aber schon recht wild zusammengewürfelt, mit Ziel minimale 
> Kosten, nicht elegantes Programm. Wir brauchen ein make-Prozess. Kein 
> Problem, cygwin mit ins Paket packen. Und wir haben da was ganz neues 
> für das SoC, jetzt in Java statt C++ wie der meiste Rest programmiert. 
> Kein Problem, packen wir noch eine JVM dazu. Unser Praktikant hat aber 
> den Memory-Generator mit einem kryptischen Perl-Script geschrieben, wäre 
> zuviel Arbeit den in Java umzusetzen. Und schwupps, ist Perl mit allen 
> dazugehörigen Bibliotheken auch noch mit drin. Ach ja, die 
> Simulationstools arbeiten mit Tcl/Tk, nochmal ein dickes Packet mit drin 
> usw. Und natürlich brauchen wir noch für SoC eine komplette 
> Cross-Compiler Toolchain und dann kommen die ganzen zugekauften 
> Programme für die eigentliche Synthese noch hinzu, mit viel 
> Klebersoftware zusammengeklebt. Langfristig ist Wartung, Fehlerbehebung 
> usw. wohl mehr Aufwand, als das sauber neu aus einem Guß aufzusezten.

Da gebe ich dir recht. Allerdings hat zumindest Xilinx mit Vivado
versucht da eine halbwegs einheitliche Oberfläche auf den Weg zu
bringen. Wobei ich mittlerweile eh auf Makefile + vim "umgestiegen"
bin. Mit ISE mach' ich da kaum noch etwas...

/grw

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

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

#191348

On 2015-08-27 2:11 PM, Guenther Wenninger wrote:
> Joerg <news@analogconsultants.com> schrieb:
>> On 2015-08-26 8:59 AM, Johannes Bauer wrote:
>>> On 26.08.2015 17:23, Michael Reinck wrote:
> [...]
>>> 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.
>>>
>>
>> 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.
>
> Die multilayer PCB, die du für den FPGA brauchst, ist durch die
> vielen Lagen in sich so starr, dass das als Argument gegen große
> BGAs quasi wegfällt. Allerdings sollten man auch eine Lötbude nehmen,
> die das nicht - wie in den USA vielleicht üblich - im Hinterhof
> zusammenklöppelt.
>

Da wo wir fertigen lassen, sind das keine Hinterhofbuden:

http://aa-pcbassembly.com/capabilities/equipment-list/
https://www.youtube.com/watch?v=qjymEaUeBAw

Am Ende ist aber jede Platine flexibel, auch wenn sie 12 Lagen und 1oz 
Kupfer hat. Nicht umsonst sind aufgrund der Einfuehrung von BGA ganz 
neue Geschaeftsmodelle entstanden: Re-Ballers und BGA Repair Shops 
sprossen wie Pilze aus dem Boden.


>>> Vom Preis ganz zu schweigen. Völlig außer Konkurrenz, wenn man dieselbe
>>> Applikation in eine MCU reinpressen kann.
>
> Klar. Niemand wird einen 400,- EUR FPGA verbauen, wenn es auch mit einem
> uC für 2,50 EUR geht. Wir machen auch Medizinprodukte und nutzen einen
> 1156er BGA. 's geht halt nicht anders.
>
>> Sobald der Preis zweistellig wird, isses meist aus, geht nicht.
>
> Wadd mudd, dadd mudd.
>

Bei so fetten Sachen haben wir zwar schonmal in FPGA entwickelt, sind 
dann jedoch fuer die Serie auf ASIC gegangen. Im Digitalbereich ist das 
nicht teuer. Allerdings haben wir Heimvorteil, weil es an der 
US-Westkueste haufenweise ASIC-Schmieden gibt.

[...]

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

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

#191350

Joerg <news@analogconsultants.com> schrieb:
> On 2015-08-27 2:11 PM, Guenther Wenninger wrote:
>> Joerg <news@analogconsultants.com> schrieb:
>>> On 2015-08-26 8:59 AM, Johannes Bauer wrote:
>>>> On 26.08.2015 17:23, Michael Reinck wrote:
>> [...]
>>>> 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.
>>>>
>>>
>>> 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.
>>
>> Die multilayer PCB, die du für den FPGA brauchst, ist durch die
>> vielen Lagen in sich so starr, dass das als Argument gegen große
>> BGAs quasi wegfällt. Allerdings sollten man auch eine Lötbude nehmen,
>> die das nicht - wie in den USA vielleicht üblich - im Hinterhof
>> zusammenklöppelt.
>>
>
> Da wo wir fertigen lassen, sind das keine Hinterhofbuden:
>
> http://aa-pcbassembly.com/capabilities/equipment-list/
> https://www.youtube.com/watch?v=qjymEaUeBAw
>
> Am Ende ist aber jede Platine flexibel, auch wenn sie 12 Lagen und 1oz 
> Kupfer hat. Nicht umsonst sind aufgrund der Einfuehrung von BGA ganz 
> neue Geschaeftsmodelle entstanden: Re-Ballers und BGA Repair Shops 
> sprossen wie Pilze aus dem Boden.

Natürlich. Am Ende ist allerdings auch ein BGA flexibel.
Und es ist logisch, dass da neue Geschäftsmodelle entstehen,
eben WEIL man um BGA zu löten spezielle Technik braucht.
Und dass es bei der Neueinführung von Lötprozessen etc. zu
Kinderkrankheiten kommt, ist sicher nicht unnatürlich.
Daher vielleicht der schlechte Ruf.

>>>> Vom Preis ganz zu schweigen. Völlig außer Konkurrenz, wenn man dieselbe
>>>> Applikation in eine MCU reinpressen kann.
>>
>> Klar. Niemand wird einen 400,- EUR FPGA verbauen, wenn es auch mit einem
>> uC für 2,50 EUR geht. Wir machen auch Medizinprodukte und nutzen einen
>> 1156er BGA. 's geht halt nicht anders.
>>
>>> Sobald der Preis zweistellig wird, isses meist aus, geht nicht.
>>
>> Wadd mudd, dadd mudd.
>>
>
> Bei so fetten Sachen haben wir zwar schonmal in FPGA entwickelt, sind 
> dann jedoch fuer die Serie auf ASIC gegangen. Im Digitalbereich ist das 
> nicht teuer. Allerdings haben wir Heimvorteil, weil es an der 
> US-Westkueste haufenweise ASIC-Schmieden gibt.

Finde ich cool, bin ich aber nicht der ganz große Fan von. Solange es
ein FPGA bleibt, bleibt man auch flexibel was neue Funktionen o.ä.
angeht.

/grw

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

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web