Forum: Mikrocontroller und Digitale Elektronik PIC Microchip lebt noch?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von kyrk.5 (Gast)


Lesenswert?

Hallo,

seit dem es mit dem Arduino gibt, habe ich das Gefühl, dass die 
Microchip PICs nicht mehr in der Mainstream so sind.

Interresante Development Boards scheint es nicht mehr so richtig zu 
geben. Bei Olimex habe ich zwar etwas gefunden, aber es scheint nicht 
mehr so aktiv entwickelt zu werden. Gibt es andere Firmen die hier noch 
etwas machen?

MPLAB X habe ich schon lange aufgegeben. Wird immer größer, aber so 
richtige Neuerungen sehe ich da nicht.

Harmony finde ich nicht so toll. Als Beispiel ok, aber produktiv eher 
weniger. Man kann da schon etwas aus extrahieren im sinne von C Code. 
Sonst mit MPLAB X und Harmony wurde ich nicht anfangen zu entwickeln.

ICD4 gibt es aktuell, oder? Habe den gekauft und schnell wieder 
versteckt. Instabil und problematisch. Vielleicht ist es schon jetzt 
besser. ICD3 finde ich viel stabiler.

Das einzige was da noch gut ist, ist der XC compiler.

Hobbyprojekte? Gibt es da noch jemand der etwas mit PICs macht? Überall 
sehe ich ESP oder Arduino.

von Teddy (Gast)


Lesenswert?

Microchip hat Atmel einverleibt. Ja sie leben noch!

von merciMerci (Gast)


Lesenswert?

kyrk.5 schrieb:
> ICD4 gibt es aktuell, oder? Habe den gekauft und schnell wieder
> versteckt.

Wenn du das Teil verkaufen willst, dann hätte ich vielleicht Interesse.

von Schwätzer (Gast)


Lesenswert?

Ich kauf Devboards und Compiler bei Mikroelektronika(mikroe.com)

von W.S. (Gast)


Lesenswert?

kyrk.5 schrieb:
> Interresante Development Boards scheint es nicht mehr so richtig zu
> geben.

Wozu denn auch?
Bei den diversen PIC's ist es doch seit Jahren bereits so, daß man sich 
seine Platine für den gedachten Einsatzzweck macht, dort den PIC 
draufpackt und fertig. Da braucht es schon lange keine Eval-Boards mehr.

Abgesehen davon ist es durchaus interessant, mal zu sehen, was Microchip 
sich seit einigen Jahren so an Firmen und Produkten einverleibt hat.

W.S.

von MaWin (Gast)


Lesenswert?

kyrk.5 schrieb:
> Hobbyprojekte? Gibt es da noch jemand der etwas mit PICs macht? Überall
> sehe ich ESP oder Arduino.

Hobbyisten denken und handeln anders als Profis.

Für Hobbyisten ist wichtig, dass es 'möglichst einfach' ist. D.h. USB 
Stecker vom PC rein und fertig, statt programmieren möglichst nur 
zussmmenklicken. Dafür zahlen sie auch gerne mehr, 10, 30 oder 50 EUR 
für Arduino oder rPi oder ESP sind kein Hinderungsgrund.
Und alles, was angeschlossen wird, ob LCD oder Motoren, Sensoren, WiFi, 
darf auch noch mal kosten, Hauptsache es ist abge'shield'ed und die 
Software liegt als Library vor.

Für Profis ist das ein no-go.

Da darf es nichts kosten, 3 oder 5 ct sind pro Controller viel, 20ct für 
USB, 50 ct für WiFi, dafür kauft man sich ggf. teure OTP 
Entwicklungsumgebung oder PSoC. LCD müssen direkt als Glas anschliessbar 
sein bei Microampere Stromaufnahme oder LED direkt im Multiplex, und 
Analogsensoren direkt auswertbar sein, Stichwort PGA oder audiotaugliche 
D/A-A/D oder BLDC taugliche Hardwaretimer

Das alles kann es AVR oder ESP oder rPi nicht, der einzige AVR mit LCD 
ATmega169 ist abgekündigt, 100mA LED Treiber Pinausgange gibt es nur bei 
einigen PIC oder Sinowealth, und billig ist PMS15A 1ct OTP, CH551G 15ct 
PTBO153CX SOT6 OTP 1.5ct aber kein Arduino/rPi/ESP.

Profis nutzen also ganz andere Chips als Hobbybastler.

von Cyblord -. (cyblord)


Lesenswert?

Teddy schrieb:
> Microchip hat Atmel einverleibt. Ja sie leben noch!

Es geht nicht um Microchip sondern um PICs

von auweia (Gast)


Lesenswert?

Das was die *uinos verbauen ist doch ein Fliegenschiss gegen
die Stueckzahlen der Industrie.

> dort den PIC draufpackt und fertig

Um die mache ich mir ueberhaupt keine Sorgen.

Allein schon wegen der praeziseren Peripherie (Clocl, ADC, ...).

Von rauschenden AD-Wandlern und der Notwendigkeit eines
Quarzes/Resonators fuer eine simple asynchrone Kommunikation
ist bei den PICs nichts bekannt.

Beitrag #6306032 wurde von einem Moderator gelöscht.
von Max D. (max_d)


Lesenswert?

Insgesamt wird doch der 8-Bit (und zu einem guten Teil auch 16-Bit) 
Markt von Oben her von den budget-ARMs (STM32F0 zb) und von Unten her 
von billo OTPs (Padauk war ja hier auch der Hype letztes Jahr) 
aufgefressen. Dazwischen bleibt keine große Nische mehr in der sich die 
8-Bit PICs oder AVRs halten könnten.

Beitrag #6306070 wurde von einem Moderator gelöscht.
von auweia (Gast)


Lesenswert?

> von den budget-ARMs (STM32F0 zb)
Nicht jeder hat Lust einfache und unkomplizierte Controller
durch komplexe ARMs zu ersetzen. Wenn einem 64 byte Register
reichen, nimmt man keine 8 k RAM.

> Padauk
Nicht jeder hat Lust chinesische oder schlecht uebersetzte
Datenblaetter zu deuten.
Da spielt es dann keine Rolle ob der Controller nun
30 ct oder 3 ct kostet.

> 1) Alle AD-Wandler rauschen.
> 2) Längst nicht alle PICs

Rauschen ist systemimmanent. Du bist das beste Beispiel.
Da wird jenseits des Six Sigma nach Tatsachen gesucht um
hier zu schwadronieren.

von merciMerci (Gast)


Lesenswert?

Max D. schrieb:
> Dazwischen bleibt keine große Nische mehr in der sich die
> 8-Bit PICs oder AVRs halten könnten

Wohl eher ein Scherz von dir, weil die Nische ist eher ein Riesenmarkt
in dem PICs, ... und auch weiterhin 8051 Derivate gut gedeihen.

Ein Nachteil der ARM Architektur ist z.B. die relative lange IRQ 
Latenszeit, darum sind in vielen Machinensteuerungen auch oft PICs 
anzutreffen.

Die PIC on-chip Peripherie e.g. NCO, SMT, CTMU sucht seinesgleichen!

von Frank K. (fchk)


Lesenswert?

kyrk.5 schrieb:

> Hobbyprojekte? Gibt es da noch jemand der etwas mit PICs macht? Überall
> sehe ich ESP oder Arduino.

Ich nehme gerne PICs. Weniger die 8-Bitter, sondern eher PIC24/dsPIC 
oder PIC32. Und das deswegen, weil die Peripherie deutlich besser als 
bei zB AVR ist. Beispiel PPS: Du kannst bei einem PIC, der das hat (das 
sind recht viele, aber nicht alle) fast jede Peripheriefunktion auf fast 
jeden IO-Pin legen. Das erleichtert beispielsweise das Layout erheblich. 
Bei so einem Arduino-AVR Mega328 bist Du eben darauf festgelegt, dass 
Dein einer SPI auf PB3 bis PB5 liegt. Bei einem dsPIC33CK256MP502 z.B. 
hast Du drei SPI-Einheiten und die Pins kannst Du beliebig auf den 16 
Pins des 'B' IO-Ports verteilen. Du hast viel mehr Peripherieeinheiten 
und bist viel flexibler. Plus: Der Chip läuft intern mit bis zu 100 MHz. 
Kein Scherz.

https://www.microchip.com/wwwproducts/en/dsPIC33CK128MP508

