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?!
PSoC 5lp kann das eventuell auch. Kuerzlich hatte ich einen Datenstrom generiert, der 128 bit lang war. Vermutlich klappt das mit dem Empfangen auch.
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)
Allenfalls kann man auch mit Bitbang empfangen ... was ich machen wuerd.
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
was sind denn dass für exoten?(damit ich sie vermeiden kann)
Ist das so ein Laser-Scanner-Protokoll wie z.B. XY2-100? http://www.alaser.com.tw/db/upload/webdata4/5alaser_201412422541519318.pdf
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.
oder du bastelst da an die clock noch irgendwelche zähler, die nur 20 impulse durchlassen und nimmst standard-spi mit 7 oder 8 bit
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 ..
Ja, wie heißen denn nun Quelle und Ziel Baustein....? Bestimmt geht das auch mit einer normalen SPI, sonst wärs kein SPI..
Uwe B. schrieb: > STM32F0,F3,F4, F7,L0,L4 und H7 koennen 4.. 16 bit SPI. Also dann nehm ich 3 mal 6.6666 = 20 bit
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.
Wenn Du die Daten als Slave empfängst könntest Du ja notfalls die fehlenden 4 Clocks nach dem Deselect selber generieren.
Vorschlag: Drei kaskadierte Schieberegister verwenden oder per Software-SPI.
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_USB http://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.
Der ESP32 kann SPI von 0 - 512 bits im data segment. Optional kann mann noch command und address fields vorab senden/empfangen. pitschu
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.
Schreib dir selber die SPI. Wenn das nicht passt, da gibt es noch PIC24 und PIC32 die können beide 16 und 32Bit Modus
Silabs EFM32 könnten das mit dem USART als 2x10bit oder 4x5Bits abbilden. Wenn es schnell und SPI Slave sein muss, dann hätten die auch DMA.
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.
Beitrag #5809989 wurde von einem Moderator gelöscht.
Beitrag #5810053 wurde von einem Moderator gelöscht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.