Forum: Mikrocontroller und Digitale Elektronik Wie setze ich ein Bit korrekt in einem "bitfield" ?


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 Harry R. (harryr)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

ich habe es eben geschaft mein erstes Programm für den PIC10F202
zu debuggen (ich bitte um Applaus :-)

Dabei ist mir aufgefallen, dass das Setzen von einzelnen Bits in einem
bitfield nicht so funktioniert, wie ich mir das dachte.

Hier mal (eine sicher bekannte) Definition eines structs, das die 4 Pins 
des GPIO des PIC10F202 definiert.
1
// bitfield definitions
2
typedef union {
3
    struct {
4
        unsigned GP0                    :1;
5
        unsigned GP1                    :1;
6
        unsigned GP2                    :1;
7
        unsigned GP3                    :1;
8
    };
9
} GPIObits_t;
10
extern volatile GPIObits_t GPIObits __at(0x006);

Also dachte ich - naiv wie ich bin - dass folgender Code
1
  GPIO &= 0b001000; // set each "output" low
2
  OPTION = 0b10111111; 
3
  
4
  GPIObits.GP2 = 1;
5
  GPIObits.GP1 = 1;
6
  GPIObits.GP0 = 1;


folgendes Ergebnis ergibt:

GPIO = 0b00001111

Aber, es kommt folgendes heraus:

GPIO = 0b00001001

Kann mir das jemand erklären ?
Ich könnte natürlich auch einzelne Bits mit OR/XOR/AND-Operationen auf 
GPIO selbst setzen, aber die struct-Varante ist irgendwie schöner (wenn 
sie funktionieren würde).

Viele Grüße
Harry

PS.:  Siehe auch den Screenshot aus der MPLAB X IDE

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


Lesenswert?

Bitte beachten, dass diese PICs nicht jenen Zustand lesen, den du 
reingeschrieben hast, sondern stets den Zustand des Pins selbst. Wenn du 
in einen Pin mit schwachem Pullup eine 1 reinschreibst, der Pin aber 
extern runter gezogen wird, liest du eine 0 zurück. TRIS mischt auch 
noch mit.

Dieses Verhalten kann zu recht überraschenden Effekten führen und ist 
der Grund, weshalb neuere Architekturen zwischen den Registern für 
Output und für Input unterscheiden.

: Bearbeitet durch User
von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Harry R. schrieb:
> Kann mir das jemand erklären ?
Ich würde mir einfach mal den aus der C-Datei erzeugten Assemblercode 
ansehen, da sieht man dann, ob und wie so ein Bit gesetzt wird.

: Bearbeitet durch Moderator
von Harry R. (harryr)


Lesenswert?

Lothar M. schrieb:
> Harry R. schrieb:
>> Kann mir das jemand erklären ?
> Ich würde mir einfach mal den aus der C-Datei erzeugten Assemblercode
> ansehen, da sieht man dann, ob und wie so ein Bit gesetzt wird.
1
!GPIObits.GP2 = 1;
2
0x174: BSF GPIO, 0x2
3
!GPIObits.GP1 = 1;
4
0x175: BSF GPIO, 0x1
5
!GPIObits.GP0 = 1;
6
0x176: BSF GPIO, 0x0

Hmmm Assemblertechnisch bin ich nicht so bewandert,
aber, wenn BSF VARIABLE, X bedeutet, dass das X-te Bit (gezählt ab 0) 
auf 1 gesetzt wird, dann ist mein Code okay.

Grüßle

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Da steht was zu aufeinanderfolgenden read-modify-write Zugriffen:
* https://www.microchip.com/forums/m147383.aspx
* Beitrag "PIC read modify write Problem"

Ich würde das mehrfache R-M-W aus dem Prozess entfernen und die Variante 
mit dem Schattenregister wählen: schreib alle deine Änderungen in ein 
lokales Register und schreibe dieses Register am Ende der gesammelten 
Portzugriffe auf das Portregister.

Dazu brauchst du natürlich einen Programmablauf, bei dem die 
Hauptschleife dauernd durchlaufen, an ihrem Anfang die Eingänge gelesen, 
diese Information bearbeitet und das Ergebnis am Ende rausgeschrieben 
wird. Und das dann hunterte bis zigtausendmal pro Sekunde.

von Gasheizer (Gast)


Lesenswert?

Du olltest A.K. Vorschlag folgen.
Wenn ich mich recht entsinne, wird selbt im Datenblatt davor gewarnt,
an den GPIO-Bits einzeln herumzuspielen.
Richtig benutzt man entweder den Ausgabelatch, wenn der verwendete
PIC den hat, oder ein Schattenregister das man dann nach der
Bitkippelei komplett(!) ins GPIO schreibt.

von Harry R. (harryr)


Lesenswert?

Gasheizer schrieb:
> Du olltest A.K. Vorschlag folgen.
> Wenn ich mich recht entsinne, wird selbt im Datenblatt davor gewarnt,
> an den GPIO-Bits einzeln herumzuspielen.
> Richtig benutzt man entweder den Ausgabelatch, wenn der verwendete
> PIC den hat, oder ein Schattenregister das man dann nach der
> Bitkippelei komplett(!) ins GPIO schreibt.

Wenn ich wüsste, was ein Schattenregister ist,
würde ich das natürlich testen ;-)

von (prx) A. K. (prx)


Lesenswert?

Harry R. schrieb:
> Wenn ich wüsste, was ein Schattenregister ist,
> würde ich das natürlich testen ;-)

Beitrag "Re: PIC read modify write Problem"

von Gasheizer (Gast)


Lesenswert?

Such mal nach der DS33023A.

Da den Abschnitt "9.10  I/O Programming Considerations"

von Roland F. (rhf)


Lesenswert?

Hallo,
Harry R. schrieb:
> Wenn ich wüsste, was ein Schattenregister ist,
> würde ich das natürlich testen ;-)

Du setzt in einem (freien) Register des Prozessor die entsprechenden 
Bits und kopierst dann den Inhalt dieses Registers "in einem Rutsch" in 
den jeweiligen GPIO.

rhf

von Jens M. (schuchkleisser)


Lesenswert?

Da jeder Befehl in PICs 4 Takte braucht und das Lesen am Anfang, das 
Schreiben jedoch erst am Ende passiert, schreibt dein 1. BSF gerade das 
Bit, wenn der letzte BSF die Eingänge liest.
Dieser setzt dann das gelesene Muster.

Du musst einfach ein paar NOPs einbauen (oder was anderes sinnvolles 
tun) und es wird gehen, wenn die Hardware nicht allzu stark an den Pins 
zieht.
Wenn sie es doch tut und/oder du keinen Bock hast auf solche Sachen zu 
achten, nutze ein Schattenregister.

Wat is'n dette? hör ich da...

Entweder hat die Hardware eins (also ein Register, das rein und 
ausschließlich schreibend auf die Hardware wirkt, auch wenn man es 
selbst lesen kann) oder ein Stück RAM, in dem du so tust als würdest du 
dich über leuchtende LEDs freuen, und immer wenn du meinst jetzt wäre 
ein guter Zeitpunkt die ganzen Änderungen mal nachzutragen machst du 
MOVF x,W und MOVWF GPIO.

von Nop (Gast)


Lesenswert?

Harry R. schrieb:

>   GPIObits.GP2 = 1;
>   GPIObits.GP1 = 1;
>   GPIObits.GP0 = 1;

Das ist schon deswegen eine schlechte Idee, weil der C-Standard nicht 
definiert, wie die Bits in einem Bitfield angeordnet sind. Sie sind 
ausschließlich zum Speichersparen gedacht, aber nicht für 
Register-Mapping.

von W.S. (Gast)


Lesenswert?

Gasheizer schrieb:
> Du olltest A.K. Vorschlag folgen.
> Wenn ich mich recht entsinne, wird selbt im Datenblatt davor gewarnt,
> an den GPIO-Bits einzeln herumzuspielen.

Das hast du nur flüchtig gelesen. Wenn man alle PortPins als Ausgang 
konfiguriert hat, dann ist das einzelne Setzen völlig OK, aber wenn man 
Eingänge am Port dabei hat, dann kommt in das eigentlich abgeschaltete 
Pin-Flipflop eben der Zustand, den das Pin grad hat. Das ist eigentlich 
völlig ungefährlich, da der Pin ja ein Eingang ist. Aber wenn man 
glaubt, in dem zwar zugänglichen aber abgeschalteten FF sich irgend 
etwas merken zu wollen, dann geht das schief.

W.S.

von W.S. (Gast)


Lesenswert?

Nop schrieb:
> Das ist schon deswegen eine schlechte Idee, weil der C-Standard nicht
> definiert, wie die Bits in einem Bitfield angeordnet sind.

Naja, so ein kleiner PIC hat zum einen nur einen recht kleinen Platz für 
Code aber zum anderen nette Maschinenbefehle, mit denen man ein 
einzelnes Bit setzen und testen kann. Sowas kann man jedoch nur in 
Assembler richtig ausnutzen. Sowas wie C ist dafür nicht eingerichtet. 
Das ist eben das Problem, wenn man Programmiersprachen erfinden will, 
die hardwareunabhängig sein sollen. Die können dann naturgemäß nicht auf 
einzelne Details irgendeiner Plattform eingehen.

W.S.

Beitrag #7329955 wurde vom Autor gelöscht.
von (prx) A. K. (prx)


Lesenswert?

W.S. schrieb:
> Naja, so ein kleiner PIC hat zum einen nur einen recht kleinen Platz für
> Code aber zum anderen nette Maschinenbefehle, mit denen man ein
> einzelnes Bit setzen und testen kann.

Nein, die hat er auch in Asm-Code nicht wirklich, auf Portbits bezogen. 
Befehle wie BSF manipulieren kein einzelnes Portbit, sondern lesen den 
ganzen Port, ändern ein Bit, und schreiben zurück. Und genau das ist das 
Problem. Siehe Datasheet Abschnitt 5.4. "I/O Programming 
Considerations".

8051 Pins arbeiten von Haus aus als O.D. mit Pullup, aber während deren 
Port-Read Befehle den Zustand der Pins lesen, lesen Read-Modify-Write 
Befehle das Latch, was Bitoperationen absichert. Ersetzt man "Port |= 
Maske" durch "Port = Port | Maske" (ohne entsprechende Optimierung), hat 
man bei 8051 das gleiche Problem, was eigentlich inkompatibel zur 
Definition von C ist.

: Bearbeitet durch User
von Gasheizer (Gast)