Die Welt ist also nicht bei AVRs und Arduinos stehen geblieben, sondern 
hat sich weiter gedreht. Und der Prozessorkern ist immer unwichtiger 
geworden, weil man immer weniger unbedingt in Assembler machen muss und 
der Compiler den Rest abstrahiert. Daher ist es mir egal, ob ARM, MIPS, 
PPC oder RiscV drin ist.

fchk

von Petermann (Gast)


Lesenswert?

"Der Chip läuft intern mit bis zu 100 MHz."

Werden DSP-Befehle in einem Takt ausgeführt?

von Petermann (Gast)


Lesenswert?

Hat sich erledigt :)

von auweia (Gast)


Lesenswert?

> Hat sich erledigt :)

Quasi in einem Takt. :-)

Beitrag #6306441 wurde von einem Moderator gelöscht.
von spess53 (Gast)


Lesenswert?

Hi

> Bei so einem Arduino-AVR Mega328 bist Du eben darauf festgelegt, dass
> Dein einer SPI auf PB3 bis PB5 liegt

Nö, bist nicht. Kannst du auch auf PD0/1 und 4 legen.

MfG Spess

von kyrk.5 (Gast)


Lesenswert?

merciMerci schrieb:
> kyrk.5 schrieb:
>> ICD4 gibt es aktuell, oder? Habe den gekauft und schnell wieder
>> versteckt.
>
> Wenn du das Teil verkaufen willst, dann hätte ich vielleicht Interesse.

Ich warte noch ab, vielleicht schaffen die es in ein paar Jahren dass 
das Ding brauchbar wird....

von Tim  . (cpldcpu)


Lesenswert?

Für Fans der kleinen PICs gibt es jetzt die Padauk-Microcontroller:

Beitrag "Padauk MCU für 0.038 USD aus Taiwan"

- Kosten ein Zehntel
- Besser programmierbar
- Multithreading

von Martin (Gast)


Lesenswert?

spess53 schrieb:
> Hi
>
>> Bei so einem Arduino-AVR Mega328 bist Du eben darauf festgelegt, dass
>> Dein einer SPI auf PB3 bis PB5 liegt
>
> Nö, bist nicht. Kannst du auch auf PD0/1 und 4 legen.
>
> MfG Spess

Ist natürlich Quatsch, weil es sich dabei nicht um das Mapping der Pins 
handelt, sondern um die USART-Schnittstelle im SPI-Mode.

von W.S. (Gast)


Lesenswert?

Tim  . schrieb:
> Für Fans der kleinen PICs gibt es jetzt die Padauk-Microcontroller

Schön vorsichtig sein damit. Soweit ich weiß, hat der Hersteller ja 
nicht mal die Programmieralgorithmen offengelegt. Obendrein ist wohl der 
Datenaustausch zwischen deren Mini-C-IDE und deren Brennprogramm 
verschlüsselt.

Das sind alles keine wirklich vertrauensbildenden Maßnahmen, sondern 
eher deren Gegenteil.

W.S.

von Frank K. (fchk)


Lesenswert?

W.S. schrieb:

> Das sind alles keine wirklich vertrauensbildenden Maßnahmen, sondern
> eher deren Gegenteil.

Und dann noch mal schauen, wie lange es die Chips und den Hersteller 
noch gibt. Für irgendwelche Consumerprodukte, die chargenweise 
entwickelt und in Millionenstückzahlen verschifft werden, ist das kein 
Problem. Updates wird es da eh nicht geben.

Hier in Forum sind wohl eher 1-2 stellige Stückzahlen üblich. Und da ist 
es völlig egal, ob der Prozessor jetzt 1.98€ (Mega328P im TQFP32) oder 
3.24€ (dsPIC33CK256MP502 in SSOP28) kostet (beides Digikey-Preise). 
Siehe meinen vorherigen Post.

fchk

von spess53 (Gast)


Lesenswert?

Hi

 Martin (Gast) schrieb

>Ist natürlich Quatsch, weil es sich dabei nicht um das Mapping der Pins
>handelt, ...

Ich finde, das Pin-Mapping total überbewertet wird. Es geht nichts gegen 
eine gute Planung und gutes PCB-Routing.

MfG Spess

von qwerty (Gast)


Lesenswert?

Tim  . schrieb:
> Für Fans der kleinen PICs gibt es jetzt die Padauk-Microcontroller:
>
> Beitrag "Padauk MCU für 0.038 USD aus Taiwan"
>
> - Kosten ein Zehntel
> - Besser programmierbar
> - Multithreading

Für Billig-Basteleien ganz OK. Die Padauk MCUs würde ich aber für 
ernsthafte Anwendungen nicht in Betracht ziehen. Die geben nicht einmal 
die data retention time bei den MTP-Versionen an oder weisen extra 
darauf hin, die MCUs nicht in AC Umgebungen einzusetzen (Not supposed to 
use in AC RC Step-down powered or high ETF requirement applications.). 
In einem Heizkissen möchte ich so etwas nicht haben...

von Andi B. (andi_b2)


Lesenswert?

spess53 schrieb:
> Ich finde, das Pin-Mapping total überbewertet wird. Es geht nichts gegen
> eine gute Planung und gutes PCB-Routing.

Naja, wenn man mit dem gleichen Prozessor im 32 Pin Gehäuse einmal 
Geräte mit z.B. 14 ADC Eingängen bauen will neben UARTs, und I²C und ein 
paar digitalen I/Os, dann aber mit dem gleichen (Synergie in SW und HW 
Entwicklung!) wieder mal mehrere Timer Aus-/Eingänge und I²Cs und mehr 
USARTs braucht parallel zu normalen I/Os und nur wenigen ADCs, dann 
lernt man umfangreiche Pin-mapping Möglichkeiten schon zu schätzen. So 
ein EFM321G1B z.B. ist da noch um einiges mächtiger als ein PIC24. 
Klarerweise deswegen aber auch komplizierter.

Darum, klar gibt's nach wie vor einen Anwenderkreis und Geräte für ganz 
kleine PICs aber auch große PICs. Einer der größten Vorteile der PICs 
ist für viel, dass die praktisch nie abgekündigt werden/wurden. Man ist 
also nicht gezwungen umzusteigen. Und solange man mit einem alten MPLAB 
und einem RealICE oder auch einem PicKIT zufrieden ist, kann man ja 
weiterarbeiten damit. Wer sich aber weitergebildet hat und schon mal was 
besseres genutzt hat, wird eher nicht traurig sein, wenn er sich mit 
(kleinen) PICs oder gar Atmels nicht mehr rumschlagen muß.

Beitrag #6308219 wurde von einem Moderator gelöscht.
von MaWin (Gast)


Lesenswert?

Andi B. schrieb:
> Einer der größten Vorteile der PICs ist für viel, dass die praktisch nie
> abgekündigt werden/wurden.

?!? Genau deswegen haben die meisten Nutzer Microchip verlassen: wenn 
sie nach dem sie den PIC16C84 kennengelernt hatten gleich zum PIC16F84 
wechseln mussten, und der damals abgekündigt wurde, konnte man gleich 
zum AVR gehen.

von Gerhard O. (gerhard_)


Lesenswert?

Es widerstrebt mir zuzugeben, daß ich aus purer Bequemlichkeit von PIC 
auf AVR migriert bin. Früher mußte ich für PIC Projekte Leiterplatten 
entwerfen. Heutzutage schnappe ich mir einen NANO oder Pro-Mini und habe 
eine halbe Stunde einfache Projekte am laufen. Ich habe deswegen auch 
schon ein paar ältere Sachen von PIC auf AVR portiert. Schwer zu 
widerstehen! Mit den DsPICs habe ich allerdings in der Firma immer gerne 
gearbeitet. Die machten eigentlich kaum jemals Schwierigkeiten.

von Jens M. (schuchkleisser)


Lesenswert?

MaWin schrieb:
> PIC16F84
> wechseln mussten, und der damals abgekündigt wurde,

Aha?
OK, er ist NRND, aber bei z.B. Mouser noch in Mengen erhältlich, und es 
kommen auch noch welche nach.
Gebaut wird er also noch.

Gerhard O. schrieb:
> Heutzutage schnappe ich mir einen NANO oder Pro-Mini und habe
> eine halbe Stunde einfache Projekte am laufen.

