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.
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.
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.
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.
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.
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.
> 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.
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!
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
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
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....
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.
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.
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
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
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...
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ß.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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 :)
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.
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 ;)
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.
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.
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?
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.
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.
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 ;)
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.
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.
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.
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.
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.
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.
>>>> 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.
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
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.
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.
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.
Soul E. schrieb:> Ein 68000 mit seiner symmetrischen Architektur wurde direkt für> C-Compiler optimiert.
Du meinst: "orthogonalen Befehlssatz", nicht "symmetrische
Architektur"...
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.
> 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)
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.
> 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)?
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.
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.
> 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)
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.
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.
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.
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
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.
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.
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.
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
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
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.
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.
> 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)
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.
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.
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.
