Forum: Mikrocontroller und Digitale Elektronik Assembler-Programmieren PIC16F1934/6/7


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


Bewertung
0 lesenswert
nicht lesenswert
Bisher habe ich für den PIC16F873A erfolgreich in Assembler 
programmiert.
Eventuell möchte ich auf den PIC16F1934/6/7 umsteigen. Das Datenblatt 
zeigt mir, dass die Programmierung sich doch deutlich von der für den 
PIC16F873A unterscheidet. Wo kann ich Hilfe finden? Ich habe aber nicht 
die Absicht, in C zu programmieren. (Ich bin Jahrgang 1930).
Besten Dank im Voraus!
DIKOMOE

von Michael_O (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Die neuen Config Word Daten finden sich im Netz und der Assembler sagt 
Dir schon was er nicht mehr mag. Der Rest steht im Datenblatt. Mein vor 
10 Jahren gemachten Assemblerprogramme brauchen bis zu 5 Stunden um auf 
neueren PICs zu laufen. Der Unterschied zum 18F ist grösser.

mfg
Michael

von Werner H. (pic16)


Bewertung
0 lesenswert
nicht lesenswert
Dieter K. schrieb:
> Ich bin Jahrgang 1930

Das sind ca 87 Jährchen! Damit bist du als Assemblerprogrammierer reif 
für's Guinness-Buch der Rekorde.


> deutlich von der für den PIC16F873A unterscheidet

Nicht wirklich, der PIC16F873A hat lediglich einen erweiterten 
Befehlssatz und mehr Spezialregister. Steht aber alles im Datenblatt.

: Bearbeitet durch User
von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
2 lesenswert
nicht lesenswert
Dieter K. schrieb:
> (Ich bin Jahrgang 1930).


 Alle Achtung.
 Hättest ja fast bei der Enigma mithelfen können.

von Toxic (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Dieter K. schrieb:
> Wo kann ich Hilfe finden? Ich habe aber nicht
> die Absicht, in C zu programmieren.

Wenn dir englische Tutorials keine Probleme bereiten,wuerde ich dir 
Gooligum-Tutorials empfehlen:

http://www.gooligum.com.au/PIC-Tutorials
http://www.gooligum.com.au/PIC-tutorials/enhanced-PIC-tutorial

Bei dem "enhanced-PIC-tutorial" wird Assembler und C behandelt - 10€

Ich koennte auch 2 aeltere Gooligum-PDF-Dateien (enhanced & enhanced 
MIDrange)mit jeweils 2MByte posten.Da die damals kostenlos fuer 
jedermann zum Download zur Verfuegung standen,sollte es rechtlich 
eigentlich keine Probleme geben.Aber moeglicherweise ist Englisch eh 
nicht so dein "Ding" womit sich dieses Problem dann auch schon erledigt 
haette....

von Peter D. (peda)


Bewertung
1 lesenswert
nicht lesenswert
Dieter K. schrieb:
> Eventuell möchte ich auf den PIC16F1934/6/7 umsteigen. Das Datenblatt
> zeigt mir, dass die Programmierung sich doch deutlich von der für den
> PIC16F873A unterscheidet.

Kommt drauf an, wie Du vorher programmiert hast.
Wenn Du immer schön die Register- und Bitnamen aus dem Datenblatt 
verwendet hast und modular programmiert hast, sollte das Anpassen doch 
recht schnell und problemlos gehen.

Wenn ich so an meine Assembleranfänge zurück denke, waren die ersten 
Versuche das Gegenteil von übersichtlich und modular. In Assembler 
gehört sehr viel Disziplin dazu, Programme so zu schreiben, daß man sie 
später noch versteht und sogar erweitern kann. Ich hab mir viel 
abgeguckt, wie C-Compiler arbeiten und Register als Scratchpad oder für 
Parameterübergabe und Returnwerte reserviert haben. Und irgendwann habe 
ich gemerkt, dann kannste doch gleich besser in C schreiben.

von Dieter K. (dikomoe)


Bewertung
0 lesenswert
nicht lesenswert
Hallo, Leute,

besten Dank für Eure gut gemeinten Ratschläge. Das Umsteigen auf den 
PIC16F1934 zieht doch allerhand Blasen, wenn man genauer hinschaut. 
Fazit: Ich bleibe beim bewährten PIC16F873A

von VirusAfricanus (Gast)


Bewertung
2 lesenswert
nicht lesenswert
@Dieter Kohtz

...anerkennend neige ich, als junger 70jaehriger, mein Haupt vor Deinem 
hohen Alter :-)

Werfe nicht gleich die Flinte ins Korn! Es macht Spass die 
Moeglichkeiten des PIC16F19xx zu entdecken!

Ich programmiere bis jetzt nur in Assembler und verwende wie ich es 
gerade brauche, wahlweise
PICs 16F628, 16F876, 16F1827, 16F1936 (28 Pin, 5V).

Die neuen PICs 16F17xx mit Configurable Logic Cell und Numeric Conrolled 
Oscillator, besorge ich mir zum Experimentieren, sobald ich wieder 
zuhause bin.

Du hast bei den "Extented MCUs" 16F18.. 16F19.. einige Vorteile:
- Interner Ozillator gestuft bis 32MHz, ersetzt oft den Quartz
- 10 bit Analog-Digital-Converter
- 8 bit Digital-Analog-Converter
- Capacitive Sensing Module
- 5 Timer (Timer 0,1,2,4,6
- Capture, Compare, PWM Modules
- usw... (siehe Datenblatt)
Also jede Menge Module zum Spielen, Experimentieren und zum Aufbau 
praktischer Schaltungen (hier im Forum gibt es ja Hilfe wenn Du mal 
feststecken solltes).

Wenn Du Dir ein Modul ums andere vornimmst, kannst Du viel Neues lernen 
und dabei Spass haben!

Also, ruecke vor auf LOS!

VirusAfricanus

von Dieter K. (dikomoe)


Bewertung
1 lesenswert
nicht lesenswert
@VirusAfricanus

Eugen Roth sagt:
Ein Mensch in seinem ersten Zorn
wirft schnell die Flinte in das Korn.
Doch es bedarf dann mancher Finte,
zu kriegen eine neue Flinte.

Vielen Dank für Deine aufmunternden Worte. Nur geht es mir nicht um die 
beachtlichen Fähigkeiten des PIC16F19xx, sondern um seinen Preis. Für 
die Anwendungen, die ich im Auftrag programmiere, sind die Fähigkeiten 
des 16F873A völlig ausreichend. Ich müsste mir für den PIC1619xx einen 
anderen Programmer besorgen und auf MPLABX umsteigen und mich mit den 
Unterschieden der Programmierung vertraut machen, und das sehe ich für 
mich nicht als lohnend an.

Beste Grüße
Dieter Kohtz

von Werner H. (pic16)


Bewertung
1 lesenswert
nicht lesenswert
Dieter K. schrieb:
> Ich müsste mir für den PIC1619xx einen
> anderen Programmer besorgen und auf MPLABX umsteigen

Pickit3 für unter 15€ und MPLAB IDE v8.92 kann den auch. Ich mag MPLABX 
auch nicht.

von Dieter K. (dikomoe)


Bewertung
0 lesenswert
nicht lesenswert
@Werner H.

Ich habe MPLAB IDE 8.46, kann damit ein Testprogramm für den 16F1934 
"builden" und simulieren. Ich habe auch PICKit3, aber schaffe es damit 
nicht einmal, ein Programm für den PIC16F873 zu brennen. Das Manual für 
PICKit3 ist eine Zumutung, und keine Hilfe.

von Erhard S. (ste)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Hr. Kohtz!

Ich wollte ihnen auf diese Weise nochmal für die Artikelserie "PIC 
Programmierung mit PIC 16F84A" in der EAM (Ausgabe 12/2000 - 2006 glaube 
ich) danken.

Ich habe damals ihre Beiträge sehr interessiert gelesen und mir auch 
manche Sachen abgeschaut.

Zu ihrer Anfrage:
Wenn es nur um die Erweiterung von 28 auf 40 Pins geht, dann sind doch 
der PIC16F877 (alt aber gut) oder der PIC16F887 (nicht so alt aber 
besser) genau das Richtige. Der Befehlssatz ist gleich, ebenso die 
Handhabung.
Die Unterschiede zwischen den Controllern sind dem Datenblatt leicht zu 
entnehmen.

Mfg

von Dieter K. (dikomoe)


Bewertung
0 lesenswert
nicht lesenswert
@Erhard S.

Herzlichen Dank für die netten Worte!
Den Anstoß für meine Frage ist nicht die Pin-Zahl sondern der Preis.
Bei Reichelt: PIC16F873A: 3,35 EUR, PIC16F1936: 2,35 EUR. Würde ich nur 
zum Spaß programmieren, wäre mir das egal, es geht aber um Stückzahlen, 
die meinen Auftraggeber nachdenklich machen könnten.

Freundliche Grüße
Dieter Kohtz

von Thomas E. (picalic)


Bewertung
2 lesenswert
nicht lesenswert
Hallo Dieter,

Dieter K. schrieb:
> Ich habe MPLAB IDE 8.46,

die ist aber arg veraltet - die letzte MPLAB-Version ist 8.92. Die 
solltest Du besser mal updaten. Vielleicht liegt das Problem mit dem PK3 
ja auch daran? Der Link zum Download der MPLAB-IDE 8.92 ist etwas 
versteckt (über den Reiter "Download Archive", nachdem man sich zum 
Download von MPLAB-X durchgeklickt hat).
Das Programmierproblem mit dem PICKit sollte sich jedenfalls lösen 
lassen, evtl. mit etwas Hilfe aus dem Forum. Bei mir wollte das am 
Anfang auch nicht gleich, und manchmal gibt es auch merkwürdige Effekte. 
Z.B. musste ich mal die VDD-Spannung am PICKit auf etwas weniger, als 5V 
konfigurieren, damit ich den PIC programmieren konnte.
Ich denke, der Umstieg von Midrange auf auf die Enhanced Midrange Typen 
lohnt sich m.E. auf jeden Fall, nicht nur wegen dem Preis. Allein schon, 
daß bei Interrupts automatisch alle Register gerettet werden, finde ich 
einen großen Fortschritt. Aber auch andere Kleinigkeiten, wie die neuen 
Möglichkeiten mit den FSR-Registern oder daß das W-Register auch als SFR 
angesprochen werden kann (z.B. incf WREG,F) und viele Kleinigkeiten 
mehr, die einem das Leben erleichtern können...

Viele Grüße,

Thomas

von kopiert (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
>Ich habe aber nicht die Absicht, in C zu programmieren.

>(Ich bin Jahrgang 1930).

Das wäre ein hervorragender Grund, damit JETZT anzufangen.
Du hast nicht mehr endlos Zeit.

Wer mit dem Hirnkrebs PIC zurande kommt, für den sollte alles Andere
kein Problem mehr sein.

von Michael O. (michael_o)


Bewertung
0 lesenswert
nicht lesenswert
Ich fand ICD2 war eine Zumutung aber seit ICD3 und PicKit3 läuft es bei 
mir immer ohne Klimmzüge am Brotkasten.
Spielen mit der Versorgung war auch nie nötig, ich versorge die meisten 
Projekte aber nicht über den Programmer.

Die MPLABx habe ich auch nicht gleich gemocht, fand ich den Aufwand mich 
da einzuarbeiten doch einfach viel zu groß. Wir haben uns aber 
aneinander gewöhnt...

Das einzige was ich dem PicKit3 nachsagen kann ist, das da gern mal ein 
Transistor drin stirbt und ich schon zwei davon reparieren musste.

mfG
Michael

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
kopiert schrieb:
> Wer mit dem Hirnkrebs PIC zurande kommt, für den sollte alles Andere
> kein Problem mehr sein.

Schön gesagt.
Ich habe mit Z80, 8051 und AVR angefangen, die waren leicht 
verständlich. Aber der PIC war mir zu kompliziert. Man muß beim PIC zu 
sehr um die Ecke denken.

von Volker S. (vloki)


Bewertung
2 lesenswert
nicht lesenswert
Peter D. schrieb:
> Man muß beim PIC zu sehr um die Ecke denken

Ist mir nie aufgefallen. Z80, 68HC??, C166, C51 und schon seit langem 
nur noch PICs. Die haben genau so viele Ecken wie die Anderen auch. 
(Vier - wenn wir das jetzt Mal zweidimensional betrachten ;-)

von Michael O. (michael_o)


Bewertung
0 lesenswert
nicht lesenswert
Richtig Mist fand ich nur 8051. 8085 war richtig nett und die PICs finde 
ich richtig gut. Etwas Herausforderung sollte man seinem Gehirn 
schließlich gönnen. Und die neueren PICs mit ihrer sehr aufwändigen 
Peripherie sind schon manchmal eine Herrrausforderung.

mfg
Michael

von H-G S. (haenschen)


Bewertung
0 lesenswert
nicht lesenswert
Mir scheint dass ein großes Problem bei der Assembler-Programmierung die 
zur Verfügung stehenden Schreibfläche ist.

Einige Verzweigungen etc. brauchen Platz zum Notieren... ich benutze 
schon Vorder- und Rückseiten meiner DIN-A4 Blätter für den 
Programmablaufplan aber es geht manchmal zweispurig und wenn da noch 
eine Verzweigung auftritt wars das.

Man bräuchte eine große Pinwand, aber meine Wände sind alle 
zugestellt...

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
H-G S. schrieb:
> Einige Verzweigungen etc. brauchen Platz zum Notieren... ich benutze
> schon Vorder- und Rückseiten meiner DIN-A4 Blätter für den
> Programmablaufplan aber es geht manchmal zweispurig und wenn da noch
> eine Verzweigung auftritt wars das.

Das wäre dann der richtige Zeitpunkt, weg vom Spaghetticode und hin zur 
modularen Programmierung zu gehen. Diese Erfahrung muß wohl jeder 
Programmieranfänger für sich selber machen, das Mantra der erfahrenen 
Programmierer verhallt bis dahin ungehört.
Und ja, man muß in der Regel allen bisherigen Code wegschmeißen.
Belohnt wird damit, daß man nun deutlich größere Projekte in Angriff 
nehmen kann und diese nun wartbar, erweiterbar und wiederverwendbar 
sind.

von H-G S. (haenschen)


Bewertung
-1 lesenswert
nicht lesenswert
Ja, alleine das einfache Erstellen von Variablen ist ein unglaublicher 
Segen!

Per Hand in Assembler muss man sich eine freie Speicherstelle im 
(internen ?) RAM suchen und diese im Variablen-Übersichtszettel notieren 
etc. - im C-Compiler gibt man nur Typ und Namen an und ab gehts.

von Dieter K. (dikomoe)


Bewertung
0 lesenswert
nicht lesenswert
@Thomas Elger

Hallo, Thomas,

Besten Dank! Ich habe MPLAB IDE 8.92 installiert und zum Testen 
versucht, einen PIC16F873 mit PICKit3 zu programmieren. Beinahe mit 
Erfolg. Folgende Fehlermeldung erscheint: target ID 00000000 not 
required ID 0000960.
Der Versuch, mit CONFIGURE > ID Memory die gewünschte ID zu laden, führt 
nicht zum Erfolg. Der Programmiervorgang lässt sich zwar starten und 
läuft offenbar auch, aber mit dem Ergebnis 00000000. Hast Du eine 
Ahnung, wo der Kinken Stecken könnte?

Besten Gruß
Dieter

von Dieter W. (dds5)


Bewertung
1 lesenswert
nicht lesenswert
target ID 00000000 ist ein Indiz für unterbrochene Kommunikation 
zwischen Controller und PICKit.

von (prx) A. K. (prx)


Bewertung
-1 lesenswert
nicht lesenswert
Volker S. schrieb:
>> Man muß beim PIC zu sehr um die Ecke denken
>
> Ist mir nie aufgefallen. Z80, 68HC??, C166, C51 und schon seit langem
> nur noch PICs. Die haben genau so viele Ecken wie die Anderen auch.

Die PICs sind mnemotechnisch teilweise etwas aus der Zeit gefallen und 
die Kennzeichnung der Operationsweise durch W oder F hinten ist 
gewöhnungsbedürftig. Aber wer alt genug ist, schon Architekturen aus den 
50ern und 60ern zu kennen, den schreckt das nicht. Die waren oft ähnlich 
schräg.

von Dieter K. (dikomoe)


Bewertung
0 lesenswert
nicht lesenswert
@Dieter Werner

Beim Aufruf von Programmer > PICKit3 erscheint folgende Meldung:

PICkit 3 detected
Connecting to PICkit 3...
Firmware Suite Version...... 01.28.90
Firmware type......................Midrange
PICkit 3 Connected.
Target Detected
Target Device ID (00000000) does not match expected Device
ID (00000960).

Geht daraus nicht hervor, dass PICKit und Controller verbunden sind?
(Ich hatte auch schon mal die Meldung: Target not detected)

von Thomas E. (picalic)


Bewertung
1 lesenswert
nicht lesenswert
Hallo Dieter,

leider habe ich kein PICKit3 zuhause, so daß ich hier nichts Testen und 
ausprobieren kann. Deine Firmware-Version (01.28.90) scheint aber auch 
nicht gerade die neueste zu sein, zumindest erscheinen in diversen 
Google-Suchergebnissen höhere Nummern. Bei "Firmware type" müsste für 
den PIC16F193x m.E. auch "Enhanced Midrange" stehen.
Die Firmware des Programmers kannst Du im MPLAB über 
Programmer->Settings->Configuration updaten. Vielleicht klappt's dann 
schon...

von Michael_ohl (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Target ID 00000000 deutet immer darauf hin, das das PicKit den PIC nicht 
richtig lesen kann. Fremdbeschaltung auf MCLR fehlende Versorgung oder 
irgend etwas das die Clock oder Datenleitung nicht richtig spielt.
Wenn das PicKit in Ordnung ist und alles von den Datenleitungen entfernt 
wurde nur noch Prüfen wer die Versorgung übernehmen soll - PicKit oder 
Selbstversorger muss einsprechend im MPLABx angegeben werden.
Einzige Ausnahme war bei mir mal der Transistor der die Versorgung im 
PicKit schaltet. Wenn der durch ist kommt halt keine Versorgung beim PIC 
mehr an und es gibt immer Device ID Fehler.


mfG
Michael

von Toxic (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Dieter K. schrieb:
> PICkit 3 detected
> Connecting to PICkit 3...
> Firmware Suite Version...... 01.28.90
> Firmware type......................Midrange
> PICkit 3 Connected.
> Target Detected
> Target Device ID (00000000) does not match expected Device
> ID (00000960).

Ich benutze keinen PICKit aber ich habe eben mal auf dem Microchip Forum 
nachgesehen:
http://www.microchip.com/forums/m759961.aspx?high=does+not+match+expected+Device+ID

Interessant sind die letzten Eintraege die den PICKit als Fehlerursache 
ausmachen.

Unabhaengig davon:
Als angemeldeter User kannst du auf diesem Microchip Forum gute und 
schnelle Hilfe bekommen.
http://www.microchip.com/forums

von Volker S. (vloki)


Bewertung
1 lesenswert
nicht lesenswert
Ein fieser Fehler kann auch auftreten, wenn man aus irgendwelchen 
Gründen die Programmer Software benutzt, die das PICkit in etwas anderes 
verwandelt. Es funktioniert unter der IDE dann nicht mehr korrekt. Da 
habe ich diesen Fehler auch schon gesehen. In der Programmer Software 
bekommt man aber einen entsprechenden Hinweis, dass man das PICkit hier 
zuerst wieder richtig konfigurieren muss, damit es in der IDE nutzbar 
ist.

von W.S. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Dieter K. schrieb:
> Ich habe auch PICKit3, aber schaffe es damit
> nicht einmal, ein Programm für den PIC16F873 zu brennen. Das Manual für
> PICKit3 ist eine Zumutung, und keine Hilfe.

Hach, das kenne ich zur genüge.
ich hab mit den PIC16's so 1991 herum angefangen und finde sie noch 
immer für kleinere Aufgaben in Assembler richtig handlich. Knuffig 
sozusagen. Aber die Software von MicroChip ist ne Kröte - schon immer 
gewesen.

Die Programmierhardware auch.

Kennst du noch den sauteuren PIC-Programmer, wo man für jeden Typ ne 
neue SHFassung zum Draufschrauben mit diesen häßlichen 
Leitplastik-Kontakten kaufen mußte? Oder den ollen PICALC ?

Ich hatte mir notgedrungen nen handlicheren Assembler selber geschrieben 
und auch einen ordentlichen Programmer gebaut, beides benutze ich im 
Prinzip immer noch. Allerdings den Assembler als DLL entweder mit 
vorgeschaltetem Kommandozeilentool oder in selbstgebauter Mini-IDE.

Der Brenner läuft seit damals (vor 25 Jahren!) per Parallelport, was 
einem heutzutage seit Win7 ein Problem macht. Aber mit den PICkit2 und 3 
bin ich nie wirklich warm geworden. Es sind mMn elende Krücken, ebenso 
wie der letzte PIC-Assembler, den ich mir (mal wieder) angewidert 
angesehen habe.

So. Derzeit denke ich über nen eigenen Brenner nach, als USB-Teil mit 
nem STM32F103 als Adapter und das PC-Programm von meinem ST-Programmer 
abgeleitet - soweit ich abends dazu Zeit habe.



Peter D. schrieb:
> Schön gesagt.
> Ich habe mit Z80, 8051 und AVR angefangen, die waren leicht
> verständlich. Aber der PIC war mir zu kompliziert. Man muß beim PIC zu
> sehr um die Ecke denken.

Hehe, du bist lediglich vom AVR versaut. Bei den PIC's (gerade bei den 
kleinen 16F) muß man eigentlich garnicht um die Ecke denken, es 
erscheint dir bloß so. Das läuft auf ne Diskussion a la C versus Pascal 
hinaus - und die ist überflüssig, weil die AVR-Leute die PIC-Architektur 
einfach nicht verstanden haben. Glaube du also lieber nicht, in den 
PIC16 würde man per Assembler nur Spaghetticode schreiben. Zumeist ist 
das völlig Gegenteil der Fall. Allerdings gibt es eben wegen des 
HW-Stacks keine Parameter auf dem Stack, sondern nur in W und/oder FSR 
oder FSR^. Diesen Umstand muß man erstmal kapieren.

Ich hab nie verstehen können, warum manche Leute ne Registermaschine als 
einfacher empfinden:
 Lade Register aus RAM
 mache ne Operation mit Register
 speichere Register in RAM

anstatt
 mache ne Operation im RAM

zu schreiben.

W.S.

von Volker S. (vloki)


Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
> Aber mit den PICkit2 und 3 bin ich nie wirklich warm geworden. Es sind
> mMn elende Krücken,

Ich finde die richtig gut. Das PICkit2 haben wir früher als 
SMD-Bestückungsversuch von unseren Studierenden bauen lassen. Das 
dürften sie dann sogar behalten.
Als das PK3 dann rauskamen und es anfing, dass einige PICs vom PK2 nicht 
mehr unterstützt würden hat das schon genervt und auch, dass das neue 
ständig seine Firmware ändern muss, wenn ein anderer PIC programmiert 
werden soll. Inzwischen habe ich mich daran gewöhnt...

Auf jeden Fall für viel besser als ICD2 mit denen wir ständig in den 
Rechnerpools Treiberprobleme hatten. MCHP hat kostenlos alle unsere ICD2 
gegen PK3 ersetzt. Die alten ICD2 müssten wir noch nicht mal zurück 
schicken.

Einen reinen Programmer, der nicht debuggen kann würde ich nicht mal 
geschenkt nehmen und auch nicht selber bauen, solange ich ein PK3-Klon 
für 10€ bekomme.

W.S. schrieb:
> Peter D. schrieb:
>> Man muß beim PIC zu
>> sehr um die Ecke denken.
>
> Hehe, du bist lediglich vom AVR versaut

Jo, verstehe gar nicht, warum manche PIChater sich immer wieder so 
blödsinnig in reinen PIC-Threads äußern müssen.

W.S. schrieb:
> Ich hab nie verstehen können, warum manche Leute ne Registermaschine als
> einfacher empfinden:
+1

von Dieter K. (dikomoe)


Bewertung
1 lesenswert
nicht lesenswert
Hallo, Leute,

jetzt habe ich tagelang versucht, den PICKit3 zum Programmieren zu 
überreden, leider ohne Erfolg. Was ich im Forum von Microchip so über 
ihn erfahren habe, hat meine Motivation endgültig zu Null gemacht. Für 
die Aufgaben, die ich vorhabe, komme ich mit den 16F8xx-Typen und 
PICKit2 bestens zu Potte. Habt Dank für Eure guten Ratschläge und 
macht's gut.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Ich mag ja Bootloader via Async. Vorzugsweise schon ab Werk drin. 
Erspart die Suche nach dem passenden Programmer.

von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
Dieter K. schrieb:
> Was ich im Forum von Microchip so über
> ihn erfahren habe, hat meine Motivation endgültig zu Null gemacht
In den Foren stehen eben immer nur Probleme. Wenn's läuft fragt doch 
keiner warum ;-)


Dieter K. schrieb:
> Für
> die Aufgaben, die ich vorhabe, komme ich mit den 16F8xx-Typen und
> PICKit2 bestens zu Potte.
Dann nimm doch das PK2 ;-)
Kann mir zwar nicht vorstellen warum es nicht auch mit dem PK3 gehen 
sollte, aber wenn es schon eine funktionierende Lösung gibt...


A. K. schrieb:
> Ich mag ja Bootloader via Async. Vorzugsweise schon ab Werk drin.
> Erspart die Suche nach dem passenden Programmer.
Kann man da auch debuggen? (also mit Anhalten, Breakpoints, Register 
anschauen und so...)

: Bearbeitet durch User
von (prx) A. K. (prx)


Bewertung
-1 lesenswert
nicht lesenswert
Volker S. schrieb:
> Kann man da auch debuggen? (also mit Anhalten, Breakpoints, Register
> anschauen und so...)

Nö, brauche ich aber nur selten. Ich hatte mir zwar mal ein JTAG für ein 
paar alte AVRs gebaut, aber so gut wie nie verwendet.

: Bearbeitet durch User
von Klaus (Gast)


Bewertung
1 lesenswert
nicht lesenswert
A. K. schrieb:
> Nö, brauche ich aber nur selten. Ich hatte mir zwar mal ein JTAG für ein
> paar alte AVRs gebaut, aber so gut wie nie verwendet.

Genies brauchen keinen Debugger, die machen immer alles gleich richtig. 
Richtige Programmierer morsen Registerwerte auf ner LED. Nur Weicheier 
lassen sich Strukturelemente mit Klartextnamen im Debugger anzeigen.

MfG Klaus

von W.S. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
A. K. schrieb:
> Ich mag ja Bootloader via Async. Vorzugsweise schon ab Werk drin.
> Erspart die Suche nach dem passenden Programmer.

Du sprichst mir aus dem Herzen.

Und die obigen Einlassungen bzgl. Debugging sind eben auch nur ein 
Zeichen dafür, daß die Betreffenden nicht wirklich sauber und zumeist 
eben nur in C programmieren können und genau deshalb den Debugger 
brauchen, um zu merken, was für einen Murks sie tatsächlich geschrieben 
haben. Oft genug ist nämlich gerade bei C ein himmelweiter Unterschied 
zwischen dem, was man gemeint hat und dem, was der Compiler dabei 
verstanden hat.

Ich hab auch diverse Debugger-Geschirre in der Bastelkiste 
sedimentieren, aber eigentlich noch nie eines davon wirklich benötigt.

W.S.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Klaus schrieb:
> Genies brauchen keinen Debugger, die machen immer alles gleich richtig.

Missverständnis. Es gibt schlicht auch andere Methoden. Typischerweise 
ist etlicher Tracecode drin. Wichtig ist, dass z.B. eine Miniversion von 
printf funktioniert (C), oder andere Formen irgendeiner Ausgabe (ASM). 
Ganz am Anfang und auf unterster Ebene auch mal LEDs. Letztere sind dort 
von Vorteil, wo der Zeitfaktor keine andere Möglichkeit lässt, oder ISRs 
beteiligt sind.

Liegt vielleicht auch daran, dass diese Methode so ziemlich überall 
gleichermassen funktioniert. Debug-Schnittstellen hingegen sind grad bei 
AVRs vergleichsweise neumodisch, gab es früher nur bei den Grossen. Bei 
den PICs fehlt mir der diesbezügliche Überblick.

: Bearbeitet durch User
von Volker S. (vloki)


Bewertung
-2 lesenswert
nicht lesenswert
W.S. schrieb:
> nd genau deshalb den Debugger
> brauchen, um zu merken, was für einen Murks sie tatsächlich geschrieben
> haben.

Es ist einfach nur Faulheit. Wenn man merkt, dass man IRGENDWO einen 
Murks geschrieben hat, dann findet man viel schneller wo.
(Natürlich murkst man viel einfacher in C ;-)

In der "Lehre" ist es aber auch ganz nett, Schritt für Schritt durch den 
Maschinencode eines in C geschriebenen Programms steppen zu können...

: Bearbeitet durch User
von Volker S. (vloki)


Bewertung
-1 lesenswert
nicht lesenswert
A. K. schrieb:
> Typischerweise
> ist etlicher Tracecode drin. Wichtig ist, dass z.B. eine Miniversion von
> printf funktioniert (C), oder andere Formen irgendeiner Ausgabe (ASM).
> Ganz am Anfang und auf unterster Ebene auch mal LEDs. Letztere sind dort
> von Vorteil, wo der Zeitfaktor keine andere Möglichkeit lässt, oder ISRs
> beteiligt sind.

Ausgaben über die Serielle Schnittstelle sind mir zu umständlich/bremsen 
das Programm aus, für LEDs bin ich meistens zu langsam. Ein Oszilloskop 
als Hilfsmittel weil ich zu langsam bin und das Programm auch nicht 
anhalten will, finde ich aber mehr als nützlich!

<edit>Sorry, ich(wir) schweife vom Thema ab.
JA, Assemblerprogrammierer haben das/sich besser im Griff und müssen 
weniger debuggen!

: Bearbeitet durch User
von Klaus (Gast)


Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
> Oft genug ist nämlich gerade bei C ein himmelweiter Unterschied
> zwischen dem, was man gemeint hat und dem, was der Compiler dabei
> verstanden hat.

Das gilt aber eigentlich nur, wenn man C nicht verstanden hat, es 
einfach nicht kann. Wer es können will, kann es lernen, wer nicht findet 
Ausreden.

A. K. schrieb:
> Debug-Schnittstellen hingegen sind grad bei
> AVRs vergleichsweise neumodisch, gab es früher nur bei den Grossen. Bei
> den PICs fehlt mir der diesbezügliche Überblick.

Einen Pic debugged man über dieselbe Schnittstelle, über die man ihn 
auch programmiert. Und das tut man auch über das gleiche Teil, z.B. 
einen PICKit. 3 Drähte, Vcc und GND, fertig. Das können selbst die 
8-Beiner. Hardwarebreakpoints sind im Chip eingebaut, bei den neueren 
auch Datenbreakpoints. Ob ich C-Code für den PC mit netbeans entwickle 
oder mit MPLABX (ist auch netbeans) für einen PIC ist fast kein 
Unterschied. Bevor ich auf diesen Komfort verzichte, muss der µC schon 
etwas besonderes leisten, so wie der ESP z.B. mit WLAN.

MfG Klaus

von Werner H. (pic16)


Bewertung
1 lesenswert
nicht lesenswert
Dieter K. schrieb:
> jetzt habe ich tagelang versucht, den PICKit3 zum Programmieren zu
> überreden, leider ohne Erfolg.

Ja, kenne ich. Das Ding ist widerborstig mit dem MPLab. Ziehe dir 
einfach die Standallone Software bei Microchip runter, dann gehts 
problemlos.

von Dieter K. (dikomoe)


Bewertung
0 lesenswert
nicht lesenswert
Werner H. schrieb:
> Ja, kenne ich. Das Ding ist widerborstig mit dem MPLab. Ziehe dir
> einfach die Standallone Software bei Microchip runter, dann gehts
> problemlos.

Danke für den konstruktiven Beitrag. Ich habe die Standallone Software 
erfolgreich installiert. Sieht alles wunderbar aus, aber Ergebnis trotz 
diverser Versuche: No device detected. Meine Hardware ist dieselbe, mit 
der PICKit2 bestens funktioniert. Versorgung extern mit 5 V.  PICKit3 
ist original Microchip und praktisch neuwertig.

von Werner H. (pic16)


Bewertung
1 lesenswert
nicht lesenswert
Dieter K. schrieb:
> Ich habe die Standallone Software erfolgreich installiert.

Hast du die "PICkit3 Programmer Application v3.10" verwendet oder die 
"PICkit_3_Programmer_1_0"?
Die 3.1 ist die richtige. Du musst auch die Firmware Laden 
(PK3OSV020005.hex), im Menü Tools.

von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
So langsam macht ihr mich echt neugierig. Ich muss das wohl mal 
ausprobieren, ob es mit dem 16F87xA auch bei mir Probleme gibt.
Einen 873A habe ich zwar nicht, aber noch viele alte 877A, die früher 
beim PICDEM 2+ dabei waren. Müsste ja vom Programmieren her gleich sein.

PIC16 habe ich in letzter Zeit nur neuere benutzt (mit 4 oder 5 Stellen 
hinter dem F, z.B 16F1459) und bei denen gab es keinerlei Probleme.
Mit PIC18 auch nicht. (alle mit USB, die K22, K80 ...). Bei PIC10, 12, 
PIC24... eigentlich kann ich mich an keine nennenswerte Probleme 
erinnern.

Die alte IDE verwenden wir schon lange nicht mehr. Wenn man auch in C 
programmiert, bietet MPLABX trotz den deutlichen 
Geschwindigkeitseinbußen für uns einige Vorteile. (unter anderem den, 
dass die Studierenden vorher schon Netbeans benutzt haben und nicht die 
unsägliche Einrichtung der Tools von jedem neuen Benutzer gemacht werden 
muss)

Die Verwendung der Programmer App bringt bei uns nur Probleme, weil die 
Studies natürlich immer einfach alles anklicken und dann das PICkit3 in 
MPLABX nicht mehr funktioniert.

Egal, ich muss es testen - aber erst übernächste Woche ;-)

