Hallo Habe hier mal ein Board gemacht das für PIC Mikrokontroller ist. Das soll sich in erster Linie an Anfänger richten, die gerade mit der Programmierung anfangen, deshalb ist auch nichts in SMD gemacht worden. So kann man es auch selber löten. Das Board ist auch noch in einem anderen Forum eingestellt. Vielleicht findet ja auch noch hier jemand Fehler im Schaltplan und auf dem Board, bevor ich es mal fertigen lasse. Ich danke euch. Peter.
Peter schrieb: > Habe hier mal ein Board gemacht das für PIC Mikrokontroller > ist. Es ist offenbar nur für den PIC18F45K50 gemacht (soweit man das aus den geposteten Bildern ersehen kann). Und es ist - in Relation zum PIC - auch extrem umfänglich. Es paßt vermutlich auch nicht in ein übliches Gehäuse als Frontplatte mit ergonomisch angeordneten Bedienelementen hinein. Peter schrieb: > Das soll sich in erster Linie an Anfänger richten, > die gerade mit der Programmierung anfangen Meinst du das wirklich? ich habe da so meine Bedenken, daß es gerade dafür nicht wirklich gut ist. Was soll ein Anfänger damit lernen? Etwa C-Programmierung? Die lernt man direkt am PC leichter. Oder PIC-Assembler-Programmierung? Dafür wären eher die kleinen älteren PIC16F geeignet. Oder wie man so einen PIC in einer eigenen Schaltung benutzt, um damit etwas zu machen, an das du beim Entwerfen deiner LP noch garnicht gedacht hattest (wie auch, du kannst ja nicht die Gedanken lesen, die jemand anderes künftig mal haben wird)? Dafür wäre ein Minimalboard eher geeignet, was außer dem PIC nur noch Spannungsregler, Quarz, Reset und Programmierport enthält. Und SMD ist heutzutage das Übliche. Ich teile deine Ansicht über SMD versus THT nicht. Und SMD in 1206 sind für wenig Geld bei Ali zu haben und diese eignen sich selbst für Grobmotoriker und Programmierer mit 3 linken Händen. Ich will dich nicht von deinem Projekt abhalten, aber mache es lieber nur in Rücksicht auf deine eigenen Wünsche, nicht aber mit der Idee, daß es für einen von dir angedachten Anfänger zum Lernen der Grundlagen gut geeignet sei. W.S.
W.S. schrieb: > Es ist offenbar nur für den PIC18F45K50 gemacht Bei den PICs kann man fast jeden PIC18 und evtl. auch PIC16 im gleichen Gehäuse (hier DIP40) ohne große Änderungen einfach tauschen. Abgesehen von den jeweiligen Spezialitäten (hier USB) sind die pinkompatibel. Beim Controller selbst finde ich es darum gar nicht so übel, auf einem solchen Board kein SMD Gehäuse zu verwenden.
Peter schrieb: > eshalb ist > auch nichts in SMD gemacht worden. So kann man es auch selber also bis 0402 kann man eigl. alles selber löten. LG
Arno K. schrieb: > also bis 0402 kann man eigl. alles selber löten. Wenn du mindestens 8 Stunden am Tag 0402er Grabsteine entfernst mag das stimmen. Für einen Anfänger mit wenig bis gar keiner Löterfahrung ist schon 0805 eine Herausforderung.
Der Schaltplan ist schon für Profis eine Zumutung. Da möchte ich nicht wissen, wie Anfänger den verstehen sollen. Da fehlt jede Nachvollziehbarkeit. Wer hat den denn verbrochen? Es gibt dafür Normen.
Der Schaltplan ist von mir. Was verstehst du denn daran ist ? Was ist nicht Nachvollziehbar ? Ein Anfänger beschäftigt sich mit dem Board und der Programmierung und nicht mit dem Schaltplan. Wie üblich kann der Prozessor mit jeder Sprache programmiert werden. und kein Anfänger programmiert nur auf dem PC ohne Controller. Kein Anfänger der gerade mal weis wo ein Lötkolben heiß wird, wird mit SMD anfangen. Deshalb keine SMD Bauteile auf dem Board.
Und wo kann man es bestellen? Was soll es kosten? Du solltest unbedingt noch Fassungen für 28 und 20 pol. vorsehen. Ich würde keine 40 beinigen Koffer mehr kaufen wenn es schon THT ist.
So nun mal eingelogt. Wollte eigentlich den Beitrag unter meinem Account schreiben aber irgendwie ging es nicht. Zuerst müßen mal alle Fehler raus, dann kann ich sie fertigen lassen. Der Preis der leeren Platine hängt natürlich von der Menge ab, die ich herstellen lasse. Bei kleinen Mengen, wird der Preis pro Platine ca.5€ plus Porto betragen. Wer interesse hat, kann sich ja schon mal melden, dann kann ich auch einen genauen Endpreis sagen, wenn ich dann bestelle. Einen kleineren Prozessor bringt nicht viel, da es dann schwierig wird die ganze Hardware was auf dem Board ist, unter zu bringen. Ausserdem gibt es nicht viele Prozessoren die USB unterstützen und bei einem deutschen Händler zu bekommen sind. Peter.
:
Bearbeitet durch User
> Einen kleineren Prozessor bringt nicht viel, da es dann > schwierig wird die ganze Hardware was auf dem Board ist, > unter zu bringen. Richtige Evalboards führen die Pins auf Stiftleisten die dann mit Jumpern wiederum auf Stiftleisten die Peripherie anbinden. Eigentlich eher andersrum. Nicht jeder will das schon alle IO zugeschaufelt sind. USB interessiert mich da auch nur sehr sekundär. > mal melden [x] Aber nur wenn ich da auch 28 pol. (z.B. den 2550/886) und 20 pol. (1508/9) versenken kann.
Peter schrieb: > Der Schaltplan ist von mir. Was verstehst > du denn daran ist ? Was ist nicht Nachvollziehbar ? Dein Stromlaufplan ist tatsächlich Mist. Sowas machen Chinesen und Amis gern, aber die sind kein Maßstab. Plaziere deine Symbole so auf der Seite, daß du tatsächlich alle Verbindungen mit Netzlinien ausführst. Das gilt auch für Busse, die du entsprechend mit Namen versiehst. Ebenso plaziere Labels auf alle Busanbindungen. Einfach nur die Fläche mit Puzzle-Stücken zu füllen, ist noch lange kein Stromlaufplan. > Ein Anfänger beschäftigt sich mit dem Board und der > Programmierung und nicht mit dem Schaltplan. Genau das sind deine Annahmen über "DEN" Anfänger. Erstens sind sie falsch und zweitens frage ich dich, woher du die Gewißheit denn hast, daß "Ein Anfänger" sich nicht mit der Schaltung befaßt. W.S.
Man hätte sie anders plazieren sollen, dann wäre es lesbarer gewesen. Und die Busse teilweise miteinander verbinden sollen. Dann wäre der zusammenhang besser zu erkennen. Aber beschriftet sind doch die Leiterbahnen auf dem Bus eindeutig. Wenn da RB0 dran steht dann geht die Leitung über den Bus an den Controller zu RB0. Es ist nicht vorgesehen einen Controller mit weniger Pins als 40polig ein zu bauen. Das würde eine Unmenge an Jumper zusätzlich auf dem Board bedeuten. Dies wird für einen Anfänger zu unübersichtlich. Alle Ports sind nach drausen geführt und die Hardware wird über Jumper oder Dip-Schalter zugeschaltet. Die USB-Schnittstelle wird hier zur programmierung benötigt. Mit Hilfe des Bootloaders wird kein Brenner benötigt und der Anfänger braucht sich nur aus dem Netz den Compiler runter zu laden und kann sofort beginnen.
Peter K. schrieb: > Aber beschriftet sind doch die Leiterbahnen > auf dem Bus eindeutig. Lüg nicht. Am PIC hast du überhaupt kein Netz beschriftet. Und am Display hast du die Netze - naja sagen wir mal - extrem unkonventionell gewählt: RS mit RB4, R/W mit GND, LED+ mit LCD und so weiter. Und GND ist offenbar Member eines Busses. Nein, dein Stromlaufplan ist eher ein halbgrafisches Text-Adventure. W.S.
An dem Controller sind doch die Beschriftungen dran. Warum sollte ich da nochmal den Bus beschriften ? Am Display sind auch Beschriftungen dran, wie RS und der Bus der da dran geht ist beschriftet mit der Bezeichnung RB4, so sieht man doch direkt wo RS hin geht und man braucht nicht weiter im Schaltplan zu suchen. Was macht das für einen Sinn wenn ich den RS vom Display auf dem Bus mit RS beschrifte und man muß nun suchen wo RS hin geht. Genauso R/W. Auf dem Bus steht dran wo das Signal hin geht. So ist doch die Beschriftung wie ich sie habe viel eindeutiger als was du da erzählst. Gut LED+ kann man so lassen und nicht umbenennen. Das stimmt schon.
Peter K. schrieb: > Auf dem Bus steht dran wo das > Signal hin geht. Ne, da steht nur, zu welchem Signal (Label) die Leitung gehört. Wieviele weiteren Leitungen am gleichen Signal angeschlossen sind und sich auf dem Board verbergen, sieht man nicht und man muss Suchen wie Blöde. Also ist der Schaltplan einfach unübersichtlich. Damit wird die Nutzung eines Busses mit Label nicht Normgerecht genutzt. Du wurdest jetzt von verschiedenen Usern darauf aufmerksam gemacht, das der Plan so einfach nicht zu lesen ist. Mach es besser oder bleibe Belehrungsresistent fern von diesem Forum. Erwarte sonst, dass du hier keine weitere Hilfe bekommst oder die Trolle deinen Beitrag in den Verriss nehmen.
Das der Schaltplan so schwer zu lesen ist, habe ich ja schon vor ein paar Posts eingesehen und auch gesagt das man den umzeichnen muß und das das Bussystem besser verlegt werden muß damit man die Zusammenhänge besser sieht. Die eigentliche Frage war ja ob noch Fehler im Schaltplan sind. Das mit der unübersichtlichkeit muß noch geändert werden. Aber sind sonst noch Fehler drin ausser die des Aussehens ?
Peter K. schrieb: > Aber sind sonst noch Fehler drin ausser die des Aussehens ? Ja, im Konzept: Wieso sollte man einem Anfänger in 2019 noch empfehlen sich mit PICs zu beschäftigen? PICs haben nette Peripherie, aber eine ziemlich ungünstige Architektur für Hochsprachen. Daher gibt es nur wenige, spezialisierte Compiler dafür. Eigentlich sind die dafür konzipiert in Assembler programmiert zu werden. Das ist doch eine ziemliche Sackgasse und sollte man einem Anfänger nicht zumuten. Ich würde für Anfänger eher AVRs empfehlen, da gibt es mit Arduino einen riesigen Haufen von Bibliotheken, Einführungs-Dokumentationen, Hilfe in Foren etc. Auch ist die Architektur wesentlich besser für Compiler geeignet, daher gibt es z.B. den avr-gcc. Wenn man dann als Anfänger die allerersten Schritte hinter sich gelassen hat, kann man sich dann die verschiedenen Cortex-M-Familien von den entsprechenden Anbietern anschauen. Alternativ gleich von Anfang an Cortex-M mit einem Framework wie z.B. mbed.
Warum soll das eine Sackgasse sein das ist doch Blödsinn. Es gibt immer Anfänger die sich mit PICs beschäftigen und dafür ist das Board gedacht. Programmiert werden kann der PIC wie auch andere Controller in der Sprache die man sich ausgesucht hat. Wie auf dem Board zu sehen ist, hat es eine Mikro-Bus Schnittstelle. Über diese gibt es einiges im Netz an Hardware die darauf läuft. Aber das hier soll keine Diskussion über PIC und andere Controller werden. Davon ist das Forum hier voll.
Gerd E. schrieb: > Wieso sollte man einem Anfänger in 2019 noch empfehlen sich mit PICs zu > beschäftigen? > > PICs haben nette Peripherie, aber eine ziemlich ungünstige Architektur > für Hochsprachen Jein. Ab PIC24 bzw. dsPIC aufwärts gehts dann wieder. Aber alles bis PIC18 kann man nur ausgewiesenen Masochisten anbieten. Davon scheint es erstaunlich viele zu geben.
Axel S. schrieb: >> PICs haben nette Peripherie, aber eine ziemlich ungünstige Architektur >> für Hochsprachen > > Jein. Ab PIC24 bzw. dsPIC aufwärts gehts dann wieder. Aber dennoch ist die Auswahl an Compilern auch bei denen extrem eng. Gibt es da einen, der z.B. einigermaßen aktuelles C++ kann? Also z.B. C++14 oder C++17? Wie sieht es aus mit aktuellem C? Gibt es da welche, die nicht bei grad bei C89 stecken geblieben sind? > Aber alles bis > PIC18 kann man nur ausgewiesenen Masochisten anbieten. Davon scheint es > erstaunlich viele zu geben. Der TO scheint genau diese PIC18er für Anfänger zu empfehlen. Ich kann das nicht nachvollziehen.
Warum soll man denn nicht mit einem PIC18er anfangen ? Den kann man genauso gut z.B in C, programmieren wie eine andere PIC Familie.
:
Bearbeitet durch User
Habe mal den usbasp vom AVR auf einen PIC16F transformiert. Ging fast zu einfach, dank C und mcc. Musste die soft-spi rausnehmen; der PIC kann auch das in HW. Total wiederlich diese Geschwindigkeit. Bloß 12800 Bytes/s. Dann doch lieber Zeit verschwenden und mit dem AVR-usbasp und ca. 2 kBytes/s vorlieb nehmen.
1 | $ avrdude -p m328p -c usbasp -P usb -v -U flash:w:dummy32k -B 0.5 |
2 | |
3 | avrdude: Version 6.3, compiled on May 8 2019 at 19:46:05 |
4 | Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ |
5 | Copyright (c) 2007-2014 Joerg Wunsch |
6 | |
7 | System wide configuration file is "/etc/avrdude.conf" |
8 | User configuration file is "/home/surfer/.avrduderc" |
9 | User configuration file does not exist or is not a regular file, skipping |
10 | |
11 | Using Port : usb |
12 | Using Programmer : usbasp |
13 | Setting bit clk period : 0.5 |
14 | AVR Part : ATmega328P |
15 | Chip Erase delay : 9000 us |
16 | PAGEL : PD7 |
17 | BS2 : PC2 |
18 | RESET disposition : dedicated |
19 | RETRY pulse : SCK |
20 | serial program mode : yes |
21 | parallel program mode : yes |
22 | Timeout : 200 |
23 | StabDelay : 100 |
24 | CmdexeDelay : 25 |
25 | SyncLoops : 32 |
26 | ByteDelay : 0 |
27 | PollIndex : 3 |
28 | PollValue : 0x53 |
29 | Memory Detail : |
30 | |
31 | Block Poll Page Polled |
32 | Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack |
33 | ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- |
34 | eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff |
35 | flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff |
36 | lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 |
37 | hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 |
38 | efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 |
39 | lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 |
40 | calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00 |
41 | signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00 |
42 | |
43 | Programmer Type : usbasp |
44 | Description : USBasp, http://www.fischl.de/usbasp/ |
45 | |
46 | avrdude: set SCK frequency to 1500000 Hz |
47 | avrdude: AVR device initialized and ready to accept instructions |
48 | |
49 | Reading | ################################################## | 100% 0.00s |
50 | |
51 | avrdude: Device signature = 0x1e950f (probably m328p) |
52 | avrdude: safemode: hfuse reads as D9 |
53 | avrdude: safemode: efuse reads as FD |
54 | avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed |
55 | To disable this feature, specify the -D option. |
56 | avrdude: erasing chip |
57 | avrdude: set SCK frequency to 1500000 Hz |
58 | avrdude: reading input file "dummy32k" |
59 | avrdude: input file dummy32k auto detected as raw binary |
60 | avrdude: writing flash (32768 bytes): |
61 | |
62 | Writing | ################################################## | 100% 2.56s |
63 | |
64 | avrdude: 32768 bytes of flash written |
65 | avrdude: verifying flash memory against dummy32k: |
66 | avrdude: load data flash data from input file dummy32k: |
67 | avrdude: input file dummy32k auto detected as raw binary |
68 | avrdude: input file dummy32k contains 32768 bytes |
69 | avrdude: reading on-chip flash data: |
70 | |
71 | Reading | ################################################## | 100% 1.60s |
72 | |
73 | avrdude: verifying ... |
74 | avrdude: 32768 bytes of flash verified |
75 | |
76 | avrdude: safemode: hfuse reads as D9 |
77 | avrdude: safemode: efuse reads as FD |
78 | avrdude: safemode: Fuses OK (E:FD, H:D9, L:E7) |
79 | |
80 | avrdude done. Thank you. |
> Total wiederlich diese Geschwindigkeit. Ja wenn du meinst. Einen AVR brogrammiere ich nur alle droellfzig Wochen einmal. Meine Lieblingscontroller booten im allg. von einem SPI-Flash. Aber wenn mein starker Arm es will, auch mal direkt von einer SD-Card. Da ist mir das mit der Geschwindigkeit eigentlich Wurscht. Die kleinen PICklinge sind mir an einem PICKIT2 aber auch noch nicht unangenehm aufgefallen. Vermutlich weil so klein und so winzig sind. Bei 2 kbyte/s muss aber was an deinem USBASP kaputt sein.
Peter K. schrieb: > Die eigentliche Frage war ja ob noch Fehler im Schaltplan > sind. Die kannst du bekommen, allerdings ohne Garantie auf Vollständigkeit. Dein Relais X1 braucht noch eine Freilaufdiode. Weil das wohl eine SDS-Relais ist, reicht eine 1N4148 o.ä. wohl aus. Die Leuchtdioden sind nicht benannt. So kann man die Vorwiderstände die wohl auch zu hoch bewertet sind, nicht kontrollieren. Einige Widerstände (z.B. fürs Display) haben auch keine Werte. Wenn die 470R haben wie bei DP, werden die wohl zu hoch sein. Man rechnet: R=(Ub-Ud)/IF. Bei Multiplexbetrieb muss der Wert noch weiter runter. Die Formel fällt mir im Moment dafür nicht ein. Der µC braucht für den Rest einen Kondensator (ca. 100nF). Dann bekommt der Chip nach dem Einschalten automatischen einen Reset und muss sich nicht wundern, das die Kiste nicht läuft, wenn man mal vergisst die Taste zu drücken. Die Schaltung D16/17 wird so kaum funktionieren, wenn die Sicherung auslöst. Zum einen müsste auf dem Board ein Permanetkurzschluss sein und zum anderen der Vorwiderstand von R16 richtig dimensioniert sein, das ausreichend IF-Strom durch die LED fliest. D17 wird gar nicht funktionieren, weil die Spannung sich ja nicht umpolt wie bei Wechselspannung. Ein Sicherungsdetektor muss schon etwas cleverer konstruiert sein damit der Wunschgemäß funktioniert. Die vielen GND am Display die auf D0-4 beschaltet sind verwirren mich. (Hier wäre das übliche simple Massezeichen ausssagekräftiger). Jedenfalls wird das Display da einiges nicht anzeigen. Die Widerstandsnetzwerke scheinen mir etwas hochohmig. 10k reichen auch. Je hochohmiger um so anfälliger für EMV. Funktionieren würde es aber auch mit 100k. Ansonsten scheint die Schaltung stimmig zu sein, aber wie schon gesagt, ohne Gewähr.
Peter schrieb: > Habe hier mal ein Board gemacht das für PIC Mikrokontroller > ist. Das soll sich in erster Linie an Anfänger richten, > die gerade mit der Programmierung anfangen, deshalb ist > auch nichts in SMD gemacht worden. Sorry, aber was hat SMD mit Programmierung zu tun? Dein Ansinnen ist löblich, aber von vornherein zum Scheitern verurteilt. Es wird eins der tausend vergeblich konstruierten Anfängerboards, die im Netz vor sich hin schmoren. Guck allein mal bei Oshpark, was da so an Breakout-Boards zu finden ist. Du hast erfolgreich den Start gemeistert, aber jetzt denkst Du, genügend Knowhow zu haben, um Anfänger didaktisch an die Hand zu nehmen? Sei mir nicht böse, aber das nennt man Dunning-Kruger-Syndrom. Wichtiger als irgendwelche Boards, die auch noch selbst zu bauen sind mit allen Problemen, (Beschaffung, richtige Bestückung, Löten, Messen, Inbetriebnahme, usw.) wären vollständige, gut bebilderte und didaktisch strukturierte Howtos, die an einem billig und überall zu bekommenden sowie gut erweiterbaren Breakout-Board den Einstieg lehren. Sowas gibt es selten im Netz, viele fangen sowas an, aber vollendet wird nur wenig. Zum PIC gibt es zudem sprut.de, das zu toppen ist schwierig.
Also die LEDs sind 3mm standart LEDs. Die haben 560 Ohm Widerstand das sollte eigentlich hell genug sein, werde es aber nochmal überprüfen. Welche Widerstände meinst du für das Display ? R32 und R33 ? Die sind aber eigentlich nicht zu hoch damit läuft das Display ganz gut ohne Fehler. D16 soll auch nur anzeigen wenn eine Überlast aufgetreten ist. Bei über 0,5A löst die Sicherung aus und soll so das USB Netzteil schützen. Um einen Kurzschluß zu vermeiden nimmt man eine Glassicherung die reagiert viel schneller als eine Polyfuse Sicherung. D17 soll anzeigen das die Spannung verpolt angeschlossen ist. Ja ich hätte auch am LCD das Masse Symbol nehmen können, aber sonst sollte das Display laufen, ist ja eine standart Beschaltung. Einen Kondensator an Reset wird auch noch rein gemacht. Zuerst mal Danke und werde mich mal um die Fehler kümmern.
Peter K. schrieb: > standart Google mal die korrekte Schreibweise, sonst machst du dich nur lächerlich, sofern das nicht schon passiert ist. Peter K. schrieb: > Also die LEDs sind 3mm standart LEDs. Da gibt es keinen Standard. Es gibt Leds die sich in Kategorien einordnen lassen. Manche brauchen 20-30mA und andere kommen mit 5mA aus, um Hell zu leuchten. Bei gemultiplexten Anzeigen sieht es wieder anders aus. Auch die Art, z.B. Charlieplexing, hat da Einfluss auf die Lesbarkeit. > Die haben 560 Ohm Widerstand das sollte eigentlich > hell genug sein, werde es aber nochmal überprüfen. "Sollte" oder "ist"? Entweder betreibt man einige LEDs mit 1,5V oder mit 3 Volt. 5V - 1,5V/ 20mA = 175 Ohm. Man kann mit den Werten aber ein bisschen rum spielen, z.B. 5mA, 10mA, 15mA...usw. Typen angeben, Grundsätzlich und Datenblatt studieren. Grenzwerte beachten.
Also die Leds können max. 20mA. Bei 560 Ohm sind sie hell genug. Selbst 1KOhm würde noch gehen. Das jeweils bei 5V und 3V getestet.
Gerd E. schrieb: > Axel S. schrieb: >>> PICs haben nette Peripherie, aber eine ziemlich ungünstige Architektur >>> für Hochsprachen >> >> Jein. Ab PIC24 bzw. dsPIC aufwärts gehts dann wieder. > > Aber dennoch ist die Auswahl an Compilern auch bei denen extrem eng. OK. Aber das ist dann keine "ungünstige Architektur für Hochsprachen", sondern (Preis)Politik des Herstellers. > Gibt es da einen, der z.B. einigermaßen aktuelles C++ kann? Also z.B. > C++14 oder C++17? Basiert beides auf gcc. Keine Ahnung, wieviel Aufwand MCP da in ihre Ports steckt bzw. wieviel Aufwand jeweils überhaupt nötig ist. Bei PIC32 (vulgo: MIPS) dürfte der Codegenerator praktisch unverändert sein. Ich sehe keinen Hinderungsgrund, warum der gcc für PIC32 nicht den aktuellen gcc Stand und damit C/C++ Standard unterstützen können sollte. Obwohl ich MCP natürlich absolut zutraue, das entweder gezielt zu sabotieren oder einfach nur zu verbocken. Bei deren track record ... >> Aber alles bis >> PIC18 kann man nur ausgewiesenen Masochisten anbieten. >> Davon scheint es erstaunlich viele zu geben. > > Der TO scheint genau diese PIC18er für Anfänger zu empfehlen. Ich kann > das nicht nachvollziehen. Dito. Peter K. schrieb: > Warum soll man denn nicht mit einem PIC18er > anfangen ? Den kann man genauso gut z.B in C, programmieren > wie eine andere PIC Familie. Genauer gesagt kann (besser: will) man PIC18 (und kleiner) nur in C programmieren. PIC12/16/18 Assembler verursacht Krebs. Oder schlimmeres. Und der Vergleich mit "eine andere PIC Familie" assoziiert Vergleiche zwischen Pest und Cholera. "Nehmen Sie Pest, das ist ohne Durchfall". DANKE. Aber NEIN, Danke.
Axel S. schrieb: > Genauer gesagt kann (besser: will) man PIC18 (und kleiner) nur in C > programmieren. PIC12/16/18 Assembler verursacht Krebs. Oder schlimmeres. Ähem... ersetze mal 'man' mit 'ich'. Die PIC16 wurden für die Programmierung in Assembler entwickelt. Und da ist deren Architektur ziemlich charmant. Das Einzige, was man als Programmierer ein wenig vermißt, ist die Addition mit Carry. Kurzum, deine Ansicht spiegelt die Befindlichkeit derer wider, die (aus was für Gründen auch immer) eine Aversion gegen Assembler-Programmierung haben. Das ist alles, was dazu zu sagen ist. Ich sagte ja schon, daß man am PC das Programmieren in C weitaus besser lernen kann als wenn man dafür einen µC im Allgemeinen bzw. einen PIC im Besonderen zu verwenden gedenkt. Und wer das Programmieren eines PIC's ins Auge faßt, der sollte sich zuvörderst mit Schaltung und Hardware und der Peripherie der PIC's vertraut machen und anschließend zumindest für die kleinen PIC's sich in Assembler üben. Und wer das ablehnt, sollte sich anderen Chips zuwenden. W.S.
W.S. schrieb: > wer das Programmieren eines PIC's ins Auge faßt ... > in Assembler ... sollte sich anderen Chips zuwenden. Ich hab es mal auf das wesentliche verkürzt. Was deine Behauptung angeht, ich hätte eine Aversion gegen Assembler ... das mußt du halluzinieren. Allein hier im Forum finden sich genügend Gegenbeweise. Trotzdem wünsche ich auch dir Frohe Weihnachten!
W.S. schrieb: > was man als > Programmierer ein wenig vermißt, ist die Addition mit Carry. Die "Enhanced Mid-Range Devices" PIC16F1... haben die Addition mit Carry "ADDWFC f, d". Wer noch die anderen PIC16F benutzt ist selbst schuld.
Peter K. schrieb: > Bei 560 Ohm sind sie hell genug. Selbst 1KOhm > würde noch gehen. Das jeweils bei 5V und 3V getestet. Unwahrscheinlich, dann fließen nur ca.6 bzw. 3,5mA. Das reicht für gewöhnlich bei 20mA-Typen nicht. Die fangen nämlich erst so ab 10mA schwach an zu leuchten. Dann müssen das 5mA-Typen sein. Wie hoch ist denn der Spannungsabfall am 560 bzw. 1kOhm-Widerstand? Typenbezeichnung der LEDs bitte, keine Fantasien. Wenn man keine Typen reproduzierbar auswählt, kann man mit anderen LEDs (Ersatztyp) Probleme bekommen wenn eine gekaufte Charge verbraucht ist und nicht wieder beschafft werden kann.
Die sind hell genug. Sogar bei Tageslicht. Spannungsabfall ist ca.3V am Widerstand. Hier nochmal das Datenblatt: https://www.reichelt.de/led-3-mm-bedrahtet-gruen-32-mcd-60-led-3mm-st-gn-p6829.html?&trstct=pos_0
Axel S. schrieb: > Was deine Behauptung angeht, ich hätte eine Aversion gegen Assembler ... > das mußt du halluzinieren. Nö. Ich zitiere dich mal in deiner eigenen auf's Wesentliche reduzierten Art: "Genauer gesagt kann/will ich PIC18 (und kleiner) nur in C programmieren." Siehste. Ingo schrieb: > Die "Enhanced Mid-Range Devices" PIC16F1... haben die Addition mit Carry Ja, ja, ist bekannt. Aber die gab's in den 90er Jahren noch gar nicht. W.S.
Bitte 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.