Lesenswert?

> Das hast du nur flüchtig gelesen.

Da bislang alle verbauten PICs, und das sind eine ganze Menge,
das tun was sie sollen, habe ich wohl doch genau genug gelesen.
Das war auch mehr der Wink mit dem Zaunpfahl an den TO,
sich den Abschnitee genau durchzulesen.
Im uebrigen habe ich ja auch noch auf DS33023 verwiesen.

Man muss auch immer bedenken, dass eine Schaltung/Geraet in
jeder Umgebung funktionieren sollte. Und das dann kapazitive
Lasten wenn geschludert wurde, sonderbare :) Effekte ausloesen
koennen...

> zum anderen nette Maschinenbefehle, mit denen man ein
> einzelnes Bit setzen und testen kann.

Insbesondere die kleinen PICs erfreuen sich bei mir zumeist
an einem Mix aus XC-8 C und XC-8 Assembler.

von Gasheizer (Gast)


Lesenswert?

@ W.S.

> Wenn man alle PortPins als Ausgang
> konfiguriert hat, dann ist das einzelne Setzen völlig OK

Schliess mal an die Ausgaenge Kondensatoren von 1 uF an.
Nicht das ich das tun wuerde. Aber Kunden machen sowas...
Dann wirst du sehen wie wunderbar das schief geht :).

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Harry R. schrieb:
> Dabei ist mir aufgefallen, dass das Setzen von einzelnen Bits in einem
> bitfield nicht so funktioniert, wie ich mir das dachte.
Wenn es nur so ein kapazitiver Effekt ist, der den Fehler auslöst, dann 
hast du  hast du gute Chancen, dass dein Programm "funktioniert", wenn 
du in Einzelschritten von Hand durch die drei Zeilen durchgehst...

: Bearbeitet durch Moderator
von Harry R. (harryr)


Lesenswert?

Danke erst mal für die Erläuterungen der technischen Hintergründe.

Was mich ein wenig stutzig macht, ich teste das Ganze ja vorerst in 
einer Simulation, da kann ja im Grunde kein Input-Pin in die Quere 
kommen, denn das kann ich ja selbst beeinflussen (und triggere eben 
gerade keinen Input).

Eine kurze Frage zur Initialisierung des PIC10F202 und die 
Implementierung in meinem Progrämmchen..
1
  
2
  TRIS = 0b110111; // configure GP3 (only) as an input
3
  GPIO &= 0b001000; // set each out low
4
5
  // bit 6 GPPU: Enable Weak Pull-ups bit (GP0, GP1, GP3)
6
  // 1 = Disabled
7
  //0 = Enabled
8
  OPTION = 0b10111111;

Stimmt das so ?
Für GP2 gibt es keinen konfigurierbaren Pullup ?

Wenn ich lieber einen Pulldown hätte, müsste ich einen Masse-Widerstand 
am entsprechenden Pin anbringen, welchen Wert würde man da nehmen, wenn 
man
bereits intern einen Pullup konfiguriert hat (man kann das ja leider nur 
für alle 3 Pins konfigurieren) ?

Die beste Lösung wäre wohl dann, die internen Pullups nicht zu 
konfigurieren
und die Pullup/Pulldown mit je einem externe Widerstand (? Ohm) zu 
realisieren ?

Danke und Grüße

Harry

von Gasheizer (Gast)


Lesenswert?

Das hier wird fuer einen nichtsimulierten PIC nicht reichen:

<pre>
  // bit 6 GPPU: Enable Weak Pull-ups bit (GP0, GP1, GP3)
  // 1 = Disabled
  //0 = Enabled
  OPTION = 0b10111111;
</pre>

Wenn man Pins nicht als Eingang benutzen will, definiert man
sie als Ausgang. Was man an das MCLR Pin anschliesst,
sollte im Datenblatt mit Schaltung und Erklaerung dazu stehen.

Ansonsten kann man deine Fragen nur mit der Universalantwort:
"Es haengt davon ab." beantworten.

Datenblaetter sind dazu da, solche Einfachstfragen allumfassend
zu beantworten. Wenn man sie liest. Und versteht.

von W.S. (Gast)


Lesenswert?

Gasheizer schrieb:
> Schliess mal an die Ausgaenge Kondensatoren von 1 uF an.

Scherzbold! Ich habe oft genug dagegen gewettert, daß z.B. FET's direkt 
mittels Portpins geschaltet werden, was man hier in diesem Forum fast 
jeden Tag findet. Zumal es genug Gatetreiber gibt, die so etwas 
zuverlässig erledigen.

(prx) A. K. schrieb:
> Nein, die hat er auch in Asm-Code nicht wirklich, auf Portbits bezogen.

Er hat diese Maschinenbefehle. Das Gegenteil kann man bei Chips mit 
Load-Modify-Store Architekturen sehen, da braucht es 3 Maschinenbefehle 
dafür. Und da im betreffenden Befehl bei den PIC sowohl Adresse als auch 
Bitnummer enthalten ist, kann man bei sinnvoller Implementierung einer 
Bit-Vereinbarung auch sicherstellen, daß man nicht versehentlich eine 
Bitnummer zusammen mit einer falschen Adresse anwendet. In Assembler 
geht das, in maschinenunabhängigen Sprachen eben leider nicht. 
Allerdings hat selbst Microchip das noch nicht richtig gemerkt. Es ist 
doch einfacher und leserlicher, wenn man schreibt:
CE_LCD:   BIT   PortB, 0
...
          BSF    CE_LCD
anstelle
          BSF    PortB, CE_LCD

Und wie ein Maschinenbefehl physisch funktioniert, ist ein anderes Thema 
als daß es Maschinenbefehle zum Hantieren mit einzelnen Bits gibt.

W.S.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Angehängte Dateien:

Lesenswert?

Harry R. schrieb:
> und triggere eben gerade keinen Input
Welchen Pegel legst du an den Eingangspin an?
Oder andersrum: welchen Pegel siehst du am IO-Pin bei Single-Step?

: Bearbeitet durch Moderator
von Gasheizer (Gast)


Lesenswert?

> welchen Pegel siehst du am IO-Pin bei Single-Step?

Na den, den er im Simulator einstellt :).

von W.S. (Gast)


Lesenswert?

Harry R. schrieb:
> ich habe es eben geschaft mein erstes Programm für den PIC10F202
> zu debuggen (ich bitte um Applaus :-)

Bittesehr: Du bist ein Held!

> Dabei ist mir aufgefallen, dass das Setzen von einzelnen Bits in einem
> bitfield nicht so funktioniert, wie ich mir das dachte.

Ich kannte zwar mal jemanden, der da meinte "ich sehe keinen Grund, so 
einen PIC NICHT in C zu programmieren" - aber ich teile solche Ansicht 
nicht. Der von dir genannte PIC hat (wimre) noch nicht einmal 1 K an 
Programmspeicher, also kann dessen Flash wohl nur maximal 512 
Maschinenbefehle speichern. Und der Umfang an Maschinenbefehlen ist 
gering, es sind nur 33 verschiedene Befehle (oder waren es nur 32 ?). 
Bei so kleinen Plattformen sehe ich als Programmiersprache nur 
Assembler, denn alles andere ist etwa so wie mit dem SUV mal eben zum 
Bäcker um die Ecke zum Brötchen holen zu fahren. Der braucht zum 
Anlassen und aus der Parklücke zu rangieren doppelt so viel Sprit wie 
für die eigentliche Strecke.

Ich hoffe nur, daß du nicht auch auf die Idee kommst, auf diesem PIC 
sowas wie printf benutzen zu wollen. Versuche dich lieber mal in 
Assembler, das erscheint mir leichter, als auf so einer Nußschale deine 
gewünschte Funktionalität in C formulieren zu wollen.

W.S.

von Stefan F. (Gast)


Lesenswert?

W.S. schrieb:
> Versuche dich lieber mal in Assembler, das erscheint mir leichter,
> als auf so einer Nußschale deine gewünschte Funktionalität in C
> formulieren zu wollen.

Als ich das las kam mir spontan der Gedanke, dass du wahrscheinlich 
total übertreibst, aber ...

... das ist ja wirklich eine Nußschale. Aber Hallo! Ich wusste gar 
nicht, dass es so kleine Mikrocontroller gibt.

von (prx) A. K. (prx)


Lesenswert?

Stefan F. schrieb:
> ... das ist ja wirklich eine Nußschale. Aber Hallo! Ich wusste gar
> nicht, dass es so kleine Mikrocontroller gibt.

Diese PIC10 sind im Grunde lebende Fossilien. Sie stammen wenig 
verändert vom allerersten PIC ab, dem PIC1650 von 1976. Aber es gibt 
eben Aufgaben, wo das ausreicht.

Der Befehlssatz war schon damals auf diese 512 Worte à 12 Bits 
optimiert, von denen sogar nur 256 Worte universell ansprechbar sind. 
Mehr als diese, und mehr als die 32 Bytes Datenadressraum für RAM und 
I/O-Registern, sind nicht ohne Bank-Switching machbar. Der '200 hat 
sogar nur 256 Worte und 16 statt 24 Bytes RAM freigegeben.

Warum man sich allerdings ausgerechnet sowas als Lernplattform 
aussucht... Und da muss ich W.S. ausnahmsweise Recht geben: ASM 
bevorzugt.

: Bearbeitet durch User
von Gasheizer (Gast)


Lesenswert?

Es ist zwar nur eine Bequemlichkeitsfrage, aber was mich an
6 Pinnern stoert, ist das man den ICSP-Adapter entweder
abziehen oder "eindesignen" muss.

Wieso man sich als Anfaenger diese Zwerge antut? Keine Ahnung.

Selbst die aeltesten und sparsam ausgestatteten 12F675 und
12F683 sind da um Groessenordnungen komfortabler und vermutlich
wegen groesserer Stueckzahlen obendrein billiger.

von c-hater (Gast)


Lesenswert?

Stefan F. schrieb:

> ... das ist ja wirklich eine Nußschale. Aber Hallo! Ich wusste gar
> nicht, dass es so kleine Mikrocontroller gibt.

Der Punkt ist aber eigentlich ein anderer, nämlich:

Es wird bei der ganz kleinen Hardware nur besonders deutlich, dass 
Assembler rules, weil es dort über geht oder geht nicht für eine 
konkrete Anwendung entscheiden kann.

Aber: auch bei den größeren Maschinen ist ein liebevoll handoptimiertes 
Assemblerprogramm immer schneller als das, was Compiler hervorbringen 
können.