Genau das ist der einzige Grund.
Hätte sich der Arduino-Erfinder aus einem PIC-Jünger heraus entwickelt, 
müsste man sich heute nicht mit der unsäglichen Dämlichkeit 
herumschlagen, das die Konfiguration des Controllers immer "per Hand" 
mitgeliefert und in jedem Programmer anders eingetragen werden muss.
Der Mist kommt in den Quellcode, wird in die HEX-Datei eingetragen und 
fertig ist das, egal welchen Programmer man benutzt.

von W.S. (Gast)


Lesenswert?

Moby schrieb im Beitrag #6308219:
> Was heißt rumschlagen.
> Die Frage ist einzig: Langen sie in Hardware für die Anwendung oder
> nicht.

Rein sachlich hast du ja Recht.

Aber sieh dich mal um und schau, wieviele "Anwender" überhaupt noch 
Fähigkeiten in Assembler haben. Einen Furz in C hinzuschreiben kriegen 
die Leute ja zuwege, aber dafür ist dann der übernächstgrößere Chip 
vonnöten.

Naja und gerade die kleineren PIC's sind für Assembler gemacht. Jeder, 
der das nicht kann oder will oder sich zu erhaben über sowas erachtet, 
kommt damit eben nicht klar und so einer braucht dann eben was größeres.

W.S.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

Ach deswegen kannst du kein C.
Danke für die Aufklärung W.S.

Beitrag #6308657 wurde von einem Moderator gelöscht.
von goc911 (Gast)


Lesenswert?

Flieg nicht so hoch junger Freund. Wie viele Leiterplatten hast du denn 
schon EMV-erfolgreich bewerkstelligt? Selbstverständlich ist es ein 
Vorteil, ja, wenn pin-mapping möglich ist. Insbesondere dann, wenn z.B. 
die Lagenzahl auf z.B. 4 Lagen begrenzt ist. Dann hast du i.d.R. den 
Top-Layer als Signallage, Layer 2 muss zwingend eine ununterbroche 
GND-Plane sein. Also wirst du in Layer 3 etwas mit Stromversorgungen 
haben, hoffentlich etwas rechteckiges und keine "komischen geometrischen 
Gebilde". Und Layer 4 für die Leitungen die sonst keinen Platz gefunden 
haben. Na, wo fliest der Strom beim Durchsteiger in Lage 4? In der 
Stromversorgungslage Lage 3, da Layer 4 keinen direkten GND-Bezug hat. 
Nennt sich dann Übersprechen. Und dann merkst sehr schnell dass 4 Lagen 
schon sehr sportlich sind ein physikalisch korrektes Layout zu 
realisieren. Habe bisher sehr sehr wenige kennen gelernt die so etwas 
können mit so wenigen Lagen, eine Hand reicht zur Abzählung voll aus.

PS: Gerhard Eigelsreiter, bekannt aus der Leiterpaltte 2010, konnte gut 
mit vielen Layern und seinen 50µm Substraten. Zu seiner meltemi mit 6 
Lagen sagte er mal zu mir "Des moch i ni wieder". Ist übrigends 
Österreicher.

von goc911 (Gast)


Lesenswert?

geht an spess 53

von Zeno (Gast)


Lesenswert?

Mw E. schrieb:
> Ach deswegen kannst du kein C.
> Danke für die Aufklärung W.S.

Warum muß eigentlich in jedem Thread einer aufschlagen, der zwar nix zum 
Thema beiträgt, aber erst mal völlig grundlos andere beleidigt?

Beitrag #6308832 wurde von einem Moderator gelöscht.
von auweia (Gast)


Lesenswert?

Auch die "kleinen" PICs mit 1 k oder 2 kWorten Flash lassen sich
komfortabler in C programmieren. Auch ein Mix von C und Assembler
wird vom XC8 gut unterstuetzt.
Manches laesst sich in Assembler tatsaechlich leichter und besser
hinschreiben als in C.

von Toby P. (Gast)


Lesenswert?

kyrk.5 schrieb:
> seit dem es mit dem Arduino gibt, habe ich das Gefühl, dass die
> Microchip PICs nicht mehr in der Mainstream so sind.

Waren es in Deutschland noch nie. Das sieht in den USA z.B. anders aus.

> aber Interresante Development Boards scheint es nicht mehr so richtig zu
> geben.

Microchip selber bringt immer mal neue raus.


> MPLAB X habe ich schon lange aufgegeben. Wird immer größer, aber so
> richtige Neuerungen sehe ich da nicht.

Das war schon immer ein überfrachtetes Gewirr. Hab ich selber nie 
genutzt.

Die IPE Proggersoftware ist m.E. aber richtig gut (wenn man die Finger 
von MPLAB lässt)

>
> Harmony finde ich nicht so toll. Als Beispiel ok, aber produktiv eher
> weniger. Man kann da schon etwas aus extrahieren im sinne von C Code.
> Sonst mit MPLAB X und Harmony wurde ich nicht anfangen zu entwickeln.

Find ich super, kann man schnell was einstellen

> Hobbyprojekte? Gibt es da noch jemand der etwas mit PICs macht? Überall
> sehe ich ESP oder Arduino.

Das geht wohl allen älteren Chips so, egal ob Atmel, MSP oder PIC.

von Tim  . (cpldcpu)


Lesenswert?

qwerty schrieb:
> Tim  . schrieb:
>> Für Fans der kleinen PICs gibt es jetzt die Padauk-Microcontroller:
>>
>> Beitrag "Padauk MCU für 0.038 USD aus Taiwan"
>>
>> - Kosten ein Zehntel
>> - Besser programmierbar
>> - Multithreading
>
> Für Billig-Basteleien ganz OK. Die Padauk MCUs würde ich aber für
> ernsthafte Anwendungen nicht in Betracht ziehen. Die geben nicht einmal
> die data retention time bei den MTP-Versionen an oder weisen extra
> darauf hin, die MCUs nicht in AC Umgebungen einzusetzen (Not supposed to
> use in AC RC Step-down powered or high ETF requirement applications.).
> In einem Heizkissen möchte ich so etwas nicht haben...

You get what you pay for... In einer Applikation mit FuSi-Anforderungen 
wird man hoffentlich keinen 0.03 USD Microcontroller einsetzen.

Padauk hat allerdings auch eine Serie MCUs von MCUs für Anwendungen mit 
erhöhten Anforderungen (PFC*** statt PFS***). Die werden aber auch ein 
paar cent teurer sein.

von Tim  . (cpldcpu)


Lesenswert?

W.S. schrieb:
> Tim  . schrieb:
>> Für Fans der kleinen PICs gibt es jetzt die Padauk-Microcontroller
>
> Schön vorsichtig sein damit. Soweit ich weiß, hat der Hersteller ja
> nicht mal die Programmieralgorithmen offengelegt. Obendrein ist wohl der
> Datenaustausch zwischen deren Mini-C-IDE und deren Brennprogramm
> verschlüsselt.

Es gibt jetzt eine komplette Open-Source Toolchain.

Kommt halt darauf an, was man machen will. Allerdings ist man bei vielen 
Projekten dann auch schnell bei 32 Bit Controllern, daher hinkt der 
Vergleich zwischen 8 Bittern.

: Bearbeitet durch User
von Cyblord -. (cyblord)


Lesenswert?

goc911 schrieb:
> geht an spess 53

Lern zitieren.

von Andi B. (andi_b2)


Lesenswert?

kyrk.5 schrieb:
> seit dem es mit dem Arduino gibt, habe ich das Gefühl, dass die
> Microchip PICs nicht mehr in der Mainstream so sind.
>
.....
> Hobbyprojekte? Gibt es da noch jemand der etwas mit PICs macht? Überall
> sehe ich ESP oder Arduino.

Was definierst du unter Mainstream? Ich würde das an Stückzahlen 
festmachen und da wette ich, haben die PICs haushoch die Nase vorn 
gegenüber Arduino.

Und für Hobbyprojekte nimmt man auch das was man hat und was man kennt. 
Da ich die PICs von denn 12er bis zu den 32ern kenne, sowie sehr viele 
Atmels, davon auch einen Haufen welche schon gar nicht mehr erhältlich 
sind, sowie diverse andere uC Serien von anderen Herstellern, nehme ich 
persönlich bevorzugt EFM32. Aber weil ich die HW und SW dazu kenne und 
verfügbar habe. Wenn ich eine alte Leiterplatte mit Display und Tasten 
recyceln kann, dann auch mal den PIC24. Das heißt aber noch lange nicht, 
dass z.B. die aktuellen Infineons schlecht wären.