: Bearbeitet durch User
von Dieter K. (dikomoe)


Bewertung
0 lesenswert
nicht lesenswert
Werner H. schrieb:
> Hast du die "PICkit3 Programmer Application v3.10" verwendet oder die
> "PICkit_3_Programmer_1_0"?
> Die 3.1 ist die richtige. Du musst auch die Firmware Laden
> (PK3OSV020005.hex), im Menü Tools.

Ich habe von Microchip "PICKit3 Stand Alone Programmer Application v1.0" 
verwendet und installiert. Nach dem Aufruf von PICKit3 erscheint u.a. 
die Meldung: "Found 1 Firmware suit, latest Version 01.38.51". Wenn ich 
tools anklicke, wird das file "PK3FW_012633.jam" angeboten. Wenn ich das 
wähle, werden die files "AP01.14.15-07" und "RS01.13.04" als geladen 
gemeldet, dann erfolgt ein endloser Ladevorgang (offensichtlicher 
Absturz?)
Das file "PK3OSV020005.hex" ist im Verzeichnis PICKit3 nicht zu finden.

von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
Dieter K. schrieb:
> Das file "PK3OSV020005.hex" ist im Verzeichnis PICKit3 nicht zu finden.

Ich glaub dafür muss man das installieren:
"PICkit 3 Programmer App and Scripting Tool v3.10"
http://ww1.microchip.com/downloads/en/DeviceDoc/PICkit3%20Programmer%20Application%20v3.10.zip