Das Problem ist eigentlich nur, dass man erheblichen Zeitaufwand in so 
ein Assemlerprogramm versenken muss. Zeit ist Geld. Und da wird es dann 
schnell sehr attraktiv, Asm Asm sein zu lassen und einfach auf fettere 
Hardware umzuschwenken, die halt schnell genug ist, um auch die 
suboptimalen Compilate hinreichend schnell ausführen zu können...

Die (noch nicht ganz überstandene) Lieferkrise bei der Hardware hat hier 
allerdings einiges in Bewegung gebracht. Extreme Preissteigerungen bei 
der Hardware und teilweise Nicht-Verfügbarkeit haben es wieder 
finanziell attraktiver gemacht, bei der Software nicht mehr nach der 
"was kost' die Welt"-Methode vorzugehen, sondern mal wieder ernsthaft 
über die Effizienz des Codes nachzudenken. Muss ja nicht immer zu Asm 
führen...

von Gasheizer (Gast)


Lesenswert?

> ein liebevoll handoptimiertes Assemblerprogramm

Hast du ueberhaupt schon mal die (Midrange-)PICs in Assembler
programmiert?

Weisst du was der XC-8 Compiler an Optimierung leistet?

Oder sonderst du hier nur Heissluft ab?

von Volker S. (vloki)


Lesenswert?

Als ich das erste Mal so einen Winzling in C programmiert habe,
war ich ehrlich gesagt ziemlich erstaunt, wir gut das Ergebnis
trotz fehlender Optimierung usw. beim xc8 war.

Da das Programm für einen 10F wirklich nicht sehr umfangreich sein kann, 
kann man meiner Meinung durchaus mal testen es in C zu schreiben, wenn 
man in der Lage ist den Maschinencode der dabei heraus kommt zu 
bewerten. Ist meiner Meinung nach auf jeden Fall erheblich lesbarer als 
Assembler.

Zugegebenermaßen war es bei mir ein 10F3xx der schon zu den 
Midrangetypen zählt und ein LATCH Register hat, das man auch lesen 
kann...

von Nop (Gast)


Lesenswert?

c-hater schrieb:

> Die (noch nicht ganz überstandene) Lieferkrise bei der Hardware hat hier
> allerdings einiges in Bewegung gebracht.

Aber eher nicht mit mehr Assembler, weil das nicht portabel ist. Eine 
Anwendung mit brauchbarer Schichten-Architektur kann man portieren, 
wenngleich man die Lowlevel-Schicht neu machen muß - aber erstens nur 
die, und zweitens geht auch das in C schneller als in Assembler.

Drittens hat man spätestens danach die Beschaffungsoption mit "second 
source" und hat damit eine andere Verhandlungsbasis, falls man groß ist, 
und die Möglichkeit, jederzeit auf Marktpreise zu reagieren, falls man 
klein ist.

> Extreme Preissteigerungen bei der Hardware

Jo, und wenn man eine Anwendung hat, die auf diese CPU festgenagelt ist, 
weil in Assembler geschrieben, wird man so ziemlich jeden Preis zahlen. 
Preis-unelastische Nachfrage ist ja in einer Marktwirtschaft der Grund 
für extreme Preissteigerungen bei Knappheit.

von Jens M. (schuchkleisser)


Lesenswert?

Immer dieses Rumgereite auf der Portabilität von C-Code.
Die Geräte bestehen zu etwa einem Prozent aus CPU, auch wenn ein großer 
Teil der Funktionalität mittlerweile auf der Software basiert, so ist 
doch wesentlich mehr an Chips beteiligt die ebenfalls knapp sind und 
kaum ersetzbar.
Die zahlreichen Geräte aus allen möglichen Teilen der Industrie die ich 
kenne  sind jedenfalls deutlichst teurer geworden, weil ein Softwareport 
auf einen anderen Prozessor genau gar nichts bringt, wenn man die 
anderen ICs nicht mehr bekommt.
Also muss man eh neu designen, und da lässt man dann die Software 
laufen, denn 10€ pro CPU mehr oder 10€ pro Gerät für den Port mehr ist 
wurscht.

Ich kenne jedenfalls kein einziges Produkt wo die ach so gelobte 
Portabilität genutzt wurde.

von (prx) A. K. (prx)


Lesenswert?

Nop schrieb:
> Aber eher nicht mit mehr Assembler, weil das nicht portabel ist. Eine
> Anwendung mit brauchbarer Schichten-Architektur kann man portieren,

Wobei so ein PIC10 nicht wirklich zu komplexer Software-Architektur 
einläd. Da sitzt ein C-Programm genauso unabstrakt auf der Hardware wie 
ein Assembler-Programm und das grösste Problem der Portierung liegt bei 
Asm in der armen Sau, die sich nach Abgang des einzigen PIC-Experten mit 
einem Befehlssatz rumärgern darf, in dem alles anders heisst, als sonst 
üblich.

Schätze, dass so mancher PIC10 nicht viel mehr ist, als ein digitaler 
stromsparender Ersatz eines NE555. Ein paar Zeilen Initialisierung, 
vielleicht völlig ohne Hauptprogramm.

: Bearbeitet durch User
von Nop (Gast)


Lesenswert?

Jens M. schrieb:

> Also muss man eh neu designen

Und die ganze Software komplett neu schreibt, oder wie? Naja, wenn's 
nicht mehr als ein LED-Blinky ist, mag das noch angehen.

Ansinsten habe ich in realen Projekten schon Hardware-Abstraktion 
braucbar implementiert gesehen von dem Level, wo mit Evalboard und 
Steckerleiste die SW parallel zum eigentlichen HW-Design gemacht wurde 
(mit sehr unterschiedlicher Pinbelegung) bis dahin, daß die SW im Mockup 
am PC laufen kann - einfach, indem in der Build-Konfig das unterste 
Layer getauscht wird.

Letzteres bedeutet hatürlich eine tatsächliche Hardware Abstraction 
Layer und nicht bloß die Umbenennung von Registern in Structs, wie das 
bei STs Möchtegern-HAL der Fall ist.

von Jens M. (schuchkleisser)


Lesenswert?

(prx) A. K. schrieb:
> Schätze, dass so mancher PIC10 nicht viel mehr ist, als ein digitaler
> stromsparender Ersatz eines NE555. Ein paar Zeilen Initialisierung,
> vielleicht völlig ohne Hauptprogramm.

Lach dich tot, genau dazu isser gemacht. Kleinste einfachste Aufgaben 
die sich gerade eben nicht mehr mit einem NE555 erledigen lassen und 
oder mehr Bauteile bräuchten kann man hier mit wenigen Zeilen, Teilen 
und Moneten erledigen.

Nop schrieb:
> Und die ganze Software komplett neu schreibt, oder wie?

Bei den Projekten die ich zu bearbeiten die Ehre hatte in den letzten 25 
Jahren: ja. "Ist eh alt, machen wir komplett neu, muss eh neu zugelassen 
werden".
Da wurden höchstens die grundsätzlichen Ideen des alten Codes 
übernommen.

von Gasheizer (Gast)


Lesenswert?

> Ansinsten habe ich in realen Projekten schon Hardware-Abstraktion
> braucbar implementiert gesehen

Das ist fuer kleine 8 bit PICs voellig ueberzogen.
Es reicht da voellig, Teilfunktionen zu kapseln.

> Aber eher nicht mit mehr Assembler

Genau du bist wahrscheinlich nicht in der Zielgruppe.
Wenn man die besonderen Eigenschaften der Architektur nutzen will,
fuehrt an Assembler zumindest in Teilfunktionen kein Weg vorbei.
Das kann man entweder mit Inlineassembler oder wenn es mehr wird,
mit separatten Assemblerquellen tun.

> wenn man eine Anwendung hat, die auf diese CPU festgenagelt ist

Wenn der eindesignte Wunsch-PIC nicht verfuegbar sein sollte,
wird man mit einiger Sicherheit einen alternativen Typ finden,
der die benoetigte Peripherie enthaelt.
Aber z.B. einen groesseren Flash hat.
Die Standardperipherie ist ueber alle Typen sehr uniform,
was einen Wechsel erleichtert.

> es in C zu schreiben

Ja.
Die strukturierenden Elemente koennen natuerlich in C geschrieben sein,
was die Uebersicht und die Lesbarkeit verbessert.
Der XC8-Compiler hat aber architekturbedingt seine Eigenarten
die man kennen sollte.

Ein
> liebevoll handoptimiertes Assemblerprogramm

tut man sich auch nur an, um bestimmte Timingvorgaben bei der
Erzeugung von Signalablaeufen in Software zu erfuellen.

von John (Gast)


Lesenswert?

Harry R. schrieb:
> Eine kurze Frage zur Initialisierung des PIC10F202 und die
> Implementierung in meinem Progrämmchen..
> 1
> 2  TRIS = 0b110111; // configure GP3 (only) as an input
> 3  GPIO &= 0b001000; // set each out low
> 45  // bit 6 GPPU: Enable Weak Pull-ups bit (GP0, GP1, GP3)
> 6  // 1 = Disabled
> 7  //0 = Enabled
> 8  OPTION = 0b10111111;
>
> Stimmt das so ?

Eine „1“ im TRIS-Register definiert den entsprechenden Pin als Eingang, 
und bei „0“ ist der Pin als Ausgang konfiguriert.

Gruß
John

von Stefan F. (Gast)


Lesenswert?

c-hater schrieb:
> Es wird bei der ganz kleinen Hardware nur besonders deutlich,
> dass Assembler rules

War klar dass du das so aufgreifst. Man könnte aber auch sagen, dass 
Assembler eben nicht mehr "rules" weil diese extrem schwachen 
Mikrocontroller kaum noch relevant sind.

> Aber: auch bei den größeren Maschinen ist ein liebevoll handoptimiertes
> Assemblerprogramm immer schneller als das, was Compiler hervorbringen
> können.

Premature optimization führt dort wo ich arbeite zur Kündigung. Solange 
der Computer schnell genug funktioniert, verschwendet man damit unnötig 
Zeit und macht das Programm unnötig kompliziert.

> Das Problem ist eigentlich nur, dass man erheblichen Zeitaufwand
> in so ein Assemlerprogramm versenken muss. Zeit ist Geld.

So ist es. Bei Hobbyprojekten kann man sich den Aufwand eher leisten, 
wenn man will.

von Jens M. (schuchkleisser)


Lesenswert?