von kyrk.5 (Gast)


Lesenswert?

Tim  . schrieb:
> In einer Applikation mit FuSi-Anforderungen
> wird man hoffentlich keinen 0.03 USD Microcontroller einsetzen.

Ausser es gibt einen Technical Safety Manual und da wird alles schön 
beschrieben wie man ASIL A,B,C,D level erreichen kann :)

von kyrk.5 (Gast)


Lesenswert?

Andi B. schrieb:
> Was definierst du unter Mainstream?

Tcha, gute Frage. Im Bereich Hobby würde ich das relativ unklar so 
definieren: Was man halt im Internet und in Zeitungen so sieht. Im 
Bereich Profi würde ich auch die Stückzahlen nehmen.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

Zeno schrieb:
> Warum muß eigentlich in jedem Thread einer aufschlagen, der zwar nix zum
> Thema beiträgt, aber erst mal völlig grundlos andere beleidigt?

Bei W.S. ist das nicht grundlos, ließ doch mal seine Beiträge hier im 
Forum quer.
Anderen Leuten seinen grottenschlechten Code quasi aufzwingen und selber 
andere immer dumm von der Seite anmachen.
Vor allem im Projekte Forum ist er da immer sehr "nett" wenn etwas nicht 
so schlecht programmiert ist wie seine Lernbetty.
Ich geb ihm nur etwas von seiner Medizin zurück ;)

von goc911 (Gast)


Lesenswert?

Cyblord -. schrieb:
> goc911 schrieb:
>> geht an spess 53
>
> Lern zitieren.

Versuchen wir es mal.
Gut so?

Danke Heini für den Hinweis, wird künftig so gemacht. Aber dfür ist dass 
Board ja da. Höflich auf Missstände Hinweisen, auch wenn keiner danach 
gefragt hat.

von W.S. (Gast)


Lesenswert?

Tim  . schrieb:
> Es gibt jetzt eine komplette Open-Source Toolchain.
>
> Kommt halt darauf an, was man machen will.

Ähem.. ja. eben. Ich kann das verstehen, daß man diese kleinen Padauk's 
interessant findet und soweit ich das per Drüberlesen über den 
ellenlangen Thread im eevblog habe sehen können, haben sich dort viele 
Leute richtig Mühe gegeben, um etwas von dem herauszukriegen, was der 
Hersteller partout nicht veröffentlichen will.

naja, vielleicht lade ich mir da alles mal herunter und versuche es zu 
sichten um dann mal ne Art "zusammenfassende Doku" zu schreiben. So 
etwas fehlt da nämlich noch - und das ist wohl immer so (Programmierer 
haben ne gewaltige Abscheu vor dem Schreiben von Dokumentationen..), 
obwohl eigentlich notwendig, weil sonst die wenigen gefundenen Nadeln im 
Heuhaufen wieder untergehen.

W.S.

von Jens (Gast)


Lesenswert?

Toby P. schrieb:
> Das war schon immer ein überfrachtetes Gewirr. Hab ich selber nie
> genutzt.
>
> Die IPE Proggersoftware ist m.E. aber richtig gut (wenn man die Finger
> von MPLAB lässt)

Sorry für meine Unwissenheit, aber womit schreibst du die Programme?

ASM habe ich mit dem Windows-Editor geschrieben, dann direkt in den 
MPASM geladen und mit dem Sprut-8-Brenner in den PIC gebrannt. Da 
brauchte ich keine echte IDE.

Für die aktuellen Sachen braucht es ja MPLAB um dem C-Compiler eine 
Heimat zu geben. Oder habe ich gerade ein Brett vorm Kopf? Was gibt es 
noch für IDEs mit C?

von W.S. (Gast)


Lesenswert?

Zeno schrieb:
> Warum muß eigentlich..

Ach, weil dieser schon früher mal sich daneben benommen hat, zusammen 
mit Bernd K. und unserem Frank (dem Moderator). Ausgangspunkt war eine 
Absturzbehandlung, die er hier vorgestellt hatte. Die ist zwar nett für 
den Zeitraum der Entwicklung, hat aber wenig Sinn für den späteren 
Einsatz, wenn der µC im Betrieb nicht aufgrund von Programmierfehlern, 
sondern aufgrund von unvorhersehbaren Störungen mal abstürzt. Da hat er 
einfach nix verstanden und ist grob und unverschämt geworden. Kann er 
bei mir steckenlassen. Und seit Helge Tefs ihm obendrein nochmal ein 
paar deftige Worte gesagt hat, hat er ne innere Verklemmung.
Wir hatten hier schon etliche davon, z.B. so nen Doktor Frühling oder 
so, der sich als Beckmesser des Forums profilierte. Schwamm drüber und 
einfach sachlich bleiben.

An dieser Stelle kommen wir auch wieder auf die PIC's zurück: sie sind 
ganz einfach robuster gegenüber Störungen, eben aufgrund ihrer relativen 
inneren "Übersichtlichkeit" gegenüber den größeren Boliden unter den µC, 
wo eben wegen der weitaus größeren Komplexität auch mehr schief gehen 
kann.

W.S.

von W.S. (Gast)


Lesenswert?

Moby schrieb im Beitrag #6308657:
> Aber davon mal abgesehen, wenn man sich in diversen Foren umschaut ist
> das Asm-Thema noch lang nicht tot.

Naja, wie sollte es auch. Gerade wenn man sich kleinere Chips anschaut, 
stellt man fest, daß es in deren Hardware so einiges gibt, was man in 
höheren Programmiersprachen entweder nur ganz schwer oder überhaupt 
nicht darstellen kann. Wer da vom Assembler nichts wissen will, kann 
einen Teil der Effektivität eben dieser Chips gar nicht benutzen.

W.S.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

W.S. schrieb:
> Ach, weil dieser schon früher mal sich daneben benommen hat, zusammen
> mit Bernd K. und unserem Frank (dem Moderator). Ausgangspunkt war eine
> Absturzbehandlung, die er hier vorgestellt hatte. Die ist zwar nett für
> den Zeitraum der Entwicklung, hat aber wenig Sinn für den späteren
> Einsatz, wenn der µC im Betrieb nicht aufgrund von Programmierfehlern,
> sondern aufgrund von unvorhersehbaren Störungen mal abstürzt. Da hat er
> einfach nix verstanden und ist grob und unverschämt geworden. Kann er
> bei mir steckenlassen.

Dass deine Warnehmung durchaus komplett falsch ist haben dir ja schon 
viele gesagt.
Bei deinen unterirdischen Falshcaussagen müssen ziemlich viele 
"daggenehalten" das ist jetzt schon eine 2 stellige Anzahl an user.
Deine Beiträge zeigen da auch immer gut ins minus.
Aber das geht bei deinem Alzheimer eben nicht mehr durch.
Der Ausgangspunkt ist übrigens, dass du hier andauernd Magic Number Code 
mit gotos postest und das als dem besten Code der Welt anpreist.
Das im Faulthandlerfred war nur die Fortestzund deiner Idiotie.
Ich fands ja eher interessant, dass ich alle deine Argumente Widerlegt 
habe und du dir nur eins rausgreist und dann falsch weitergeritten bist.
Dabei steht doch im Thread drinne, dass der Code  für die ENtwicklung 
ist, daher beuaptest du hier mal wieder falsche Tatsachen.
Aber so kennt man dich ja.
Sehr interessant sind auch imemr deine HAsstiraden gegen Debugger.
Dabei hat jemand in deinem Code mit einem Debugger noch gravierende Bugs 
gefunden.
Also kannst du dich nichtmal an deine eigenen Ansprüche halten!
Richtig lustig war deine Erfindung eiens Cortex-M4 ohne DSP Befehle.

Mt überheblich daneben benehmen sollteste dir übrigens mal an die eigene 
Nase fassen.
Wer hat denn hier versucht jamnden anderen mit einem besseren und 
bugfreien USB Stack aufs mieseste runterzumachen?
Lustigerweise haste dann behauptet, dass dein Code Dinge könnte, die er 
garnicht kann.

W.S. schrieb:
> Schwamm drüber und
> einfach sachlich bleiben.

