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.
Teddy schrieb: > Microchip hat Atmel einverleibt. Ja sie leben noch! Es geht nicht um Microchip sondern um PICs
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.
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 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
"Der Chip läuft intern mit bis zu 100 MHz." Werden DSP-Befehle in einem Takt ausgeführt?
Beitrag #6306441 wurde von einem Moderator gelöscht.
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....
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
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ß.
Beitrag #6308219 wurde von einem Moderator gelöscht.
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.
Beitrag #6308657 wurde von einem Moderator gelöscht.
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?
Beitrag #6308832 wurde von einem Moderator gelöscht.
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.
:
Bearbeitet durch User
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.
Beitrag #6314492 wurde von einem Moderator gelöscht.
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
Beitrag #6315056 wurde von einem Moderator gelöscht.
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.
> Coca-Cola, Pepsi oder Fritz Cola
An einem heissen Sommertag geht doch nix über eine eiskalte Pubsicola!
Natürlich aus einer Glasflasche.
> 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)?
Angehängte Dateien:
-
PIC24FJ128GA310_S005.jpg
350 KB
Hier ein Bild der Pinbelegung mit Markierungen. EPMP grün markiert. also....grässlich
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.
Christian schrieb: > Afug-Info.de War ja klar, wieder mal ewig gestrige Funkamateuere schaffen es nicht auf was halbwegs aktuelles.
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
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.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.