Stefan F. schrieb:
> Solange
> der Computer schnell genug funktioniert, verschwendet man damit unnötig
> Zeit und macht das Programm unnötig kompliziert.

Ach daher kommen die unglaublichen Anforderungen und Updategrößen für 
triviale Aufgaben...

von (prx) A. K. (prx)


Lesenswert?

Stefan F. schrieb:
> weil diese extrem schwachen
> Mikrocontroller kaum noch relevant sind.

Atmel brachte recht spät mit den ATtiny4..10 eine direkte Konkurrenz zu 
den PIC10. Ganz so irrelevant schien diese Klasse für Atmel folglich 
nicht zu sein.

von Harry R. (harryr)


Lesenswert?

Hallo Leute,

ich habe jetzt alle Dokumentationen und Datenbätter zum PIC10F202 
gelesen und hoffentlich verstanden.
Wenn ich es richtig verstanden habe ist ein Schatten-Register nichts 
weiter als eine (temp.) Variable, in die ich einen Wert aus einem 
Reister (hier GPIO) kopiere, dort "bearbeite" und dann in das Register 
zurückkopiere !?
(Schatten-Register ist also nur ein Synonym für ene temp. Variable).

Ich habe jetzt ein kleines Testprogramm geschrieben, das nichts weiter 
machen soll, als in GPIO0-GPIO2 eine 1 bzw eine 0 zu schreiben (bzw, vom 
PIN aus gesehen, High- bzw Low-Level setzen).

Wie der Teufel so will, funktioniert das Ganze bis auf eine Winzige 
Kleinigkeit, das Schreiben einer 1 in GPIO2 funktioniert einfach nicht.
Ob es mit dem Wert 0 funktioniert weiß ich nicht, da GPIO2 ja immer 0 
ist (egal, was ich mache)
Ich zeige hier mal meine C-Source, die sicher nicht optimal ist (weil 
ich inzwischen auch alles ausprobiert habe um GPIO2 willig zu machen, 
hat aber bisher nicht funktioniert). Rahmenbedingung des Programms ist 
dass GPIO0-GPIO2 outputs sind GPIO3 ist (natürlich) ein Input.
1
/**************************************************************************
2
#if defined(__XC)
3
    #include <xc.h>         /* XC8 General Include File */
4
#elif defined(HI_TECH_C)
5
    #include <htc.h>        /* HiTech General Include File */
6
#endif
7
8
#include <stdint.h>        /* For uint8_t definition */
9
#include <stdbool.h>       /* For true/false definition */
10
11
12
// no ext reset, no code protect, no watchdog
13
#pragma config MCLRE = OFF, CP = OFF, WDTE = OFF
14
#define _XTAL_FREQ 4000000 // oscillator frequency for _delay()
15
16
#define GPIO0BIT 1
17
#define GPIO1BIT 2
18
#define GPIO2BIT 4
19
20
uint8_t sGPIO;
21
22
void setGPIOOUT(uint8_t bitval)
23
{
24
  sGPIO |= bitval; // toggle shadow bit corresponding to GP1
25
  GPIO = sGPIO; // write to GPI
26
  NOP();
27
  NOP();
28
  NOP();
29
}
30
31
void unsetGPIOOUT(uint8_t bitval)
32
{
33
  sGPIO &= ~bitval; // toggle shadow bit corresponding to GP1
34
  GPIO = sGPIO; // write to GPI
35
  NOP();
36
  NOP();
37
  NOP();
38
}
39
40
void main(void)
41
{
42
    sGPIO = 0; // shadow copy of GPIO
43
    TRIS = 0b11111000;
44
45
    while (1)
46
    {
47
       setGPIOOUT(GPIO2BIT);
48
       setGPIOOUT(GPIO0BIT);
49
       setGPIOOUT(GPIO1BIT);
50
          
51
       unsetGPIOOUT(GPIO0BIT);
52
       unsetGPIOOUT(GPIO1BIT);
53
       unsetGPIOOUT(GPIO2BIT);
54
    }
55
    
56
}

Ich verwende MPLAB X IDE v6.05 mit xcu (2.40) unter Windows10 UND Ubuntu 
22.04 LTS (was  bzgl. des Problems keinen Unterschied macht, aber ich 
probiere gerne alles aus, wenn es zielführend ist).

Bin mal gespannt, ob  ich da ein Brett vorm Kopf habe oder was das 
Problem auch immer verursacht.

Grüßle
Harry

von Peter D. (peda)


Lesenswert?

(prx) A. K. schrieb:
> Atmel brachte recht spät mit den ATtiny4..10 eine direkte Konkurrenz zu
> den PIC10. Ganz so irrelevant schien diese Klasse für Atmel folglich
> nicht zu sein.

Ja, wohl auch deshalb, weil die AVRs für C optimiert sind.
Die ATtiny4..10 haben einen echten Stack im SRAM, Interrupts, Timer, 
ADC. Nur der EEPROM fehlt, kann aber im Flash emuliert werden.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Harry R. schrieb:
> in die ich einen Wert aus einem Reister (hier GPIO) kopiere, dort
> "bearbeite" und dann in das Register zurückkopiere !?
Fast richtig. In deinem Fall ist es aber ein Register, wo du das 
gewünschte Bitmuster für die Ausgänge erzeugst und das dann von diesem 
"Schattenregister" ohne Read-Modify-Write direkt geradeaus auf den 
Ausgang schreibst.

Worauf basieren diese "Angst-NOPs"? Genau die brauchst du nicht mehr, 
wenn du nur schreibst und keine Read-Modify-Write-Zugriffe machst.

Oder andersrum: dich interessiert in deinem Fall überhaupt nicht, 
welchen Pegel der Ausgangspin gerade hat, deshalb musst du ihn auch 
niemals lesen.

> das Schreiben einer 1 in GPIO2 funktioniert einfach nicht.
Nur im Simulator? Oder auch in echt?

> unset
Wieder ein überraschender neuer Name für "reset" oder "clear".


Wie schon gesagt: ich würde das Rausschreiben pro Mainloop-Durchlauf nur 
1x machen. Eben nicht gleich jedesmal, wenn sich irgendein Bit geändert 
hat. Aber keine Sorge: auf diesen Programmierstil mit der 
schnellstmöglich durchlaufenden Mainloop und den Zustandsautomaten wirst 
du im späteren Verlauf der Programmierkarriere auch noch kommen  ;-)

von Peter D. (peda)


Lesenswert?

c-hater schrieb:
> Das Problem ist eigentlich nur, dass man erheblichen Zeitaufwand in so
> ein Assemlerprogramm versenken muss. Zeit ist Geld. Und da wird es dann
> schnell sehr attraktiv, Asm Asm sein zu lassen und einfach auf fettere
> Hardware umzuschwenken

Die Hardware muß nichtmal riesig fett sein für C. Schon ein ATtiny10 
läßt die Vorteile von C benutzen und damit schneller und deutlich 
weniger fehleranfällig programmieren.

Das Problem mit den RMW-Zugriffen auf die Portpins haben die AVRs auch 
elegant gelöst. Ich würde das Fehlverhalten der PIC als Bug einstufen. 
Es ist nämlich vom CPU-Takt abhängig, ob der Bug auftritt oder nicht.

von (prx) A. K. (prx)


Lesenswert?

Peter D. schrieb:
> Das Problem mit den RMW-Zugriffen auf die Portpins haben die AVRs auch
> elegant gelöst. Ich würde das Fehlverhalten der PIC als Bug einstufen.

Eine Art Altererscheinung. Als man die PIC10 Architektur in den 1970ern 
konzipierte, war dieser Denkfehler bei I/O-Ports weit verbreitet. Die 
AVRs kamen zu einem Zeitpunkt raus, zu dem dieses Problem bereits 
bekannt war.

PICs mit neuerer Architektur haben ein LATx Register für den 
Ausgangszustand, vgl AVR. Aber den PIC10 hat Microchip das nicht 
angedeihen lassen. Vielleicht auch, weil der Adressraum für RAM und 
I/O-Ports mit 32 Bytes ziemlich knapp bemessen ist.

von Harry R. (harryr)


Lesenswert?

Lothar M. schrieb:
> Harry R. schrieb:
>> in die ich einen Wert aus einem Register (hier GPIO) kopiere, dort
>> "bearbeite" und dann in das Register zurückkopiere !?
> Fast richtig. In deinem Fall ist es aber ein Register, wo du das
> gewünschte Bitmuster für die Ausgänge erzeugst und das dann von diesem
> "Schattenregister" ohne Read-Modify-Write direkt geradeaus auf den
> Ausgang schreibst.
Ohne nerven zu wollen (ich will es einfach nur verstehen),
ich definiere mit
1
uint8_t sGPIO;
im Sinne von "C" eine Variable. C läßt mich im unklaren, wo sich diese 
Variable befindet. Warum ist diese Variable denn jetzt ein 
(Schatten)Register ?

> Worauf basieren diese "Angst-NOPs"? Genau die brauchst du nicht mehr,
> wenn du nur schreibst und keine Read-Modify-Write-Zugriffe machst.
Angst NOPs , da hast du recht und sie sind sicher unnötig, aber
was macht man nicht alles um zum Ziel zu kommen :-)
> Oder andersrum: dich interessiert in deinem Fall überhaupt nicht,
> welchen Pegel der Ausgangspin gerade hat, deshalb musst du ihn auch
> niemals lesen.
Ja, stimmt, aber ich möchte in der Simulation ja schon wissen, ob das 
was ich beabsichtige auch passiert.
>> das Schreiben einer 1 in GPIO2 funktioniert einfach nicht.
> Nur im Simulator? Oder auch in echt?
Nur im Simulator oder besser Debugging !
Es kann ja auch ein Fehler in der Entwicklungsumgebung sein.
Ich möchte gerne wissen, ob jemand einen Fehler im Code sieht
oder ob jemand, der/die den Code in seiner IDE ausprobiert genau das 
gleiche sieht wie ich.