Sobald bei dir ausnahmsweise mal was sachliches kommt (was ja durchaus 
auch mal vorkomtm) is von mir ja nix zu lesen ;)

von kyrk.5 (Gast)


Lesenswert?

Jens schrieb:
> Für die aktuellen Sachen braucht es ja MPLAB um dem C-Compiler eine
> Heimat zu geben. Oder habe ich gerade ein Brett vorm Kopf? Was gibt es
> noch für IDEs mit C?

Prinzipiell kann man auch Makefiles machen und damit arbeiten. Der MPLAB 
8 kann Makefiles exportieren. Ist zwar ein sehr einfaches, nicht einfach 
zu maintainen aber es ist möglich auch ohne MPLAB 8 zu erweitern. Seit 
ich mehrere Varianten von einem SW bauen muss (debug, nicht debug, mit 
bootloader, ohne bootloader) mache ich Makefiles und eine Batch Datei 
baut alles. Würde sich auch in Jenkins einfach einbinden lassen.

Um ehrlich zu sein, brauche ich relativ wenig um Entwickeln zu können. 
Meist reicht ein Notepad++, Make, und etwas wo ich flashen, breakpoint 
setzten kann und variablen auslesen kann. Das geht leider nur in IDEs.

von kyrk.5 (Gast)


Lesenswert?

Toby P. schrieb:
> Microchip selber bringt immer mal neue raus.

Kannst du bitte Beispiele nennen? Ich würde gerne sehen was andere 
Interessant finden um mir eventuell auch etwas davon zu bestellen.

Seit einige Zeit gibt es einen dsPIC mit 2 Kernen. Habe den interessant 
gefunden und auch eins von Microchip gekauft. Im Geschäft habe ich ja 
auch mit Multi-Core zu tun. Wobei wegen Zeitmangel habe ich da noch 
nicht so richtig etwas damit gemacht. Kurz ausprobiert, lässt sich 
debuggen, toll. SW Laden ist interessant gemacht. So weit ich es gesehen 
habe, kann man nur den ersten Core flashen, wenn der läuft dann wird der 
zweite Core dadurch geladen. Laufzeit technisch ist das nicht so gut 
aber es funktioniert. Ich hoffe das Microchip auch bei den PIC32 
irgendwann mal einen Multi-Core herausbringt, wobei ich glaube nicht 
dass Multi-Core in dem Form bei Bastlern viel Erfolg zeigen wir. Für den 
Bastler ist es einfach zu komplex.

Beitrag #6314492 wurde von einem Moderator gelöscht.
von Toby P. (Gast)


Lesenswert?

kyrk.5 schrieb:
> Kannst du bitte Beispiele nennen? Ich würde gerne sehen was andere
> Interessant finden um mir eventuell auch etwas davon zu bestellen.

Läuft unter Curiosity bei Microchip, die haben jetzt Steckplätze für 
Mikroe Click Boards. .Von gibt es hunderte, für alle möglichen 
Funktionen. Geht superschnell damit Prototypen zu bauen ohne was zu 
löten.

Multicore finde ich jetzt nicht so interessant. Ohne ein OS welches die 
Tasks regelt ist das sehr aufwendig und eher für exotische Anwendungen. 
Selbst dann multiplizieren sich die Probleme. Wenn man klar getrennte 
Tasks  die leicht parallel laufen hat sieht das evtl.  anders aus.

Ist eher was für Linux.

von Toby P. (Gast)


Lesenswert?

Michael M. schrieb im Beitrag #6314492:
> Multicore für Bastler ist auch nichts neues.
> Parallax bietet solche noch an (Propeller).
> Daß sich diese aber breit am Markt durchgesetzt hätten kann man nicht
> behaupten.

Hab damit mal herumgespielt. Der Komplexitätsgrad steigt exponentiell. 
Meiner einer blickt da dann schnell nicht mehr durch.

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Lesenswert?

Die 8-Bit-PIC haben halt doch eine eher unschöne Architektur. Und 
inzwischen gibt es genug billige Alternative, so dass der früher oft für 
PIC sprechende Grund des Preises wegfällt.

Dass die pic-Backends in SDCC seit vielen Jahren als "in development 
gelten", während die neuen Padauk-Backends in kurzer Zeit daran 
vorbeizogen, und nun zumindest für pdk14 und pdk15 "stable" sind, liegt 
auch an der Architektur.

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Lesenswert?

auweia schrieb:
>> von den budget-ARMs (STM32F0 zb)
> Nicht jeder hat Lust einfache und unkomplizierte Controller
> durch komplexe ARMs zu ersetzen. Wenn einem 64 byte Register
> reichen, nimmt man keine 8 k RAM.
>
>> Padauk
> Nicht jeder hat Lust chinesische oder schlecht uebersetzte
> Datenblaetter zu deuten.
> Da spielt es dann keine Rolle ob der Controller nun
> 30 ct oder 3 ct kostet.

Wenn es keine Rolle spielt, ob der Controller 3¢ oder 30 ¢ kostent, 
nimmt man aber keinen 8-Bit-PIC, sondern eher einen STM8 oder MCS-51; 
die sind angenehmer zu programmieren und besser von Tools unterstützt.

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Lesenswert?

>>
>> Für Billig-Basteleien ganz OK. Die Padauk MCUs würde ich aber für
>> ernsthafte Anwendungen nicht in Betracht ziehen. Die geben nicht einmal
>> die data retention time bei den MTP-Versionen an oder weisen extra
>> darauf hin, die MCUs nicht in AC Umgebungen einzusetzen (Not supposed to
>> use in AC RC Step-down powered or high ETF requirement applications.).
>> In einem Heizkissen möchte ich so etwas nicht haben...
>
> You get what you pay for... In einer Applikation mit FuSi-Anforderungen
> wird man hoffentlich keinen 0.03 USD Microcontroller einsetzen.
>
> Padauk hat allerdings auch eine Serie MCUs von MCUs für Anwendungen mit
> erhöhten Anforderungen (PFC*** statt PFS***). Die werden aber auch ein
> paar cent teurer sein.

Wenn man OTP in Kauf nimmt (also PM? statt PF?), gibt es den PMC150 im 
6-Pin-gehäuse bei LCSC auch für 3¢ bei 5000 Stück.
Und als P?C sollte der robuster sein.

von Frank K. (fchk)


Lesenswert?

Philipp Klaus K. schrieb:
> Die 8-Bit-PIC haben halt doch eine eher unschöne Architektur. Und
> inzwischen gibt es genug billige Alternative, so dass der früher oft für
> PIC sprechende Grund des Preises wegfällt.

Wenn Du C benutzt (und das wirst Du ab einer gewissen Komplexität, wenn 
Dein Tag auch nur 24h hat), dann merkst Du vom Core nicht wirklich viel. 
Ich bin der Überzeugung, dass es immer weniger wichtig ist, welcher Core 
unter der Haube ist. Und XC8 funktioniert.

Und natürlich hat 8-Bit PIC seine Architekturbeschränkungen. In sehr 
vielen Köpfen ist es einfach noch nicht angekommen, dass es seit 
Jahrzehten auch 16 und 32 Bit PICs gibt. Die Peripherie ist sehr 
ähnlich, man braucht nur einen anderen Compiler. Und ob darunter nun 
ARM, MIPS, PPC oder RISC-V werkelt ist genauso entscheidend wie ob ich 
im Markt Coca-Cola, Pepsi oder Fritz Cola nehme.

Und 16-Bit PIC ist in einer Hinsicht interessant: Es kommt in der 
Leistungsfähigkeit an kleinere 32-Bit Architekturen wie Cortex M0 heran, 
ohne jedoch die Nachteile zu haben wie z.B. keine atomaren 
Bitoperationen auf SFRs (was ARM und PIC durch Bit-Banding und 
Erweiterungen in der Peripherie ausgleichen müssen) und eine sehr viel 
engere Koppelung der SFRs an den Core.

fchk

Beitrag #6315056 wurde von einem Moderator gelöscht.
von W.S. (Gast)


Lesenswert?

Philipp Klaus K. schrieb:
> Die 8-Bit-PIC haben halt doch eine eher unschöne Architektur.

Das empfinde ich nun wiederum nicht so. Für das Programmieren in 
Assembler hat diese Architektur durchaus Charme - lediglich dann, wenn 
man das Programmieren nur aus Sicht eines C-Programmierers sieht, wird 
es schwierig mit den kleinen PIC's. Es ist eben nicht jede 
Programmiersprache für jede Architektur gleich gut geeignet.

