Hallo zusammen, die aktuelle Lage macht es wirklich schwer Leiterplatten zu entwickeln. Aktuell bin ich auf der suche nach einem CAN-fähigen Controller, der im besten Fall nicht mehr als 100 Pins hat. Zusätzlich zum CAN sind SPI interface, einige PWM und ADC/DAC Pins benötigt. Kennt da jemand zufällig was gutes ?
Bob E. schrieb: > einige DAC Im Ernst? Denn mit DAC wird die Auswahl ganz schnell ganz klein. Deshalb nehme ich nur noch externe DAC. Und wenn du trotzdem weiter auf den DAC beharrst: wieviele davon willst du und wieviele Bits sollen die können?
:
Bearbeitet durch Moderator
Bob E. schrieb: > Kennt da jemand zufällig was gutes ? Das, was heute beschaffbar ist, kann schon morgen vergriffen sind. Standardbauteile die von mehreren hergestellt wären, wären gut, aber ich kenn keine '8051 mit CAN' funktionskompatiblen.
Bei Digi-Key die PIC32MX-Reihe derzeit gut verfügbar: https://www.digikey.de/products/de/integrated-circuits-ics/embedded-microcontrollers/685?k=PIC32MX795F512 Viele Grüße Jochen
Mouser hätte noch 518 Stück AT89C51CC03 im PLCC-52 mit CAN, SPI, ADC, PWM. https://www.mouser.de/ProductDetail/Microchip-Technology-Atmel/AT89C51CC03UA-S3SUM?qs=8jWQYweyg6Pfw5BFgsik1A%3D%3D
Bob E. schrieb: > Kennt da jemand zufällig was gutes ? Zahlreiche STM32 Controller haben CAN und sind weitgehend zueinander Pinkompatibel. Zum Beispiel die STM32F103 und STM32F303 Serien. Leider sind beider nicht verfügbar, aber wenn es wieder welche gibt stehen die Chancen damit gut dass es eine der beiden sein wird.
es ist eine Frage der Stückzahl. Wenn es z.B. um STM32 geht kann für Prototypen ein Nucleo Board ein Bauteilspender sein. Die Nucleos sind verfügbar auch wenn die entsprechende CPU derzeit nicht einzeln erhältlich ist.
Bob E. schrieb: > Hallo zusammen, > > die aktuelle Lage macht es wirklich schwer Leiterplatten zu entwickeln. > > Aktuell bin ich auf der suche nach einem CAN-fähigen Controller, der im > besten Fall nicht mehr als 100 Pins hat. Zusätzlich zum CAN sind SPI > interface, einige PWM und ADC/DAC Pins benötigt. https://www.digikey.de/product-detail/de/texas-instruments/TM4C1230H6PMIR/296-43613-1-ND/5864721 848 Stück sofort verfügbar. TQFP64. https://www.digikey.de/product-detail/de/texas-instruments/TM4C1231H6PZIR/296-43614-1-ND/5864723 767 Stück sofort verfügbar. TQFP100. fchk
Wie schauts eigentlich aus mit der Halbleiterkrise? Wenn ich mir die Entwicklung der Direktzugriffsspeicher-Preise anschaue, kommt mir der Eindruck dass bei der Halbleiterkrise gerade Halbzeit ist, d.h. die Preise sind allmählich wieder in Richtung vor-der-Krise unterwegs. PS: Ich würde auf Software-Entwicklung umsteigen. Das ist deutlich stressfreier. Und mit den Ressourcen muss man auch nicht mehr so haushalten wie damals beim MCS51 mit dem internen SRAM.
Anarchist schrieb: > Ich würde auf Software-Entwicklung umsteigen. > Das ist deutlich stressfreier. Ja, das ist in der Tat so. Kann ich dir bestätigen.
Anarchist schrieb: > PS: Ich würde auf Software-Entwicklung umsteigen. Das ist deutlich > stressfreier. Nicht unbedingt. Wenn man die Firmware aus Lieferproblemen auf nen ARM-Cortex eines anderen Herstellers umschreiben muß. Bei den IO-Zugriffen kocht jeder Hersteller sein eigenes Süppchen. Die Register haben andere Namen, die Bits darin andere Funktionen.
Peter D. schrieb: > Wenn man die Firmware aus Lieferproblemen auf nen ARM-Cortex eines > anderen Herstellers umschreiben muß. und schon macht ein standardisiertes API eines OS Sinn. Bob E. schrieb: > Kennt da jemand zufällig was gutes ? 10 Stück LPC1549JBD64 könnte ich anbieten, habe ich noch unbenutzt von Mouser. Aber bei den Distris sind die auch gerade mau.
Hallo, bei der Auswahl eines uC legt man sich i.d.R. auf einen Hersteller bzw. Typfamilie fest bzw. sucht dort nach geeigneten Bauteilen. Grund: Software-Entwicklung, vorhandene Erfahrung mit entsprechenden Tools. Was nützt der tolle uC des Herstellers A, wenn das SW-Team bisher nur mit B gearbeitet hat? Wer zahlt die 3-monatige Einarbeitungszeit bzw. Verzögerung durch Erfahrungsaufbau? Gruss
ich habe auch noch 40 Stueck 16F684. Die werden wohl reichen. Komischerweise kann man die sogar im Moment noch kaufen. Da kann die Krise ja nicht so schlimm sein.
Erich schrieb: > i.d.R. war bisher auch alles innerhalb weniger Tage lieferbar. PIClig schrieb: > Da kann die Krise ja nicht so schlimm sein. es betrifft auch viele analoge Teile die nicht programmiert werden müssen. Auch simple Rohstoffe um z.B. irgendwelche Gehäuse bauen zu lassen.
Johannes S. schrieb: > Erich schrieb: >> i.d.R. > > war bisher auch alles innerhalb weniger Tage lieferbar. > NEIN ! Nein. No. Ich schrieb überhaupt nichts zu Lieferproblemen. Ich schrieb hingegen was zum fehlenden Denkansatz bzgl. der SW Entwicklung. Ach ja: SW == Software. uC brauchen sowas, sonst tun sie nichts. Gruss
Erich schrieb: > Ich schrieb überhaupt nichts zu Lieferproblemen. die gibt es aber gerade in dieser Welt. Und weil die Vertriebler x-tausend Geräte verkaufen könnten wenn dieser eine Käfer käuflich wäre, werden die erfinderisch. Ist gerade nicht lieferbar wie sonst immer, also fragt der Vertriebler die Entwicklung ob man nicht mal eben was anderes benutzen kann. Fragen kann man ja mal.
PIClig schrieb: > ich habe auch noch 40 Stueck 16F684. > Die werden wohl reichen. > Komischerweise kann man die sogar im Moment noch kaufen. > Da kann die Krise ja nicht so schlimm sein. Die Krise ist nicht so schlimm als dass sich Leute die übele PIC Architektur antun.
MaWin schrieb: > Die Krise ist nicht so schlimm als dass sich Leute die übele PIC > Architektur antun. Ach, die größeren PICs sind doch garnicht so schlimm. Die ollen 8Bitter waren natürlich absolut räudig, keine Frage.
> die übele PIC Architektur antun.
Es ist wohl eher so, dass sie sich nicht jedem sofort erschliesst.
Dank XC8-Compiler darf man auch in C mit den kleinen Kerlchen reden.
PIClig schrieb: >> die übele PIC Architektur antun. > > Es ist wohl eher so, dass sie sich nicht jedem sofort erschliesst. > Dank XC8-Compiler darf man auch in C mit den kleinen Kerlchen reden. Mit einer Sprache ohne wirkliche Worte mit einem Gegenüber kommunizieren, der halbtaub ist. Macht nicht wirklich Spass... Und ist im Endeffekt vor allem verdammt ineffizient. Ja, der Code ist in C genausoschnell runtergeschrieben wie für jedes andere Target. Aber die Laufzeiteigenschaften des Ergebnisses sind im Vergleich zu konkurrierenden Architekturen geradezu abartig Scheiße...
> im Vergleich zu > konkurrierenden Architekturen geradezu abartig Scheiß Ein Soft-UART macht auf so einem 16F684 bei 8 MHz Takt immerhin 230 kbit/s. Wahlweise auch in IRDA. Da finde ich das A*uinogedoehns was die Geschwindigkeit angeht, noch sehr viel mehr Scheiß.
PIClig schrieb: > Ein Soft-UART macht auf so einem 16F684 bei 8 MHz Takt > immerhin 230 kbit/s. Bidirektional? Mir konkurierenden Interrupts? Wohl kaum...
> Bidirektional? Mir konkurierenden Interrupts? Sicher. Fuer bidirektional einfach 2 PICs nehmen. Fuer den konkurrienden Interrupt dann noch einen dritten...
PIClig schrieb: > Bei halbduplex reicht natuerlich einer. Als Empfänger gerade mal so. Bloß was tut er dann mit den empfangenen Daten? Keine Rechenzeit mehr frei... Er ist dann darauf angewiesen, das der Sender auch mal eine Pause einlegt, damit er sie verarbeiten kann...
PIClig schrieb: > Da finde ich das A*uinogedoehns was die Geschwindigkeit > angeht, noch sehr viel mehr Scheiß. Natürlich, das ist halt wie Lego für Kleinkinder. Einfachst zusammenzuschnappen aber taugt nicht für Maschinenbau. Der drunterliegende ATmega ist aber potent, so wie Plastik im Spitzguss sehr einsatzfähig ist. Dass mit PICs kein Arduino-Spielzeug erfunden wurde, liegt an der trotz hoher Taktfrequenz und zeitlich vor den AVR verfügbaren PIC einfach an deren mieser Leistung unter C++.
c-hater schrieb: > Er ist dann darauf angewiesen, das der Sender auch mal eine Pause > einlegt, damit er sie verarbeiten kann... Ja, wie im echten leben.
MaWin schrieb: > Dass mit PICs kein Arduino-Spielzeug erfunden wurde, liegt an der trotz > hoher Taktfrequenz und zeitlich vor den AVR verfügbaren PIC einfach an > deren mieser Leistung unter C++. Das stimmt so nicht. Das Arduino Projekt begann mit dem bereits etablierten Wiring Board, auf dem sich bereits ein AVR befand. https://www.electronicsforu.com/buyers-guides/software-buyers-guide/wiring-open-source-platform-microcontrollers
:
Bearbeitet durch Moderator
MaWin schrieb: > Dass mit PICs kein Arduino-Spielzeug erfunden wurde, liegt an der trotz > hoher Taktfrequenz und zeitlich vor den AVR verfügbaren PIC einfach an > deren mieser Leistung unter C++. Das kannst du auch anders herum formulieren: Es liegt an der miserablen Leistung von C++ auf einem PIC. Und Assembler-Programmierung würde ja bedeuten, sich mit der zugrundeliegenden Architektur zu befassen. Genau DAS ist jedoch heutzutage unerwünscht, da mit Lernvorgängen verbunden. Also lassen wir dieses Seitenthema lieber, hier wollte einer wissen, ob und wo es noch "geheime" Insider-Tipps für µC mit einer Breitseite von DAC's geben könnte. Meine Antwort ist: So einen Tip gibt es nicht. Also entweder warten (wenn's nur Hobby ist) oder so hardwareunabhängig wie möglich sein System entwickeln und sich dabei 2 oder 3 verschiedene Varianten mit jeweils anderem µC offenhalten - sofern das möglich ist. W.S.
W.S. schrieb: > unerwünscht, da mit Lernvorgängen verbunden. Wie viel Bullshit kann man eigentlich so von sich geben, ohne dass einen der Blitz trifft?
> Wie viel Bullshit kann man eigentlich so von sich geben, ohne dass einen > der Blitz trifft? W.S. hat ja recht. Zur allgemeinen Kenntnis eines Controllers zaehlt auch der (Assembler-)Befehlssatz, Adressierungsarten etc. pp. Niemand verlangt aber, dass er sein Gesamtkunstwerk deswegen in Assembler schreiben muesste. Wer das nur mit dem Grund ablehnt, weil seine 'generischen' C-Kenntnisse zum Programmieren ausreichen, der soll das tun. Der wird dann aber u.U. eben Bullshit produzieren.
Mit "Bullshit" meine ich die hier immer wieder anzutreffende pauschale Behauptung, dass Lernen unerwünscht sei. Nicht nur von W.S.
W.S. schrieb: > sich mit der zugrundeliegenden Architektur zu befassen. Genau > DAS ist jedoch heutzutage unerwünscht, da mit Lernvorgängen verbunden. Gerade weil viele Lernen kommt man von ASM weg.. ich meine irgendwer muss ja in den sauren Apfel beissen. Und klar erstellt sich irgendjemand irgendwann eine C-Lib in dessen Funktionen "ASM" umgesetzt wird. Wenn diese Lib dann noch veröffentlich wird damit sich das andere ersparen können, bzw. die Hersteller das noch gleich dazulegen als Software ist das nur ein Entstehungsprozess von leicht verwendbarer Hard&Software. Das sich da ein paar altgesottene angep*sst fühlen das sie jahrelang in ASM rumschreiben mussten und dieser Code nun sogar noch einfacher mit Arduino umgesetzt werden kann.. kann ich verstehen, aber das ist ein Entwicklungsprozess wie z.B. Auto. ATSAMC21E18A-AUT (2222Stück)kann direkt bei Microchip noch dieses Jahr geliefert werden.. andere wohl erst Ende nächstes Jahr.. vielleicht hat der einen Haken :| Es lohnt sich aber bei Microchip direkt nach can-MCUs zu suchen.. da gibts noch einige.
:
Bearbeitet durch User
W.S. schrieb: > Genau > DAS ist jedoch heutzutage unerwünscht, da mit Lernvorgängen verbunden. Hmm? Redest du wieder über dich selbst? Deine unkenntnis gegenüber DMA zeigt doch immerwieder, dass du selber sehr lernresistent bist.
Philipp K. schrieb: > Gerade weil viele Lernen kommt man von ASM weg.. ich meine irgendwer > muss ja in den sauren Apfel beissen. Nun, "Hochsprachen" wurden ja erfunden, um hardware-unabhängig programmieren zu können. Da sind zum Programmieren im Prinzip keine oder nur rudimentäre Hardware-Kenntnisse erforderlich. Das ist bei Assembler völlig anders und die PIC-Architektur ist vornehmlich für das Programmieren in Assembler konstruiert. Da tun sich Programmiersprachen wie Pascal und C schwer damit. Man sollte das wissen und nicht solche Vergleiche tun, wie Mawin das weiter oben getan hat. Das ist der Punkt dieses Seitenthemas. W.S.
W.S. schrieb: > > Nun, "Hochsprachen" wurden ja erfunden, um hardware-unabhängig > programmieren zu können. Da sind zum Programmieren im Prinzip keine oder > nur rudimentäre Hardware-Kenntnisse erforderlich. Ich plädiere auch für die Programmierung in C. Aber im embedded Bereich benötigt man immer ein gewisses oder höheres Verständnis von Hardware bzw. komplexer Peripherie-Einheiten in modernen uC. Denn fertig einsetzbare Libraries gibt es nicht in allen Fällen, je spezieller die Anforderungen umso weniger. CAN ist beispielsweise verhältnismäßig kompliziert, da sind immer viele Einstellungen erforderlich, selbst wenn es Beispiele für den eingesetzten uC gibt. Gruss
W.S. schrieb: > Nun, "Hochsprachen" wurden ja erfunden, um hardware-unabhängig > programmieren zu können. Da sind zum Programmieren im Prinzip keine oder > nur rudimentäre Hardware-Kenntnisse erforderlich. Hochsprachen abstrahieren über den Prozessor. Manchmal auch über den Speicher. Nicht über die Peripherie. Dazu braucht es einen HAL oder gleich ein OS.
Cyblord -. schrieb: > oder gleich ein OS. Du hast direkt "Jehova" gesagt. (RT)OS verteufelt der W.S. doch auch zutiefst ;) Aber die zitierte Aussage zeigt wieder wie wenig Ahnung er hat.
Cyblord -. schrieb: > Hochsprachen abstrahieren über den Prozessor... Nö, überhaupt nicht. Sondern sie lassen den Compiler die Ideen des Quellcodeschreibers auf irgend eine Architektur übersetzen, damit sie dort ausgeführt werden können. So herum. Aber all das abseitige Geschwafel nützt dem TO gar nichts. Er hat gewisse Vorstellungen wie CAN, SPI, PWM usw., die er bei mehreren Controllertypen gern hätte, um sein Vorhaben umzusetzen. Und er fragt nach Chip-Typen, die sowas bieten UND die lieferbar sind. Ich vermute, daß er darauf keine ergiebige Antwort kriegen kann, solange es in der Szene noch kriselt. W.S.
W.S. schrieb: >> Hochsprachen abstrahieren über den Prozessor... > > Nö, überhaupt nicht. Sondern sie lassen den Compiler die Ideen des > Quellcodeschreibers auf irgend eine Architektur übersetzen, damit sie > dort ausgeführt werden können. So herum. Wo ist jetzt genau der Widerspruch zu meiner Aussage?
Cyblord -. schrieb: > Wo ist jetzt genau der Widerspruch zu meiner Aussage? In deiner Wortwahl. W.S.
W.S. schrieb: > In deiner Wortwahl. Die Wortwahl des Cyblords ist um einiges freundlicher als deine ;) Also wo wolltest du dich denn jetzt wieder absichtlich verlesen?
Beitrag #6833282 wurde von einem Moderator gelöscht.
W.S. schrieb: > Aber all das abseitige Geschwafel nützt dem TO gar nichts. Er hat > gewisse Vorstellungen wie CAN, SPI, PWM usw., die er bei mehreren > Controllertypen gern hätte, um sein Vorhaben umzusetzen. Und er fragt > nach Chip-Typen, die sowas bieten UND die lieferbar sind. Ich vermute, > daß er darauf keine ergiebige Antwort kriegen kann, solange es in der > Szene noch kriselt. Hab ich doch gemacht: Beitrag "Re: Verfügbare µC" Damit sollte er eine Weile hinkommen. fchk
oder gleich der Griff zum Chinesen... der ESP32 hat CAN, SPI, I2C, I2S, ETH-MAC, 2 serielle Schnittstellen, 2x DAC, ADC (ok, grausige Genauigkeit), diverse PWM, 16 LED-Dimmer-Kanäle. Ach ja, WLAN und BT hat er auch noch.
Beitrag #6834364 wurde von einem Moderator gelöscht.
Jan schrieb im Beitrag #6834364:
> Ich habe hier noch tausende xmega rumfliegen ^^
Aha, die Sackgasse ohne CAN.
Beitrag #6834736 wurde von einem Moderator gelöscht.
Beitrag #6834752 wurde von einem Moderator gelöscht.
Die ATSAME51J19A-AU wären toll, wenn man die denn gerade bekommen könnte. Die haben nämlich vor allem zwei CAN-FD Kanäle eingebaut. Dazu Peripherie bis unters Dach inklusive zwei DACs. Ja, ich weiß, der TO hat kein CAN-FD gefordert, aber meine Anforderungen sind ähnlich genug und langsam bräuchte ich auch mal einen anderen Controller, aber keiner der Kandidaten ist lieferbar. Der TI oben ist interessant, hat aber nur CAN 2.0b. Also wenn jemand Tipps zu beschaffbaren Controllern mit 64 Pins in TQFP und zwei CAN-FD Kanälen hat, nur raus damit. :-) Zumindest bei Digi-Key kann man nicht nach CAN-FD filtern. Aus "Verzweiflung" habe ich gerade schon eine Platine designed auf die ein Teensy 4.0 aufgelötet werden wird. Der hat zwar nur einen CAN-FD und kostet mehr als die komplette BOM vorher inklusive dem Gehäuse, aber dafür sind die Dinger (noch) lieferbar. Keine Ahnung ob es die Controller an sich geben würde, da es die nur als BGA gibt ist mir das aber auch ziemlich egal soweit. :-)
Beitrag #6834874 wurde von einem Moderator gelöscht.
Beitrag #6834880 wurde von einem Moderator gelöscht.
Beitrag #6834888 wurde von einem Moderator gelöscht.
Ich habe gerade gesehen das Mouser ATSAME51J20A-AF rein bekommen hat: https://www.mouser.de/ProductDetail/Microchip-Technology-Atmel/ATSAME51J20A-AF?qs=y6ZabgHbY%252ByKmI%252BFD2VVtQ%3D%3D 1447 Stück, nice, mal sehen bis wann die weg sind.
Beitrag #6835177 wurde von einem Moderator gelöscht.
Beitrag #6835182 wurde von einem Moderator gelöscht.
Mw E. schrieb: > W.S. schrieb: > >> In deiner Wortwahl. > > Die Wortwahl des Cyblords ist um einiges freundlicher als deine ;) > Also wo wolltest du dich denn jetzt wieder absichtlich verlesen? Wie eine lästige Scheißhausfliege dieser "fritzler". Hat er echt nichts anderes zu tun als sich ständig am wesentlich kompetenteren W.S. abzuarbeiten?
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.