>> unset
> Wieder ein überraschender neuer Name für "reset" oder "clear".
set/unset, für mich ist das eine seit langem gängige Bezeichnung für zb 
boolsche oder Bit- oder Zustands-"Dinge" :-)
>
> Wie schon gesagt: ich würde das Rausschreiben pro Mainloop-Durchlauf nur
> 1x machen. Eben nicht gleich jedesmal, wenn sich irgendein Bit geändert
> hat.
In echt wäre nach jedem "set" erst mal ein delay, das jede Menge 
Rechnenzeit verbraucht (im ms-Bereich)
> Aber keine Sorge: auf diesen Programmierstil mit der
> schnellstmöglich durchlaufenden Mainloop und den Zustandsautomaten wirst
> du im späteren Verlauf der Programmierkarriere auch noch kommen  ;-)
Keine Angst, ich programmiere seit Jahrzehnten, aber bei µC gilt es für 
mich erst mal die "Hello World"-Ebene erfolgreich zu verlassen.
Im Grunde ist das, was passiert ja "nur" Zustände zu lesen oder zu 
schreiben und das MUSS rocksolid sein, oder ?
Rechenzeit interessiert mich nicht, ich möchte gute Lösungen für einfach 
Probleme finden.
Mir ist schon klar, dass ich auf dem PIC10F202 keine Tabellenkalkulation 
hinbekomme :-)

von Harry R. (harryr)


Lesenswert?

(prx) A. K. schrieb:
> Peter D. schrieb:
>> Das Problem mit den RMW-Zugriffen auf die Portpins haben die AVRs auch
>> elegant gelöst. Ich würde das Fehlverhalten der PIC als Bug einstufen.
>
> Eine Art Altererscheinung. Als man die PIC10 Architektur in den 1970ern
> konzipierte, war dieser Denkfehler bei I/O-Ports weit verbreitet. Die
> AVRs kamen zu einem Zeitpunkt raus, zu dem dieses Problem bereits
> bekannt war.
>
> PICs mit neuerer Architektur haben ein LATx Register für den
> Ausgangszustand, vgl AVR. Aber den PIC10 hat Microchip das nicht
> angedeihen lassen. Vielleicht auch, weil der Adressraum für RAM und
> I/O-Ports mit 32 Bytes ziemlich knapp bemessen ist.
Das alles beantworte leider meine Frage nicht, selbst wenn ich den 
Aufruf
1
setGPIOOUT(GPIO2BIT);
nur jede Minute mache geht es nicht (in der Simulation mit Step over zb
passiert ja alles höchstens in 10Sec-Schritten).
Dass die PIC alt sind und es bessere Hardware gibt hat ja nichts damit 
zu tun, dass eine "einfache" Aufgabe wie das Setzen von GPIO2 nicht 
funktioniert (wie geschrieben in Der Simulation/Debugging). Da es den 
PIC1F202 schon seit Jahrzehnten gibt, wird auch das Beschreiben von 
GPIO2 seit Jahrzehnten funktionieren , oder ?

Grüßle

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Harry R. schrieb:
> C läßt mich im unklaren, wo sich diese Variable befindet.
Sie ist irgendwo im Speicher.

> Warum ist diese Variable denn jetzt ein (Schatten)Register ?
Weil es in deinem Programmkonzept und Willen liegt, diese Variable als 
"Schatten" des GPIO-Registers zu verwenden. Nur deshalb ist das ein 
"Schattenregister".

> Ich möchte gerne wissen, ob jemand einen Fehler im Code sieht
Dein C-Code hat keinen Fehler. Kannst du deine Änderung an dem 
Schattenregister erkennen? Gibt es im Assemblerfile einen Startup-Code, 
der vor deiner main() ausgeführt wird? Falls ja: was passiert dort?

Harry R. schrieb:
> Dass die PIC alt sind und es bessere Hardware gibt hat ja nichts damit
> zu tun, dass eine "einfache" Aufgabe wie das Setzen von GPIO2 nicht
> funktioniert (wie geschrieben in Der Simulation/Debugging).
Dann probier das doch einfach mal im echten Leben mit einem richtigen 
µC.


BTW und nur weil mir noch keiner eine Antwort gegeben hat:
wo lernt man denn das Plenken?

von Harry R. (harryr)


Angehängte Dateien:

Lesenswert?

Mir ist eben beim "herumspielen" im MPLAB folgendes aufgefallen (siehe 
screenshot)

Irgendwie sieht es so aus, als ob GP2 nicht als Output konfiguriert ist 
..

Grüßle

von Harry R. (harryr)


Angehängte Dateien:

Lesenswert?

Ich klopfe mir mal selbst auf die Schulter (siehe Screenshot) und beende 
den Thread mit einem kleinem entscheidendem Stück C-Code
1
  OPTION = 0b11011111; // GP2 -> TRIS

Grüßle Harry

von Harry R. (harryr)


Lesenswert?

Lothar M. schrieb:
> Harry R. schrieb:
>> C läßt mich im unklaren, wo sich diese Variable befindet.
> Sie ist irgendwo im Speicher.
>
>> Warum ist diese Variable denn jetzt ein (Schatten)Register ?
> Weil es in deinem Programmkonzept und Willen liegt, diese Variable als
> "Schatten" des GPIO-Registers zu verwenden. Nur deshalb ist das ein
> "Schattenregister".
Also ist es eine Variable, die als Wert die Kopie des Wertes eines 
Registers bekommt, "Schattenregister" ist wohl so etwas wie µC-Gebabbel.
>> Ich möchte gerne wissen, ob jemand einen Fehler im Code sieht
> Dein C-Code hat keinen Fehler. Kannst du deine Änderung an dem
> Schattenregister erkennen? Gibt es im Assemblerfile einen Startup-Code,
> der vor deiner main() ausgeführt wird? Falls ja: was passiert dort?
Nein und siehe die Lösung unten.
> Harry R. schrieb:
>> Dass die PIC alt sind und es bessere Hardware gibt hat ja nichts damit
>> zu tun, dass eine "einfache" Aufgabe wie das Setzen von GPIO2 nicht
>> funktioniert (wie geschrieben in Der Simulation/Debugging).
> Dann probier das doch einfach mal im echten Leben mit einem richtigen
> µC.
Schlaumeier, im echten Leben komme ich noch ohne µC aus und das wird 
auch so bleiben,
du bist wohl eine Art Borg, wenn ein µC zu deinem echten Leben gehört 
:-)
>
> BTW und nur weil mir noch keiner eine Antwort gegeben hat:
> wo lernt man denn das Plenken?
Keine Ahnung, wen interessiert das und worauf beziehst du dich ?

von Harry R. (harryr)


Angehängte Dateien:

Lesenswert?

Harry R. schrieb:
> Ich klopfe mir mal selbst auf die Schulter (siehe Screenshot) und beende
> den Thread mit einem kleinem entscheidendem Stück C-Code
>
1
>   OPTION = 0b11011111; // GP2 -> TRIS
2
>
>
> Grüßle Harry

Falscher Screenshot, hier ist der richtige.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Harry R. schrieb:
> Also ist es eine Variable, die als Wert die Kopie des Wertes eines
> Registers bekommt, "Schattenregister" ist wohl so etwas wie µC-Gebabbel.
Ja, tatsächlich ist das ein üblicher Begriff in der Hardware. Und wenn 
man mit µC und konsequenterweise mit hardwarenaher Programmierung 
herummacht, dann sollte man dieses "Gebabbel" als "Sprache" beherrschen. 
Immerhin findet Google dazu 380000000 Treffer: 
https://www.google.com/search?q=shadow+register

Harry R. schrieb:
> Wenn ich lieber einen Pulldown hätte, müsste ich einen Masse-Widerstand
> am entsprechenden Pin anbringen, welchen Wert würde man da nehmen, wenn
> man bereits intern einen Pullup konfiguriert hat (man kann das ja leider
> nur für alle 3 Pins konfigurieren) ?
Der interne Pullup hat irgendwas im Bereich ab 15kOhm aufwärts. Und die 
Schaltschwelle für LOW liegt bei 0,2*Vdd. Ergo muss der Pulldown 
merklich kleiner sein als ein viertel des Pullups. Du müsstest bei 
aktiviertem Pullup also für sicheres Erkennen des LOW-Pegels einen 
Pulldown im Bereich unter 3kOhm nehmen.

Aber der Witz liegt eigentlich in den 6 Worten am Anfang dieses Satzes:
> Wenn ich lieber einen Pulldown hätte
Im Grunde ist es völlig egal, was du lieber hättest. Sondern du 
solltest deine Schaltung so auslegen, wie es der µC gerne hätte.

> du bist wohl eine Art Borg, wenn ein µC zu deinem echten Leben gehört
Nein, ich habe Strom und Internet und verwende täglich viele µC, um mein 
echtes Leben angenehm zu machen. Nur wer irgendwo fernab als 
Selbstversorger in einer Einsiedelei ohne Strom und Internet lebt, 
könnte von sich behaupten, dass kein µC in seinem echten Leben 
auftaucht.

Harry R. schrieb:
> Lothar M. schrieb:
>> wo lernt man denn das Plenken?
> Keine Ahnung,
Ok, akzeptiert.
> wen interessiert das
Wie gesagt: mich.
> und worauf beziehst du dich ?
Auf die fehlerhaften Leerzeichen vor manchen Satzzeichen:
https://de.wikipedia.org/wiki/Plenk
Und meine Frage ist: warum machst du die? Wo hast du das gelernt?
Ich frage das nur, weil wirklich viele das machen und mir wie gesagt 
noch keiner eine Antwort gegeben hat.

Ein Grund kann sein: ich wohne in Frankreich! Das gilt als Argument, 
dort lernt man das so. Allerdings als nichttrennbares Leerzeichen, das 
fest mit dem vorhergehenden Wort verbunden ist und deshalb niemals eine 
eigene Zeile bekommt. Es wird immer zusammen mit dem vorhergehenden Wort 
umgebrochen:
https://de.babbel.com/de/magazine/franzoesische-satzzeichen

: Bearbeitet durch Moderator
von Teo D. (teoderix)


Lesenswert?

Lothar M. schrieb:
> Und meine Frage ist: warum machst du die? Wo hast du das gelernt?
> Ich frage das nur, weil wirklich viele das machen und mir wie gesagt
> noch keiner eine Antwort gegeben hat.

Wir (DE) haben doch keine Computer in den Schulen und für Handschrift 
ist das kein Theme. Also wird da, neu an der Tastatur, nach Gefühl eine 
eigene Regel aufgestellt. ... So meine These.
Sollte als ein Phänomen der pre millenniums Kids sein. ... Hoffe ich.

von Gasheizer (Gast)


Lesenswert?

> Ich klopfe mir mal selbst auf die Schulter

Scheinbar reicht deine Aufmerksamkeitsspanne nicht dazu aus,
etwas vollstaendig zu erledigen. Dafuer muss man sich nicht
auch noch auf die Schulter klopfen.