W.S.

von Soul E. (Gast)


Lesenswert?

Nicht vergessen, General Instruments hatte bei der Konzipierung der 
PIC16-Architektur speicherprogrammierte Steuerungen (SPS bzw PLC) im 
Hinterkopf. Wer schonmal eine Simatic S5 in AWL programmiert hat fühlt 
sich beim PIC16 sofort wohl.

Ein 68000 mit seiner symmetrischen Architektur wurde direkt für 
C-Compiler optimiert.

von W.S. (Gast)


Lesenswert?

Soul E. schrieb:
> Nicht vergessen, General Instruments

Jaja, es war der PIC ja nur als "P"eripherer "I"nterface "C"ontroller 
damals geplant. Eine richtige CPU hatten die auch im Programm, aber wie 
das Schicksal halt so spielt, hat sich nur der kleine 
Peripherie-Controller zu dem gemausert, was wir heut als PIC kennen.

W.S.

von c-hater (Gast)


Lesenswert?

Soul E. schrieb:

> Ein 68000 mit seiner symmetrischen Architektur wurde direkt für
> C-Compiler optimiert.

Du meinst: "orthogonalen Befehlssatz", nicht "symmetrische 
Architektur"...

von kyrk.5 (Gast)


Lesenswert?

Toby P. schrieb:
> Multicore finde ich jetzt nicht so interessant. Ohne ein OS welches die
> Tasks regelt ist das sehr aufwendig und eher für exotische Anwendungen.

Das hängt immer davon ab. Man kann auch ohne einen OS Multicore 
programmieren und davon die Vorteile genießen. Man muss nur die Aufgaben 
gut aufteilen können. Zum Beispiel User Interface ist Core1 und 
Kommunikation und Berechnen ist Core2. Ob man hier einen OS noch hat, 
was hilf um Tasks Preemtiv oder Kooperativ zu machen ist eine andere 
Frage. Auch ob der OS inter-core Kommunikation unterstützt oder nicht.

Wo ich mit Multi-Core zu tun gehabt habe, wusste der OS gar nicht dass 
der uC Multi-Core ist. Es gab dann auch 1 OS pro Kern. Interprocess 
Kommunikation gab es auch nicht. Das musste man auch selber machen. Es 
ist natürlich leichter wenn man alles fertig bekommen würde. Aber es ist 
leider in vielen Fällen einfach nicht so.

Multi-Core finde ich interessant für Professionelle Organisationen, wo 
die Infrastruktur dazu ausgebaut werden kann. Oder für Professionelle 
Anwender wo die Infrastruktur fertig zu Verfügung steht.

von Ex (Gast)


Lesenswert?

> Coca-Cola, Pepsi oder Fritz Cola

An einem heissen Sommertag geht doch nix über eine eiskalte Pubsicola!
Natürlich aus einer Glasflasche.

von MCUA (Gast)


Lesenswert?

> Die PIC on-chip Peripherie e.g. NCO, SMT, CTMU sucht seinesgleichen!

> Beispiel PPS: Du kannst bei einem PIC, der das hat (das
> sind recht viele, aber nicht alle) fast jede Peripheriefunktion auf fast
> jeden IO-Pin legen. Das erleichtert beispielsweise das Layout erheblich.


Aber was haben die sich gedacht bei der Pinbelegung von dem EPMP 
(XMEM-Interface) ???
Die Pins vom Bus sind kreuz und quer (!) über den Chip verteilt, auf 
alle 4 Seiten, nichtmal portweise zusammenhängend!
(Bsp. PIC24FJ128GA310 FAMILY , 64, 80, 100 Pins / oder auch PIC33..)
Sowas will doch kein Mensch routen! Und wenn man es macht hat es 
Nachteile.
(solch Pin-Kauderwelch ist mir bei keiner anderen CPU-Architektur 
bekannt)

von W.S. (Gast)


Lesenswert?

MCUA schrieb:
> (solch Pin-Kauderwelch ist mir bei keiner anderen CPU-Architektur
> bekannt)

Dann guck mal bei den Cortexen von NXP und ST und dort auf die 
jeweiligen externen Businterfaces. Die sind bei vielen Chips ebenfalls 
kreuz und quer über alle Seiten bzw. Balls verteilt.

Und ja, man kann das routen, auch auf einer nur 2 seitigen LP und es 
funktioniert. Aber man muß sich eben mal etwas Mühe geben. Das ist 
alles.

W.S.

von MCUA (Gast)


Lesenswert?

> Dann guck mal bei den Cortexen von NXP und ST und dort auf die
> jeweiligen externen Businterfaces.

Nein, meist sind die mindest. zusammehängend pro 8 Bit-Port. (Bsp D0..7 
oder A0..7 an einem Port).
Auch das das ist bei den PIC24 nicht der Fall!

Einzelne Ctr-Signale zu holen und zu routen ist kein Problem.
Wenn man aber (nur) 16 zusammenhängene Sigale aus 4,5,6 Ports 
herauspicken muss ist das eine Katastrophe!

