Verfügbare µC

PSOCs haben 'einige' DACs.

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.

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.

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.

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

Bei halbduplex reicht natuerlich einer.

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

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.

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

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.

Cyblord -. schrieb:
> Wo ist jetzt genau der Widerspruch zu meiner Aussage?

In deiner Wortwahl.

W.S.

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

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?

Peter D. schrieb:
> Aha, die Sackgasse ohne CAN.

Sackgassen-Typen denken oft nur in Sackgassen