> Das hier wird fuer einen nichtsimulierten PIC nicht reichen:
>
>  // bit 6 GPPU: Enable Weak Pull-ups bit (GP0, GP1, GP3)
>  // 1 = Disabled
>  //0 = Enabled
>  OPTION = 0b10111111;

In mein allererstes (PIC-)Prograemmelchen habe ich mir die
Belegung des OPTION-Words als Kommentar hineinkopiert.
Da konnte man dann schon im Code sehen, was Sache ist.
Das Ergebnes war dann auch straightforward auf Anhieb richtig.

Wie willst du eigentlich komplexere Probleme angehen?
Mit unbekuemmerten Herumprobieren?

von Harry R. (harryr)


Lesenswert?

Lothar M. schrieb:
> Harry R. schrieb:
>> Also ist es eine Variable, die als Wert die Kopie des Wertes eines
>> Registers bekommt, "Schattenregister" ist wohl so etwas wie µC-Gebabbel.
> Ja, tatsächlich ist das ein üblicher Begriff in der Hardware. Und wenn
> man mit µC und konsequenterweise mit hardwarenaher Programmierung
> herummacht, dann sollte man dieses "Gebabbel" als "Sprache" beherrschen.
> Immerhin findet Google dazu 380000000 Treffer:
> https://www.google.com/search?q=shadow+register
Das kannst du so sehen, ich finde es ist ein unnötiger Begriff für eine 
einfache Sache: temporäre Variable das passt - generalistisch - für jede 
Art Programmierung. Mir hat "Schattenregister" den Eindruck vermittelt, 
dass das eine andere Art von Registern im µC ist und das genau ist es 
nicht.
> Harry R. schrieb:
>> Wenn ich lieber einen Pulldown hätte, müsste ich einen Masse-Widerstand
>> am entsprechenden Pin anbringen, welchen Wert würde man da nehmen, wenn
>> man bereits intern einen Pullup konfiguriert hat (man kann das ja leider
>> nur für alle 3 Pins konfigurieren) ?
> Der interne Pullup hat irgendwas im Bereich ab 15kOhm aufwärts. Und die
> Schaltschwelle für LOW liegt bei 0,2*Vdd. Ergo muss der Pulldown
> merklich kleiner sein als ein viertel des Pullups. Du müsstest bei
> aktiviertem Pullup also für sicheres Erkennen des LOW-Pegels einen
> Pulldown im Bereich unter 3kOhm nehmen.
>
> Aber der Witz liegt eigentlich in den 6 Worten am Anfang dieses Satzes:
>> Wenn ich lieber einen Pulldown hätte

Was du alles witzig findest.
Jetzt geht es in diesem Thread also um Begrifflichkeiten, Fakt ist, dass 
ich die Lösung des Problems selbst gefunden habe und die meisten hier 
lieber Vorschläge gemacht haben, die mich nicht weiter gebracht haben.
> Im Grunde ist es völlig egal, was du lieber hättest. Sondern du
> solltest deine Schaltung so auslegen, wie es der µC gerne hätte.
Sprachakrobatik, scheint wohl dein Fachgebiet zu sein.
>> du bist wohl eine Art Borg, wenn ein µC zu deinem echten Leben gehört
> Nein, ich habe Strom und Internet und verwende täglich viele µC, um mein
> echtes Leben angenehm zu machen. Nur wer irgendwo fernab als
> Selbstversorger in einer Einsiedelei ohne Strom und Internet lebt,
> könnte von sich behaupten, dass kein µC in seinem echten Leben
> auftaucht.
Mein Gott bist du humorlos.
> Harry R. schrieb:
>> Lothar M. schrieb:
>>> wo lernt man denn das Plenken?
>> Keine Ahnung,
> Ok, akzeptiert.
>> wen interessiert das
> Wie gesagt: mich.
>> und worauf beziehst du dich ?
> Auf die fehlerhaften Leerzeichen vor manchen Satzzeichen:
> https://de.wikipedia.org/wiki/Plenk
> Und meine Frage ist: warum machst du die? Wo hast du das gelernt?
Ich mache das, weil ich es als richtig empfinde.
> Ich frage das nur, weil wirklich viele das machen und mir wie gesagt
> noch keiner eine Antwort gegeben hat.
>
> Ein Grund kann sein: ich wohne in Frankreich! Das gilt als Argument,
> dort lernt man das so. Allerdings als nichttrennbares Leerzeichen, das
> fest mit dem vorhergehenden Wort verbunden ist und deshalb niemals eine
> eigene Zeile bekommt. Es wird immer zusammen mit dem vorhergehenden Wort
> umgebrochen:
> https://de.babbel.com/de/magazine/franzoesische-satzzeichen
Ist mir egal, ich rede/schreibe deutsch und denke dass man versteht, was 
ich will. Wenn das deine einzige Sorge ist, geht es dir wohl sehr gut.

So lieber Lothar, zum Schluss eine Bitte. Wenn du dich in Threads, die 
ich angefangen habe oder anfangen werde zukünftig mehr um das Thema als 
die sprachliche Form kümmerst wäre mir das recht, vielen Dank im voraus.

von (prx) A. K. (prx)


Lesenswert?

Harry R. schrieb:
> Das kannst du so sehen, ich finde es ist ein unnötiger Begriff für eine
> einfache Sache: temporäre Variable das passt

Dummerweise ist ein richtig verstandenes Schattenregister keine 
temporäre Variable, sondern eine permanente.

von Harry R. (harryr)


Lesenswert?

Gasheizer schrieb:
>> Ich klopfe mir mal selbst auf die Schulter
>
> Scheinbar reicht deine Aufmerksamkeitsspanne nicht dazu aus,
> etwas vollstaendig zu erledigen. Dafuer muss man sich nicht
> auch noch auf die Schulter klopfen.
Du kannst mich mal !
>> Das hier wird fuer einen nichtsimulierten PIC nicht reichen:
>>
>>  // bit 6 GPPU: Enable Weak Pull-ups bit (GP0, GP1, GP3)
>>  // 1 = Disabled
>>  //0 = Enabled
>>  OPTION = 0b10111111;
>
> In mein allererstes (PIC-)Prograemmelchen habe ich mir die
> Belegung des OPTION-Words als Kommentar hineinkopiert.
> Da konnte man dann schon im Code sehen, was Sache ist.
> Das Ergebnes war dann auch straightforward auf Anhieb richtig.
Deine Aufmerksamkeitsspanne erlaubt es dir aber dir jetzt selbst auf die 
Schultern zu klopfen du Held du großer !
> Wie willst du eigentlich komplexere Probleme angehen?
Indem ich kleine wie dich einfach ignoriere :-)
> Mit unbekuemmerten Herumprobieren?
Um es offen zu sagen, deine Art zu kommunizieren gefällt mir nicht,
ich bitte dich Threads, die ich zukünftig beginnen werde, zu ignorieren
Unterhalte dich mit Lothar über Satzzeichen, Umlaute und 
Rechtschreibung.
Dann ist allen geholfen.
Danke im Voraus

von Harry R. (harryr)


Lesenswert?

(prx) A. K. schrieb:
> Harry R. schrieb:
>> Das kannst du so sehen, ich finde es ist ein unnötiger Begriff für eine
>> einfache Sache: temporäre Variable das passt
>
> Dummerweise ist ein richtig verstandenes Schattenregister keine
> temporäre Variable, sondern eine permanente.
Was für ein Unsinn.

von Teo D. (teoderix)


Lesenswert?

Harry R. schrieb:
>> Dummerweise ist ein richtig verstandenes Schattenregister keine
>> temporäre Variable, sondern eine permanente.
> Was für ein Unsinn.

Du hast das mit dem Schattenregister, alias Latch-Register, immer noch 
nicht wirklich verstanden!

von Harry R. (harryr)


Lesenswert?

Teo D. schrieb:
> Harry R. schrieb:
>>> Dummerweise ist ein richtig verstandenes Schattenregister keine
>>> temporäre Variable, sondern eine permanente.
>> Was für ein Unsinn.
>
> Du hast das mit dem Schattenregister, alias Latch-Register, immer noch
> nicht wirklich verstanden!
Troll dich !

von Gasheizer (Gast)


Lesenswert?

Hach, ein kritikresistentes Schneefloeckchen. Wie putzig.
Und auch noch verbal ausfaellig.

> ich bitte dich Threads, die ich zukünftig beginnen werde, zu
> ignorieren

Diesem Aufruf werden sicherlich viele folgen.

von Harry R. (harryr)


Lesenswert?

Gasheizer schrieb:
> Hach, ein kritikresistentes Schneefloeckchen. Wie putzig.
> Und auch noch verbal ausfaellig.
Hast du nichts besseres zu tun ?
>> ich bitte dich Threads, die ich zukünftig beginnen werde, zu
>> ignorieren
>
> Diesem Aufruf werden sicherlich viele folgen.
Du bist also "viele" ?

von Teo D. (teoderix)


Lesenswert?

Harry R. schrieb:
>> Diesem Aufruf werden sicherlich viele folgen.
> Du bist also "viele" ?

Wie dämlich bist du den?-O

von Harry R. (harryr)


Lesenswert?

Teo D. schrieb:
> Harry R. schrieb:
>>> Diesem Aufruf werden sicherlich viele folgen.
>> Du bist also "viele" ?
>
> Wie dämlich bist du den?-O
Hast du wohl nicht verstanden !?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Harry R. schrieb:
> und die meisten hier lieber Vorschläge gemacht haben, die mich nicht
> weiter gebracht haben.
Aber wenigstens hast du was gelernt wie z.B. "Schattenregister" und 
"Plenk" und dass man im Debugger am **fett** geschriebenen Wort bei 
"Owner or Mapping" ganz leicht eine unerwünschte Konfiguration des Pins 
erkennt.

> temporäre Variable
Warum verwendest du selbst dann mit sGPIO eine globale Variable? Und 
nicht eine temporäre Variable, die nur in einer Unterroutine bekannt 
ist und dort bei jedem Funktionsauf neu initialisiert wird.

> Jetzt geht es in diesem Thread also um Begrifflichkeiten
Wenn du nicht weißt, was der im Internet 390 Millionen mal verwendete 
Begriff "Schattenregister" ist und jemand erklärt es dir, dann würde 
hinterher ein schlichtes "Danke, das wusste ich bisher nicht!" auch 
schon reichen.

>> Plenk
> Ich mache das, weil ich es als richtig empfinde.
Ok, vermerkt.