Und wie ist das beim AVR (ders vom '51 abgeguggt hat)?

von MCUA (Gast)


Angehängte Dateien:

Lesenswert?

Hier ein Bild der Pinbelegung mit Markierungen.
EPMP grün markiert.
also....grässlich

von Ben S. (bensch123)


Lesenswert?

MCUA schrieb:
> Hier ein Bild der Pinbelegung mit Markierungen.
> EPMP grün markiert.
> also....grässlich

Da lobe ich mir die Dokumentation der STM32. Schöne saubere Tabelle, im 
Footprint dann nur die Pinbezeichnungen. Das hier ist ja grausam.

von W.S. (Gast)


Lesenswert?

MCUA schrieb:
> Einzelne Ctr-Signale zu holen und zu routen ist kein Problem.
> Wenn man aber (nur) 16 zusammenhängene Sigale aus 4,5,6 Ports
> herauspicken muss ist das eine Katastrophe!

Route du mal einen 32 bittigen SDRAM und ein TFT-Interface an einen 
LPC4088. Dann sprechen wir uns wieder.

W.S.

von MCUA (Gast)


Lesenswert?

> Dann sprechen wir uns wieder.
Dann kannst du ja vieleicht die Logic hinter dieser PIC..Pin..Belegung 
erklären? Oder sind alle anderen dann doof?
Beim sep. Ansprechen sind zudem auch mehrere Befehle nötig, es müssen 
einzelne Bits isoliert werden. Ein x-facher Aufand!
Also, was für ein Sinn soll es machen einen logisch zusammenhängenden 
8-Bit-Port auf mehrere Ports aufzuteilen?
(auch 5V-toleranz ist durcheinander und nicht beim Bus anwendbar)
(und EMV ist auch viel schlechter)

von P. S. (namnyef)


Lesenswert?

Ich denke schon, dass die kleinen PICs und vielleicht noch die dsPICs 
ihren Platz haben. Die PIC32 hingegen werden es wohl schwer haben gegen 
die ARM Cortex-M. Leider stellt Microchip den an sich guten Chips schon 
fast traditionell miese Tools zur Seite. Auch wenn MPLAB X nicht mehr 
eine ganz so große Katastrophe ist wie MPLAB.

von Christian (Gast)


Lesenswert?

kyrk.5 schrieb:
> Hobbyprojekte? Gibt es da noch jemand der etwas mit PICs macht?

Afug-Info.de hat auf ihrer Homepage ein paar PIC Projekte.
Letztens hat sie auch ein Video gemacht und meinte darin sie könnte sich 
vorstellen, einen Video Programmier Kurs online zu machen, ab Min. 18:19
Ich vermute stark für PICs.

https://www.youtube.com/watch?v=mkth0hOBHCc


Welche Compiler nutzt ihr so?
Gibt es vielleicht einen, mit einer ordentlichen Hilfefunktion?
Ich bin schon so oft auf dem Schlauch gestanden, weil die Befehl 
Beschreibungen nicht brauchbar sind.

von Cyblord -. (cyblord)


Lesenswert?

Christian schrieb:
> Afug-Info.de

War ja klar, wieder mal ewig gestrige Funkamateuere schaffen es nicht 
auf was halbwegs aktuelles.

von Gerhard O. (gerhard_)


Lesenswert?

W.S. schrieb:
> MCUA schrieb:
>> Einzelne Ctr-Signale zu holen und zu routen ist kein Problem.
>> Wenn man aber (nur) 16 zusammenhängene Sigale aus 4,5,6 Ports
>> herauspicken muss ist das eine Katastrophe!
>
> Route du mal einen 32 bittigen SDRAM und ein TFT-Interface an einen
> LPC4088. Dann sprechen wir uns wieder.
>
> W.S.

Der Schein trügt manchmal. Trotz der scheinbar "wahllosen" Anordnung der 
uC Pins ist solch Layout bei einer mehrlagigen LP nicht wirklich 
schwierig. Vor zehn Jahren arbeitete ich an einen SPS Firmenprojekt mit 
dem LPC2476 (TQFP-208) und 3.5" TFT display mit SDRAM and FLASH 
Speicher. Die LP hatte ähnliche Größe wie das 3.5 Zoll Display und hatte 
auch noch eine Ethernetschnittstelle, ZigBee, CAN, RS485, RS232, vier 
Expansionsbusse, Spannungsregler und DS3232 RTC drauf. Das Layout gelang 
auf einer sechslagigen LP und die SPS wird heute noch nach zehn Jahren 
immer noch hergestellt. Es war nicht wirklich so schwierig. Die TFT und 
Speicher Anschlußleitungen sind am Ende geordneter wie man sich 
anfänglich vorstellt. Es kommt halt auch auf optimale Orientierung und 
Anordnung der kritischen ICs an. Jedenfalls hatte ich das Layout 
innerhalb von zwei Wochen manuell in PR99SE fertig. Man darf sich nur 
nicht von der "scheinbaren" Komplexität einschüchtern lassen.

: Bearbeitet durch User
von Christian (Gast)


Lesenswert?

Cyblord -. schrieb:
> War ja klar, wieder mal ewig gestrige Funkamateuere schaffen es nicht
> auf was halbwegs aktuelles.

Och, da ist einer aber neidisch.
Ts ts ts

von W.S. (Gast)


Lesenswert?

Gerhard O. schrieb:
> Vor zehn Jahren arbeitete ich an einen SPS Firmenprojekt mit
> dem LPC2476 (TQFP-208)

Ja, kenne ich, ist weitgehend pinkompatibel zum LPC4088. Habe beide in 
Benutzung.

Und was das Routen betrifft: Ich komme bei der LP mit schlichten 2 Lagen 
aus. Es geht, man muß lediglich ein bissel Gefühl dafür haben.

Aber weiter oben haben wir jemanden, der sich darüber beklagt, daß es 
bei seinem PIC ein wenig ähnlich aussieht wie bei den besagten LPC. Ich 
meine, daß das alles lediglich eine Sache der Übung ist. Wer im Layouten 
zu ungeübt ist, der klagt über zu große Kompliziertheit, wer im 
Programmieren zu ungeübt ist, klagt ebenso, es ist immer die Diskrepanz 
zwischen dem Habenwollen/Machenwollen und dem Können.

Irgend jemand hatte ja mal den Satz geprägt, daß es nicht auf das Wollen 
ankommt, sondern auf das Können, weil Kunst von Können herkommt und 
nicht vom Wollen, sonst hieße sie nämlich Wunst und nicht Kunst.

W.S.

von MCUA (Gast)


Lesenswert?

ich habe nicht gesagt, dass man es nicht routen kann, sondern dass die 
Pinbelegung -auf deutsch- Schwachsinn ist, die nur Nachteile keine 
Vorteile hat.
(routen kann man (wenn man will) alles mögliche, auch auf 2 Lagen (bsp 
Wire 6mil). also brüstet euch nicht damit. es geht nicht darum)
Die gestellten Fragen (ua zu Sinnhaftigkeit (!)) kann deshalb hier auch 
keiner beantworten, auch PIC-Fans nicht.

von W.S. (Gast)


Lesenswert?

MCUA schrieb:
> Die gestellten Fragen (ua zu Sinnhaftigkeit (!))

Vielleicht begreifst du mal, daß es durchaus nicht das Allereinfachste 
ist, all die Funktionalität der verschiedenen Port-Funktionen passend 
hinzukriegen. Wenn dabei dann herauskommt, daß so ein Port eben quer 
über alle vier Seiten verteilt ausgepinnt ist, dann hat das eben den 
Grund, daß dies durch die chipinternen Notwendigkeiten verursacht ist. 
Immerhin ist der "Port", also ein Stück GPIO, ja auch nur ein 
Peripherieteil unter vielen anderen Teilen der Peripherie.

W.S.

von Hobbyist (Gast)


Lesenswert?

Hallo

Gerhard O. schrieb:
> Es widerstrebt mir zuzugeben, daß ich aus purer Bequemlichkeit von PIC
> auf AVR migriert bin. Früher mußte ich für PIC Projekte Leiterplatten
> entwerfen. Heutzutage schnappe ich mir einen NANO oder Pro-Mini und habe
> eine halbe Stunde einfache Projekte am laufen. Ich habe deswegen auch
> schon ein paar ältere Sachen von PIC auf AVR portiert. Schwer zu
> widerstehen! Mit den DsPICs habe ich allerdings in der Firma immer gerne
> gearbeitet. Die machten eigentlich kaum jemals Schwierigkeiten.

Das fasst es ziemlich gut zusammen warum "der" PIC nicht nur gefühlt im 
reinen Hobbyumfeld (bitte das Wörtchen "Hobby" unbedingt zu beachten) 
keine starke Position (mehr?) hat.
Arduino (Clones) - machen es schon von der Hardware her sehr einfach, 
preiswert bis billig (und zwar billig von Geld her) möglich das jeder 
interessierte, der keine (!) berufliche Vorbelastung hat oder (und) 
schon sehr lange - also mindestens seit den "nuller" Jahren,  meist aber 
noch deutlich länger dabei ist, mitmachen kann.
Wer C oder gar den jeweiligen Assembler bis in die Feinheiten beherrscht 
und Quasi seit frühster Jugend - möglichst beginnend in den 70er bis 
90er Jahren diese Sprache und die ehemals noch sehr teure Hardware und 
Software (nicht zu vergessen auch die Lernquellen) das alles 
"aufgesogen" hat, denkt anders und kann und wird anders arbeiten bzw. 
mit Leichtigkeit lustig zwischen allen möglichen µC Welten hin und her 
springen.

Aber die Arduino (Clone)Hardware ist schon eine heftige Konkurrenz - 
wobei Arduino ja schon länger nicht automatisch AVR ist - aber zugegeben 
gerade bei den "typischen" kleinen und "einfachen" praktischen µC 
Lösungen weiterhin dominiert.
Anstatt viel Hardware nimmt man halt einen Pro Mini oder ähnliches für 
irgendwas ab 3 Euro das Stück, passt irgendwo den im Netz vorhandene 
-gut funktionierenden (!) - Code für sich an und flasht das einfach über 
die USB Schnittstelle bzw. einen USB Seriell (TTL) Wandler für unter 4 
Euro (mit Versandkosten von eine deutschen Versender) mittels einer 
kostenlosen und relativ kleinen und leicht zu nutzenden GUI (welche 
dementsprechend natürlich auch ihre Einschränkungen hat - was aber auch 
gleichzeitig für viele eben das große Plus ist weil mehr nur verwirren 
würde).
Wenn man ganz neu anfängt dauert das bei ersten mal vielleicht 1-2 
Stunden, aber schon beim dritten male ist das eine Sache von Minuten 
(Wenn der Sourcecode keinen ärger macht...).

Und weil das alles so einfach geht und vor allem weil man an jeder Ecke 
Informationen beliebiger tiefe und Niveaus bekommt (Ja auch unter der 
Arduino GUI kann man nah an der Hardware und Datenblatt und in "reinen" 
c bzw. C+  programmieren - wenn man es denn kann...) hat sich in 
Bastlerkreisen halt der Arduino und somit halt auch der AVR (Bei den 8 
Bit Typen) durchgesetzt.

Das das im Profibereich wo es um jeden Cent geht, die Platine sowieso 
immer für den jeweiligen Einsatz entwickelt wird, die Entwickler immer 
Profis sind, je nach Gebiet so manche detaillierte bis "kleinliche" 
gesetzlichen Vorgaben beachtet werden müssen (Avionik, 
Medizintechnik,Automotive und sicherlich noch viel mehr) und die 
"einmaligen" Kosten der Entwicklungswerkzeuge keine Rolle - zumindest 
verglichen mit den Lohnkosten der Entwickler- spielen, ganz andere 
Spielregeln gelten ist mir schon klar - aus Langeweile gibt es ja 
bestimmt nicht gefühlt (oder sogar tatsächlich?)immer noch hunderte µC 
Linien und tausende Unterfamilien die teilweise noch aus den 70er Jahren 
stammen, teilweise aber auch topaktuell, und immer wieder neu sind.

Aber im Hobbybereich bei den nicht "Superhardcore" Freaks bzw. denen die 
seit mindestens 20 aber eher schon über 40 Jahren dabei sind hat der PIC 
oder gar was davor mal relativ groß in der Hobbyszene war wirklich sehr 
schwer - da hat der AVR einfach mehr Glück gehabt das er bei Arduino 
genutzt wird und wurde - bzw. ist es sogar mittlerweile immer öfter den 
Hobby Anwender egal was für ein µC nun genau verwendet wird und es zählt 
nur noch die Programmierschnittelle -sowohl von der Hardware- (Board) 
als auch der Softwareseite (GUI) und vor allem die Unterstützung die im 
Netz zu finden ist.

Hobbyist

von MCUA (Gast)


Lesenswert?

1. muss man keinen Port auf 4 IC-Seiten verteilen, das ist Quatsch!
      (andere (auch weitaus bessere CPUs) machen das auch nicht)
2. ist am Bild zu sehen, dass ein logischer 8BitPort (Bsp A0..7, oder 
A8..15) noch nichtmal (!) auf einen physik. 8-Bit-Port (bsp wäre RD0..7) 
aufgeteilt ist (selbst wenn die auf einer Seite liegen würden), sondern 
auf mehrere physik.Ports verteilt ist (!).
Was soll das?

Wenn man nun (nicht über EPMP, aber genau diese Pins müssen benutzt 
werden) bsp.weise 8 Bits vom Register nach A0..7, oder A8..15, 
verschicken will, muss man umständliche Bit-verschiebungen vornehmen und 
dann auch noch bei mehreren physik. Ports entsprechende RMW-Befehle 
durchführen.
Das sind zig ASM-Befehle (!), wo bei ordenlicher Pin-Belegung nur 1..2 
ASM-Befehle nötig wären.
Also, sind jetzt zig nötige ASM-Befehle besser als nur 1..2?
Das zeigt dass schon deshalb die Belegung Schwachsinn ist.

Bsp Aufteilung vom o.g. PIC24:
PMD0..7:   RE0..7 (das wäre ok)
PMD8..15:  RG0..1, RF1..0, RD12..13, RD6..7
PMA0..7:   RB15..14, RG9..6, RA10..9

von Andi B. (andi_b2)


Lesenswert?

Der Großteil der PIC wird aber nicht dort eingesetzt wo man unbedingt 
breite Parallelports braucht, sondern eben als Mikrocontroller der 
hauptsächlich mit den internen Ressourcen die gestellte Aufgabe erfüllt. 
Also was soll das Gejammere um die Pinanordnung? Und bei viele PICs 
lassen sich Pins auch variabel umkonfigurieren. Aber wer z.B. unbedingt 
an einem PIC24 ein 24 Bit TFT Anschließen will oder ein SRAM, hat 
natürlich Probleme. Der PIC ist da aber IMO das kleinste davon.

Also nur weil einmal ein bestimmter PIC für eine Aufgabe nicht passend 
war, sind nicht alle unbrauchbar. Man sollte halt den passenden 
Controller zur Aufgabe aussuchen. Und sind bei verschiedenen Projekten 
durchaus verschiedenste uCs.

von Jens M. (schuchkleisser)


Lesenswert?

MCUA schrieb:
> Wenn man nun (nicht über EPMP, aber genau diese Pins müssen benutzt
> werden) bsp.weise 8 Bits vom Register nach A0..7, oder A8..15,
> verschicken will, muss man umständliche Bit-verschiebungen vornehmen und
> dann auch noch bei mehreren physik. Ports entsprechende RMW-Befehle
> durchführen.

Ich habe vor vielen Jahren mal einen PIC mit ecternem Speicher benutzt, 
der auch einen Port dazu hatte, der über viele Pins verteilt war.
Da war es aber so, das es Register gab, die Byteweise gefüllt wurden und 
passend an den verschiedenen Ports rauskamen.
D.h. das angemeckerte bitweise Ansprechen der Ports hätte man nur, wenn 
man die Hardware so verdrahtet, die Ports aber als GPIO nutzt und das 
Hardwareinterface selbst in der Firmware emuliert.

Ich hab mir das bei deinem Chip nicht angesehen, aber ich denke, das es 
da ebenso ist, wäre ja auch Quatsch.
Das ändert nix an der schrägen verteilung über die Pins des Gehäuses, 
die ist in der Software aber unsichtbar.

(D)Ein Problem hättest du nur, wenn du die Restpins auch gern noch als 
8-bit-Port verwendet hättest, weil da eben keiner mehr komplett über 
ist.

von MCUA (Gast)


Lesenswert?

> die ist in der Software aber unsichtbar.
Nein ist es nicht.
Les mein Post.
Das Problem besteht, wenn man den EPMP (das alleine wäre progr.techn 
gesehen ok, funkt. ja wie typ XMEM-Interface) verwenden will UND auch 
(auf gleicher Platine , quasi als zusätzlichen Modus) diese je 8 
Bit-Ports des EPMP (bsp A0..7, A8..15) separat, mit einzelnen ASM 
-Befehlen ansteuern will (wofür der EPMP nicht genommen werden kann, 
eben weil typ. XMEM-Interface), dann sind wegen der Portaufteilung zig 
ASM-Befehle (!) nötig.
Bei sinnreicher Pin-Belegung wäre das Problem überhaupt nicht vorhanden!
(andere Möglichkeit wäre Multiplexer dahinter zu schalten, was aber 
weiterer Hardware-Aufwand ist, zudem die Laufzeit verlängert)

von Jens M. (schuchkleisser)


Lesenswert?

Achso, ein selbstgeschaffenes Problem.
Tja, das ist natürlich schlimm.

von asdf (Gast)


Lesenswert?

Hobbyist schrieb:
> Arduino (Clones) - machen es schon von der Hardware her sehr einfach,
> preiswert bis billig (und zwar billig von Geld her) möglich das jeder
> interessierte, der keine (!) berufliche Vorbelastung hat oder (und)
> schon sehr lange - also mindestens seit den "nuller" Jahren,  meist aber
> noch deutlich länger dabei ist, mitmachen kann.
> Wer C oder gar den jeweiligen Assembler bis in die Feinheiten beherrscht
> und Quasi seit frühster Jugend - möglichst beginnend in den 70er bis
> 90er Jahren diese Sprache und die ehemals noch sehr teure Hardware und
> Software (nicht zu vergessen auch die Lernquellen) das alles
> "aufgesogen" hat, denkt anders und kann und wird anders arbeiten bzw.
> mit Leichtigkeit lustig zwischen allen möglichen µC Welten hin und her
> springen.

Ich kann dir nur vollstens zustimmen.

Und möchte noch ergänzen, dass es leider so ist, dass jeder alles haben 
und machen will, aber keiner mehr was lernen will.
Deshalb erfreut sich Arduino der Beliebtheit und der PIC, bei dem was 
gelernt haben muss, wird beschimpft.

von MCUA (Gast)


Lesenswert?

> Achso, ein selbstgeschaffenes Problem.
Nö, das hat MCH geschaffen.

von asdf (Gast)


Lesenswert?

Wer programmieren kann, dem wird es egal sein, ob er mit PIC oder Atmel 
oder ARM arbeitet.

Wer nicht programmieren kann, wird sich an Arduino klammern müssen.

von Cyblord -. (cyblord)


Lesenswert?

asdf schrieb:
> Wer programmieren kann, dem wird es egal sein, ob er mit PIC oder Atmel
> oder ARM arbeitet.

Naja ich programmiere beruflich so ziemlich von A-Z, also vom AVR über 
STM32 bis zu ARM9, Sitara usw. Aber PIC würde ich wenn irgendwie möglich 
zu vermeiden suchen.

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.