Hi,
ich bin auf der Suche nach einem Mikrocontroller, der unter anderem 2
oder 3 SPIs anbietet, die allerdings etwas speziell sein müssten.
Mein Problem: die SPI-artigen Datenframes, die ich empfangen möchte,
haben eine Länge von 20 Bit, so dass mir ein SPI, der stupide nur 8 Bit
empfangen kann, nicht hilft. Ebensowenig ist es keine Lösung, einfach
auf 2 Frames (=5x 8 Bit) zu warten, da ich nicht auf das dann zwingend
benötigte zweite Frame warten kann.
Deswegen: kennt jemand einen günstigen Mikrocontroller, der SPIs mit
programmierbarer Bitanzahl hat und mit mehr als 20 MHz läuft?
Danke!
Schau mal bei den C2000 von TI.
Der Normale SPI hat eine Einstellbare Bitanzahl von 1 - 16.
Der hat aber auch noch einen McBSP, das Ding ist komplexer einstellbar.
Ob der aber 20 BIT kann weiß ich auch nicht. Muss du schauen.
Schau mal bei Renesas, mit einem M16C habe ich sowas mal vor Jahren
gemacht. USART im synchronen Modus (das können viele MCs) und mit
variabler Bitzahl (da wird die Luft schon dünner).
Es gibt sicher etliche die das können.
Alesund schrieb:> Deswegen: kennt jemand einen günstigen Mikrocontroller, der SPIs mit> programmierbarer Bitanzahl hat und mit mehr als 20 MHz läuft?
Die Antwort "Nimm ein CPLD/FPGA ggf mit SoftCore CPU und mach Dir den
Exoten-SPI selbst" magst du nicht hören?!
Alesund schrieb:> haben eine Länge von 20 Bit, so dass mir ein SPI, der stupide nur 8 Bit> empfangen kann, nicht hilft. Ebensowenig ist es keine Lösung, einfach> auf 2 Frames (=5x 8 Bit) zu warten, da ich nicht auf das dann zwingend> benötigte zweite Frame warten kann.
Moin, Cypress PSoC kann 16 Bit, evtl reicht das.
Mfg aus dem Pott
bitwurschtler schrieb:> Die Antwort "Nimm ein CPLD/FPGA ggf mit SoftCore CPU und mach Dir den> Exoten-SPI selbst" magst du nicht hören?!
Nein, die mag ich nicht hören weil: Zu teuer, zu unflexibel, zu
kompliziert zu programmieren.
Moin,
schau mal bei ehemals Freescale bzw ST vorbei.
Den SPC564B74 hatte ich mal im Projekt.
Die koennen 4..32bit SPI frames. Bei 25Mbit war glaube ich schluss,
bin mir aber nicht sicher. Die SPI ist da sehr maechtig.
Wie teuer der ist, weiss ich nicht.
Gibts single und dual Core mit 8 SPI.
Der Z4 rennt schon ganz ordentlich (bis 120MHz).
Hatten den damals auf 80MHz betrieben.
Alesund schrieb:> Mein Problem: die SPI-artigen Datenframes, die ich empfangen möchte,> haben eine Länge von 20 Bit, so dass mir ein SPI, der stupide nur 8 Bit> empfangen kann, nicht hilft.
Du hast sicherlich das Datenblatt deine SPI Quelle noch nicht
genau genug gelesen. Kein Chip-Hersteller wird so dumm sein
nicht eine Hintertüre offen zu lassen um die 20 Bit in einem
3 mal 8 Transfer zuzulassen.
(ist ja geheim, diese sonderbare SPI Quelle, nicht wahr?)
Wenn es was "Hausgemachtes" ist dann würde ich dieses modifizieren
damit ich nicht gezwungen bin irgendeinen exotischen Controller
nehmen zu müssen der genau diese Thematik, Problematik erschlägt
Verwegener Bastler schrieb:> Du hast sicherlich das Datenblatt deine SPI Quelle noch nicht> genau genug gelesen.
Das würde mich auch interessieren.
Und vor Allem: ob es überheupt eine "Quelle" ist. Nicht, dass wir
hinterher von einem SPI-Device reden, wo lediglich die letzten 20 Bits
rechts oder links ausgerichtet sein müssen und die dann bei der
steigenden Flanke des SS# übernommen werden.
Alesund schrieb:> bitwurschtler schrieb:>> Die Antwort "Nimm ein CPLD/FPGA ggf mit SoftCore CPU und mach Dir den>> Exoten-SPI selbst" magst du nicht hören?!> Nein, die mag ich nicht hören
Jaja, Maggi...
> weil: Zu teuer, zu unflexibel, zu kompliziert zu programmieren.
Das mittlere Argument stimmt mit Sicherheit nicht.
Nenn doch einfach mal Ross und Reiter und deine Anwenung mitsamt dem Typ
und Bestellbezeichnung dieses seltsamen Schaltkreises. DANN hat man was
zum diskutieren.
Verwegener Bastler schrieb:> (ist ja geheim, diese sonderbare SPI Quelle, nicht wahr?)
Klugscheißer.
Die Quelle sendet die Daten per Bitbanging - was beim Senden ja deutlich
einfacher und mit weniger Rechenleistung möglich ist als beim Empfangen.
Also nix mit Hintertüre :-/
Lothar M. schrieb:> Nenn doch einfach mal Ross und Reiter
Das wird nach meiner Einschätzung nicht funktionieren bzw
passieren da das Ganze sehr nach halb-trolliger abstrakter
Problemstellung riecht die nichts mit der Realität zu tun hat.
Freitag ist übermorgen.
Alesund schrieb:> Klugscheißer.
--> Da hammas scho.
Alesund schrieb:> Die Quelle sendet die Daten per Bitbanging
Dann kann man die Quelle auch veranlassen mehr oder weniger
Bits zu senden. Auch mit entsprechendem Framing.
Verwegener Bastler schrieb:> Dann kann man die Quelle auch veranlassen mehr oder weniger> Bits zu senden. Auch mit entsprechendem Framing.
Aha. Und was, wenn die Quelle die Daten in einem definierten Format
schickt? Fragen wir dann einfach alle Hersteller weltweit, ob sie nur
für mich mal eben die Definition und sämtliche existierenden Geräte
ändert?
Ja, nee, schon klar...
kann man nicht zB in von nem AtMega[4,8,16,32]8(P) nicht die USART dafür
benutzen? sie hat einen synchronen Modus und unterstützt datenlängen von
5-9 Bit. Man könnte also 4 5bit frames abwarten (oder 2x7 und 1x6, wobei
ich nicht weiß, wie schnell sich das zwischendurch umkonfigurieren
lässt)
Lothar M. schrieb:> Nenn doch einfach mal Ross und Reiter und deine Anwenung mitsamt dem Typ> und Bestellbezeichnung dieses seltsamen Schaltkreises. DANN hat man was> zum diskutieren.
Es ist kein Schaltkreis, der sowas abliefert sondern ein
Industriestandard in einer sehr kleinen Branche, die eben auf dieses
seltsame Format setzt. Ich kann jetzt hier gerne eine ausufernde
Abhandlung schreiben - aber wozu? Nur um dann zu erfahren, was ich schon
weiß, nämlich dass ich tatsächlich an diese 20 Bit gebunden bin?
Keine Ahnung, was so schwer daran ist, eine Frage einfach mal so zu
beantworten, wie sie gestellt wurde (OK, 3..4 Leute haben das hier
tatsächlich geschafft und mir hilfreiche Tipps gegeben, die mich
durchaus weiterbringen).
Ist das Größenwahn, immer erst mal anzunehmen, ein Fragesteller ist dumm
wie Stroh und sowieso nicht in der Lage, ein Problem zu erkennen? Oder
was soll das sonst, eine Frage immer mit Antworten zuzuschütten, die
weder hilfreich sind, noch auf die Frage eingehen noch zum Thema
überhaupt passen?
In diesem Sinne: Danke an alle, die mir ein paar MCUs genannt haben, das
schaue ich mir an, damit kann ich was anfangen.
Vlad T. schrieb:> kann man nicht zB in von nem AtMega[4,8,16,32]8(P) nicht die USART dafür> benutzen? sie hat einen synchronen Modus und unterstützt datenlängen von> 5-9 Bit. Man könnte also 4 5bit frames abwarten (oder 2x7 und 1x6, wobei> ich nicht weiß, wie schnell sich das zwischendurch umkonfigurieren> lässt)
vergesst es.
es werden zwingend start und stopbits benötig - sonst hätte man es ja
gleich SPI nennen können ;)
Alesund schrieb:> Es ist kein Schaltkreis, der sowas abliefert sondern ein> Industriestandard
ROFL.
Ein "Industriestandard" der Daten per Bit Banging überträgt.
Ich krieg mich nicht mehr ein.
Der Trollfaktor wird immer grösser.
Hier sind bestimmt ein paat unterwegs, die mit/in/für die "Industrie"
arbeiten. Die könnten mit deinem Standard schon mal in Berührung
gekommen sein und dir gezielter helfen.
Also nochmal die Frage: Von welchem Standard reden wir hier? Standards
haben in der Regel einen Namen ;-)
Hans
Hans M. schrieb:> Also nochmal die Frage: Von welchem Standard reden wir hier?Alesund schrieb:> Es ist kein Schaltkreis, der sowas abliefert sondern ein> Industriestandard in einer sehr kleinen Branche
Und die "Branche" ist genau 1 Mann gross.
Deswegen ist sie auch so unflexibel und kann ihr Bit-Banging-
Protokoll nicht abändern damit es allgemein nutzbar ist.
Alesund schrieb:> sondern ein Industriestandard in einer sehr kleinen Branche, die eben> auf dieses seltsame Format setzt. Ich kann jetzt hier gerne eine> ausufernde Abhandlung schreiben
Brauchst Du nicht. Aber Du könntest dem ganzen einen Namen geben, so
rein der Anständigkeit halber, damit diejenigen hier, die sich
Deinetwegen die Köpfe zerbrechen, auch irgendwie den Eindruck gewinnen,
ernstgenommen zu werden.
stm32h743 etc. kann das, 4 bis 32 Bit. Die "kleineren" der stm32-Familie
können nur 8 und 16 Bit, ab welchem da die flexiblere SPI drin ist,
könnte man ja leicht nachsehen ..
Uwe B. schrieb:> STM32F0,F3,F4, F7,L0,L4 und H7 koennen 4.. 16 bit SPI.
Das stimmt so nicht ganz.
Aus RefMan STM32F4xx:
Bit 11 DFF: Data frame format
0: 8-bit data frame format is selected for transmission/reception
1: 16-bit data frame format is selected for transmission/reception
F0, F3, L0, L4, H7 hab ich nicht geprueft. Mein F746 kann die 4..16,
aber
mein F407 kann nur 8 oder 16bit.
Einfach einen kleinen Mikrocontroller zwischen schalten der die 20 Bits
in Software SPI macht und das auf der anderen Seite als gewöhnliches
3x8Bit SPI rausgibt? Dann hat man beim "Haupt Controller" volle Freiheit
der Auswahl.
In vielen Branchen gibt es komische (De-Facto-) Standards die sich
irgendwann mal jemand unter Einfluss bewusstseinserweiternder Drogen
ausgedacht hat, aber mit denen mal sich halt arrangieren muss. In der
IT-Branche z.B. gibt's da ne Menge von: C, Windows, PHP, HTML, MBR,...
Dr. Sommer schrieb:> In vielen Branchen gibt es komische (De-Facto-) Standards die sich> irgendwann mal jemand unter Einfluss bewusstseinserweiternder Drogen> ausgedacht hat
Ich vermeide Standards wo immer es geht. Da kann mir dann auch
keiner dreinreden.
Ich mach mir die Welt so wie sie mir gefällt.
H.Joachim S. schrieb:> Schau mal bei Renesas, mit einem M16C habe ich sowas mal vor Jahren> gemacht. USART im synchronen Modus (das können viele MCs) und mit> variabler Bitzahl (da wird die Luft schon dünner).> Es gibt sicher etliche die das können.
Renesas RX mit RSPI bspw. die RX63N/RX631 mit drei RSPI-Kanälen, die
Cortex-M4 (u.a. S3A7, S5D9, S7G2) aus der Synergy-Reihe haben bis zu
zwei RSPI-Kanäle (dort nur SPI genannt). Die normalen SCIs können nur
8-Bit SPI. Dafür aber noch einfaches I²C, UART/USART und sind in Hülle
und Fülle vorhanden (bis zu afair 12x je nach Modell)
> MSB-first/LSB-first selectable> - Transfer bit length is selectable as 8, 9, 10, 11, 12, 13, 14, 15, 16, 20, 24,
or 32 bits.
> - 128-bit transmit/receive buffers> - Up to four frames can be transferred in one round of transmission/reception
(each frame consisting of up to 32 bits).
Lothar M. schrieb:> Alesund schrieb:>> bitwurschtler schrieb:>>> Die Antwort "Nimm ein CPLD/FPGA ggf mit SoftCore CPU und mach Dir den>>> Exoten-SPI selbst" magst du nicht hören?!>> Nein, die mag ich nicht hören> Jaja, Maggi...>>> weil: Zu teuer, zu unflexibel, zu kompliziert zu programmieren.> Das mittlere Argument stimmt mit Sicherheit nicht.
Das letzte Argument ist auch Ansichtssache, so wie Fishermam's friend ->
sind sie zu stark, bist du zu schwach. Unsere Väter haben ganze Modems
und Videoconsolen aus 74-logik zusammengenagelt und in ein GAL/CPLD
gedengelt, aber für Kinder geht ein bißchen De-serialisierung nur per
HiTechSpezial-µC.
Das Kannst Du mit einem STM32 erledigen. Du benötigst aber etwas mehr
Peripherie und Konfig-Aufwand als bei einer "normalen" SPI:
Nimm für jeden Pseudo-SPI einen:
* Timer mit externem Clock-Eingang.
Diesen benutzt Du als SPI-Clock-Eingang.
Konfiguriere den Timer so, dass er bei jedem Clock-Puls einen ISR
auslöst.
Durch dieses ISR-Bit triggerst Du einen
* DMA, der dadurch bei jedem SPI-Clock-Puls aktiv wird.
Den DMA konfigurierst Du so, dass er den Port des
SPI-Data-Pins in einen 20 int großen Buffer kopiert.
Der DMA kann nach 20 Zyklen einen ISR auslösen.
Bei entsprechender Konfiguration kann der DMA nahtlos beginnen,
einen zweiten Buffer zu füllen.
* Der "Empfangs-ISR" muss noch aus den 20 Bytes des Buffers das
20Bit Datenwort zusammenkopieren.
* Falls gleichzeitig auch SPI-Senden möglich sein soll,
ist jeweils noch ein zweiter DMA fällig.
Gruß, Stefan
Unglaublich welche Energie manche Leute hier dafür aufbringen.
Dafür dass irgendeine Spinnerei die sich jemand ausgedacht
hat, befriedigt wird (die niemals eine Umsetzung in Realität
erfahren wird).
Ich glaub's einfach nicht.
Aber der hautsächliche Sinn solch eines Spinnerei-Threads
ist wohl der dass hier auf uC.net möglichst viel Traffic
erzeugt wird (der ja Werbe-Umsatz verursacht).
@TO:
Schreibe bitte einfach mal die Anforderungen:
Format wurde schon genannt, aber wie sieht die Taktrate aus?
Idealerweise ein Timingdiagramm vom Frame.
Dann findet sich eine fundierte Antwort.
Wenn der Sender Bitbanging macht, kann's ja nicht sooo schnell sein.
Der einfachste STM32F0 kann mehrere Kanäle mit über 1MHz mit beliebigen
Formaten lesen und schreiben.
0.5MHz machen PICs und AVRs auch problemlos.
Stefan K. hat Dir den Lösungsansatz ja schon auf dem Silbertablett
serviert. Schrieb im Beitrag #5342384.
Wenn ein wenig Werbung erlaubt ist:
http://www.harerod.de/applications_ger.html#SSI_USBhttp://www.harerod.de/applications_ger.html#SSI_USB_DUO
Die Dinger werden weltweit eingesetzt, z.B. wenn mal wieder ein
"seltsames Format" in ein anderes "proprietäres Format" übersetzt werden
soll. Passiert ja gerne mal, wenn z.B. ein SSI-Geber einer alte
Maschinen an eine neue Steuerung angepasst werden soll. MCU ist ein
STM32F4.
Das hier war noch ein FPGA-Lösung, da ist das Speedlimit durch den
Leitungstreiber gegeben:
http://www.harerod.de/applications_ger.html#SSI_TOOL1
Alesund schrieb:> Es ist kein Schaltkreis, der sowas abliefert sondern ein> Industriestandard in einer sehr kleinen Branche, die eben auf dieses> seltsame Format setzt. Ich kann jetzt hier gerne eine ausufernde> Abhandlung schreiben - aber wozu? Nur um dann zu erfahren, was ich schon> weiß, nämlich dass ich tatsächlich an diese 20 Bit gebunden bin?
So so, da kommen allmählich die Salamischeibchen angekleckert. Ebenso
wie das Bitbanging. Da weiss man also langsam, dass der TO null Ahnung
hat.
Bei so einem "Affenzahn" den Controller anhand 20-Bit-SPI (ach nein,
nicht SPI, sondern SPI-artig ...) auswählen zu wollen ohne Rücksicht auf
sonstige Eigenschaften, Tools, Preis, ... ist ja leicht ab ...-artig.
Alesund schrieb:> Es ist kein Schaltkreis, der sowas abliefert sondern ein> Industriestandard ...
Dann hat beim Setzen dieses Standards wohl jemand gewaltig gepennt oder
wollte anderen das Leben bewusst schwer machen.
bitwurschtler schrieb:> Lothar M. schrieb:>> Alesund schrieb:>>> bitwurschtler schrieb:>>>> Die Antwort "Nimm ein CPLD/FPGA ggf mit SoftCore CPU und mach Dir den>>>> Exoten-SPI selbst" magst du nicht hören?!>>> Nein, die mag ich nicht hören>> Jaja, Maggi...>>>>> weil: Zu teuer, zu unflexibel, zu kompliziert zu programmieren.>> Das mittlere Argument stimmt mit Sicherheit nicht.>> Das letzte Argument ist auch Ansichtssache, so wie Fishermam's friend ->> sind sie zu stark, bist du zu schwach. Unsere Väter haben ganze Modems> und Videoconsolen aus 74-logik zusammengenagelt und in ein GAL/CPLD> gedengelt, aber für Kinder geht ein bißchen De-serialisierung nur per> HiTechSpezial-µC.
Richtig, so ein bisschen VHDL/Verilog, wie in diesem Fall, wird man wohl
hoffentlich noch hinbekommen. Einarbeitung ist freilich nötig, aber auch
für andere Anwendungen lohnenswert.
Des weiteren teuer sind FPGAs auch nicht mehr. Es gibt heutzutage
genügend kleine FPGAs für ein paar Euro, die bei einer Kleinserie nicht
wehtun. Eventuell kann man durch den Einsatz sogar Geld einsparen, bevor
ein fetter µC verbaut und durch allerlei Getrickse die Entwicklungszeit
erhöht wird, lieber einen kleinen µC + kleinen FPGA verwenden.
Hier der erste FPGA, der mir ins Auge gefallen ist und für die Aufgabe
in Frage kommen würde:
LCMXO3LF-640E-5MG121I (640 LUTs) Preise bei Mouser:
Ab 1 Stk. 3,82 €
Ab 25 Stk. 3,34 €
Ab 100 Stk. 3,19 €
Wahrscheinlich gehts noch billiger.
> Industriestandard ...
Anhand der vielen Fragen würde ich mal sagen: Bestenfalls in
Nordgrönland. Womit ich aber nichts gegen die Grönländer sagen möchte.
Auf die Schnelle würde ich vorschlagen: Selber machen!
Am einfachsten mit einem "eigenen" µP und in Software.
Sollte der eigentliche Grübler hierfür keine Ressourcen mehr frei haben,
so klebe einfach einen dedizierten µP dazu. Ein ATTiny?? ist nicht nur
recht klein, mit 20MHz auch relativ flott und fällt in die Kategorie:
Kost fast nix.
Der kaut dann den Input vor und liefert das Ergebnis, in akzeptablen
Häppchen, an den eigentlichen Rechner.
Ich sehe die Lösung ehr in Richtung CPLD. Die Dinger sind billig und gut
zu in VHDL / Verilog zu programmieren und man muss wenig Kompromisse
eingehen.
Mit einem schnellen STM32 könnte man sowas auch machen. Es ist abhänig
von der geforderten Konvertiergeschwindigkeit. Die MCU will aber auch
programmiert werden und kostet in entsprechender Ausführung mehr als
eine einfach CPLD.
So komplex ist eine synchrone de-serialisierung ja nicht wirklich.
Diskrete Schieberegister machen auch nichts anderes, benötigen aber mehr
Raum und sind eben nicht flexibel. Sie liefern parallele Daten die
ebenfalls noch aufbereitet werden müssen. Es gibt wohl viele Wege die
nach Rom führen. Wenn man sich nur nach den eigenen Standards richtet,
ist es mit Massenlösungen, die zu günstigen Preisen und guter
Verfügbarkeit eben nicht so weit her.
Nun, im Grunde war meine Idee ja schon genannt und daher denke ich wird
es auf eine Lösung nach "eigenem Standard" hinauslaufen.
Ich bin mal auf den Lösungsweg gespannt, der Deinen Anforderungen
gerecht werden wird.