> So lieber Lothar, zum Schluss eine Bitte. Wenn du dich in Threads, die
> ich angefangen habe oder anfangen werde zukünftig mehr um das Thema als
> die sprachliche Form kümmerst wäre mir das recht
Liebster Harry, erinnere mich bitte daran, falls ich nochmal ungewollt 
irgendwas in einem deiner Threads schreibe.

> vielen Dank im voraus.
Keine Ursache.

von Dietrich L. (dietrichl)


Lesenswert?

Harry R. schrieb:
> Jetzt geht es in diesem Thread also um Begrifflichkeiten

Ja, so ist das nun bei Sprache und Informationsaustausch.
Die Verständigung zwischen den Teilnehmern funktioniert halt nur, wenn 
man verständliche und richtige Begriffe verwendet. Sonst redet man oft 
aneinander vorbei...

von Bauform B. (bauformb)


Lesenswert?

Lothar M. schrieb:
> BTW und nur weil mir noch keiner eine Antwort gegeben hat:
> wo lernt man denn das Plenken?

Auf einem ADM3A ;) Da verbessert es die Lesbarkeit deutlich.

Beitrag #7334918 wurde von einem Moderator gelöscht.
von (prx) A. K. (prx)


Lesenswert?

Angst essen Drosseln auf schrieb im Beitrag #7334918:
> Hinweis: Wenn man nicht helfen kann, oder auch nicht will: Einfach mal
> die Pfoten von der Tastatur lassen!

Manchen Threads wäre besser geholfen, wenn die Ersteller die zulässigen 
Antworten gleich in der Frage mit auflisten. Und man nur noch ankreuzen 
darf. Fehlt darin "nichts von alledem, und zwar...", erspart es solche 
Diskussionen wie hier.

: Bearbeitet durch User
Beitrag #7334933 wurde von einem Moderator gelöscht.
von Harry R. (harryr)


Lesenswert?

Dietrich L. schrieb:
> Harry R. schrieb:
>> Jetzt geht es in diesem Thread also um Begrifflichkeiten
>
> Ja, so ist das nun bei Sprache und Informationsaustausch.
> Die Verständigung zwischen den Teilnehmern funktioniert halt nur, wenn
> man verständliche und richtige Begriffe verwendet. Sonst redet man oft
> aneinander vorbei...

Endlich mal wieder ein sinnvoller Beitrag, danke dafür :-)

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


Lesenswert?

Stefan F. schrieb:
> Als ich das las kam mir spontan der Gedanke, dass du wahrscheinlich
> total übertreibst, aber ...
>
> ... das ist ja wirklich eine Nußschale. Aber Hallo! Ich wusste gar
> nicht, dass es so kleine Mikrocontroller gibt.

Tja, wenn ich mal übertreibe, dann schreibe ich das dazu. Damit das 
jeder sogleich sehen kann.

Und die bodenlose Angst vor jeglicher Assembler-Programmierung scheint 
mir nur ein Ausdruck mangelnder Fähigkeiten zu sein. Gerades bei 
kleineren PIC's mit nur wenig Flash und ebenso wenig RAM ist das 
(zumindest für mich) deutlich einfacher, schneller und platzsparender 
als das Verwenden einer maschinenunabhängigen Sprache wie z.B. C.

Allerdings räume ich ein, daß ich gerade die PIC16 seit ganz vielen 
Jahren und in Assembler programmiere. Das ist etwas anderes als bei 
jemandem, der mit Mühe gerade mal C erlernt und die zu programmierende 
Plattform nur so ungefähr mal gesehen hat.

Oft werden Argumente für C angebracht, die bei näherer Betrachtung 
albern oder gar auf falschen Randbedingungen fußen.
- Portabilität: So etwas greift bei Algorithmen, die im Grunde 
hardwareunabhängig sind. Beispiele: Software-I2C-Treiber, um serielle 
EEPROM's zu benutzen oder Kreisberechnung für Displayzwecke. Aber für 
das, was man mit einem 6 pinnigen µC und bis zu 512 Maschinenbefehlen 
überhaupt machen kann, ist das Argument albern.
- Entwicklungszeit und -Aufwand und Fehlervermeidung: So etwas greift 
ebenfalls nur bei größeren Projekten. Bei kleineren Projekten sind es 
eher die mangelnden Fähigkeiten des Programmierers. Man sieht es hier am 
Thema dieses Threads bereits: Da hat jemand zwar von Bitfeldern in C 
gehört/gelesen, aber er verstrickt sich dabei in einem Dickicht aus Wenn 
und Abers, das zum Teil von C her kommt und nur zum anderen Teil aus der 
Unkenntnis/Nichtbeachtung der PIC-Architektur.
- Lesbarkeit: Das ist ein Problem der Umsetzung von dem, was man in der 
Plattform bewirken will hin zu dem, was man in C überhaupt formulieren 
kann. Bisweilen kommt dann in C ein Schwulst dabei heraus, wo man 
erstmal grübeln muß, was der Autor da überhaupt mit bezwecken will.
Soviel zur Kritik an Argumenten zu C.

Ein anderes Thema tritt hier in diesem Thread ebenfalls deutlich in 
Erscheinung: Die Ansichten der Leute, die sich auf bestimmte 
Architekturen konzentriert haben über andere Architekturen, die sie nur 
vom Hörensagen kennen, aber an der ihnen vertrauten Arcitektur messen 
wollen. Einen typischen Satz darüber gebe ich hier nochzum Besten: "Die 
PIC16 haben ja nur 1 Register in der CPU, wie erbärmlich." Gemeint ist 
das W-Register und eben nicht bekannt ist, daß ein Großteil der 
Operationen ohne CPU-Register direkt im RAM bzw. Hardwareregistern 
stattfindet.

W.S.

von Harry R. (harryr)


Lesenswert?

W.S. schrieb:
> Stefan F. schrieb:
>> Als ich das las kam mir spontan der Gedanke, dass du wahrscheinlich
>> total übertreibst, aber ...
>>
>> ... das ist ja wirklich eine Nußschale. Aber Hallo! Ich wusste gar
>> nicht, dass es so kleine Mikrocontroller gibt.
>
> Tja, wenn ich mal übertreibe, dann schreibe ich das dazu. Damit das
> jeder sogleich sehen kann.
>
> Und die bodenlose Angst vor jeglicher Assembler-Programmierung scheint
> mir nur ein Ausdruck mangelnder Fähigkeiten zu sein. Gerades bei
> kleineren PIC's mit nur wenig Flash und ebenso wenig RAM ist das
> (zumindest für mich) deutlich einfacher, schneller und platzsparender
> als das Verwenden einer maschinenunabhängigen Sprache wie z.B. C.
Ich habe keine Angst, habe bereits Ende der 1980er eifrig assembliert, 
x86 damals.
> Allerdings räume ich ein, daß ich gerade die PIC16 seit ganz vielen
> Jahren und in Assembler programmiere. Das ist etwas anderes als bei
> jemandem, der mit Mühe gerade mal C erlernt und die zu programmierende
> Plattform nur so ungefähr mal gesehen hat.
Da stimme ich dir teilweise zu.
Ich habe im Laufe meines Lebens (historisch sortiert):
- meinen Taschenrechner programmiert
- Basic gekernt und es schnell wieder sein gelassen.
- Turbo Pascal geliebt, leider braucht das heute niemand mehr (+ Asm im 
TC-Code)
- Assembler x86
- Im Studium : Modula-2
- C - eine Sprache, die man überall brauchen kann (PC, Arduino, Raspi, 
µC)
- C++ - einfach klasse

Im Berufsleben
- Java  - meine derzeitige Hauptsprache
- Perl - aber das brauche ich gottseidank nicht mehr
- Ruby -  jobbedingt musste ich diese Kröte schlucken
- HTML (naja, eiegntlich keine Programmiersprache)
- sämtliche Scriptsprachen in Linux und Windoof
- python - überschätzt aber leider viel verwendet
- diverse Sprachen, die ich bereits vergessen habe

Vielleicht sollte ich noch erwähnen, dass ich im Studium 
Programmierkurse für andere Fachbereiche gemacht habe.Daher tangieren 
mich die abfälligen Bemerkungen bzgl. meiner Kenntnisse nur bedingt :-)
> Oft werden Argumente für C angebracht, die bei näherer Betrachtung
> albern oder gar auf falschen Randbedingungen fußen.
> - Portabilität: So etwas greift bei Algorithmen, die im Grunde
> hardwareunabhängig sind. Beispiele: Software-I2C-Treiber, um serielle
> EEPROM's zu benutzen oder Kreisberechnung für Displayzwecke. Aber für
> das, was man mit einem 6 pinnigen µC und bis zu 512 Maschinenbefehlen
> überhaupt machen kann, ist das Argument albern.
Nein, das Argument ist valide. C ist prinzipiell harwareunabhängig. Dass 
man ein beliebiges C-Programm nicht auf jede Hardware anwenden kann ist 
einfach ein Fakt, aber kein Argument gegen C.
> - Entwicklungszeit und -Aufwand und Fehlervermeidung: So etwas greift
> ebenfalls nur bei größeren Projekten. Bei kleineren Projekten sind es
> eher die mangelnden Fähigkeiten des Programmierers. Man sieht es hier am
> Thema dieses Threads bereits: Da hat jemand zwar von Bitfeldern in C
> gehört/gelesen, aber er verstrickt sich dabei in einem Dickicht aus Wenn
> und Abers, das zum Teil von C her kommt und nur zum anderen Teil aus der
> Unkenntnis/Nichtbeachtung der PIC-Architektur.
Ich war auf der Suche des "GP2 lässt sich nicht beschreiben"-Problems
und habe dabei alles probiert, was mir sinnvoll erschien.
Um es mal so zu sagen: Nach der Veröffentlichung meines Quelltextes hies 
es, dass er fehlerfrei ist. Also habe ich einfach Dinge ausprobiert.
Niemand hat bemerkt, dass "OPTION" noch nicht korrekt gesetzt war.
Einer hat sich damit gebrüstet, dass er selbst das schon von Anfang an 
alles richtig gemacht hat, das ist ihm aber erst eingefallen, nachdem er 
meine Lösung gelesen hat. Solche Kommentare nach dem Motto - hab' ich's 
doch gewussst, bin aber selbst nicht drauf gekommen finde ich nicht sehr 
hilfreich.
> - Lesbarkeit: Das ist ein Problem der Umsetzung von dem, was man in der
> Plattform bewirken will hin zu dem, was man in C überhaupt formulieren
> kann. Bisweilen kommt dann in C ein Schwulst dabei heraus, wo man
> erstmal grübeln muß, was der Autor da überhaupt mit bezwecken will.
> Soviel zur Kritik an Argumenten zu C.
C reicht für mein Projekt, also nehme ich es. Wer Textverarbeitungen in 
Assembler schreibt möge das tun :-)
Wer in C Schwulst schreibt wird es bei Assembler auch tun.
> Ein anderes Thema tritt hier in diesem Thread ebenfalls deutlich in
> Erscheinung: Die Ansichten der Leute, die sich auf bestimmte
> Architekturen konzentriert haben über andere Architekturen, die sie nur
> vom Hörensagen kennen, aber an der ihnen vertrauten Arcitektur messen
> wollen. Einen typischen Satz darüber gebe ich hier nochzum Besten: "Die
> PIC16 haben ja nur 1 Register in der CPU, wie erbärmlich." Gemeint ist
> das W-Register und eben nicht bekannt ist, daß ein Großteil der
> Operationen ohne CPU-Register direkt im RAM bzw. Hardwareregistern
> stattfindet.
>
> W.S.
Da hast du recht, Antworten die darauf hinauslaufen, dass ich den 
falschen Prozessor verwende waren nicht im mindesten hilfreich. Das sind 
halt Zeitgenossen, die sich nicht mit dem eigentlichem (meinem) Problem 
befassen, sondern lieber rumquasseln, weil sie eine Art Langeweile 
erfasst hat, die wohl nur mit wenig hilfreichen Posts kompensiert werden 
kann.