<edit> Siehe auch https://www.youtube.com/watch?v=vfmLu6XzBtw (38:40)

: Bearbeitet durch User
von Ottmar K. (wil1)


Bewertung
0 lesenswert
nicht lesenswert
Dieter K. schrieb:

> Target Detected
> Target Device ID (00000000) does not match expected Device
> ID (00000960).
>
> Geht daraus nicht hervor, dass PICKit und Controller verbunden sind?
> (Ich hatte auch schon mal die Meldung: Target not detected)

Dieser Fehler tritt auch auf, wenn der PIC sich in der Schaltung 
befindet und per ICSP programmiert werden soll.

Abhilfe:
; Wird die ICSP-Schnittstelle verwendet, MÜSSEN die Pins PGC und PGD
; (beim 16Fxxx RB6/PGC, RB7/PGD) mit einem Widerstand von wenigstens
; 1kOhm (oder mittels Jumper) von der übrigen Schaltung (auch von
; LCD-Datenleitungen) entkoppelt sein!
;
; Geschieht dies nicht, meldet das PICkit3 schon beim Anschluss
;     "Target Device ID (00000000) does not match expected Device
;     ID (00001060)"
; oder
;     "The following memory regions failed to program correctly:
;      Program Memory"

Bei mir hat dieser Tip beim Brennen mit dem PICkit3 geholfen. Dazu mehr 
auf der Seite von "sprut":
http://www.sprut.de/electronic/pic/icsp/icsp.htm
(Takt- und Datenleitung PGC (RB6) und PGD (RB7)

mfg Ottmar

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Klaus schrieb:
> Das gilt aber eigentlich nur, wenn man C nicht verstanden hat,

JEIN - so kann man das nicht stehenlassen.

Man kann mit C durchaus programmieren, wenn man noch längst nicht alle 
Möglichkeiten verstanden hat, ABER: man sollte sich dabei eine biedere 
Art des Programmierens angewöhnen und eben nicht jeden Furz, den C so 
bietet, auch tatsächlich benutzen wollen, bloß weil man solche 
Husarenstückchen irgendwo im Internet als Beispiel gefunden hat. Auch 
bei ganz simpler Programmierung kommt heutzutage kein schlechter Code 
heraus, weil man die tatsächliche Optimierung dem Compiler überlassen 
kann.

W.S.

von Werner H. (pic16)


Bewertung
1 lesenswert
nicht lesenswert
Dieter K. schrieb:
>.. Application v1.0" verwendet und installiert...

Das ist die Falsche, du musst die v3.10 nehmen da ist auch die 
"PK3OSV020005.hex" Datei mit dabei.

von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Auch
> bei ganz simpler Programmierung kommt heutzutage kein schlechter Code
> heraus, weil man die tatsächliche Optimierung dem Compiler überlassen
> kann.

Sorry, in diesem Teil kann ich jetzt nicht so ganz folgen. (Ich raff's 
nicht, was du da sagen willst)

von Dieter K. (dikomoe)


Bewertung
0 lesenswert
nicht lesenswert
Werner H. schrieb:
> Das ist die Falsche, du musst die v3.10 nehmen da ist auch die
> "PK3OSV020005.hex" Datei mit dabei.

Jetzt habe ich die heruntergeladen (wozu ist die andere gut?,)aber 
trotzdem keinen Erfolg. Ich brauche PICKit3 nicht und werde nun den 
thread nicht weiter beobachten.
Tschüs!

von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
Dieter K. schrieb:
> Ich brauche PICKit3 nicht...

Falls du es loswerden willst, dann schreib mir doch eine PN

von Klaus (Gast)


Bewertung
2 lesenswert
nicht lesenswert
W.S. schrieb:
> Klaus schrieb:
>> Das gilt aber eigentlich nur, wenn man C nicht verstanden hat,
>
> JEIN - so kann man das nicht stehenlassen.
>
> Man kann mit C durchaus programmieren, wenn man noch längst nicht alle
> Möglichkeiten verstanden hat, ABER: man sollte sich dabei eine biedere
> Art des Programmierens angewöhnen und eben nicht jeden Furz, den C so
> bietet, auch tatsächlich benutzen wollen, bloß weil man solche
> Husarenstückchen irgendwo im Internet als Beispiel gefunden hat. Auch
> bei ganz simpler Programmierung kommt heutzutage kein schlechter Code
> heraus, weil man die tatsächliche Optimierung dem Compiler überlassen
> kann.

Das ist eigentlich eine Binsenweißheit. Ich kann Fahrradfahren, trotzdem 
versuche ich nicht jeden Stunt, den ich mal gesehen hab. Deine Bemerkung 
war aber:

W.S. schrieb:
> Oft genug ist nämlich gerade bei C ein himmelweiter Unterschied
> zwischen dem, was man gemeint hat und dem, was der Compiler dabei
> verstanden hat.

Und das ist eigentlich nicht so. Mir ist es bisher noch immer gelungen, 
mein Problem so zu formulieren, daß mich der C-Compiler verstanden hat. 
Und das war eigentlich nie wirklich schwer. Dabei spare ich nicht beim 
Source, ein komplexer Regler muß nicht in eine Zeile passen, noch beim 
Objektcode. Guter Code zeichnet sich für mich dadurch aus, daß man ihn 
beim ersten Mal lesen versteht. Dabei ist es mir vollkommen egal, ob die 
CPU, auf der er läuft, Register hat, Banks umschaltet oder einen 
Datenstack in SW realisiert. Um beim Beispiel eines Reglers zu bleiben: 
wenn ich mir die Reglergleichungen im Lehrbuch ansehe, kommen 
CPU-Register oder Flash-Banks nicht vor.

Ich programmiere PICs. Da ich das schon länger mache, als es C-Compiler 
für sie gibt, weiß ich das die alten, kleinen keine Register und 
Memorybanks haben. Ob das bei den neuen Midrange immer noch so ist, weiß 
ich nicht. Ich verwende auch die 16 Bitter, PIC24. Ob die Register 
haben? Hab nicht nachgesehen, keine Ahnung. Erzeugter Assemblecode? 
Schau ich nicht an, was der Compiler für den CoreIxx auf meinem PC macht 
schau ich auch nicht an. Trotzdem hab ich allen Code zum funktionieren 
bekommen.

MfG Klaus

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Klaus schrieb:
> Ich verwende auch die 16 Bitter, PIC24. Ob die Register
> haben?

Haben sie, deren 16. Die PIC30 waren erkennbar so konzipiert worden, 
dass heutige C Compiler wie GCC keine Verrenkungen benötigen. Das ist 
schon aus Faulheit (Sparsamkeit) sinnvoll, denn nur dann kann man 
effizient auf bestehenden Compilern wie GCC aufbauen. Was Microchip ja 
auch getan hat.

> Erzeugter Assemblecode?

Kann in Einzelfällen schon mal nützlich sein. Nicht zuletzt um sicher zu 
sein, dass der Compiler auch tut was er soll. Bei meinem ersten (und 
einzigen) Testprojekt mit einem PIC30 bin ich ziemlich früh über einen 
echten Fehler im Compiler gestolpert (Kontakt mit Microchip, bestätigt 
und behoben).

von Klaus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Kann in Einzelfällen schon mal nützlich sein. Nicht zuletzt um sicher zu
> sein, dass der Compiler auch tut was er soll.

Naja, Ausnahmen bestätigen die Regel. Ich schau mit dem Source-Debugger 
in die C-Variablen, genau wie auf dem PC. Ich setze einen Breakpoint und 
schaue welchen Zweig der Code durchläuft. Da die Header für die PICs mir 
die SFR schon in Variable zerlegen, kann ich z.B. einen FIFO-Füllstand 
aus einem SFR einfach als Zahl, auf Wunsch auch als Dezimalzahl 
auslesen. Aber zu wissen, daß die PIC24 16 Register haben, beruhigt 
ungemein.

Ich hab auch noch keinen Compilerfehler entdeckt, Fehler des 
Programmierer (meist ich selbst) schon viele.

MfG Klaus

von Dieter K. (dikomoe)


Bewertung
0 lesenswert
nicht lesenswert
Volker S. schrieb:
> Falls du es loswerden willst, dann schreib mir doch eine PN

Wenn ich wüsste, was eine PN ist, würde ich Dir schreiben. Gern wäre ich 
PICKit3 + Demoboard und CD los.

von Volker S. (vloki)


Bewertung
1 lesenswert
nicht lesenswert
Persönliche Nachricht, E-Mail über Benutzer.
Wenn die Teile günstig wären, würde ich die an Studierende weiter geben.
Wie gesagt - bei uns gibt es eigentlich keine Probleme mit dem PICkit3.
Sollte es wirklich defekt sein, könnte ich es vermutlich auch ohne allzu 
große Mühe wieder richten.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert

von Dieter K. (dikomoe)


Bewertung
1 lesenswert
nicht lesenswert
@ Volker S.
Volker S. schrieb:
> Persönliche Nachricht, E-Mail über Benutzer.
> Wenn die Teile günstig wären, würde ich die an Studierende weiter geben.
> Wie gesagt - bei uns gibt es eigentlich keine Probleme mit dem PICkit3.
> Sollte es wirklich defekt sein, könnte ich es vermutlich auch ohne allzu
> große Mühe wieder richten.

Ich verschenke die Teile gern, besonders, wenn sie an Studierende gehen. 
Nur sag mir bloß, wo ich sie hinschicken soll. Wie geht "Persönliche 
Nachricht, E-Mail über Benutzer"?

Beste Grüße
Dieter Kohtz

von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe dir geschrieben.
(einfach den Benutzernamen in der Klammer anklicken)

von Michael O. (michael_o)


Bewertung
1 lesenswert
nicht lesenswert
Das PicKit3 ist so gut, das ich seit es das gibt das ICD2 im Schrank 
liegen lasse und auch das ICD3 so gut wie nie benutze. Aber für den Fall 
eines Falles habe ich auch Ersatz für PicKit3 da denn zum reparieren 
muss man schon etwas Muße aufbringen den Fehler zu suchen und zu finden.

mfG
Michael

von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
Dieter K. schrieb:
> Ich verschenke die Teile gern, besonders, wenn sie an Studierende gehen.
> Nur sag mir bloß, wo ich sie hinschicken soll.

Vielen Dank ist heute angekommen.
Wenn doch nur mehr so großzügig wären ;-)

von Maik W. (werner01)


Bewertung
1 lesenswert
nicht lesenswert
Servus,

ich verstehe das gemurmel nicht um die "unverständliche" Programmierung 
der PIC's. 1. sind das EinAdreßmaschinen und zweitens haben die Pic12 
und alle alten PIC16 nur 35 Befehle zum Auswendig lernen. Somit haben 
die ihren Platz neben all den anderen Chips verdient. Ich habe seid uber 
zwei Jahren mal wieder aus dem "kalten" eine Funkuhr gebaut mit 
Pic16f628 in Assembler.
Habe zwar vergessen das man auch einzelne BIT's setzen kann mit BSF o. 
BCF
aber sonst null problemo. Die wirken halt blos wie ZweiTakter aber sonst 
finde ich die so schlecht nicht. Die DSPIC's machen freilich auch Spaß. 
Die haben 16 Workingregisters und relativ viel Dampf im Kessel.....


Grüße ausm Osten

von vloki (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Maik W. schrieb:
> ich verstehe das gemurmel nicht um die "unverständliche" Programmierung
> der PIC's.

Oh je, das versteht jetzt bestimmt wieder irgendeiner als Einladung 
seinen PIChater Stuss abzusondern ;-)

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




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

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