Ich hoffe dass in diesem Thread jetzt endgültig alles Wichtige und 
Unwichtige besprochen wurde. Ich habe meine Lösung und werde nun das 
implementieren, was ich vorhabe, es wird funktionieren und meine Welt 
ein wenig schöner machen :-)

In diesem Sinne, ciao

von Peter D. (peda)


Lesenswert?

W.S. schrieb:
> So etwas greift
> ebenfalls nur bei größeren Projekten.

Programme haben aber die Angewohnheit zu wachsen. Es fallen einem viele 
schöne Dinge ein, die der MC noch nebenbei machen könnte.
Dann ist es schön, wenn man einfach nur von dem 6-Pinner auf einen 
14-Pinner wechseln kann, ohne alles nochmal neu schreiben zu müssen. Und 
haste nicht gesehen, ist man beim 64-Pinner gelandet.
Ich möchte nicht extra eine Babysprache lernen müssen, nur weil das 
Projekt gerade mit einem 6-Pinner auskommt.

Bitfelder für IO-Pins benutze ich sehr gerne, es macht den Code viel 
übersichtlicher. Man muß dann je Pin nur ein Symbol definieren und nicht 
immer Bitmaske und Byteadresse getrennt mitschleifen. Bitfelder findet 
man daher auch oft in den professionellen Headern des MCs.
Auch kann es oft passieren, daß man die Pinzuordnung ändern muß, z.B. 
für ein besseres Layout oder weil alternative Funktionen einen Pin 
belegen.

von Gasheizer (Gast)


Lesenswert?

> Niemand hat bemerkt, dass "OPTION" noch nicht korrekt gesetzt war.

Ach.

Gasheizer schrieb:
> Das hier wird fuer einen nichtsimulierten PIC nicht reichen:
>   OPTION = 0b10111111;

Du kannst also nicht mal sinnverstehend lesen.
Da steht das das "nicht reicht".

> Datenblaetter sind dazu da, solche Einfachstfragen allumfassend
> zu beantworten. Wenn man sie liest. Und versteht.

Auf das Lesen und Verstehen hast du ja selbst scheinbar keine
Zeit verschwendet. Statt dessen hier herumgeflennt.

Deine uebrige Lebensbeschreibung klingt auch eher nach
subalterner IT-"Karriere". Dabei solltest du vielleicht bleiben.

Und dem Forum hier fuerderhin fern bleiben.

von Harry R. (harryr)


Lesenswert?

Gasheizer schrieb:
>
> Auf das Lesen und Verstehen hast du ja selbst scheinbar keine
> Zeit verschwendet. Statt dessen hier herumgeflennt.
>
> Deine uebrige Lebensbeschreibung klingt auch eher nach
> subalterner IT-"Karriere". Dabei solltest du vielleicht bleiben.
>
> Und dem Forum hier fuerderhin fern bleiben.
Dich ignoriere ich noch nicht mal.

von W.S. (Gast)


Lesenswert?

Peter D. schrieb:
> Programme haben aber die Angewohnheit zu wachsen. Es fallen einem viele
> schöne Dinge ein, die der MC noch nebenbei machen könnte.

Bleib mal beim Thema. Ich sehe überhaupt keine Wahrscheinlichkeit, daß 
jemand auf die Idee kommt, da einen 6-Pinner durch einen 14-Pinner oder 
gar 64-Pinner zu ersetzen. Allenfalls die umgekehrte Richtung: ihn 
wegzurationalisieren aus Kostengründen.

Harry R. schrieb:
> C reicht für mein Projekt, also nehme ich es. Wer Textverarbeitungen in
> Assembler schreibt möge das tun :-)
> Wer in C Schwulst schreibt wird es bei Assembler auch tun.

Da bist du auf dem falschen Dampfer. Mir ging es dabei darum, daß man 
mit einer maschinenunabhängigen Sprache nicht die Spezialitäten einer 
bestimmten Plattform für den Programmierer verfügbar machen kann. Also 
ist es immer ein Umschreiben dessen, was man machen will mit den 
Ausdrucksmitteln der verwendeten Sprache. Also quasi eine Art 
Workaround. Und da kommt eigentlich fast immer ein Schwulst in C bei 
heraus. Schau dir doch dein eigenes Beispiel an: Da definierst du einen 
Struct, um dem Nichtvorhandensein von echt einbittigen Booleans zu 
entgegnen. Ist nicht dein Fehler, aber an sowas siehst du, was du in C 
(oder einer anderen maschinenunabhängigen Sprache) an Workarounds machen 
mußt. Dabei ist das nur ein ganz harmloses keines Beispiel (die 
Sinnhaftigkeit von typedef will ich hier nicht diskutieren).

Die Maschinenunabhängigkeit einer Programmiersprache erkauft man sich 
durch die Beschränkung auf eine Art kleinsten gemeinsamen Nenners. Und 
die nachträgliche teilweise Wiederanpassung ist dann Obliegenheit des 
nachfolgenden Optimierers, der mehr oder weniger gut sein kann. Irgend 
eine Kröte liegt eben immer auf dem Teller.

W.S.

von Harry R. (harryr)


Lesenswert?

Herzallerliebster Moderator,

du löschst wohl gerade das, was dir nicht gefällt.
Meine Bitte : den ganzen Thread löschen, er gefällt mir nicht.

Danke

von W.S. (Gast)


Lesenswert?

Harry R. schrieb:
> Meine Bitte : den ganzen Thread löschen, er gefällt mir nicht.

Du hast eine eher seltsame Ansicht über Foren, speziell DIESES Forum. 
Wenn du nur lesen willst, was dir gefällt, dann ist ein Diskussionsforum 
nicht die richtige Stelle.

Harry R. schrieb:
> ich habe es eben geschaft mein erstes Programm für den PIC10F202
> zu debuggen (ich bitte um Applaus :-)
>
> Dabei ist mir aufgefallen, dass das Setzen von einzelnen Bits in einem
> bitfield nicht so funktioniert, wie ich mir das dachte.

Tja, das Setzen des einzelnen Bits hat wohl funktioniert, allein es 
hatte nicht die erwünschte Wirkung auf den betreffenden Chip. Das sieht 
da eher danach aus, als ob du von Anfang an nicht an der richtigen 
Stelle gesucht hattest. Kann jedem mal passieren, allerdings hätte es 
dir bereits vor dem Eröffnen dieses Treads zu denken geben können. Da 
ist es kein Wunder, daß aus einem solchen Thread auch mal eine dezente 
Zurechtweisung werden kann: "du Dussel, du hast da was ganz anderes 
vergessen!". Man sollte bei sowas nicht die beleidigte Leberwurst 
spielen.

W.S.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Harry R. schrieb:
> Herzallerliebster Moderator,
Wenn du mich meinst: du bellst den falschen Baum an. Und wenn du mich 
nicht meinst, dann hast du aber schon einen unflätigen Ton am Leib.

> du löschst wohl gerade das, was dir nicht gefällt.
Meine Zeit ist mir sogar zu schade, zu schauen, was denn da gelöscht 
wurde.

> Meine Bitte : den ganzen Thread löschen, er gefällt mir nicht.
Lies die Nutzungsbedingungen: du hast nach dem Absenden eines Posts 
die Nutzungsrechte an den Besitzer der HP abgegeben und bezüglich 
irgendwelcher Löschungen kein Mitspracherecht.

: Bearbeitet durch Moderator
von Harry R. (harryr)


Lesenswert?

Lothar M. schrieb:
> Harry R. schrieb:
>> Herzallerliebster Moderator,
> Wenn du mich meinst: du bellst den falschen Baum an. Und wenn du mich
> nicht meinst, dann hast du aber schon einen unflätigen Ton am Leib.
>
>> du löschst wohl gerade das, was dir nicht gefällt.
> Meine Zeit ist mir sogar zu schade, zu schauen, was denn da gelöscht
> wurde.
>
>> Meine Bitte : den ganzen Thread löschen, er gefällt mir nicht.
> Lies die Nutzungsbedingungen: du hast nach dem Absenden eines Posts
> die Nutzungsrechte an den Besitzer der HP abgegeben und bezüglich
> irgendwelcher Löschungen kein Mitspracherecht.
Ich habe zwei Mails bekommen, dass Beiträge von mir gelöscht wurden.
Eine Begründung gab es nicht.
Ich habe die Nutzungsbedingungen gelesen.
Ich habe gegen keine der Nutzungsbedingungen verstoßen, falls doch, kann 
man mir das ja mitteilen. Wenn du mir einen unflätigen Ton vorwirfst 
bist, hast du das Wort unflätig wohl nicht ganz verstanden. Wenn du 
nicht der "Löscher" bist und dich angesprochen fühlst, misch dich nicht 
ein.
Dass einige Poster hier einen Ton drauf haben, der mir nicht gefällt, 
ist mein Problem, dass man aber meine Beiträge löscht, obwohl sie in 
keinster Weise irgendwie zu beanstanden wären, finde ich schon recht 
merkwürdig.
Komm' mal von deinem hohen Roß runter !

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
Noch kein Account? Hier anmelden.