Forum: Mikrocontroller und Digitale Elektronik Was kann man mit 16Byte an RAM machen?


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 Max M. (maxmicr)


Bewertung
-5 lesenswert
nicht lesenswert
Guten Abend,

da es mich interessiert, wie viel man mit wenig Ressourcen machen kann, 
möchte ich demnächst ein paar kleinere Projekte mit Mikrocontrollern, 
die in Flash- und RAM-Größe sehr beschränkt sind, umsetzen. Speziell hab 
ich mir da den PIC 10F220 ausgesucht. Programmiert werden soll er mit 
dem PicKit3 und der IDE + C-Compiler von Microchip (Assembler möchte ich 
mir nicht antun).

Meine Frage ist nun: Kann man mit 16Byte und dem 8-bit Timer einen 
UA[R]T programmieren (zumindest sendend)? Theoretisch bräuchte man nicht 
mehr als eine ISR in der die Pins getoggelt werden, so viel RAM dürfte 
das nicht benötigen, oder?

Was mich ebenfalls noch interessieren würde, ist, ob sich mit den 
beschränkten Ressourcen auch eine Software-I2C Lösung implementieren 
ließe? Vom Flash her dürfte das imho kein Problem sein, aber ich weiß 
nicht, ob das RAM dafür reicht? Die Funktionalität des I2C-Systems würde 
ich auf mehrere Funktionen aufteilen, wenn man davon ausgeht, dass nach 
dem Rausspringen aus einer Funktion der RAM, der in der Funktion 
benötigten Variablen, freigegeben wird, könnte das klappen, oder? Wie 
genau überprüfen ich die Machbarkeit eines Projektes? Bei AVRs teilt 
einem avrdude mit, wie viel Flash das Programm benötigt, über die 
RAM-Auslastung wird allerdings nichts gesagt. Bekommt man in der 
Microchip IDE irgendwie mit, wie viel RAM gerade in Benutzung ist, oder 
merkt man das erst, wenn der Controller nicht mehr funktioniert bzw. 
komische Dinge macht?

Eine weitere Projektidee wäre das Ansteuern diverser WS2822...

Grüße

Max

: Bearbeitet durch User
von Michael B. (laberkopp)


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> Kann man mit 16Byte und dem 8-bit Timer einen UA[R]T programmieren

Natürlich.

> Software-I2C

Das auch. Bei begrenzten Daten (z.B. TempSensor DS1820) kann man soagr 
Daten übernehmen und dann per UART wieder raussenden.

> Wie genau überprüfen ich die Machbarkeit eines Projektes?

Programm erstellen und gucken wie gross es wird ?

Max M. schrieb:
> Bekommt man in der
> Microchip IDE irgendwie mit, wie viel RAM gerade in Benutzung ist

Im LST File steht doch, welche RAM Zellen belegt sind

MEMORY USAGE MAP ('X' = Used, '-' = Unused)
0000 : XXXX------------ ---------------- XXXXXXXXXXXXXXXX 
XX--------------
All other memory blocks unused.
Program Memory Bytes Used: 22
Program Memory Bytes Free: 32746

Eine Auswertung eines 433MHz Funkempfängers und Steuerung eines 
Garagentors mit Endschaltern, Handbedienung und Überstromerkennung passt 
jedenfalls rein. Der Sender natürlich auch.

Eine Uhr mit Wecker auch, wahlweise eine Stoppuhr oder ein 
Rückwärtstimer.

Ein Thermometer mit besagten DS1820 und LCD Glas auch, müsste sogar für 
einen Thermostaten reichen wenn simpler on/off Regler reicht.

Reicht es zur Steuerung eines GSM Moduls um Rufnummern zu wählen und 
Sprache durchzuschalten, oder GPS Lokation als SMS zu übertragen ? Hängt 
wohl im wesentlichen davon ab, wie viele Bytes man zur Authentifizierung 
speichern muss, nur die 4-stellige PIN dann reicht es jedenfalls.

: Bearbeitet durch User
von holger (Gast)


Bewertung
-9 lesenswert
nicht lesenswert
>Speziell hab ich mir da den PIC 10F220 ausgesucht.
>Programmiert werden soll er mit dem PicKit3 und der IDE + C-Compiler von

Mit 16 Byte RAM ist da wohl nix mehr gross mit C-Compiler.

>(Assembler möchte ich mir nicht antun).

Dann such dir nicht so einen unterbelichteten Schrott
als Controller aus.

von Thomas E. (Firma: Thomas Eckmann Informationst.) (thomase)


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> Theoretisch bräuchte man nicht
> mehr als eine ISR in der die Pins getoggelt werden, so viel RAM dürfte
> das nicht benötigen, oder

Minimum sind der Program Counter und das Statusregister.

Max M. schrieb:
> wenn man davon ausgeht, dass nach
> dem Rausspringen aus einer Funktion der RAM, der in der Funktion
> benötigten Variablen, freigegeben wird, könnte das klappen, oder?

Lokale Variablen werden auf dem Stack oder in den Registern angelegt. 
Die sind nach dem Verlassen der Funktion immer wieder frei. Wenn du 
allerdings eine Funktion aus einer anderen heraus aufrufst, kommen deren 
Variablen natürlich noch oben drauf.

Max M. schrieb:
> wie viel RAM gerade in Benutzung ist, oder
> merkt man das erst, wenn der Controller nicht mehr funktioniert bzw.
> komische Dinge macht

Globale und statische Variablen liegen grundsätzlich im RAM. Die kannst 
du zur Not auch selbst zusammenzählen. In den Funktionen mußt du die 
Pushs und Pops zählen. Jedes Push zählt ein Byte rauf, jedes Pop eins 
runter. Dazu kommen noch der PS, also meistens 2 Bytes und das 
Statusregister.

von Axel S. (a-za-z0-9)


Bewertung
9 lesenswert
nicht lesenswert
Max M. schrieb:
> da es mich interessiert, wie viel man mit wenig Ressourcen machen kann,
> möchte ich demnächst ein paar kleinere Projekte mit Mikrocontrollern,
> die in Flash- und RAM-Größe sehr beschränkt sind, umsetzen. Speziell hab
> ich mir da den PIC 10F220 ausgesucht. Programmiert werden soll er mit
> dem PicKit3 und der IDE + C-Compiler von Microchip (Assembler möchte ich
> mir nicht antun).

So ein Blödsinn.

Das ist wie: "ich möchte herausfinden, mit wie wenig Mitteln ich in der 
Wildnis überleben kann. Dazu habe ich mir ein Waldgebiet ausgesucht. 
Jetzt muß ich nur noch meinen Induktionsherd irgendwie angeschlossen 
bekommen (Kochen über dem offenen Feuer will ich mir nicht antun)."

Mit C geht bei 16 Byte RAM genau gar nichts. Mit Assembler durchaus. 
Mit Assembler kommt man notfalls sogar ganz ohne RAM aus, wenn man alle 
Variablen in Registern unterbringt. Das klassische Beispiel ist die 
Melodieklingel mit einer zweistelligen Anzahl Liedern, bestehend aus 
einer Z80 CPU, einem EPROM und ein paar Gattern/Flipflops [1].

Auf dem Papier sieht der PIC10 ganz gut aus mit seinen 32 Registern und 
sogar einem Hardware-Stack. Da mußte man auf dem Z80 noch ohne auskommen 
und Register hatte man nur 2x 8. Andererseits ist der PIC Befehlssatz 
... gewöhnungsbedürftig. Aber gut, du hast ihn dir selber ausgesucht. 
Hättest ja auch einen ATtiny12 oder so nehmen können ...

Ansonsten verstehe ich die Frage nicht. Leg doch einfach los. Du wirst 
schon sehen, was geht und was nicht. Aber mit Star-Allüren a'la "ich 
will mir nicht die Hände mit Assembler dreckig machen" wirst du so oder 
so nicht weit kommen.


[1] siehe z.B. hier 
http://eb-harwardt.jimdo.com/8-bit-technik/melo-5-leiterplatten-vorhanden/

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> Programmiert werden soll er mit
> dem PicKit3 und der IDE + C-Compiler von Microchip (Assembler möchte ich
> mir nicht antun).

Dann such Dir einen größeren µC aus. Diese Konfigration schreit gradezu: 
"Programmierung nur mit Assembler sinnvoll".

Außerdem sind da selbst zum LED Blinken kaum Pins übrig. Das ist eine 
für SOT23-6 gedachte Minimalst-Version die nix kosten darf und schön 
klein ist.

von Rasputin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Spannend.... Hab ich das Datenblatt richtig verstanden, der hat einen 
fixen Stack mit Platz für 2 Rücksprungadressen (und ohne Stack Pointer)? 
Heisst das, man könnte bei C nur mit globalen Variablen arbeiten? Oder 
kann der Compiler das irgendwie umgehen?

Auf jeden Fall eine Herausforderung, das Ding... ;)

http://ww1.microchip.com/downloads/en/DeviceDoc/40001270F.pdf

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> Speziell hab ich mir da den PIC10F220 ausgesucht

Ein EFM8BB1 mit immerhin 512B RAM kostet weniger und ist auch in C 
ordentlich programmierbar.

> Assembler möchte ich mir nicht antun

PIC10F220 geht nur in Assembler.

Beitrag "v0.9 Update - ARM Cortex support"

> Ansteuern diverser WS2822

Da würde sich eher ein LPC810 DIP8 anbieten, wegen dem State 
Configurable Timer, auch wenn der teurer ist.

Beitrag "v0.9 Update - ARM Cortex support"

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
Rasputin schrieb:
> man könnte bei C nur mit globalen Variablen arbeiten? Oder
> kann der Compiler das irgendwie umgehen?

Ja. Der HiTech-Compiler weiss, welche Funktionen von wo aufgerufen 
werden und legt die lokalen Variablen so übereinander, dass sie sich 
nicht zerstören aber möglichst effektiv wiederverwendet werden.

Daher keine Rekursion und keine Funktionspointer-Funktionen, die zur 
Rekursion führen können (Funktionspointer sind aber prinzipiell erlaubt)

: Bearbeitet durch User
von Chris D. (m8nix)


Bewertung
-3 lesenswert
nicht lesenswert
Mit 16 Byte würde ich 15 Bier und ein Taxi bestellen *g

von (º°)·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.· (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kleiner als 12F675 (64 Byte RAM/1 kWorte Flash/128 byte EEPROM)
tue ich mir und dem XC8/Pro nicht an.

Groesser als 16F684/16F886 aber auch nicht.
Dafuer gibt es dann doch besseres...

von Toxic (Gast)


Bewertung
3 lesenswert
nicht lesenswert
holger schrieb:
> Dann such dir nicht so einen unterbelichteten Schrott
> als Controller aus.

Was soll diese unqualifizierte Aussage?
Hast du dir schon mal die Frage gestellt warum solche kleine Controller 
produziert werden?
Nun gut.Wenn also der PIC10F220 deiner Meinung nach unterbelichteter 
Schrott ist was ist dann wohl erst ein einzelner Transistor - die 
groesste Kacke aller Zeiten oder was?

von Tom (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Hast du dir schon mal die Frage gestellt warum solche kleine Controller
produziert werden?

Warum wird das gemacht, wenn es günstigere und gleichzeitig 
leistungsstärkere gibt?

von Poster (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
So vor etwa 25 Jahren hatte ich RFID Leser mit PIC16C71 gebaut und 
verkauft.
Der hatte auch nicht mehr RAM. Natürlich in Assembler programmiert.
Da war man noch mit jedem Bit per du.

von Uwe D. (monkye)


Bewertung
0 lesenswert
nicht lesenswert
Einigen Schreibern ist offenbar das Wort "wirtschaftlich" halt fremd. 
Für einen Einsteiger, und so verstehe ich die Worte zwischen den Zeilen, 
ist diese Herausforderung eher ein Hindernis.
Das ist übrigens einer der Gründe für den Arduino gewesen, aber das ist 
wieder ein anderes Politikum.

Also @Max, tue Dir selbst einen Gefallen und kauf' einen PIC mit mehr 
RAM....

von chris_ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>da es mich interessiert, wie viel man mit wenig Ressourcen machen kann,
>möchte ich demnächst ein paar kleinere Projekte mit Mikrocontrollern,

Eine Zeit lange habe ich einen Attiny13 in C-programmiert ( 1 KFlash, 64 
Byte Ram ).
Das geht relativ gut in C.

von Christian M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> PIC10F220 geht nur in Assembler.

Nein, sogar sehr gut mit Oshonsoft-Compiler!

Gruss Chregu

von Max M. (maxmicr)


Bewertung
-2 lesenswert
nicht lesenswert
Danke für eure hilfreichen Antworten. Vllt. eine naive Frage, aber warum 
kann man den genannten PIC nicht mit der IDE in C programmieren bzw. 
warum ist mit Assembler ein größerer Funktionsumfang möglich als mit C? 
Liegt. es an den Header-Dateien die man z.B für die ISRs importieren 
müsste (wobei die eigentlich im Flash landen). Der Overhead von C müsste 
doch hauptsächlich im Flash stattfinden, oder?

von Seppel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

der Chip kann mehr, ist nur per Configbits auf 16 Byte. 16 Byte ist eher 
Marketing, ich würde mit Microchip mal den Preis verhandeln,...

Seppel

von Dampf T. (ouuneii)


Bewertung
0 lesenswert
nicht lesenswert
Am besten faengst du mal mit dieser Maschine an. Und mit ASM. Dort den 
gesammten Befehlssatz plus die zugehoerige Architektur, Register usw 
verinnerlichen. Dann heraussuchen, welche Operationen moeglichst RAM 
sparend ausgefuehrt werden. Einfach Probieren.

Plus einfache analog Operationen. zB wie mach ich einen 10..12Bit ADC & 
DAC, kann ich einen Teddy plaerren lassen, ..

solche Machinen werden gerne fuer Projekte mit ultra hohen Stueckzahlen, 
dh groesser als 1 million, eingesetzt. Dafuer werden auch noch 4 bit 
Maschinen eingesetzt.

Vor einigen Jahren waren die globalen Stueckzahlen bei den 4 Bit 
Maschinen ein Stueck groesser wie die der 8 Bitter. Es gibt Leute, die 
Leben ganz gut mit genau solchen Anwendungen. Rechne : Bei 10 Millionen 
Stueck 2 Cent sparen macht auch schon 200'000.

: Bearbeitet durch User
von Peter D. (peda)


Bewertung
1 lesenswert
nicht lesenswert
Solche spartanisch ausgerüsteten MCs sind nur was für extrem 
kostensensitive Anwendungen mit riesen Stückzahlen, wo die 
Entwicklungskosten (Zeit) egal sind.

Ich hab damals mit dem ATtiny12/15 experimentiert, die Programmierung 
war ein Albtraum. Am schlimmsten war der Hardwarestack. Ich schreibe 
gerne modular, da kommt man mit einem nur 3 Level Hardwarestack 
überhaupt nicht aus. Ich hab notgedrungen ein Pseudocall-Macro 
geschrieben, damit die Programme übersichtlich bleiben.

Ich hab für mich als kleinsten sinnvollen MC den ATtiny25 festgelegt. 
Falls es mal klemmt, kann man den einfach auf den ATtiny85 (512Byte RAM) 
pimpen.

: Bearbeitet durch User
von Gästchen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> Danke für eure hilfreichen Antworten. Vllt. eine naive Frage, aber
> warum
> kann man den genannten PIC nicht mit der IDE in C programmieren bzw.
> warum ist mit Assembler ein größerer Funktionsumfang möglich als mit C?
> Liegt. es an den Header-Dateien die man z.B für die ISRs importieren
> müsste (wobei die eigentlich im Flash landen). Der Overhead von C müsste
> doch hauptsächlich im Flash stattfinden, oder?

Ich würds einfach ausprobieren. Dann wirst du das schon sehen. Du kannst 
in MPLABX immer noch auf Assembler umsteigen.

Mach einen Trockenauf - nimm den XC8-Compiler, setz ein Blink-Beispiel 
auf und lass es durchrattern.

Dann siehst du ja, ob der Compiler das da reinbringt.

Ich tipp mal drauf, dass man damit schon was machen kann, auch mit C. 
Für geschätzte 90% der Projekte hier reicht das (LED blinken lassen).

Was schon klar sein muss: Mit Assembler ist man da natürlich besser dran 
;-)

Für C und Minimalisten würde ich den PIC12F1840 empfehlen. Der hat auch 
nur 8 Haxen, hat aber komforatbel Flash und satt Periperie. Damit kann 
man schon richtig was anfangen.
Eine richtige Herausforderung ist aber immer die Anzahl an Pins bei dem 
Teil.

von Stefan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
holger schrieb:
> it 16 Byte RAM ist da wohl nix mehr gross mit C-Compiler.

Für den, der weiß was er tut, ist da C kein Problem.

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> Danke für eure hilfreichen Antworten. Vllt. eine naive Frage, aber warum
> kann man den genannten PIC nicht mit der IDE in C programmieren bzw.
> warum ist mit Assembler ein größerer Funktionsumfang möglich als mit C?

Das letztere hat überhaupt niemand gesagt. Und C geht (vielleicht mit 
Ausnahme einiger Spezial-Compiler) deswegen nicht, weil es auf 
Architekturen mit einer Mindest-Größe an RAM zugeschnitten ist.

Ein C-Compiler erwartet z.B. einen Stack, der nicht nur Rücksprung- 
adressen, sondern auch Funktionsparameter aufnehmen kann. Ein C-Compiler 
hält Variablen im RAM und lädt sie nur zur Optimierung mal für längere 
Code-Abschnitte in Register. Eine Variable rein im Register geht oft nur 
für lokale Variablen.

> Der Overhead von C müsste
> doch hauptsächlich im Flash stattfinden, oder?

Es liegt nicht am Overhead, sondern an ABI Design-Entscheidungen. Wenn 
man z.B. Parameter- und Returnwert-Übergabe ausschließlich in Registern 
macht, dann braucht man kein RAM für einen Stack. Wenn man die Variablen 
bezüglich Anzahl und Größe so einschränkt, daß sie alle in Register 
passen, dann braucht man kein RAM für Variablen. Allerdings kriegt man 
so keinen vollwertigen C-Compiler, denn etliche gültige Programme wird 
man damit einfach nicht übersetzen können.

Am Ende läuft es darauf hinaus, daß man das bißchen Funktionalität, das 
man mit einem derartig abgespeckten C-Compiler erzeugen kann, auch 
gleich in Assembler schreiben kann. Womit wir wieder beim Anfang wären.

Und bevor du fragst: Assembler hat das Problem nicht, weil es da kein 
starres ABI gibt. Wie du Werte an Funktionen übergibst, kannst du machen 
wie du lustig bist. Wenn du keinen Stack hast, kannst du halt kein 
CALL/RET (oder wie immer das auf der jeweiligen Architektur heißt) 
benutzen. Und um die Anordung deiner Variablen in RAM und/oder Registern 
mußt du dich auch alleine kümmern.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
Es ist auf jeden Fall eines: Masochismus.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Ich habe mal eine DCF-77 Uhr mit einem µC ganz ohne RAM in Assembler 
programmiert. Der hatte nur relativ viele Register (wie AVR's) und genau 
ein Register für die Rücksprungadresse der ISR.

Heute würde ich das nie wieder tun, damals hatte ich es als Gehirnsport 
empfunden. Was tut man nicht alles sinnloses, einfach nur weil man es 
kann?

: Bearbeitet durch User
von Georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> Der Overhead von C müsste
> doch hauptsächlich im Flash stattfinden, oder?

Nein, der Programmspeicher ist meistens überhaupt nicht das Problem. 
Aber, nur zum Beispiel, man könnte ewig so weitermachen: in Assembler 
bestimmt der Programmierer, was beim Aufruf einer Funktion auf dem Stack 
abgelegt ist und wie tief die Aufrufe verschachtelt sind. Bei C ist eine 
Prozedur wie etwa printf natürlich kein einfacher Aufruf, sondern die 
ruft andere, einfachere Prozeduren usw. auf und dein Stack ist 
übergelaufen ohne dass du weisst warum, von Variablen mal ganz 
abgesehen.

Stefan schrieb:
> Für den, der weiß was er tut, ist da C kein Problem.

Unbestritten, man kann auch ein C-Programm bis in den letzten Aufruf 
analysieren. Nur ist es dann auch nicht bequemer als Assembler, und für 
die Probleme muss man dann ja auch noch Abhilfe schaffen. Da bleibe ich 
lieber gleich bei Assembler und habe alles im Griff (hoffentlich). 
Teilweise habe ich es auch schon umgekehrt gemacht: ein 
Assemblerprogramm mit geringstem Resourcenverbrauch geschrieben, das 
eine einzelne C-Funktion aufruft, etwa für eine Fliesskommarechnung. 
Aber da muss man wirklich wissen was man tut.

Ein Anfänger wie der TO kann sich natürlich sagen, interessiert mich 
alles nicht, soll der Compiler machen. Aber dann ist der Ansatz mit 
einem Kleinstcontroller natürlich völlig falsch, er sollte gleich einen 
Arm mit haufenweise Rom und Ram nehmen. Allerdings wird er dann nie 
etwas über die internen Details wisssen, aber das Knowhow stirbt sowieso 
aus.

Georg

von Gästchen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Georg schrieb:
>> doch hauptsächlich im Flash stattfinden, oder?
>
> Nein, der Programmspeicher ist meistens überhaupt nicht das Problem.
> Aber, nur zum Beispiel, man könnte ewig so weitermachen: in Assembler
> bestimmt der Programmierer, was beim Aufruf einer Funktion auf dem Stack
> abgelegt ist und wie tief die Aufrufe verschachtelt sind. Bei C ist eine
> Prozedur wie etwa printf natürlich kein einfacher Aufruf, sondern die
> ruft andere, einfachere Prozeduren usw. auf und dein Stack ist
> übergelaufen ohne dass du weisst warum, von Variablen mal ganz

Wer auf DEM Gerät printf() benutzt, der gehört nackt ausgepeitscht.
Vermutlich belegt das alleine 180% vom Flash.

Speziell string-Funktionen sind auf PICs sehr ineffizient. snprintf() 
und Konsorten verwende ich nur, wenn ich Devices wie PIC24 mit 128k 
Flash habe und Projekte mit vielen String-Operationen. Bei µC mit <4k 
tut man gut daran, sowas "händisch" zu machen. Was auch in C 
hervorragend klappt.

Wer so wenig Stack hat, überlegt sich jeden Funktionsaufruf sowieso 
doppelt. Hoffentlich.

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:
> Ein C-Compiler erwartet z.B. einen Stack, der nicht nur Rücksprung-
> adressen, sondern auch Funktionsparameter aufnehmen kann.

Naja, das stimmt so für die PIC-Compiler halt nicht. Es gibt dort keinen 
Stack im herkömmlichen Sinne, sondern der Compiler für diese PICs 
analysiert die komplette Aufrufhirarchie. Ist zwar rückwärts durch die 
Brust ins Auge, der geschreibene Code ist aber wirklich ANSI-C wie auf 
"normalen" Maschinen, nur ohne Rekursion.

Der wahr Grund für Assembler bei so kleinen µC ist eher die 
Herausforderung. Um wirlich das letzte Bit zu sparen wird C 
komplizierter als Assembler, da ich nicht nur schreiben muss, was ich 
möchte, sondern auch so, dass der Compiler es auf die gewünschte Weise 
tut.

Ihr kennt sicher das Poormans Oszilloskop auf PIC12-Basis. Aus 1kB ROM 
und 64 Byte RAM zaubert er ein Oszilloskop mit Monitorausgabe und 
Menüführung.

http://www.dos4ever.com/uscope/uscope_e.html#youtube

von Mike (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Ich habe vor einigen Jahren ein Projekt mit dem PIC10F222, dem etwas 
größeren Bruder des PIC10F220, geleitet. Es ging um einen 
Akkucontroller, bei dem es dem Management auf Centbeträge ankam. Er 
sollte die vorhandene diskrete Schaltung aus mehreren Komparatoren, 
Flipflops etc. ersetzen. Gelinde gesagt war die Entwicklung mühsam. Im 
Prinzip schien der Chip für den Zweck gut geeignet, kleines SOT-26 
Gehäuse, niedrige Betriebsspannung bis hinunter zu 2V, integrierter AD 
Wandler mit Spannungsreferenz.

Die Tücken offenbarten sich dann während des Entwicklungsprozesses: Von 
den 4 Portpins des Winzlings waren 3 durch den Programmieradapter 
belegt, so dass kein In-Circuit Debugging möglich war. Wir haben dann 
vom Microchip einen Adapter bekommen, der einen größeren Pic (ich weiss 
nicht mehr, welcher) enthielt und den 10F220 emulierte. Programmiert 
wurde in Assembler, wobei das Banking des Programmspeichers Probleme 
bereitete. Funktionsaufrufe von der oberen in die untere Hälfte des 
Programmspeichers und umgekehrt sind mangels genügend Adressbits nicht 
direkt möglich.

Laut Datenblattsollte der XC8-Compiler aber funktionieren.

Die unangenehmste Überraschung war jedoch die starke Streuung der 
Spannungsreferenz, die eine Einzelkalibrierung der Bauteile nötig 
machte.  Ohne EEPROM oder selbstprogrammierbares Flash ist das ziemlich 
aufwändig. Der Kostenvorteil war damit auch wieder dahin. 
Bezeichnenderweise hat  Microchip sich geweigert, eine 
Genauigkeitsspezifikation für diese Referenz anzugeben.



Fazit: Anfängern würde ich von dieser Art Minimalcontrollern abraten und 
wenn nicht ganz zwingende Gründe dagegen sprechen, einen größeren PIC 
wählen.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Toxic schrieb:

> Hast du dir schon mal die Frage gestellt warum solche kleine Controller
> produziert werden?

Weil die Leute ihn kaufen. Vermutlich um sportliche Wettbewerbe im 
Ressourcensparen auszutragen. Auch wenn er doppelt so viel kostet wie 
ein Controller mit 20 mal soviel RAM und 8 mal soviel Flash.

Verkauf ihn mir für < 8ct und wir reden nochmal drüber.

: Bearbeitet durch User
von Axel S. (a-za-z0-9)


Bewertung
2 lesenswert
nicht lesenswert
Achim S. schrieb:
> Axel S. schrieb:
>> Ein C-Compiler erwartet z.B. einen Stack, der nicht nur Rücksprung-
>> adressen, sondern auch Funktionsparameter aufnehmen kann.
>
> Naja, das stimmt so für die PIC-Compiler halt nicht. Es gibt dort keinen
> Stack im herkömmlichen Sinne, sondern der Compiler für diese PICs
> analysiert die komplette Aufrufhirarchie. Ist zwar rückwärts durch die
> Brust ins Auge, der geschreibene Code ist aber wirklich ANSI-C wie auf
> "normalen" Maschinen, nur ohne Rekursion.

Das kann ich mir ehrlich gesagt nicht vorstellen. Ein C-Compiler, der 
keine Rekursion kann, ist doch sicher aus der Spezifikation, oder?

Ansonsten kann ich mir schon vorstellen, daß die verkorkste^W spezielle 
Architektur der 8-Bit PICs Auswirkungen auf Design-Entscheidungen bei 
den C-Compilern und insbesondere dem ABI hatte. Ist ja auch kein Zufall, 
daß es nie [1] einen open-source C-Compiler für diese Architektur gab.

[1] ok, fast. SDCC kann seit einiger Zeit auch PIC. Keine Ahnung, ob das 
taugt. Ich halte von 8-Bit PICs vor allem eins: Abstand.

: Bearbeitet durch User
von c-hater (Gast)


Bewertung
-6 lesenswert
nicht lesenswert
Max M. schrieb:

> da es mich interessiert, wie viel man mit wenig Ressourcen machen kann,
[...]
> (Assembler möchte ich mir nicht antun).

Und schon komplett als Looser geoutet. Es gibt nunmal theoretisch und 
praktisch keinen besseren Weg, Resourcen maximal effizient zu nutzen als 
eben die optimierte Programmierung in Assembler. Ob dir das paßt oder 
nicht, spielt gegenüber der Allgewalt der Gesetze der Informatik sowas 
von keine Rolle...

D.h.: bestenfalls kannst du mit höheren Programmiersprachen 
Gleichstand mit einer optimierten Asm-Lösung erreichen. In aller Regel 
wirst du aber ein suboptimales Ergebnis erzielen. Das ist kein Problem, 
so lange reichlich Resourcen vorhanden sind, aber eben gerade dann ein 
Problem, wenn genau das nicht der Fall ist, also genau in deinem 
Ziel-Szenario...

Deswegen: Du bist einfach nur DUMM, wenn du den einzig zielführenden 
Weg von vornherein kategorisch ausschließt...

von hgmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
sich in die Butz.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:
> Das kann ich mir ehrlich gesagt nicht vorstellen. Ein C-Compiler, der
> keine Rekursion kann, ist doch sicher aus der Spezifikation, oder?

Doch das geht sehr gut, z.B. beim Keil C51 Compiler.
Da der 8051 viele Operationen im RAM ausführen kann, wurde dadurch der 
Code sehr kompakt und schnell.
Der 8051 kann aber auch PUSH/POP, d.h. man kann Funktionen auch als 
reentrant deklarieren. Das geht allerdings zu Lasten der Codedichte und 
Ausführungszeit.

http://www.keil.com/support/man/docs/c51/c51_le_reentrantfuncs.htm

von Olmau (Gast)


Bewertung
3 lesenswert
nicht lesenswert
c-hater schrieb:

> Deswegen: Du bist einfach nur DUMM, wenn du den einzig zielführenden
> Weg von vornherein kategorisch ausschließt...

Wichtig ist doch, dass er nicht dümmer ist als du.

von c-hater (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
Olmau schrieb:

> Wichtig ist doch, dass er nicht dümmer ist als du.

Aber das ist er ja leider. Denn ich ziehe diesen Weg bei 
Resourcenknappheit immer in Betracht, zumindest als Alternative zur 
Aufweitung der Resourcen durch Verwendung eine anderen Hardware.

Ich wähle dann, was unterm Strich günstiger kommt. So geht man an die 
Sache heran, wenn man nicht dumm ist...

So kann man aber nur an die Sache herangehen, wenn man sich nicht das 
Gehirn von vornherein zunagelt. Genau das ist der springende Punkt!

von Klaus (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Axel S. schrieb:
> Ich halte von 8-Bit PICs vor allem eins: Abstand.

Da bin ich aber froh, da kommen wir uns nicht in die Quere.

MfG Klaus

von Thomas E. (Firma: Thomas Eckmann Informationst.) (thomase)


Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> So kann man aber nur an die Sache herangehen, wenn man sich nicht das
> Gehirn von vornherein zunagelt.

Das kommt mir irgendwie bekannt vor. Du wohnst nicht zufällig in 
Katzelsried?

von W.S. (Gast)


Bewertung
4 lesenswert
nicht lesenswert
Axel S. schrieb:
> Ansonsten kann ich mir schon vorstellen, daß die verkorkste^W spezielle
> Architektur der 8-Bit PICs Auswirkungen auf Design-Entscheidungen bei
> den C-Compilern und insbesondere dem ABI hatte.

Axel, du bist ein AVR-Mann und als solcher verstehst du die PIC-Welt 
nicht bzw. willst sie nicht verstehen. Kannst du ja machen, es gibt für 
jeden Geschmack eine µC-Architektur.

Die Architektur der kleinen PIC's ist nämlich überhaupt nicht verkorkst, 
sondern auf einfaches und dabei effizientes Assembler-Programmieren hin 
optimiert - und nicht für C als Programmiersprache. Wer nen Horizont 
hat, der direkt hinter C endet, für den sind die PIC's nicht.

Die kleinen PIC's sind NICHT für große Systeme gedacht, sondern für all 
die kleineren Anwendungen, die man im Allgemeinen nicht wahrnimmt.

So ein Winzig-PIC im SOT23-5 fällt fast nirgendwo auf, er kann dennoch 
Protokolle umsetzen, Peripherie betreiben, Codenummern liefern, ne Menge 
kleinere Aufgaben erledigen und das recht stromsparend - eben alles, 
wofür ein dickerer µC schlichtweg übertrieben oder nicht anwendbar wäre.

Ich selber programmiere solche kleinen PIC's schon seit vielen Jahren - 
und das in Assembler. Wer sowas nicht kann, sondern nix anderes als C 
kennt, ist bei den PIC's im verkehrten Film - da hilft ihm auch keine 
große Klappe. Mir fällt da ein angeregter Zähler-Disput zwischen 40 MHz 
AVR und >100 MHz PIC ein..


..Aber lassen wir das mal. Das Folgende hingegen hast du sehr schön 
formuliert. Man sollte es dem TO ruhig nochmal zu lesen geben:

> Das ist wie: "ich möchte herausfinden, mit wie wenig Mitteln ich in der
> Wildnis überleben kann. Dazu habe ich mir ein Waldgebiet ausgesucht.
> Jetzt muß ich nur noch meinen Induktionsherd irgendwie angeschlossen
> bekommen (Kochen über dem offenen Feuer will ich mir nicht antun)."

Eben.

W.S.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Doch das geht sehr gut, z.B. beim Keil C51 Compiler.
> Da der 8051 viele Operationen im RAM ausführen kann, wurde dadurch der
> Code sehr kompakt und schnell.

Lob den C51 mal nicht in den Himmel, der kann schon ganz schöne Böcke 
schießen die unangenehm auffallen wenn Flash oder Rechenzeit knapp wird. 
Versuch zum Beispiel mal ein uint32_t um 8 bit (ein Byte!) nach rechts 
zu schieben. Oder von 0x1ffff auf null zu zählen. Oder schreib eine 
Funktion die einen Pointer als Argument hat foo(uint16_t* bar) und ruf 
sie auf. Oder teile ein uint32_t mit den / Operator durch eine 
konstante(!) Zweierpotenz. Und dann wirf einen Blick in den erzeugten 
Code um rauszufinden wohin grad wieder mit einem Schlag eine 
dreistellige Zahl von Bytes verschwunden ist und was er da für Kapriolen 
dreht (brauchst nen separaten Disassembler um das Elend zu bewundern 
weil der Linker kann das Zeug was er selber erzeugt oder dazulinkt nicht 
in sein Listing schreiben). Man merkt schon deutlich daß da vor 20 
Jahren (als er noch vergleichsweise toll war) die Entwicklung 
eingeschlafen ist, verglichen mit heutigen Compilern auf anderen 
Architekturen. Von dem C89 Sprachstandard möcht ich jetzt gar nicht erst 
anfangen. Es dauert wahrscheinlich nicht mehr lange und der SDCC hat ihn 
überholt.

: Bearbeitet durch User
von Jan W. (jannyboy)


Bewertung
0 lesenswert
nicht lesenswert
holger schrieb:
> Dann such dir nicht so einen unterbelichteten Schrott
> als Controller aus.

Da kreischt schon wieder einer der keine Ahnung von der Materie hat.

Max M. schrieb:
> PIC 10F220

Das ist einer meiner Lieblingstypen neben dem PIC10F322 und dem 
PIC12F1572.
Der PIC ist billiger als ein NE555.
Wenn eine Blaue LED an 3V ein und ausschalten will und sie auch noch 
Dimmbar sein soll ist der PIC genau richtig.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Lob den C51 mal nicht in den Himmel, der kann schon ganz schöne Böcke
> schießen die unangenehm auffallen wenn Flash oder Rechenzeit knapp wird.

Ich kann da nicht klagen, Flash oder CPU-Zeit wurden bei mir nie knapp. 
Ich hab allerdings hauptsächlich 8 oder 16Bit Variablen verwendet und 
float bzw. 32Bit nur sparsam. Ein deutlicher Codezuwachs ergibt sich 
immer nur beim ersten Aufruf einer neuen Lib-Funktion. Danach kostet es 
nur noch einen weiteren Call.

Mein größtes 8051-Projekt ist über viele Jahre auf 48kB angestiegen, da 
ist also noch Luft bis 64kB. Ich bin der vierte, der an diesem Programm 
gearbeitet hat, d.h. es ist nicht sonderlich effizient geschrieben. 
Daran habe ich auch den großen Vorteil von C erkannt, daß dadurch 
mehrere an einem Projekt erfolgreich weiter arbeiten können.
Assembler ist dagegen nur für Einzelkämpfer geeignet. Wenn da der 
Entwickler die Firma verläßt und es erweitert werden muß, wird es weg 
geschmissen und komplett neu angefangen (in C natürlich).

von Andy (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Max M. schrieb:
> da es mich interessiert, wie viel man mit wenig Ressourcen machen kann,...
Okay, das soll wohl heißen: spielend*, jedoch nicht aus wirtschaftlichen 
Interesse.

> (Assembler möchte ich mir nicht antun).
Diese Entscheidung ist ein zusätzlich gewähltes freiwilliges Handikap 
(Vgl. Boxen mit einem Arm auf dem Rücken).

> Meine Frage ist nun: Kann man mit 16Byte und dem 8-bit Timer..
> einen UA[R]T programmieren
> eine Software-I2C Lösung implementieren
> Ansteuern diverser WS2822...
Also all diese Funktionen mit Assembler: kein Problem
In C: naja, es würde definitiv grenzwertig: manches wird gar nicht 
implementierbar sein, manches nur mit bestimmten Compilern, (bzw mit 
entsprechenden Compileroptionen), und alles geht nur mit entsprechender 
Auslegung des Quellcodes auf entsprechend wenig RAM-Bedarf.

Wenn das der entsprechende Nerfenkitzel ist...
Rein wirtschaftlich würde man von vornherein entweder einen anderen 
Controller oder Assembler wählen.

Achja: auch bei den AVRs gibts solche "hochgerüsteten Transistoren"


*Entwicklungsprozess "Spielen".

von Timmy (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
W.S. schrieb:
> Ich selber programmiere solche kleinen PIC's schon seit vielen Jahren -
> und das in Assembler. Wer sowas nicht kann, sondern nix anderes als C
> kennt, ist bei den PIC's im verkehrten Film - da hilft ihm auch keine
> große Klappe. Mir fällt da ein angeregter Zähler-Disput zwischen 40 MHz
> AVR und >100 MHz PIC ein..

FALSCH

Der xmega kann seine Timer mit PLL auf 128 MHz betreiben, und zwar alle.

Ansonsten hast du Recht. C-Programmierer bringens einfach nicht, wenn es 
drauf ankommt.

von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> (Assembler möchte ich mir nicht antun).
Auf einem STM32 wird man fast nie so tief einsteigen.

Assembler war für allgemeine Aufgaben schon vor 25 Jahren out.

Was mich nicht daran gehindert hat, in Spezialfällen trotzdem darauf 
zurückzugreifen.
Bei stark begrenzten Ressourcen 
(Platz/Zeit/Energie/Bauraum/Serienkosten) hat Maschinensprache den 
Vorteil, dass man als Entwickler direkt steuern kann, wie diese 
eingesetzt werden.

Beispiel 1 - Thema Speicher - Tiny10 im SOT23-6 Gehäuse, welcher 
pinkompatibel zum PIC10F200 ist:
Diesen Tongenerator haben wir hier im Forum schonmal behandelt:
http://www.harerod.de/applications_ger.html#TQ10_melody

Beispiel 2 - Thema Speicher und Rechenzeit:
Die schwebende Eisenkugel ist schon ein wenig anspruchsvoller. Die 
Abbildung eines Regelalgorithmus' mit Integerarithmetik in 
Maschinensprache ist schon etwas weniger komfortabel, als mit Labview, 
dafür ist der Materialeinsatz einen Tick geringer:
http://www.harerod.de/applications_ger.html#xmasball2012

Beispiel 3 - Thema Rechenzeit und Energieverbrauch:
Bei dieser Anwendung war die Stückzahl für ASIC noch zu gering, deswegen 
kommt hier ein PIC16F57 zum Einsatz. Der arbeitet hier mit 8192Hz 
Befehlstakt und multiplext das LCD und misst nebenbei noch ein wenig 
Zeit:
http://www.harerod.de/applications_ger.html#allTimer


Max M. schrieb:
> Meine Frage ist nun: Kann man mit 16Byte und dem 8-bit Timer einen
> UA[R]T programmieren (zumindest sendend)?
> Was mich ebenfalls noch interessieren würde, ist, ob sich mit den
> beschränkten Ressourcen auch eine Software-I2C Lösung implementieren
> ließe?
Mann kann! Denn echte Programmierer meiden Pascal...
http://www.pbm.com/~lindahl/real.programmers.html

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Marcus H. schrieb:
> Max M. schrieb:
>> Meine Frage ist nun: Kann man mit 16Byte und dem 8-bit Timer einen
>> UA[R]T programmieren (zumindest sendend)?
>> Was mich ebenfalls noch interessieren würde, ist, ob sich mit den
>> beschränkten Ressourcen auch eine Software-I2C Lösung implementieren
>> ließe?
> Mann kann!

Naja, für UART und I2C braucht man in der Regel noch einen Datenpuffer 
und dafür ist bei 16Byte einfach kein Platz mehr.
Für die UART nehme ich mindestens je 30 Byte Sende-/Empfangspuffer, 
damit man kürzere Texte ein- bzw. ausgeben kann.
Und z.B. bei nem DS1307 (I2C-RTC) braucht man mindestens 8 Byte Puffer, 
um die Zeit konsistent lesen bzw. schreiben zu können.

Man müßte die Strings/Daten "on the fly" basteln bzw. auswerten, was ein 
sehr unübersichtliches Programm ergibt (riesiges unentwirrbares 
Codeknäuel statt einfacher einzelner Module).
Und wie schon gesagt, hat man als nächstes Problem bei der modularen 
Programmierung den viel zu kleinen HW-Stack.
Z.B. meine LCD-Lib hat allein schon einen Callingtiefe von 4.
http://www.avrfreaks.net/forum/tutc-lcd-tutorial-1001

: Bearbeitet durch User
von Marcus H. (Firma: www.harerod.de) (lungfish) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Und wie schon gesagt, hat man als nächstes Problem bei der modularen
> Programmierung den viel zu kleinen HW-Stack.
Der SRAM-Stack und General Purpose Registersatz - das sind genau die 
Punkte, warum der AVR deutlich komfortabler als der PIC zu programmieren 
ist.

Modulare Programmierung ist Teil des Gesamtkonzepts einer 
"wirtschaftlichen Entwicklungleistung". Jedoch wird man in dieser 
Kampfklasse wohl keinen HAL zwischenschieben wollen, oder? ;)

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> [8051]
> Ich kann da nicht klagen, Flash oder CPU-Zeit wurden bei mir nie knapp.

Ich schon, denn bei mir wird es immer knapp. Es kommt drauf an was Dich 
dazu antreibt den zu verwenden. Der Hauptgrund bei mir der mich heute 
zwingt mich mit 8051 zu beschäftigen ist daß ein EFM8BB1 von Silabs 
deutlich weniger als 30ct kostet. Dies geht jedoch damit einher daß man 
leider nur noch 2kB Flash hat, da herrscht beklemmende Enge schon wenn 
man nur damit anfängt über die angedachten Features zu diskutieren. 
Sobald ich aber die größeren Varianten mit 4 oder 8kB ins Auge fasse 
verschwindet der Preisvorteil schnell, Arm fängt bei ~50ct an.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Es kommt drauf an was Dich
> dazu antreibt den zu verwenden.

Mit dem Einsatz wurde 1995 angefangen, vorwiegend Philips und die damals 
brandneuen Flash 8051 von Atmel.
Die DACs und ADCs waren 12/14Bit, d.h. alle Daten waren 16bittig. Keil 
war wohl auch der Meinung, wer 32Bit benutzt, dem kommt es auf die 
Optimierung nicht so sehr an und der nimmt nen dicken 8051 mit viel 
PROM.
Bei 1, 8 und 16Bit Variablen war der Keil extrem effektiv.

von (º°)·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.· (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
> Der SRAM-Stack und General Purpose Registersatz - das sind genau die
> Punkte, warum der AVR deutlich komfortabler als der PIC zu programmieren
> ist.

Das ist etwa so falsch wie die Aussage eines Buchautors ueber
den PIC-Befehl SUBWF/SUBWL der "falsch herum" subtrahieren wuerde.

Der hat es einfach nicht verstanden. Du ja uebrigens auch nicht...

von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:

> Assembler ist dagegen nur für Einzelkämpfer geeignet. Wenn da der
> Entwickler die Firma verläßt und es erweitert werden muß, wird es weg
> geschmissen und komplett neu angefangen (in C natürlich).

Das glauben eben nur Leute, die Assembler nicht beherrschen. Ich habe da 
(neben vielen anderen Sachen) von meinem Vorgänger ein in Stückzahlen 
verkauftes HC12-Werk übernommen. Ich hatte selber vorher niemals Kontakt 
mit diesen Motorola-µC-Teilen. Aber ich war trotzdem in der Lage, 
innerhalb von nur zwei Tagen eine vom Kunden gewünschte Änderung 
einzupflegen. Hat mich nur den Download von ein paar PDFs gekostet und 
einige Stunden Lektüre dieser Dokumente und der Quelltexte meines 
Vorgängers. Assembler ist halt i.A. eine einfache und leicht 
verständliche Sprache ohne jegliche bösen Fallstricke, wie sie dieses 
Drecks-C nur allzu reichlich bereit hält...

Den Assembler-Dialekt eines neuen Controllers kann man üblicherweise in 
wenigen Stunden vollständig lernen (für lesende Anwendung und um 
"leichte" Änderungen daran vornehmen zu können, um aktiv optimalen Code 
programmieren zu können, braucht man natürlich deutlich mehr Zeit).

Für C hingegen braucht man mindestens einige Wochen, wenn nicht Monate, 
um es auch nur vollständig lesen zu können. Vor allem dann, wenn da ein 
"C-Crack" am Werk war. Einer von den Blinden Wichsern, die glauben, dass 
eine besonders geringe Zahl von Zeichen im Quelltext besonders schnellen 
Code erzeugt...

von Thomas E. (Firma: Thomas Eckmann Informationst.) (thomase)


Bewertung
1 lesenswert
nicht lesenswert
c-hater schrieb:
> Aber ich war trotzdem in der Lage,
> innerhalb von nur zwei Tagen eine vom Kunden gewünschte Änderung
> einzupflegen.

Das ist ja großartig, du Held.

: Bearbeitet durch User
von W.S. (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Peter D. schrieb:
> Und wie schon gesagt, hat man als nächstes Problem bei der modularen
> Programmierung den viel zu kleinen HW-Stack.

Ach Peter, du kommst genauso wie Axel nicht heraus aus deiner AVR- und 
C-Denkweise. Das ist alles. Folglich kannst du auch keine Probleme der 
Art lösen, wie sie typisch und passend sind für solche kleinen PIC's.

Mal ne kleine Erklärung:
Der HW-stack in den PIC's ist ausschließlich für Rücksprungadressen und 
NICHT für Argumente aller Art. Die CPU hat gar kein Register und 
arbeitet normalerweise mit den RAM-Zellen und den HW-Registern direkt 
oder über das W-Register, was nur teilweise ein echter Akku ist. 
UP-Calls gehen dank HW-Stack in effektiv nur 2 Takten (Inclusive 
Call-Befehl selbst). Selbst das indirekte Arbeiten mit RAM und 
HW-Registern über das "Register 0" geht ohne zusätzlichen Takt.

Das ist eben alles anders, als du es vom AVR her gewohnt bist. Aber 
gerade deswegen kann man mit dieser Architektur in Assembler sehr viel 
mehr machen als mit vielen anderen Architekturen. Man muß sich aber 
drauf einlassen - sonst wird das Ganze nix.

Und da scheiden sich die Geister.

Heutige Dünnbrettbohrer wollen dediziert NICHT sich mit HW und 
HW-bezugenem wie Assembler befassen müssen - ist mit zuviel 
Gehirnanstrengung verbunden. Eben nicht wirklich selbst potent sein, 
sondern das Bumsen einer Library anheim stellen - ist bequemer.


W.S.

von c-hater (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
Thomas E. schrieb:

> Das ist ja großartig, du Held.

Findest du? Ich finde das normal. Hätte ich bei einem einigermaßen 
normal formuliertem C-Programm natürlich ganz genauso machen können. 
Bräuchte dazu nichtmal C zu lernen, denn das kann ich bereits deutlich 
besser als die Mehrheit der Leute, die sich selber als "C-Programmierer" 
einstufen...

Genau das ist der Punkt. Einen C-Programmierer stelle ich nur ein (bzw. 
gebe meine Zustimmung dazu), wenn er auch nachweist, dass er für 
mindestens eine relevanten Zielarchitektur die Assemblersprache aktiv 
beherrscht. Tut er das nicht, kann man meiner Erfahrung nach getrost 
davon ausgehen, dass er auch kein C kann, sondern nur Wichsvorlagen aus 
dem Netz notdürftig zusammenleimen kann. Insbesondere ist er dann nicht 
zu einer qualifizierten Fehlersuche auf Maschinenebene in der Lage. Was 
bei C auf Grund der Mankos der Sprache nunmal zwingend erforderlich 
ist...

von ASM Superprofi (Gast)


Bewertung
5 lesenswert
nicht lesenswert
Jemand, der kein Assembler kann, kann nicht programmieren. Schon gar 
keine MCUs und PUNKT.

Das heisst nicht, dass man jeden Scheiss in Assembler schreiben muss. 
Ich hätte jetzt wirklich keine Lust, einen JPG-Encoder in ASM zu 
realisieren, aber das wäre die logische Konsequenz, wenn ich unbedingt 
JPG brauche und C nicht anfassen will. Mein B0SS würde mich feuern, wenn 
ich wochenlang an einer ASM JPG Lib sitzen würde. Auf die Frage, warum 
ich nicht einfach eine vorhandene Lib eingesetzt hätte, hätte ich in der 
Tat auch keine Antwort.

Andersrum funktioniert es aber auch. Wenn mir ein Bewerber sagt, er 
kennt die MCUs, die wir verwenden in- und auswendig und dann sagt, er 
kann kein ASM, dann kennt er die MCU auch nicht. Dann kennt er GAR keine 
MCU richtig. Fertig und tschüss. Nächster.

von ASM Superprofi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich sehs schon kommen und nehme es gleich vorweg. Ein ARM ist für mich 
keine MCU mehr, wie ich sie bei der Argumentation von vorhin im Kopf 
habe.

Ich rede hier nur von PICs, AVRs, etc.

(Wobei der ASM-Befehlssatz eine PICs ein Argument für C ist hrhrhr)

von Dieter W. (dds5)


Bewertung
0 lesenswert
nicht lesenswert
ASM Superprofi schrieb:

> (Wobei der ASM-Befehlssatz eine PICs ein Argument für C ist hrhrhr)

Wobei man durchaus zwischen PIC12/16, PIC18, PIC24/dsPIC und PIC32 
unterscheiden sollte, denn die haben ziemlich unterschiedliche 
Befehlssätze.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Mal ne kleine Erklärung:
> Der HW-stack in den PIC's ist ausschließlich für Rücksprungadressen und
> NICHT für Argumente aller Art.

In der Codesammlung findest Du Beispiele von mir mit dem ATtiny12 
(3-Level-HW-Stack). In der Not kann man einiges damit machen. Aber stolz 
bin ich darauf nicht, mich damit abgequält zu haben. Das waren nur 
Spielereien, keine professionellen Projekte.

Ich will mich voll auf die Aufgabe konzentrieren können und nicht auch 
noch auf den Stack aufpassen müssen und Unterfuntionen kopieren, statt 
sie zu callen.

von Bernd K. (prof7bit)


Bewertung
1 lesenswert
nicht lesenswert
Alter Schwede, hier sind ja wieder Kaliber unterwegs. Früher dachte ich 
mein eignes Tun sei grenzwertig weil ich lieber einen USB-Stack from 
scratch schreibe als den SDK-bloat des Herstellers zu verwenden, weil 
ich  meinen eigenen Startupcode schreibe und eigene Treiber für alles.


 Aber solche ASM-Superprofis wie hier mit derart schrägen Vorstellungen 
und Prioritäten und derartiger Selbstüberschätzung würden ein 
ernsthaftes Problem mit mir bekommen. Man kann nämlich alles übertreiben 
und wenn der Code aufgrund solcher selbstverliebter ASM Trottel und 
inkompetenter C-Verweigerer zum unwartbaren ASM-Spaghetti verkommt dann 
wäre Schluss mit lustig.

: Bearbeitet durch User
von Ehrhardt (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Aber solche ASM-Superprofis wie hier mit derart schrägen Vorstellungen
> und Prioritäten und derartiger Selbstüberschätzung würden ein
> ernsthaftes Problem mit mir bekommen. Man kann nämlich alles übertreiben
> und wenn der Code aufgrund solcher selbstverliebter ASM Trottel und
> inkompetenter C-Verweigerer zum unwartbaren ASM-Spaghetti verkommt dann
> wäre Schluss mit lustig.

du verkennst womöglich die Aussagen

ich bin auch ein Chef und wenn ich zu eintscheiden habe ob ein 
C-Programmierer eingestellt wird und dieser mir nichtmal beantworten 
kann was z.B. ein Carry-Flag ist, gechweige denn wie man damit eine 
effiziente Zählschleife baut, dann darf der gut gepflegte 
Wichtigtuer-Bengel mit seinem gepflegten Hippster-Rauschebart gerne 
seinen schmucken, weißen Laptop mitsamt seiner interaktiven Präsentation 
wieder einpacken und abdampfen, egal wieviel ach so tolle 
Open-Source-Tools er angeblich gebaut hat.

von Georg (Gast)


Bewertung
8 lesenswert
nicht lesenswert
Die Unterschiede zwischen den Assembler-Sprachen verschiedener 
Prozessoren sind sowieso nicht kriegsentscheidend, ob die Grundbefehle 
nun LD, MOV, ROT, SHIFT oder sonstwie heissen hat man bei halbwegs 
normaler geistiger Beweglichkeit schnell drauf, viel entscheidender ist 
das Wissen darüber, welche Bits man in welchem Control-Register setzen 
muss, damit serielles Senden oder eine ADC-Messung so läuft wie sich das 
der Programmierer vorstellt - und das ist bei Assembler oder C genau 
dasselbe Problem. Da muss man halt im Zweifelsfall tatsächlich mal das 
Manual lesen.

Georg

von Lothar (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Der Hauptgrund bei mir der mich heute zwingt mich mit 8051
> zu beschäftigen ist daß ein EFM8BB1 von Silabs deutlich weniger
> als 30ct kostet

Grade bei dem lässt sich in Assembler einiges mehr rausholen darum ist 
z.B. die "Standard" BLDC Regelung für Multicopter in Assembler 
programmiert:

http://fpv-racer.net/blheli-s-firmware-for-busybee-esc-aikon-sefm-30a-dys-xs20a-dys-xs30a/

von Michael L. (michaelx)


Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:
> Max M. schrieb:
>> da es mich interessiert, wie viel man mit wenig Ressourcen machen kann,
>> möchte ich demnächst ein paar kleinere Projekte mit Mikrocontrollern,
>> die in Flash- und RAM-Größe sehr beschränkt sind, umsetzen. Speziell hab
>> ich mir da den PIC 10F220 ausgesucht. Programmiert werden soll er mit
>> dem PicKit3 und der IDE + C-Compiler von Microchip (Assembler möchte ich
>> mir nicht antun).
>
> [...]
>
> Mit C geht bei 16 Byte RAM genau gar nichts. [...]

Das von anderen, insbesondere von Gästen solche uninformierten Aussagen 
kommen - geschenkt. Aber bei dir bin ich dann doch enttäuscht.

Natürlich ist der mit C programmierbar. Neben dem Microchip CX8 gibt es 
auch den CC5X von Knudsen Data.

Klar, dass man mit einem 10F220 kein Atomkraftwerk steuern kann. Noch 
nicht mal ein "Apfelmännchen" lässt sich damit nicht berechnen.

Trotz dem ist der Witzling durchaus verwendbar.

Ich hab selbst schon den 10F200 verwendet, und eine recht komplexe 
Steuerung für einen kleinen Tester umgesetzt, die den Speicher bei 
weitem nicht ausgereizt hat.  Beschaltung 1 Einganssignal, 1 LED, 1 
Piezo-Scheibe, 1 Taster, 1 Steuerausgang. Wer jetzt denkt ... uhhh ... 
das sind aber 5! - LED und Taster hingen an einem I/O-Pin. Das Programm 
konnte unterschiedliche Tastendrücke erkennen, optische und Tonsignale 
erzeugen, und den Tester automatisch selbst abschalten, und hat den 
Programmspeicher vom 10F200 nur zur Hälfte belegt, beim RAM war's wohl 
noch weniger.

Also ja, da geht was.

von Michael L. (michaelx)


Bewertung
5 lesenswert
nicht lesenswert
Ehrhardt schrieb:
> Bernd K. schrieb:
>> Aber solche ASM-Superprofis wie hier mit derart schrägen Vorstellungen
>> und Prioritäten und derartiger Selbstüberschätzung würden ein
>> ernsthaftes Problem mit mir bekommen. Man kann nämlich alles übertreiben
>> und wenn der Code aufgrund solcher selbstverliebter ASM Trottel und
>> inkompetenter C-Verweigerer zum unwartbaren ASM-Spaghetti verkommt dann
>> wäre Schluss mit lustig.
>
> du verkennst womöglich die Aussagen
>
> ich bin auch ein Chef und wenn ich zu eintscheiden habe ob ein
> C-Programmierer eingestellt wird und dieser mir nichtmal beantworten
> kann was z.B. ein Carry-Flag ist, gechweige denn wie man damit eine
> effiziente Zählschleife baut, dann darf der gut gepflegte
> Wichtigtuer-Bengel mit seinem gepflegten Hippster-Rauschebart gerne
> seinen schmucken, weißen Laptop mitsamt seiner interaktiven Präsentation
> wieder einpacken und abdampfen, egal wieviel ach so tolle
> Open-Source-Tools er angeblich gebaut hat.

So wie du dich echauffierst, verkennst du womöglich die Problematik.

Der Maßstab ist nicht, ob jemand C-Programmierer ist, sondern auf 
welchem Gebiet er SW entwickelt. Der Eine schreibt Anwendungsprogramme 
für den PC, der nächste Gerätetreiber, andere wiederum SW für 
Microcontroller. Nicht jeder kann deswegen zwangsläufig auch das andere. 
Aber C ist bestens dafür geeignet, guten Code selbst für kleinste 
Microcontroller zu schreiben. Dafür gibt es extra angepasste Compiler, 
und man kann jeder Zeit in C zwecks Optimierung Assemblercode einbetten. 
Aber meist ist der vom Compiler generierte Code besser als es die 
C-Hater wahrhaben wollen. C-Code ist zudem schneller zu erstellen und 
leichter zu pflegen, insbesondere wenn man wechselnd auf 
unterschiedlichen Hardwareplattformen arbeiten muss. Die Verwendung von 
C ist also kein Indikator. Schlechten Code kann man wirklich in jeder 
Sprache fabrizieren, auch in Assembler.

: Bearbeitet durch User
von c-hater (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
Michael L. schrieb:

> Also ja, da geht was.

Der Punkt ist: mit Assembler geht immer noch ein wenig mehr. Schlimmer 
noch: nur allzu oft überspringt man damit genau den Unterschied zwischen 
"geht nicht" und "geht doch".

Natürlich kann man das oft auch mit viel Gefrickel mit unlesbarem 
inline-Assmbler, Linkerscripts und weiß der Fuchs was für Tricks der 
konkrete Compiler für das konkrete Target bietet hinkriegen. Aber warum 
kompliziert, wenn es auch einfach, natürlich und direkt geht?

Das ist doch völliger Schwachsinn! Nur C-dioten bestehen darauf, das 
unbedingt mit den Werkzeugen ihren kleinen, beschränkten Welt abbilden 
zu wollen. Sie sind einfach unfähig zu begreifen, dass sie mit der 
Anwendung all dieser Tricks im Endeffekt die einzige Daseinsberechtigung 
ihrer Sprache vollkommen ad absurdum führen. Denn das Ergebnis ist 
genauso wenig portabel wie nativer Assemblercode. Und obendrein mit an 
Sicherheit grenzender Wahrscheinlichkeit immer noch weniger effizient 
als das Werk eines echten Assemblerprogrammierers...

Also: purer Schwachsinn in höchster Potenz. Sinnlose Verschwendung von 
Mannjahren an Entwicklungszeit.

von Michael L. (michaelx)


Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Michael L. schrieb:
>
>> Also ja, da geht was.
>
> Das ist doch völliger Schwachsinn! Nur C-dioten [...]
>
> Also: purer Schwachsinn in höchster Potenz. Sinnlose Verschwendung von
> Mannjahren an Entwicklungszeit.

Dein Vater hätte besser einen Kondom benutzt.

von Geron (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> Danke für eure hilfreichen Antworten. Vllt. eine naive Frage, aber warum
> kann man den genannten PIC nicht mit der IDE in C programmieren bzw.
> warum ist mit Assembler ein größerer Funktionsumfang möglich als mit C?
> Liegt. es an den Header-Dateien die man z.B für die ISRs importieren
> müsste (wobei die eigentlich im Flash landen). Der Overhead von C müsste
> doch hauptsächlich im Flash stattfinden, oder?

Weil du in Assembler viel mehr tricksen kannst als in C möglich wäre und 
diese Tricks, die sparen natürlich Speicherplatz.
Der C Compiler aber, der muss nach Schema F compilieren, sein einziger 
Vorteil ist nur der, das der Code leichter portierbar ist und der 
Compiler alle OpCodes kennt und daher besser optimieren kann, aber 
letzteres gilt nur dann, wenn die CPU selbst komplex ist.

Bei einem kleinen µC ist das aber nicht der Fall, das ist schließlich 
keine moderne High End CPU wie man sie bei Intel oder AMD basierten PCs 
vorfindet.
Solche kleinen µC sind überschaubar und was überschaubar ist, das kann 
der Mensch besser optimieren als ein Compiler.



Meine Empfehlung, nimm den billigsten MSP430 für ca. 36 Cent bei 
Digikey, der bietet immerhin schon 128 Bytes RAM und 512 Bytes 
Flashspeicher.
Außerdem ist dieser µC deutlich moderner und auch noch vom 
Stromverbrauch super sparsam.

von Georg (Gast)


Bewertung
13 lesenswert
nicht lesenswert
Die Diskussion entwickelt sich wie immer: diejenigen, die Assembler 
nicht beherrschen, erklären C zur Lösung für alle Probleme der Welt und 
prügeln auf die Assemblerprogrammierer ein. Die Assemblerprogrammierer 
prügeln auf die C-Fanatiker ein, weil die garkeine Ahnung haben was im 
Prozessor tatsächlich passiert. Und wer wie ich schon immer beides 
benutzt, je nach Anforderung, und meistens auch zugleich in einem 
Projekt, bekommt doppelt so viele Prügel, nämlich von beiden Seiten.

Was bringt die ganze Diskussion? Absolut nichts. Es muss eh jeder seine 
eigenen Probleme lösen, und solche Dreckschleudern wie c-hater helfen 
weder Anfängern noch Fortgeschrittenen.

Georg

von Georg (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Thomas E. schrieb:
> Das ist ja großartig, du Held.

Es gibt halt Leute, die ihr Handwerk tatsächlich beherrschen. Dass dann 
Nichtskönner sofort reflexartig mit solchen Hassausbrüchen antworten, 
ist traurig, aber nicht überraschend.

Georg

von Thomas E. (Firma: Thomas Eckmann Informationst.) (thomase)


Bewertung
0 lesenswert
nicht lesenswert
Georg schrieb:
> Thomas E. schrieb:
>> Das ist ja großartig, du Held.
>
> Es gibt halt Leute, die ihr Handwerk tatsächlich beherrschen. Dass dann
> Nichtskönner sofort reflexartig mit solchen Hassausbrüchen antworten,
> ist traurig, aber nicht überraschend.
>
> Georg

Was willst du denn?
Du tust ja gerade so, als könntest du das beurteilen.

von Georg (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Thomas E. schrieb:
> Du tust ja gerade so, als könntest du das beurteilen

Das ist garnicht nötig, du outest dich mit solchen Posts ja selber.

Georg

von Wilhelm M. (wimalopaan)


Bewertung
0 lesenswert
nicht lesenswert
Das scheint mir jetzt der richtige Zeitpunkt zu sein, um C++ ins Spiel 
zu bringen ;-)

von sadfsdf (Gast)


Bewertung
4 lesenswert
nicht lesenswert
Und wie so oft bei solchen Threads hat sich der TO schon lange 
"abgemeldet" und kringelt sich vor lachen ob der Schlammschlacht von 
Egomanen hier im Forum.

Schade eigentlich, so kurz vor dem "Fest der Liebe" sollten wir doch 
alle etwas netter zueinander sein.

Schöne Feiertage!

von Bernd K. (prof7bit)


Bewertung
11 lesenswert
nicht lesenswert
Georg schrieb:
> Die Assemblerprogrammierer
> prügeln auf die C-Fanatiker ein, weil die garkeine Ahnung haben was im
> Prozessor tatsächlich passiert.

Es gibt noch eine dritte Fraktion und die bekommt den Job: Es sind 
diejenigen die eine hervorragende Ahnung davon haben was im Prozessor 
passiert, die bei Bedarf auch zwölf Zeilen ASM entziffern können wenn es 
drauf ankommt und die genau *DESHALB* wissen daß sie 99% der 
anfallenden Programmiertätigkeit auf dem µC lieber in C oder C++ als in 
ASM betreiben sollten, weil sie die Nachteile beider Welten gesehen und 
daraufhin zielsicher das geringere Übel gewählt haben.

von Wilhelm M. (wimalopaan)


Bewertung
0 lesenswert
nicht lesenswert
sadfsdf schrieb:
> Und wie so oft bei solchen Threads hat sich der TO schon lange
> "abgemeldet" und kringelt sich vor lachen ob der Schlammschlacht von
> Egomanen hier im Forum.
>
> Schade eigentlich, so kurz vor dem "Fest der Liebe" sollten wir doch
> alle etwas netter zueinander sein.

Hat doch schon was gebracht: der nä. Post, nachdem ich C++ geschrieben 
habe, spricht vom Fest der Liebe ... ;-)

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
> Und wie schon gesagt, hat man als nächstes Problem bei der modularen
> Programmierung den viel zu kleinen HW-Stack.

Diese minimal-µC ohne RAM sind sicher nur für ganz kleine Anwendungen 
gedacht. Was will man da mit Modulen anfangen?

Man kann sich das Leben auch selbst verkomplizieren.

Wenn ich eine Schubkarre brauche, dann kaufe ich eine Schubkarre = 
simple Blechschwanne mit zwei Griffen und einem Rad drunter. Sicher kann 
man die Schubkarre auch durch eine modulare Baumaschine ersetzen, aber 
das würde ich ohne guten Grund nicht tun.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
-4 lesenswert
nicht lesenswert
Thomas E. schrieb:
> Was willst du denn?
> Du tust ja gerade so, als könntest du das beurteilen.

 Du kannst nicht beurteilen, ob er das beurteilen kann oder nicht.

 Aber egal, die Frage war: was kann man mit 16Byte an RAM machen ?
 Die Antwort ist: nicht viel in C, bedeutend mehr in ASM.

 Bei 16Byt RAM fängt man gar nicht erst mit C an. Die ganze dazu
 nötige Gehirnakrobatik, um mit 16Byte überhaupt ein einigermassen
 sinnvolles Programm zum Laufen zu bringen, lohnt sich doch eh
 nicht. Das hat man mit ASM viel schneller hingekriegt.
 Und das es Leute gibt die so etwas kaufen, um damit anzufangen,
 werde ich niemals begreifen.

 So etwas nimmt man als Sensor/Aktor und dann ist aber auch Schluss.
 Und dafür war es wahrscheinlich auch gedacht, also ASM von vorn-
 herein, kein C.

 Ende.

von Werner H. (pic16)


Bewertung
1 lesenswert
nicht lesenswert
Der Haupsächliche Einsatz laut Microchip: Timer, Logik und PLDs in 
größeren Systemen. Natürlich kann man die Dinger auch für kleinere stand 
allone Projekte einsetzen und mittels C den Inhalt drauf quetschen. Die 
Flexibilität ist aber bei ASM ungleich höher. Und ja, wer in C proggt 
solte auch ASM können und den mc kennen.

von Michael L. (michaelx)


Bewertung
3 lesenswert
nicht lesenswert
Hach, das geht ja wieder ab wie Schmitts Katze. :-D

Immer diese Lobpreisungen des jeweils beherrschten Hammers als 
ultimatives Werkzeug. Da weiß ich nie, ob ich lachen oder Mitleid haben 
soll.

Und am lautesten melden sich jeweils die zu Wort, die zur entsprechenden 
Problematik grad die geringste Ahnung haben. Der Blinde schwätzt über 
die Nutzlosigkeit von Farbe, der Taube verachtet den Gesang. Oder um es 
mit aktuellen Worten zu formulieren: Man hält seine regentropfen-kleine 
Filterblase für den Ozean.

"Mit 16 Byte geht kein C"

Ja klar, und die Hersteller entsprechender Compiler hätten besser gut 
daran getan, mal vorher bei euch Klugscheißern nachzufragen, ebenso die 
ganzen Leute, die mit diesen Compilern tagtäglich arbeiten.

Einstein hatte den Finger drauf:
"Die Majorität der Dummen ist unüberwindbar und für alle Zeiten 
gesichert."

von Schreiber (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Max M. schrieb:
> da es mich interessiert, wie viel man mit wenig Ressourcen machen kann,
> möchte ich demnächst ein paar kleinere Projekte mit Mikrocontrollern,
> die in Flash- und RAM-Größe sehr beschränkt sind, umsetzen. Speziell hab
> ich mir da den PIC 10F220 ausgesucht.

Sowas ist, bei Massenproduktion, ein zeigemäßer Ersatz für ein kleines 
Relais-, NE555- oder TTL-Grab, das mit einigen OPVs gewürzt sein kann. 
Nicht mehr und auch nicht weniger.
Bei kleineren Stückzahlen: Besseren µC mit mehr Ram und mehr Pins 
einsetzen, das schont die Nerven!

Marc V. schrieb:
> Aber egal, die Frage war: was kann man mit 16Byte an RAM machen ?
>  Die Antwort ist: nicht viel in C, bedeutend mehr in ASM.
Knapp daneben: Korrekte Antwort: nicht viel in C, kaum mehr in ASM.
Etwas Hiernschmalz beim Programmeren ist aber hilfreich, mit einem 8-bit 
Festkomma µC sollte man 32bit Gleitkomma-Berechnungen tunlichst 
vermeiden.

Zurückhaltung bei Funktionsaufrufen, passende Variablendeklaration und 
Vermeidung sinnlos Verschachtelter oder Aufgeblasener Funktionen ist 
ebenfalls sinnvoll.

von Peter D. (peda)


Bewertung
1 lesenswert
nicht lesenswert
Marc V. schrieb im Beitrag #4832187:
> Michael L. schrieb:
>> "Mit 16 Byte geht kein C"
>
>  Hat keiner gesagt.

Stimmt.
Z.B. ich habe nur gesagt, daß es für serielle Protokolle recht knapp 
werden wird, da die oft paketorientiert arbeiten, was man viel einfacher 
auf Arrays abbilden kann.

Die C-Hater sollten sich mal anschauen, wie gute Compiler arbeiten. Die 
Compilerbauer sind ja keine Anfänger und können da mehrere Mannjahre 
investieren. Nicht ohne Grund sind professionelle Compiler kein 
Schnäppchen und trotzdem keine Ladenhüter.
Man kann oftmals in C mehr aus einem knappen RAM machen, als in 
Assembler. Ein Compiler kann einfach einen Calling-Tree erstellen und 
Variablen überlagern. In Assembler wäre das sehr aufwendig und man geht 
lieber weniger effektiv mit dem RAM um.
Auch einen limitierenden HW-Stack kann ein Compiler gut verstecken. Man 
schreibt modular und der Compiler inlined dann einfach die Funktion an 
den 10 Stellen, wo sie aufgerufen wird. Kostet eben mehr Flash, als ein 
echter Stack.

Als ich den Schritt von Assembler zu C wagte, wurden die Programme 
schneller und brauchten weniger Flash. Davor hätte ich auch 1000 Eide 
geschworen, daß es genau umgekehrt sein muß. Und vor allem konnte man 
sie sauschnell schreiben im Vergleich zu Assembler.

Ich kann Assembler Output lesen, aber ob das unbedingt eine 
Voraussetzung für einen guten Programmierer sein muß, auf dieses schmale 
Brett würde ich mich nicht stellen.

Ich kann sogar PIC-Assembler lesen, aber das ist wirklich der mit 
Abstand umständlichste Assembler, der mir untergekommen ist.
Z.B. bei INCFSZ brauchte ich lange, um alle seine Feinheiten verstehen. 
Wie man in Posts lesen kann, ging das aber nicht nur mir so.

von <><><><0><><><> (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Hallo wir haben ja nicht 1969. du bist auf den Holzweg, wen du Nichts 
machen möchtest da fange erst gar nicht damit an.

von Volker S. (vloki)


Bewertung
-1 lesenswert
nicht lesenswert
Peter D. schrieb:
> Z.B. bei INCFSZ brauchte ich lange, um alle seine Feinheiten verstehen.

Manchmal scheint es mir so als hätte ich in all meinen PIC Jahren gar 
nichts kapiert. (Gar nicht gemerkt, dass es da "Feinheiten" gibt ;-)

von W.S. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Peter D. schrieb:
> In der Codesammlung findest Du Beispiele von mir mit dem ATtiny12
...
> Ich will...nicht auch..
> noch auf den Stack aufpassen müssen und Unterfuntionen kopieren, statt
> sie zu callen.

CALLEN...
(do you speak britisch? yes, a paar broken.."

Peter, lass es BITTE! Du bist gedanklich immerzu bei den AVR's und C und 
nicht bei den PIC's und Assembler.

Da sind erhebliche Unterschiede - und offensichtlich UNÜBERBRÜCKBAR. Du 
hast ja nichtmal das verstanden, was ich geschrieben habe.

Natürlich ruft man auch bei den kleinen PIC's Unterprogramme mit CALL 
auf und verläßt sie mit RETURN. Aber man packt eben keine Argumente in 
den Stack, denn der liegt völlig außerhalb von Datensegment und 
Codesegment.

Ich geb dir mal nen Ausschnitt (nur zum Draufgucken):
1
HexOut24:
2
         MOVF      ADC_roh+2,W
3
         CALL      Hexaus
4
         MOVF      ADC_roh+1,W
5
         CALL      Hexaus
6
         MOVF      ADC_roh,W
7
8
; Hexa-Ausgabe von W
9
Hexaus:  MOVWF     Hudl     ; merken
10
         SWAPF     Hudl,W   ; Hi-Nibble nach W
11
         ANDLW     15
12
         ADDLW     246      ; ab 10 --> Carry
13
         SKIP      NC
14
         ADDLW     7
15
         ADDLW     48-246+256
16
         CALL      SayIt
17
         MOVF      Hudl,W   ; Hi-Nibble nach W
18
         ANDLW     15
19
         ADDLW     246      ; ab 10 --> Carry
20
         SKIP      NC
21
         ADDLW     7
22
         ADDLW     48-246+256
23
         GOTO      SayIt

Das sind Ausgaberoutinen für Hexa-Zahlen: 4, 8 und 24 Bit in Assembler 
für PIC16F8xx oder so. Wundere dich nicht, daß es hier keine RETURN's zu 
sehen gibt. Die sind bei sinnvoller Anordnung der Funktionen oftmals 
nicht nötig, wohl aber in manchen Fällen das Sparen mit Returnadressen 
im Stack.

Es ist eben ne andere Welt als AVR.

W.S.

von S. Landolt (Gast)


Bewertung
2 lesenswert
nicht lesenswert
> Sparen mit Returnadressen im Stack.

Dies ist aber nicht PIC-spezifisch; damit spare ich auf einem AVR vor 
allem die 7 Takte für rcall & ret.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> für PIC16F8xx oder so. Wundere dich nicht, daß es hier keine RETURN's zu
> sehen gibt. Die sind bei sinnvoller Anordnung der Funktionen oftmals
> nicht nötig, wohl aber in manchen Fällen das Sparen mit Returnadressen
> im Stack.

 Ich wundere mich aber.
 Jeder CALL Befehl macht vorher ein PUSH von PC+1 auf den Stack.
 Wenn es kein RETURN gibt, kann dein Programm niemals dort zurückkehren
 von wo diese Routine aufgerufen wurde.
 Also, machen möchtegern Programierer nachträglich einen Sprung
 irgendwo vor einen RETURN und glauben, das wäre besonders klug oder
 sogar genial.
 Ich nenne so etwas dumm und Spaghetticode.

 Die einzig richtige Lösung hat Peter aber schon genannt:

Peter D. schrieb:
> Auch einen limitierenden HW-Stack kann ein Compiler gut verstecken. Man
> schreibt modular und der Compiler inlined dann einfach die Funktion an
> den 10 Stellen, wo sie aufgerufen wird. Kostet eben mehr Flash, als ein
> echter Stack.

: Bearbeitet durch User
von S. Landolt (Gast)


Bewertung
2 lesenswert
nicht lesenswert
> Wenn es kein RETURN gibt ...
Ganz sicher gibt es ein return, das steht am Ende des nicht gezeigten 
SayIt.
  Über das Gewicht der Einsparung lässt sich allerdings in der Tat 
trefflich streiten.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
S. Landolt schrieb:
> Ganz sicher gibt es ein return, das steht am Ende des nicht gezeigten
> SayIt.

 Ja.
1
         ADDLW     7
2
         ADDLW     48-246+256
3
;         GOTO      SayIt
4
SayIt:
 So wäre es besser und kürzer.

von S. Landolt (Gast)


Bewertung
2 lesenswert
nicht lesenswert
> So wäre es besser und kürzer.
Richtig, und so hat er es mit seinem Hexaus ja gemacht, es geht aber 
eben immer nur einmalig. Und was daran PIC-spezifisch sein soll, bleibt 
mir unverständlich.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Da sind erhebliche Unterschiede - und offensichtlich UNÜBERBRÜCKBAR. Du
> hast ja nichtmal das verstanden, was ich geschrieben habe.

Nö, Du hast es nicht verstanden. Nochmal, die alten ATtiny12 hatten 
einen HW-Stack, ganz genau wie die kleinen PICs. Und deshalb mußte ich 
höllisch aufpassen, eine Callingtiefe von 3 nicht zu überschreiten, bzw. 
2, wenn man Interrupts verwendete. Er war daher genauso eklig zu 
programmieren, wie die PICs mit nur 2-level HW-Stack.

von Peter D. (peda)


Bewertung
2 lesenswert
nicht lesenswert
W.S. schrieb:
> CALLEN...
> (do you speak britisch? yes, a paar broken.."

Ja, Programmierer callen, pushen, returnen, jumpen, moven usw. In der 
Regel versteht das auch jeder sofort.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
1 lesenswert
nicht lesenswert
S. Landolt schrieb:
>> So wäre es besser und kürzer.
> Richtig, und so hat er es mit seinem Hexaus ja gemacht, es geht aber
> eben immer nur einmalig. Und was daran PIC-spezifisch sein soll, bleibt
> mir unverständlich.

 Es ist nicht sein Hexaus, genauso macht man es z.B. bei AVR und der
 LCD-Ausgabe. SWAP Nibble, CALL, SWAP Nibble, durchfallen...

 Mir ist auch nicht ganz klar was daran so PIC-spezifisch sein soll.

von Max M. (maxmicr)


Bewertung
0 lesenswert
nicht lesenswert
Mir ist gerade aufgefallen, dass der PIC10F220 zwar einen Timer hat, 
aber keinen Overflow-Interrupt (bzw. gar keine Interrupts). Das macht 
das Programmieren nicht angenehmer. Ich werde versuchen, mich in den PIC 
Assembler einzuarbeiten. Aktuell ist Assembler (programmieren) auch 
Thema im Studium, von dem her kann es eh nicht schaden. Danke für die 
vielen Antworten.

: Bearbeitet durch User
von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> Mir ist gerade aufgefallen, dass der PIC10F220...

Nimm doch wenigstens einen 10F32x.

von Geron (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
Peter D. schrieb:

> Als ich den Schritt von Assembler zu C wagte, wurden die Programme
> schneller und brauchten weniger Flash. Davor hätte ich auch 1000 Eide
> geschworen, daß es genau umgekehrt sein muß. Und vor allem konnte man
> sie sauschnell schreiben im Vergleich zu Assembler.

Das sagt etwas über deine Fähigkeiten in Assembler aus.

Wie schon gesagt, auf so kleinen Dingern sind die Funktionen der CPU 
überschaubar und der Mensch kriegt bessere Ergebnisse in Assembler hin 
als der C Compiler, allerdings gilt das natürlich nicht, wenn der Mensch 
nen schlechten Code schreibt.

Da ist der Mensch nämlich dann das schlechteste Glied, aber theoretisch 
dem Compiler überlegen.

Erst dann, wenn die CPU nicht mehr überschaubar ist, liegt der Compiler 
ganz vorne.
Letzteres gilt bei so allen modernen Intel und AMD x64 CPUs, allerdings 
nicht für solche kleinen µC mit ner Handvoll überschaubarer Opcodes und 
16 Byte RAM.




> Ich kann sogar PIC-Assembler lesen, aber das ist wirklich der mit
> Abstand umständlichste Assembler, der mir untergekommen ist.
> Z.B. bei INCFSZ brauchte ich lange, um alle seine Feinheiten verstehen.
> Wie man in Posts lesen kann, ging das aber nicht nur mir so.

Deswegen habe ich weiter oben einen MSP430 empfohlen. PIC ist von 
vorgestern und dann auch noch ein 8 Bitter, der MSP430 ist schon 16 Bit 
und mit so etwas wie segmentiertem RAM oder Bankwechsel muss man sich 
bei dem auch nicht herumärgern.
Warum also so uralte CPU Architekturen einsetzen, wenn es schon längst 
bessere gibt?

Der erste Fehler beginnt nicht erst bei der verwendeten Sprache, sondern 
bei der Wahl der Hardware.

von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
Geron schrieb:
> Der erste Fehler beginnt nicht erst bei der verwendeten Sprache, sondern
> bei der Wahl der Hardware.

Und die Hardware sollte man erst wählen, wenn man ein Projekt hat, 
welches man realisieren will. Zuerst einen uC auswählen und dann ein 
Projekt dafür suchen ist schon schwierig aber ich nehme mal an der 
Threadstarter hatte irgendwas im Hinterkopf.

Max M. schrieb:
> Was mich ebenfalls noch interessieren würde, ist, ob sich mit den
> beschränkten Ressourcen auch eine Software-I2C Lösung implementieren
> ließe? Vom Flash her dürfte das imho kein Problem sein, aber ich weiß
> nicht, ob das RAM dafür reicht? Die Funktionalität des I2C-Systems würde
> ich auf mehrere Funktionen aufteilen, wenn man davon ausgeht, dass nach
> dem Rausspringen aus einer Funktion der RAM, der in der Funktion
> benötigten Variablen, freigegeben wird, könnte das klappen, oder?

Da bei so kleinen PICs das Debuggen ohne Debug-Header nicht sinnvoll 
ist, einfach das Programm schreiben und mit dem Simulator überprüfen. Da 
sieht man sofort wieviele Resourcen verbraucht werden. Kaufen muss man 
auch noch nichts. Das kann warten, bis man eine Vorstellung bekommen 
hat, ob eine Realisierung überhaupt möglich ist.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
5 lesenswert
nicht lesenswert
Geron schrieb:
>> schneller und brauchten weniger Flash. Davor hätte ich auch 1000 Eide
>> geschworen, daß es genau umgekehrt sein muß. Und vor allem konnte man
>> sie sauschnell schreiben im Vergleich zu Assembler.
>
> Das sagt etwas über deine Fähigkeiten in Assembler aus.

 Bestimmt nicht.
 Guck dir mal die vom C-Compiler erzeugten Listings an.
 Da sind manchmal Tricks drin, da fragt man sich warum man nicht
 selber draufgekommen ist und ob man wirklich so dumm ist...

 Interrupts können zu jedem beliebigen Zeitpunkt feuern, welche Register
 will man da sichern - AVR hat 32 davon - alle ?

 Wenn man ein nur einigermassen kompliziertes Programm in ASM schreibt,
 müssen die benutzten Register und die geänderten Variablen irgendwo
 verfolgt und festgehalten werden.
 Ich habe mir sogar seinerzeit ein Programm geschrieben, das nur dazu
 diente, benutzte Register und Änderungen in ASM-Listings zu verfolgen.
 CALL und RCALL rausgesucht - Routine gefunden - RET gefunden - benutzte
 Register dazwischen ausgegeben.
 Ging natürlich mit modularem Programmaufbau wunderbar, aber dann
 kamm die Entscheidung bei bedingtem Sprung, Labels, etc...
 Ich gab auf und behielt nur den CALL/RCALL Zweig und den benutze ich
 heute noch.

Geron schrieb:
> Erst dann, wenn die CPU nicht mehr überschaubar ist, liegt der Compiler
> ganz vorne.

 Deine Aussage zeugt nur davon auf welchem Schwierigkeitsgrad bzw.
 Niveau sich deine Programme befinden.

von W.S. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Peter D. schrieb:
> Und deshalb mußte ich
> höllisch aufpassen, eine Callingtiefe von 3 nicht zu überschreiten, bzw.
> 2, wenn man Interrupts verwendete. Er war daher genauso eklig zu
> programmieren, wie die PICs mit nur 2-level HW-Stack.

Na, das ist ja mal ne seltene Übereinstimmung.

Aber schreib nicht so generalisierend. Ganz alte PIC's hatten keinen 
Interrupt - ist aber schon 25 Jahre her. Die "normalen" kleinen PIC's 
(16Fxxx) haben zumeist 8 Stack-Plätze, manche neueren auch mehr. Es sind 
nur die ganz winzigen PIC's, die weniger haben - aber das kann man ja 
auch einsehen: so ein winziger 6-Beiner mit 512 Programmschritten ist 
eben nur für ganz kleine Vorhaben vorgesehen und da braucht man i.All. 
auch weniger Stacktiefe.

Nochwas zu dem geposteten Quell-Ausschnitt: Das war zum Angucken, wie 
sowas bei den PIC's aussehen kann - und nicht zum Behaupten, daß 
Prinzipien, die man zwar in Assembler, aber eben NICHT in C machen kann, 
als solche PIC-spezifisch wären. Zu sowas gehören auch Operationen 
über's carry, also Schieben, Rotieren usw. Wer den Lampe-Jorke-Wengel 
mal gelesen hat weiß, wie effektiv sowas bei kluger Planung sein kann 
(Z80).

Ich kenne Leute, die zwar von PIC's keine Ahnung haben, aber dennoch im 
Brustton allertiefster Überzeugung sagen "ich wüßte nicht, warum ich so 
einen PIC NICHT in C programmieren sollte."



Max M. schrieb:
> Mir ist gerade aufgefallen, dass der PIC10F220 zwar einen Timer hat,
> aber keinen Overflow-Interrupt (bzw. gar keine Interrupts). Das macht
> das Programmieren nicht angenehmer.

Wenn du erst noch anfangen willst, dann greife zuerst lieber zu einem 
PIC16F... und nicht zu allererst zu einem der ganz winzigen Typen.

Laß dir das geraten sein.

Und schau dir verschiedene PIC-Assembler an, denn manche haben ne 
gefälligere Syntax als die Originale von Microchip.

W.S.

von W.S. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Marc V. schrieb:
> Interrupts können zu jedem beliebigen Zeitpunkt feuern, welche Register
>  will man da sichern - AVR hat 32 davon - alle ?
>
>  Wenn man ein nur einigermassen kompliziertes Programm in ASM schreibt,
>  müssen die benutzten Register und die geänderten Variablen irgendwo
>  verfolgt und festgehalten werden.

nanana..
Mal ganz ruhig: Man weiß ja wohl, was für Register man im 
Interrupthandler zu benutzen gedenkt. Und da wir hier nicht bei AVR 
sind, sondern bei den PIC's, muß man sich um die dort üblichen 
Verdächtigen kümmern: W und Status und je nach PIC und Anwendung ggf. 
FSR und Bank.

Das war's.

Bei dem "nur einigermassen kompliziertes Programm in ASM" handelt es 
sich um eine Chimäre - konkret wird die Aussage nur dann, wenn man sie 
auf eine bestimmte CPU-Architektur bezieht. Alles durcheinanderwürfeln 
und generös von "in Assembler" reden, gilt nicht.

Bei Registermaschinen macht man das normalerweise so, daß man die in 
einem Unterprogramm benutzten Register zuvor auf dem Stack rettet - bis 
auf diejenigen, die nach eigener Konvention zum beliebigen Benutzen 
deklariert sind.

Das trifft auf die kleinen PIC's aber nicht zu, wenn man mal von W 
absieht.

Also bitte keine derartigen Verallgemeinerungen.

W.S.

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Bei Registermaschinen macht man das normalerweise so, daß man die in
> einem Unterprogramm benutzten Register zuvor auf dem Stack rettet

Welche wären das? Beim 8051 und den Cortex A/R nimmt man in Assembler 
erst mal die anderen Registerbänke her und braucht meist gar keinen 
Stack. Und bei den Cortex M werden ja bei Interrupts automatisch 
bestimmte Register auf den Stack geschoben, was dann DIE Fehlerquelle 
für den Hardfault ist.

von Georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Marc V. schrieb:
> Interrupts können zu jedem beliebigen Zeitpunkt feuern, welche Register
>  will man da sichern - AVR hat 32 davon - alle ?

Was für ein Unsinn - wozu Register sichern, die in der ISR garnicht 
verändert werden? Das sind aber nun wirklich allerprimitivste 
Grundlagen, die jeder Assembler-Programierer wissen MUSS.

Georg

von Peter D. (peda)


Bewertung
3 lesenswert
nicht lesenswert
Geron schrieb:
> Das sagt etwas über deine Fähigkeiten in Assembler aus.

Der Schuß ging ins Leere.
Schau Dir einfach mal die alten Assemblerbeispiele (8051, AVR) von mir 
an.

von Max M. (maxmicr)


Bewertung
0 lesenswert
nicht lesenswert
Also Assembler ist schon lustig :D
8% des Flash vom PIC10F200 sind mit diesem Programm belegt:
1
#include <p10f200.inc>
2
3
incrReg  EQU 10h
4
cmpVal  EQU 11h
5
cmpReg  EQU 12h
6
    
7
    org 0x00
8
call  outputGPIOs
9
    
10
main  bsf  GPIO,0    ;set GP0 to 'HIGH'
11
    
12
  movlw  00ah    ;set '10' in register 11h
13
  movwf  cmpVal
14
  
15
  call  delay    ;wait 10 incrementations
16
  bcf  GPIO,0    ;set GPO to 'LOW'
17
  goto  main
18
  
19
outputGPIOs:
20
    movlw   00h
21
    tris    6      ;set all pins as output [@TRISIO]
22
    retlw 0
23
    
24
delay:
25
    movfw   cmpVal    ;copy content from 11h to 12h
26
    movwf   cmpReg      
27
    movfw   incrReg
28
    subwf   cmpReg    ;subtract counter value
29
    btfsc   STATUS,2    ;check if compare and increment value are equal
30
    goto    endDelay
31
    incf    incrReg
32
    goto    delay
33
endDelay
34
    retlw 0
35
    
36
END

Schade, dass man 2 Register nicht direkt vergleichen kann sondern diese 
Umwege gehen muss :(

Edit: Ich hab mal versucht, das ganze in C nachzumachen:
1
#include <xc.h>
2
#define _XTAL_FREQ 4000000
3
void main(void) {
4
    TRISGPIO = 0x00;
5
    while(1){
6
        GPIO |= (1<<0);
7
        __delay_ms(1);
8
        GPIO &=~(1<<0);
9
    }
10
}

Ich weiß nun nicht, inwiefern die 2 Programme vergleichbar sind, 
allerdings belegt das C-Programm 31% des RAMs und 7% des Flashes.

: Bearbeitet durch User
von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> Schade, dass man 2 Register nicht direkt vergleichen kann sondern diese
> Umwege gehen muss

Kennst du nen µC, wo man zwei Variablen im RAM direkt miteinander 
vergleichen kann?

Bei den kleinen PIC's geht es eben nur etwa so:
1
   MOVF  Variable1,W
2
   XORWF Variable2,W  ; oder wer mag SUBWF...
3
   SKIP  Z
4
   GOTO  sonstwohin

Ach ja, so ist das mit verschiedenen Assemblern:

   movfw   cmpVal

ist so ein Fall, den ich nicht mag. Ist nicht Standard und mit movwf 
leicht zu verwechseln. Man kann es mit einem garstigen Assembler dem 
Programmierer auch künstlich schwer machen.

W.S.

von Max M. (maxmicr)


Bewertung
0 lesenswert
nicht lesenswert
Kann es sein, dass der PIC10F200 die Pins gar nicht so schalten kann, 
dass I2C direkt möglich ist (Open-Drain)?

von Michael L. (michaelx)


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> [...]
> Ich weiß nun nicht, inwiefern die 2 Programme vergleichbar sind,
> allerdings belegt das C-Programm 31% des RAMs und 7% des Flashes.

Du musst dir einfach mal den ASM-Output des C-Compilers anschauen.

Davon gabesehen ist der XC8 als kostenlose Version nicht unbedingt die 
beste Wahl, weil Microchip da die meiste Optimierung abgeschaltet hat. 
Böse Zungen würden wohl sogar behaupten, dass der Code-Output künstlich 
aufgebläht wird. Daher ist der freie CC5X für die kleinen PICs i.d.R. 
besser geeignet.

: Bearbeitet durch User
von A. S. (achs)


Bewertung
2 lesenswert
nicht lesenswert
Max M. schrieb:
> Kann es sein, dass der PIC10F200 die Pins gar nicht so schalten kann,
> dass I2C direkt möglich ist (Open-Drain)?

Kann es sein, dass Dir wirklich die Basics fehlen? Entweder zu I2C oder 
zu µControllern? Open Drain wird durch DRR=1/0 mit PIN=0 realisiert.

von Thomas E. (picalic)


Bewertung
1 lesenswert
nicht lesenswert
Max M. schrieb:
> delay:
>     movfw   cmpVal    ;copy content from 11h to 12h
>     movwf   cmpReg
>     movfw   incrReg
>     subwf   cmpReg    ;subtract counter value
>     btfsc   STATUS,2    ;check if compare and increment value are equal
>     goto    endDelay
>     incf    incrReg
>     goto    delay
> endDelay
>     retlw 0

Das ist so ziemlich der umständlichste Delay-Loop, den ich je gesehen 
habe...

Man könnte sowas auch völlig ohne RAM-Speicher machen, und viel kürzer!
1
;---------------- Delay Unterprogramm
2
;Aufruf mit Delay-Wert in W, verzögert um W*4 +3 Zyklen 
3
delay
4
  addlw  -1
5
  btfss  STATUS,Z
6
  goto  delay
7
  retlw  0

von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> GPIO |= (1<<0);

Bei deinen nächsten Versuchen in "C" probier doch mal
1
GPIObits.GPIO0 = 1;
Wahrscheinlich geht auch einfach
1
GP1 = 1;

von Max M. (maxmicr)


Bewertung
0 lesenswert
nicht lesenswert
Thomas E. schrieb:
> Man könnte sowas auch völlig ohne RAM-Speicher machen, und viel kürzer!

Der Simulator zeigt bei mir, dass 0% vom RAM genutzt wird? Ehrlich 
gesagt weiß ich gar nicht, wie ich in Assembler explizit den RAM 
adressiere... Danke für deine Delay-Funktion, hatte da etwas Tomaten auf 
den Augen.

: Bearbeitet durch User
von Thomas E. (picalic)


Bewertung
1 lesenswert
nicht lesenswert
Uuuups - sorry, sehe gerade, daß die Sache einen kleinen Haken hat: der 
PIC10F200 hat gar keinen ADDLW-Befehl (der 10F32x schon)!
Also doch mit einer RAM-Speicherzelle:
1
;---------------- Delay Unterprogramm
2
;Aufruf mit Delay-Wert in W, verzögert um W*3 +4 Zyklen 
3
delay
4
  movwf  counter
5
delay_lp
6
  decfsz  counter,F
7
  goto  delay_lp
8
  retlw  0

von Max M. (maxmicr)


Bewertung
0 lesenswert
nicht lesenswert
Yey, 3% Flash gespart :D

von Thomas E. (picalic)


Bewertung
0 lesenswert
nicht lesenswert
Ha, und es gibt doch eine Möglichkeit, keinen wertvollen RAM-Inhalt für 
den Delay-Loop zerstören zu müssen:
1
Delay
2
  xorwf  0x10,F     ;Inhalt von W und Speicher (z.B. Adresse 0x10)
3
  xorwf  0x10,W     ;austauschen
4
  xorwf  0x10,F
5
6
DelayLoop
7
  decfsz  0x10,F
8
  goto  DelayLoop
9
10
  movwf   0x10       ;original Inhalt restaurieren
11
  retlw   0

: Bearbeitet durch User
von Volker S. (vloki)


Bewertung
1 lesenswert
nicht lesenswert
Max M. schrieb:
> Der Simulator zeigt bei mir, dass 0% vom RAM genutzt wird? Ehrlich
> gesagt weiß ich gar nicht, wie ich in Assembler explizit den RAM
> adressiere...

Im "relocatable mode" wird die RAM Nutzung auch in MPLABX angezeigt.

Im "absolute mode" wo man mit EQU irgendwelche Namen durch Adressen 
ersetzten lassen kann wird ja kein Speicherplatz reserviert.

Schau mal in den Ordner mit den Templates:
.../microchip/mplabx/v3.50/mpasmx/templates

Die für "relocatable" sind im Ordner .../templates/Object

: Bearbeitet durch User
von Geron (Gast)


Bewertung
-6 lesenswert
nicht lesenswert
Marc V. schrieb:
> Geron schrieb:
>>> schneller und brauchten weniger Flash. Davor hätte ich auch 1000 Eide
>>> geschworen, daß es genau umgekehrt sein muß. Und vor allem konnte man
>>> sie sauschnell schreiben im Vergleich zu Assembler.
>>
>> Das sagt etwas über deine Fähigkeiten in Assembler aus.
>
>  Bestimmt nicht.
>  Guck dir mal die vom C-Compiler erzeugten Listings an.
>  Da sind manchmal Tricks drin, da fragt man sich warum man nicht
>  selber draufgekommen ist und ob man wirklich so dumm ist...

Dir fällt nicht einmal auf, dass das in dem Kontext nicht einmal ein 
Argument ist.
Denn es ist nicht allgemeingültig, du machst sogar den Fehler und 
schließt in dem Fall sogar von dir auf die Frage, ob der Mensch besser 
sein kann als der Compiler bei Überschaubaren CPU Architekturen.

Als Mensch kannst du veränderlichen Code programmieren, das wird ein 
normaler Compiler nicht machen.
Das allein ist schon eine Möglichkeit um mit knappen Platz umzugehen.


>  Interrupts können zu jedem beliebigen Zeitpunkt feuern, welche Register
>  will man da sichern - AVR hat 32 davon - alle ?

Das kann man so pauschal nicht beantworten und das weißt du auch. Es 
kommt auf den konkreten Anwendungsfall an und wie dein Code aussieht.
Zumal man sich jetzt darüber streiten kann, ob 32 Register für eine 
überschaubare CPU sprechen und darum geht es ja.



>
> Geron schrieb:
>> Erst dann, wenn die CPU nicht mehr überschaubar ist, liegt der Compiler
>> ganz vorne.
>
>  Deine Aussage zeugt nur davon auf welchem Schwierigkeitsgrad bzw.
>  Niveau sich deine Programme befinden.

Nein, meine Aussage ist im Gegensatz zu deiner allgemeingültig.
Oder soll ich jetzt aus deiner Antwort deuten, das du dieser Aussage 
widersprichst?

Der Compiler ist nur so schlau, wie ihn der Mensch programmiert hat und 
ja, Compilerbauer die das Hauptberuflich machen, sind schlau, es ist 
extrem wahrscheinlich dass die schlauer sind als du und der andere, bei 
dem ich auf seine Assemblerfähigkeiten hingewiesen habe, aber selbst bei 
denen kommt es vor, dass sie Optimierungsmöglichkeiten in Assembler 
kennen, die sie im Compiler nur schlecht umsetzen können.
Und schon hast du einen Fall, wo der Compiler nicht gut sein kann.

von Volker S. (vloki)


Bewertung
3 lesenswert
nicht lesenswert
Geron schrieb:
> Zumal man sich jetzt darüber streiten kann,

Bitte streitet dann aber woanders...

von Geron (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
Marc V. schrieb:
> ....

Noch etwas:

Das ganze kannst du dir wie folgende Funktion forstellen:
f=(1/x^2)   wobei für x nur der positive Wertebereich gilt.


Auf der Y-Achse hast du dann die Komplexität der CPU abgebildet
und auf der X-Achse die Anzahl an Leuten, die die mithalten können.

von Max M. (maxmicr)


Bewertung
0 lesenswert
nicht lesenswert
Nach diesem Beitrag: http://www.edaboard.com/thread114417.html

kann man einen Pin Open-Drain schalten, in dem ich die entsprechenden 
Bits im TRIS-Register setze. Wenn ich einen Pin low schalten möchte, 
muss ich das gesamte TRIS-Register neu schreiben. Damit würde ich 
automatisch auch den Zustand des 2. Pins überschreiben, d.h. ich muss 
vorher überprüfen, welchen Zustand der andere Pin hat. Das geht aber 
nicht, da laut Datenblatt das TRIS-register "write-only" ist, wie löst 
man das?

von Geron (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
Max M. schrieb:

>
> Ich weiß nun nicht, inwiefern die 2 Programme vergleichbar sind,
> allerdings belegt das C-Programm 31% des RAMs und 7% des Flashes.

Guck dir einfach den Maschinencode an, den der Compiler aus dem C Code 
backt.
Dann kannst du das auch vergleichen.

von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> Wenn ich einen Pin low schalten möchte,
> muss ich das gesamte TRIS-Register neu schreiben. Damit würde ich
> automatisch auch den Zustand des 2. Pins überschreiben, d.h. ich muss
> vorher überprüfen, welchen Zustand der andere Pin hat. Das geht aber
> nicht, da laut Datenblatt das TRIS-register "write-only" ist, wie löst
> man das?

Wenn man das nicht wissen kann, muss man es sich wohl irgendwo merken.
Wenn sich nur ein Pin änndert, dann sollte man es aber eigentlich 
wissen..
.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
Geron schrieb:
> ja, Compilerbauer die das Hauptberuflich machen, sind schlau, es ist
> extrem wahrscheinlich dass die schlauer sind als du und der andere, bei
> dem ich auf seine Assemblerfähigkeiten hingewiesen habe, aber selbst bei

 Da du dich selbst aus dem Vergleich rausgenommen hast, nehme ich an,
 dass du dich für ungemein schlau hältst.

 Sagen wir es mal so:
 Peter D. (der andere) kann bestimmt besser in Assembler programmieren
 als du.
 Und ich habe mehr von ASM-Programmierung vergessen, als du jemals
 lernen wirst.

 Das hat aber nichts mit schlau oder dumm zu tun - ein Mensch kann ganz
 einfach nicht alles wissen, alles am besten machen und immer als Erster
 auf beste Lösungen kommen.

 Und was ist von der ganzen Sache halte, habe ich schon geschrieben:
Marc V. schrieb:
> Bei 16Byt RAM fängt man gar nicht erst mit C an. Die ganze dazu
>  nötige Gehirnakrobatik, um mit 16Byte überhaupt ein einigermassen
>  sinnvolles Programm zum Laufen zu bringen, lohnt sich doch eh
>  nicht. Das hat man mit ASM viel schneller hingekriegt.
>  Und das es Leute gibt die so etwas kaufen, um damit anzufangen,
>  werde ich niemals begreifen.
>
>  So etwas nimmt man als Sensor/Aktor und dann ist aber auch Schluss.
>  Und dafür war es wahrscheinlich auch gedacht, also ASM von vorn-
>  herein, kein C.
>
>  Ende.

: Bearbeitet durch User
von Clemens L. (c_l)


Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
> Kennst du nen µC, wo man zwei Variablen im RAM direkt miteinander
> vergleichen kann?

MSP430; Beispiel aus dem Handbuch:
1
CMP.B   EDE,TONI   ; MEM(EDE) = MEM(TONI)?
2
JEQ     EQUAL      ; YES, JUMP

Die Selbstbeweihräucherung lautet wie folgt:
> The CPU incorporates features specifically designed for modern
> programming techniques such as calculated branching, table processing,
> and the use of high-level languages such as C. The CPU can address the
> complete address range without paging.
>
> The CPU features include:
> • RISC architecture with 27 instructions and 7 addressing modes.
> • Orthogonal architecture with every instruction usable with every
>   addressing mode.
> • Full register access including program counter, status registers,
>   and stack pointer.
> • Single-cycle register operations.
> • Large 16-bit register file reduces fetches to memory.
> • 16-bit address bus allows direct access and branching throughout
>   entire memory range.
> • 16-bit data bus allows direct manipulation of word-wide arguments.
> • Constant generator provides six most used immediate values and
>   reduces code size.
> • Direct memory-to-memory transfers without intermediate register
>   holding.
> • Word and byte addressing and instruction formats.

Und dann kann man natürlich darüber streiten, was "RISC" eigentlich 
bedeutet ...

von Geron (Gast)


Bewertung
-6 lesenswert
nicht lesenswert
Marc V. schrieb:
> Geron schrieb:
>> ja, Compilerbauer die das Hauptberuflich machen, sind schlau, es ist
>> extrem wahrscheinlich dass die schlauer sind als du und der andere, bei
>> dem ich auf seine Assemblerfähigkeiten hingewiesen habe, aber selbst bei
>
>  Da du dich selbst aus dem Vergleich rausgenommen hast, nehme ich an,
>  dass du dich für ungemein schlau hältst.
>
>  Sagen wir es mal so:
>  Peter D. (der andere) kann bestimmt besser in Assembler programmieren
>  als du.
>  Und ich habe mehr von ASM-Programmierung vergessen, als du jemals
>  lernen wirst.

Du kannst eine Diskussion nicht gewinnen, in dem du mich, der die andere 
Seite vertritt, persönlich angreifst. Das dies ausgesprochen dumm von 
dir ist, erwähne ich hiermit explizit.


>
>  Das hat aber nichts mit schlau oder dumm zu tun - ein Mensch kann ganz
>  einfach nicht alles wissen, alles am besten machen und immer als Erster
>  auf beste Lösungen kommen.

Noch einmal, wir sprachen von überschaubaren CPUs.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
1 lesenswert
nicht lesenswert
Geron schrieb:
> Du kannst eine Diskussion nicht gewinnen, in dem du mich, der die andere
> Seite vertritt, persönlich angreifst. Das dies ausgesprochen dumm von
> dir ist, erwähne ich hiermit explizit.

 Ich habe dich bestimmt nicht persönlich angegriffen, ganz im Gegensatz
 zu dir, sowohl in oben zitiertem Satz als auch vorher:
>> ja, Compilerbauer die das Hauptberuflich machen, sind schlau, es ist
>> extrem wahrscheinlich dass die schlauer sind als du und der andere,
>> bei dem ich auf seine Assemblerfähigkeiten hingewiesen habe,

 Als ich erwähnt habe, dass Peter besser Assembler kann als du und
 dass ich mehr davon vergessen habe etc... - das ist ganz einfach die
 Wahrheit und kein Angriff, ob du es wahrhaben willst oder nicht.
 Und dass du dich aus dem obigen Vergleich mit Compiler rausgenommen
 hast und dich durch obige Behauptung gleich angegriffen fühlst, zeugt
 nur davon, dass dein Ego weitaus grösser als deine Kenntnisse ist und
 diese bei weitem übersteigt.

>>  Das hat aber nichts mit schlau oder dumm zu tun - ein Mensch kann ganz
>>  einfach nicht alles wissen, alles am besten machen und immer als Erster
>>  auf beste Lösungen kommen.
>
> Noch einmal, wir sprachen von überschaubaren CPUs.

 Was hat meine Behauptung damit zu tun, ob eine CPU überschaubar ist
 oder nicht ?

von Carl D. (jcw2)


Bewertung
1 lesenswert
nicht lesenswert
Max M. schrieb:
> Also Assembler ist schon lustig :D
> 8% des Flash vom PIC10F200 sind mit diesem Programm belegt:
>
...
> Edit: Ich hab mal versucht, das ganze in C nachzumachen:
>
>
1
> #include <xc.h>
2
> #define _XTAL_FREQ 4000000
3
> void main(void) {
4
>     TRISGPIO = 0x00;
5
>     while(1){
6
>         GPIO |= (1<<0);
7
>         __delay_ms(1);
8
>         GPIO &=~(1<<0);
9
>     }
10
> }
11
>
>
> Ich weiß nun nicht, inwiefern die 2 Programme vergleichbar sind,
> allerdings belegt das C-Programm 31% des RAMs und 7% des Flashes.

Also weniger Flash, keine Enge im RAM und ich als *nicht-PICler kann's 
sofort verstehen. Was spricht gegen den "Universal-Assembler.

*lesen kann ich rudimentär, aber es muß nicht sein.

von Geron (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
Marc V. schrieb:
> Geron schrieb:
>> Du kannst eine Diskussion nicht gewinnen, in dem du mich, der die andere
>> Seite vertritt, persönlich angreifst. Das dies ausgesprochen dumm von
>> dir ist, erwähne ich hiermit explizit.
>
>  Ich habe dich bestimmt nicht persönlich angegriffen, ganz im Gegensatz
>  zu dir, sowohl in oben zitiertem Satz als auch vorher:
>>> ja, Compilerbauer die das Hauptberuflich machen, sind schlau, es ist
>>> extrem wahrscheinlich dass die schlauer sind als du und der andere,
>>> bei dem ich auf seine Assemblerfähigkeiten hingewiesen habe,

Der Kontext ist hier Assembler. Es macht schon einen Unterschied ob man 
eine Generelle Aussage trifft:
Compilerbauer können besser Assembler als der typische 08/15 
Programmierer. Und das dem so ist, ergibt sich aus dem Kontext, weil die 
schließlich die Compiler entwickeln und daher die Maschine und Assembler 
in und auswenig kennen und kennen müssen und man dafür auch nur die 
besten auf dem Markt nimmt. Der einfache Programmierer kriegt den Job 
erst gar nicht.
Daraus ergibt sich übrigens auch, wärst du darin gut, dann wärst du 
beruflich selbst Compilerbauer.
Das Angebot ist aber klein und die Stellen sind begehrt, das ist so wie 
Jetpilot werden zu wollen und deswegen nimmt man da auch nur die besten.


Im Gegensatz zu einer Aussage wie:
"Peter und ich können besser Assembler als du."
Zumal du hier nicht einmal weißt, wer ich bin.

Also, der einzige der hier beleidigt hat, warst du.



>  Als ich erwähnt habe, dass Peter besser Assembler kann als du und
>  dass ich mehr davon vergessen habe etc... - das ist ganz einfach die
>  Wahrheit und kein Angriff, ob du es wahrhaben willst oder nicht.

Das ist keine Wahrheit, weil dir dafür die Informationen fehlen.
Du müsstest dazu nämlich mich kennen. Es ist somit sogar eine Lüge, weil 
du mich nicht kennst.



>  Und dass du dich aus dem obigen Vergleich mit Compiler rausgenommen
>  hast und dich durch obige Behauptung gleich angegriffen fühlst, zeugt
>  nur davon, dass dein Ego weitaus grösser als deine Kenntnisse ist und
>  diese bei weitem übersteigt.

Ich habe mich rausgenommen, weil ich kein Compilerbauer bin und es für 
meine generelle Aussage auch nicht wichtig wäre.



>
>>>  Das hat aber nichts mit schlau oder dumm zu tun - ein Mensch kann ganz
>>>  einfach nicht alles wissen, alles am besten machen und immer als Erster
>>>  auf beste Lösungen kommen.
>>
>> Noch einmal, wir sprachen von überschaubaren CPUs.
>
>  Was hat meine Behauptung damit zu tun, ob eine CPU überschaubar ist
>  oder nicht ?

Eine überschaubare CPU kann man kennen, man kann sie auch gut 
programmieren, eben weil sie überschaubar ist.

von Volker S. (vloki)


Bewertung
2 lesenswert
nicht lesenswert
Geron und Mark, setzt doch bitte eure Diskussion irgendwo anders fort.

von Dampf T. (ouuneii)


Bewertung
0 lesenswert
nicht lesenswert
Ich hatte mal den AVR LS1200 oder so, der hatte glaub kein gar RAM und 
nur 1200 byte code. Und trotzdem konnte ich einen FSK generator 
reinschreiben. Abhaengig von einem Pin konnte der auf einem anderen Pin 
die eine oder andere Frequenz im 50kHz (51kHz & 55kHz) Bereich 
rauslassen.

: Bearbeitet durch User
von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> Nach diesem Beitrag: http://www.edaboard.com/thread114417.html
>
> kann man einen Pin Open-Drain schalten,

Ich hoffe Du bist Dir bewusst, dass es nur ein "pseudo" Open-Drain ist. 
Ich habe es nicht extra geschrieben, aber er funktioniert nur, wenn die 
Spannung am µC >= die vom I2C-Device ist.

> in dem ich die entsprechenden
> Bits im TRIS-Register setze. Wenn ich einen Pin low schalten möchte,
> muss ich das gesamte TRIS-Register neu schreiben. Damit würde ich
> automatisch auch den Zustand des 2. Pins überschreiben, d.h. ich muss
> vorher überprüfen, welchen Zustand der andere Pin hat. Das geht aber
> nicht, da laut Datenblatt das TRIS-register "write-only" ist, wie löst
> man das?

In der Regel nimmt man ein Shadow-Register, das man jeweils bearbeitet 
und nachher ins TRIS schreibt. Aber auch das wiederspricht natürlich der 
sportlichen Herausforderung nach möglichst wenig Speicher.

So wirklich kleinste µC verwendet man privat nur wegen der Sportlichen 
Herausforderung. Ansonsten nimmt man zumindest die größte Variante einer 
Bauform.

von michael_ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dampf T. schrieb:
> Ich hatte mal den AVR LS1200 oder so, der hatte glaub kein gar RAM und
> nur 1200 byte code.

Der AT90S1200 ist ja der Uropa der AVR.
Etwa 30 Register hat der nur.
Für viele einfache Sachen reicht der völlig.
Auf dem STK-500 ist der u.a. für die ser. Kommunikation zuständig.

von Georg (Gast)


Bewertung
1 lesenswert
nicht lesenswert
michael_ schrieb:
> Der AT90S1200 ist ja der Uropa der AVR.
> Etwa 30 Register hat der nur.

Der Z80 hat garkein RAM und viel weniger Register, trotzdem gabe es 
viele Schaltungen ohne externen RAM-Baustein. Sowas erfordert halt 
Nachdenken beim Programmierer, was seitdem aus der Mode gekommen ist.

Georg

von Schreiber (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Achim S. schrieb:
> So wirklich kleinste µC verwendet man privat nur wegen der Sportlichen
> Herausforderung. Ansonsten nimmt man zumindest die größte Variante einer
> Bauform.

Nicht übertreiben, man kann die Anforderungen durchaus realistisch 
abschätzen und die Auswahl entsprechend treffen. Den letzten Cent muss 
man aber nicht sparen wollen.

Bei der Bauform würde ich aber auch nicht sparen, ein paar pins als 
Reserve schaden auch nicht. Etwa wenn man merkt, dass der interne 
Oszillator doch nicht genau genug ist und man, entgegen der Planung, 
doch einen Quarz braucht. Oder man hat noch irgendwas andres vergessen.

Auch bei Serienfertigung: Neuere Firmwareversionen sind im zweifelsfall 
immer größer wie die vorhergehende. Wenn Kundenseitige Updates 
vorgesehen sind: Ausreichend Speicher einplanen.

von chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Diese sind für bestimmte Anwendungen ganz nett, nicht so toll ist ist 
das heikle icsp speziell wenn man die Sensoren im laufenden Betrieb 
calibrieren muss.
Hitech C funktioniert recht gut darauf, wurde von Microchip aber 
totgekauft und gibt es nicht mehr downzuladen mit eingeschalteter 
Optimierung soweit ich weiss.
Eventuell in Archiven.
Ohne baseline ASM libs und macros such dir einen anderen chip. 256 flash 
und 16 byte RAM, ein counter +wdt. Eigentlich müsste es ein die shrinked 
12f509 sein mit ADC sowie top row flash emulated eeprom.

von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Hitech C funktioniert recht gut darauf, wurde von Microchip aber
> totgekauft und gibt es nicht mehr downzuladen...

Heißt jetzt xc8.

von chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
X8c basiert auf hitech 18c Compiler, war nicht sonderlich gut. Ich bezog 
mich auf den 12c/16c/17c (lite) Compiler wo die volle Optimierung 
eingeschaltet war sowie peephole optimizer und auf 2k Rom/Flash begrenzt 
war, dafür aber gratis, auch für kommerzielle Projekte.

von Max M. (maxmicr)


Bewertung
0 lesenswert
nicht lesenswert
Ich hab mehrere Funktionen, in denen ich den gleichen Labelnamen 
verwende, nun bekomme ich beim kompilieren folgende Fehlermeldung:
1
Address label duplicated or different in second pass

Auch local:
1
;SCL is GP0
2
;SDA is GP1
3
SCLHigh:
4
    local sdaHigh,sdaLow,updateTris
5
    movfw   SDA
6
    movwf   tmp
7
    decf    tmp
8
    btfsc   STATUS,2  ;check if Z-Flag is set
9
    goto    sdaHigh  ;if so, SDA is currently High
10
    goto    sdaLow  ;otherwise, SDA is low
11
sdaHigh
12
    movlw   03h    ;SCL and SDA are high
13
    goto    updateTris
14
sdaLow
15
    movlw   01h    ;only SCL is high
16
    goto    updateTris
17
updateTris
18
    tris    6    ;update TRIS register
19
    movlw   01h    
20
    movwf   SCL    ;SCL is now high
21
    retlw   0

schafft da keine Abhilfe, der Fehler ändert sich nur von:
1
Address label duplicated or different in second pass (updateTris)

in
1
Address label duplicated or different in second pass (_0updateTris)

Hat jemand eine Idee, wie man das löst (abgesehen von jedes mal neue 
Labels zu verwenden)? Kann man Labels irgendwie explizit im Kontext der 
eigenen Funktion definieren?

von Thomas E. (picalic)


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> Kann man Labels irgendwie explizit im Kontext der
> eigenen Funktion definieren?

Soweit ich weiß, kennt MPASM keine lokalen Labels in "Funktionen" - er 
kennt nicht mal Funktionen in dem Sinn, wie z.B. C.
Lokale Labels gibt es nur modulweise, bei relocatable Code. Dann 
müsstest Du für jede Deiner Funktionen in ein separates Sourcefile 
schreiben. Das dürfte sich bei Deinen paar Programmzeilen aber nicht 
lohnen - denk Dir lieber unterschiedliche Labelnamen aus.

von Thomas E. (picalic)


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> ;SCL is GP0
> ;SDA is GP1
> SCLHigh:
-- snip ---
>     retlw   0

Ich würde sagen, der obige Code ließe sich auch einfach so schreiben:
1
#define SCL 0  ;SCL is GP0
2
#define SDA 1  ;SDA is GP1
3
4
SCLHigh
5
  movf  GPIO,W    ;read current level (SDA) -> W
6
  iorlw  1<<SCL    ;set SCL-bit
7
  andlw  1<<SCL | 1<<SDA ;keep other bits 0 (GPIO pins = output)
8
  tris  GPIO    ;-> emulate open drain output
9
  retlw  0

Und wegen evtl. Clock Stretching würde ich die Routine erst verlassen, 
wenn SCL auch tatsächlich auf high gegangen ist:
1
  ....
2
  tris  GPIO    ;-> emulate open drain output
3
  btfss GPIO,SCL
4
  goto $-1
5
  retlw  0

: Bearbeitet durch User
von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> Hat jemand eine Idee, wie man das löst

Selbstverständlich: Deklariere NIEMALS ein Label oder sonstigen Namen 
zweimal, sondern nimm jedesmal einen anderen Namen. Das ist doch 
eigentlich einleuchtend - oder?

In deinem Beispiel sehe ich auch keine "Markierungen", wo ein lokaler 
Block beginnt und wo er endet. Folglich dürfte zu vermuten sein, daß 
"local" dann eben für die gesamte Quelle gilt, womit die 
Assembler-Ausschrift erklärlich ist - auch wenn ich deinen Assembler 
nicht näher kenne. Ich benutze nämlich seit langem meinen eigenen.

Nochwas: dein Beispiel sieht mit sehr goto-lastig aus, überdenke nochmal 
deinen Ansatz: Ich würde für Tris ein halbes RAM-Byte opfern, das sieht 
mir günstiger aus.

W.S.

von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Hitech C funktioniert recht gut darauf, wurde von Microchip aber
> totgekauft und gibt es nicht mehr downzuladen mit eingeschalteter
> Optimierung soweit ich weiss.
> Eventuell in Archiven.
Der Link auf der Hi-Tech Seite hat gestern nicht funktioniert.
Heute geht es anscheinend (wieder).
http://www.htsoft.com/downloads/archive.php
ftp://Compilers-RO:C0mP!0511@ftp.microchip.com/

von Max M. (maxmicr)


Angehängte Dateien:

Bewertung
-1 lesenswert
nicht lesenswert
Ist es möglich, den grau markierten Bereich (das ist anscheinend der 
RAM) auch als Register zu benutzen (abgesehen davon, wenn man den 
relocateable Mode benutzt)?

Wenn ich versuche, in meinem Programm da was reinzuschreiben, bekomme 
ich die Fehlermeldung:
1
Invalid RAM location specified.

von Volker S. (vloki)


Bewertung
2 lesenswert
nicht lesenswert
Schon mal in's Datenblatt geschaut?
Da steht "unimplemented". Was das wohl bedeuten?

von Max M. (maxmicr)


Bewertung
0 lesenswert
nicht lesenswert
Danke, lesen sollte man können :(

Trotzdem versteh ich nicht, wo denn nun der RAM ist (also die 16Byte)?

von Volker S. (vloki)


Bewertung
1 lesenswert
nicht lesenswert
Figure 4-3 -> General Purpose Registers 10h..1Fh

von Max M. (maxmicr)


Bewertung
0 lesenswert
nicht lesenswert
Danke!

Ich versuche gerade, eine Funktion zu schreiben, die ein Byte als 
I2C-Datenpaket sendet. Aktuell scheitert die Funktion daran, dass ich 
nicht weiß, wie ich testen kann, ob eine Variable negativ ist (bzw. 255 
bzw. -1 ist). Bis zum letzten Durchlauf (wenn nicht mehr nach rechts 
geschoben wird) funktioniert alles, ich ziehe von meiner Zählervariable 
(tmp) "1" ab, das Register wird 255 aber an den Flags ändert sich 
nichts. Wie erkenne ich nun, dass ich im negativen Bereich bin?
1
;sends Byte which is stored in i2cDat Register
2
SendByte:
3
    movlw   07h
4
    movwf   tmp
5
step  movfw   tmp
6
  movwf   tmp2
7
  movfw  i2cDat
8
  movwf  tmp3
9
  movfw  tmp
10
  incf  tmp      ;do some stuff to create zero bit if necessary
11
  decf  tmp
12
sru  btfsc  STATUS,2    ;check if tmp is already zero (last step)
13
  goto  extrBit      ;if so, don't shift right anymore
14
  bcf  STATUS,0    ;clear carry bit to shift unsigned
15
  rrf  tmp3,1      ;shifted values are now in tmp3
16
  decf  tmp2
17
  btfss  STATUS,2    ;chechk if zero
18
  goto  sru      ;shift if not zero
19
extrBit
20
  movfw   tmp3      ;move shifted value to work register
21
  andlw   01h        ;extract first bit
22
  movwf   tmp2      ;contains now single bit
23
  decf    tmp2      ;decrement
24
  btfsc   STATUS,2      ;check if zero (was 1 before then)
25
  goto    setSDA      ;if, set SDA high
26
  goto    resetSDA      ;otherwise, set SDA low
27
setSDA
28
  call  SDAHigh
29
  goto  clk
30
resetSDA
31
  call  SDALow
32
  goto  clk
33
clk
34
    call    SCLHigh      ;create a clock cycle
35
    
36
    movlw   015h
37
    movwf   tmp2
38
    call    delay
39
    
40
    call    SCLLow
41
    bcf      STATUS,0      ;clear carry from previous operations
42
    decf    tmp        
43
    btfss   STATUS,0      ;check if not carry [doesn't work]
44
    goto    step      ;if not, return to top
45
    retlw   0

Hat da jemand eine Idee?

: Bearbeitet durch User
von Thomas E. (picalic)


Bewertung
1 lesenswert
nicht lesenswert
Max M. schrieb:
> Aktuell scheitert die Funktion daran, dass ich
> nicht weiß, wie ich testen kann, ob eine Variable negativ ist (bzw. 255
> bzw. -1 ist).

Eine negative Zahl erkennt man am gesetzten MSB (Bit 7). Testen kann man 
das dann leicht z.B. mit
1
  ...
2
  btfsc tmp,7
3
  goto tmp_is_negative
4
  ...
oder
1
  ...
2
  btfss tmp,7
3
  goto tmp_is_positive
4
  ...

Schleifenzähler macht man aber meistens besser so:
1
  movlw 8               ;initialize loop counter
2
  movwf counter
3
loop
4
  <(body of loop)>      ;done 8 times...
5
  decfsz counter,F
6
  goto loop
7
  ...

: Bearbeitet durch User
von Thomas E. (picalic)


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> extrBit
>   movfw   tmp3      ;move shifted value to work register
>   andlw   01h        ;extract first bit
>   movwf   tmp2      ;contains now single bit
>   decf    tmp2      ;decrement
>   btfsc   STATUS,2      ;check if zero (was 1 before then)
>   goto    setSDA      ;if, set SDA high
>   goto    resetSDA      ;otherwise, set SDA low
> setSDA
>   call  SDAHigh
>   goto  clk
> resetSDA
>   call  SDALow
>   goto  clk
> clk

warum so kompliziert? Diese goto-Orgien sind ja grausam! Ebenfalls 
grausam finde ich, die Statusbits mit Nummern anzusprechen, statt z.B. 
mit "Z" oder "C", und als Ziel der Operation "0" oder "1" zu schreiben, 
statt "W" oder "F".

Ich schlage vor, diesen Programmteil durch
1
extrBit
2
  btfsc tmp3,0
3
  call SDAHigh
4
  btfss tmp3,0
5
  call SDALow
6
clk
zu ersetzen.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Obacht: I2C auf einem PIC ohne LAT Register ist etwas tricky. Siehe 
Datasheet 5.4.1 BIDIRECTIONAL I/O PORTS.

von chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Normalerweise sieht der code so ähnlich aus:

      ; Send the byte currently in W, most significant bit first
I2CSendByte
        MOVWF   i2cdata
        MOVLW   .8
I2CSendByteLoop
        MOVWF   i2ccnt
        CALL    DataHigh
        RLF     i2cdata,F
        BTFSS   STATUS,C
        CALL    DataLow
        CALL    ClockToggle
        DECFSZ  i2ccnt,W
        GOTO    I2CSendByteLoop
        RETLW 0

von chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
1
      ; Send the byte currently in W, most significant bit first
2
I2CSendByte
3
        MOVWF   i2cdata
4
        MOVLW   .8
5
I2CSendByteLoop
6
        MOVWF   i2ccnt
7
        CALL    DataHigh
8
        RLF     i2cdata,F
9
        BTFSS   STATUS,C
10
        CALL    DataLow
11
        CALL    ClockToggle
12
        DECFSZ  i2ccnt,W
13
        GOTO    I2CSendByteLoop
14
        RETLW 0

von pic (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wir verwenden pic 12f509 für die Steuerung des Test im Ofen sowie 
diversen Langzeittests.
derzeit werden max 16 bytes verwendet.
Was angeschlossen ist:

1 io IRIG J-14 signal + error flag
1 inp dmm rs232, reset line
2 in/out rs232 MUX, kann zu mehreren Geräten gemuxt werden. Dmm Netzteil 
LCR ...
1 out scl
1 io OC sda oder rs232

Relay oder IC MUX wie auch Temperatursensoren werden über i2c gesteuert.

von Max M. (maxmicr)


Bewertung
0 lesenswert
nicht lesenswert
Sieht so aus, als wäre I2C doch nicht ganz so einfach, durch den 
begrenzten Hardware-Stack kann ich das Programm nicht so strukturieren 
wie ich gerne möchte. Wenn ich jeden Funktionsaufruf von "SendCommand" 
durch den in der Funktion enthaltenen Code ersetze, lande ich schnell 
bei 100% Flashauslastung.
Hat jemand einen Tipp, wie man die Initialisierung des SSD1306 in den 
Flash reinbekommt?
Ich bin bereits erstaunt, dass das bis jetzt überhaupt reinpasst und das 
sogar noch 24% vom Flash übrig sind! Wäre Platz für eine 
Rücksprungadresse mehr würde es, denke ich, funktionieren. Mein 
bisheriger Code (Achtung: Lang):
1
#include <p10f200.inc>
2
3
trisShadow  EQU  11h
4
tmp      EQU 12h
5
i2cDat      EQU  13h
6
tmp2      EQU  14h
7
tmp3      EQU  15h
8
i2cCmd      EQU  16h
9
      
10
    org 0x00
11
    movlw   0Fh
12
    movwf   trisShadow
13
    
14
main  
15
  call  I2CStart
16
  movlw  0aeh
17
  movwf  i2cCmd
18
  call  SendCommand
19
  call  I2CStop
20
  
21
  call  I2CStart
22
  movlw  0d5h
23
  movwf  i2cCmd
24
  call  SendCommand
25
  call  I2CStop
26
  
27
  call  I2CStart
28
  movlw  080h
29
  movwf  i2cCmd
30
  call  SendCommand
31
  call  I2CStop
32
  
33
  call  I2CStart
34
  movlw  0A8h
35
  movwf  i2cCmd
36
  call  SendCommand
37
  call  I2CStop
38
  
39
  call  I2CStart
40
  movlw  03F
41
  movwf  i2cCmd
42
  call  SendCommand
43
  call  I2CStop
44
  
45
  call  I2CStart
46
  movlw  0D3h
47
  movwf  i2cCmd
48
  call  SendCommand
49
  call  I2CStop
50
  
51
  call  I2CStart
52
  clrf  i2cCmd
53
  call  SendCommand
54
  call  I2CStop
55
  
56
  call  I2CStart
57
  movlw  04h
58
  movwf  i2cCmd
59
  call  SendCommand
60
  call  I2CStop
61
  
62
  call  I2CStart
63
  movlw  08dh
64
  movwf  i2cCmd
65
  call  SendCommand
66
  call  I2CStop
67
  
68
  call  I2CStart
69
  movlw  014h
70
  movwf  i2cCmd
71
  call  SendCommand
72
  call  I2CStop
73
  
74
  call  I2CStart
75
  movlw  020h
76
  movwf  i2cCmd
77
  call  SendCommand
78
  call  I2CStop
79
  
80
  call  I2CStart
81
  movlw  001h
82
  movwf  i2cCmd
83
  call  SendCommand
84
  call  I2CStop
85
  
86
  call  I2CStart
87
  movlw  0a1h
88
  movwf  i2cCmd
89
  call  SendCommand
90
  call  I2CStop
91
  
92
  call  I2CStart
93
  movlw  0c8h
94
  movwf  i2cCmd
95
  call  SendCommand
96
  call  I2CStop
97
  
98
  call  I2CStart
99
  movlw  0dah
100
  movwf  i2cCmd
101
  call  SendCommand
102
  call  I2CStop
103
  
104
  call  I2CStart
105
  movlw  12h
106
  movwf  i2cCmd
107
  call  SendCommand
108
  call  I2CStop
109
  
110
  call  I2CStart
111
  movlw  081h
112
  movwf  i2cCmd
113
  call  SendCommand
114
  call  I2CStop
115
  
116
  call  I2CStart
117
  movlw  0cfh
118
  movwf  i2cCmd
119
  call  SendCommand
120
  call  I2CStop
121
  
122
  call  I2CStart
123
  movlw  0d9h
124
  movwf  i2cCmd
125
  call  SendCommand
126
  call  I2CStop
127
  
128
  call  I2CStart
129
  movlw  0f1h
130
  movwf  i2cCmd
131
  call  SendCommand
132
  call  I2CStop
133
  
134
  call  I2CStart
135
  movlw  0dbh
136
  movwf  i2cCmd
137
  call  SendCommand
138
  call  I2CStop
139
  
140
  call  I2CStart
141
  movlw  40h
142
  movwf  i2cCmd
143
  call  SendCommand
144
  call  I2CStop
145
  
146
  call  I2CStart
147
  movlw  0a4h
148
  movwf  i2cCmd
149
  call  SendCommand
150
  call  I2CStop
151
  
152
  call  I2CStart
153
  movlw  0a6h
154
  movwf  i2cCmd
155
  call  SendCommand
156
  call  I2CStop
157
  
158
  call  I2CStart
159
  movlw  0afh
160
  movwf  i2cCmd
161
  call  SendCommand
162
  call  I2CStop
163
  
164
  goto  main
165
    
166
;delay funktion
167
delay:
168
    decfsz  tmp2
169
    goto    delay
170
    retlw   0
171
172
;SDA = GP0
173
;SCL = GP1
174
SCLHigh:
175
    movlw   02h
176
    iorwf   trisShadow,1
177
    movfw   trisShadow
178
    tris    6
179
    retlw   0
180
    
181
;SDA = GP0
182
;SCL = GP1
183
SCLLow:
184
    movlw   0dh
185
    andwf   trisShadow,1
186
    movfw   trisShadow
187
    tris    6
188
    retlw   0
189
    
190
;SDA = GP0
191
;SCL = GP1
192
SDAHigh:
193
    movlw   01h
194
    iorwf   trisShadow,1
195
    movfw   trisShadow
196
    tris    6
197
    retlw   0
198
199
;SDA = GP0
200
;SCL = GP1
201
SDALow:
202
    movlw   0eh
203
    andwf   trisShadow,1
204
    movfw   trisShadow
205
    tris    6
206
    retlw   0
207
208
;generates a I2C Start Condition
209
I2CStart:
210
    call    SDALow
211
    call    SCLLow
212
    retlw   0
213
    
214
;generates a I2C Stop Condition
215
I2CStop:
216
    call    SCLHigh
217
    call    SDAHigh
218
    retlw   0
219
    
220
;sends Byte which is stored in i2cDat Register
221
SendByte:
222
    movlw   07h
223
    movwf   tmp
224
step  movfw   tmp
225
  movwf   tmp2
226
  movfw  i2cDat
227
  movwf  tmp3
228
  incf  tmp      ;do some stuff to create zero bit if necessary
229
  decf  tmp
230
sru  btfsc  STATUS,2    ;check if tmp is already zero (last step)
231
  goto  extrBit      ;if so, don't shift right anymore
232
  bcf  STATUS,0    ;clear carry bit to shift unsigned
233
  rrf  tmp3,1      ;shifted values are now in tmp3
234
  decf  tmp2
235
  goto  sru      ;shift if not zero
236
extrBit
237
  btfsc  tmp3,0
238
  call  SDAHigh      ;if is '1', set SDA high
239
  btfss  tmp3,0
240
  call  SDALow      ;otherwise, set SDA low
241
  
242
    call    SCLHigh      ;create a clock cycle
243
    
244
    movlw   015h
245
    movwf   tmp2
246
    call    delay
247
    
248
    call    SCLLow
249
    decf    tmp        
250
    btfss   tmp,7      ;check if not negative
251
    goto    step      ;if so, return to top
252
    retlw   0
253
254
;send a command to SSD1306 Display
255
;command is read from i2cCmd register
256
SendCommand:
257
    movlw   078h      
258
    movwf   i2cDat
259
    call    SendByte      ;SSD1306 I2C Address
260
    clrf    i2cDat      
261
    call    SendByte      ;send 0x00 for a command
262
    movfw   i2cCmd
263
    movwf   i2cDat
264
    call    SendByte      ;send command
265
    retlw   0
266
267
    END

von Peter D. (peda)


Bewertung
2 lesenswert
nicht lesenswert
Max M. schrieb:
> Wenn ich jeden Funktionsaufruf von "SendCommand"
> durch den in der Funktion enthaltenen Code ersetze, lande ich schnell
> bei 100% Flashauslastung.

Mach ne Schleife draus, die die einzelnen Bytes aus ner Tabelle (retlw) 
liest.

von Volker S. (vloki)


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> Hat jemand einen Tipp,

10f32x nehmen? (8-Level Stack, LAT Register, Interrupt...)

: Bearbeitet durch User
von Max M. (maxmicr)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
>
> Mach ne Schleife draus, die die einzelnen Bytes aus ner Tabelle (retlw)
> liest.

Danke für deine Antwort, leider verstehe ich nicht ganz, was du meinst. 
Ich hab nicht genügend RAM um die Bytes der Initialisierung (24) zu 
speichern.

Volker S. schrieb:
> 10f32x nehmen? (8-Level Stack, LAT Register, Interrupt...)

Das wäre doch zu einfach :)

: Bearbeitet durch User
von neuer PIC Freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Das wäre doch zu einfach :)

Und immer noch nicht richtig.

Zwischen setSDA und setSCL ist kein delay. -> I2C-Spezifikation lesen. 
Besonders von dem Target.

decf + btfss + goto -> siehe decfsz

Diese überoptimierte Programmierung nur wegen 20ct Einkaufspreises 
bringt doch nichts. Lieber den 10F322 nehmen und mit C starten.

von Thomas E. (picalic)


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> Wenn ich jeden Funktionsaufruf von "SendCommand"
> durch den in der Funktion enthaltenen Code ersetze,

Ich halte es auch für keine gute Idee, beim Abflachen der 
Call-Hierarchie von oben anzufangen, also da, wo dein Unterprogramm am 
häufigsten aufgerufen wird. Dadurch multipliziert sich die Codegröße 
natürlich entsprechend. Machst Du die Hierarchie im Unterprogramm 
flacher, wird der Code vom Unterprogramm aber nur einmal länger.

Das mit der Schleife bietet sich natürlich an und macht den Code 
kompakter und übersichtlicher. Du musst die Bytes für die 
Initialisierung nicht im RAM speichern - dort liegt nur der 
Schleifenzähler. Die Daten stehen in einer Tabelle im Programmspeicher, 
etwa so:
1
ReadTable
2
  addwf  PCL,F
3
  retlw  DATA0
4
  retlw  DATA1
5
  retlw  DATA2
6
  retlw  DATA3
7
  retlw  DATA4
8
  retlw  DATA5

Um einen Wert aus der Tabelle zu lesen, wird ein "call ReadTable" mit 
der Indexnummer der Daten in W ausgeführt. Wichtig wäre bei dieser Art 
von Tabelle, daß die Daten nicht über eine 256 Words Codegrenze gehen 
(wg. Übertrag von PCL-PCH), aber beim 10F200 besteht da naturgemäß keine 
Gefahr.

: Bearbeitet durch User
von pic (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Du benützt 3 calllevel wobei nur 2 verfügbar sind. SCL wird 
normalerweise als reiner output angesteuert, in so einem Falle, das 
vereinfacht vieles.
Also einfach bsf i2c_scl anstelle von call scl-high.
#define i2c_scl i2c_scl_port,i2c_scl_bit
Für SDA
 Movlw tris_val
 Btfsc tmp3,0
 Xorlw i2c_sda_bit
 Tris  i2c_sda_port

Delay 66 US

 Movlw 0x16
 Movwf tmp2
 Decfsz tmp2
 Goto $-1

von Max M. (maxmicr)


Bewertung
0 lesenswert
nicht lesenswert
Danke für eure Antworten, da ist viel Input dabei den ich so erstmal 
nicht verstehe.

neuer PIC Freund schrieb im Beitrag #4845291:
> Zwischen setSDA und setSCL ist kein delay. -> I2C-Spezifikation lesen.
> Besonders von dem Target.

Meinst du in der SendByte Funktion? So:
1
extrBit
2
  btfsc  tmp3,0
3
  call  SDAHigh      ;if is '1', set SDA high
4
  btfss  tmp3,0
5
  call  SDALow      ;otherwise, set SDA low
6
  
7
    ;hier delay?
8
    call    SCLHigh      ;create a clock cycle
9
    
10
    movlw   015h
11
    movwf   tmp2
12
    call    delay
13
    
14
    call    SCLLow
15
    decf    tmp        
16
    btfss   tmp,7      ;check if not negative
17
    goto    step      ;if so, return to top
18
    retlw   0

neuer PIC Freund schrieb im Beitrag #4845291:
> decf + btfss + goto -> siehe decfsz

Ist das auch in der SendByte - Funktion? Decfsz bedeutet, dass der 
nächste Befehl übersprungen wird, wenn im Statusregister das Zero-Bit 
gesetzt ist, ansonsten wird dekrementiert? Es erscheint mir sinnvoller, 
wenn es die negierte Version davon gäbe, es wird also der nächste Befehl 
übersprungen, wenn es nicht Zero ist. Ansonsten bringt mir das doch 
nicht viel? Ich verstehe nicht, wie ich das hier sinnvoll implementieren 
kann, vielleicht kannst du mir einen Tipp geben?

Thomas E. schrieb:
> Die Daten stehen in einer Tabelle im Programmspeicher,
> etwa so:

Danke, ich wusste nicht, dass es so etwas gibt. Ich verstehe nicht, was:
1
addwf PCL,F

macht. Laut der Doku addiert addwf den Inhalt des W-Registers mit 
einem beliebigen anderen Register. Warum genau aus Register 15 und was 
muss da drinn stehen? 0F liegt zudem noch in einem nicht 
implementierten Bereich des PIC10F200.

pic schrieb:
> SCL wird
> normalerweise als reiner output angesteuert, in so einem Falle, das
> vereinfacht vieles.

Das ist doch nicht mehr I2C konform, dachte ich? Ist nicht jeder Pin 
Open-Drain und eben nicht push-pull?

pic schrieb:
> Also einfach

Das was danach steht, verstehe ich nicht mehr.

: Bearbeitet durch User
von Thomas E. (picalic)


Bewertung
1 lesenswert
nicht lesenswert
Max M. schrieb:
> Decfsz bedeutet, dass der
> nächste Befehl übersprungen wird, wenn im Statusregister das Zero-Bit
> gesetzt ist, ansonsten wird dekrementiert?

Nein - ganz anders! Bitte guck Dir nochmal die Beschreibung des Befehls 
im Datenblatt an. Das Z-Flag wird durch diesen Befehl gar nicht 
beeinflusst, und decrementiert wird immer, unabhängig vom Z-Flag.
1
loop
2
  decfsz temp,F
3
  goto loop
decrementiert also temp solange in der Schleife, bis temp=0 erreicht 
wird.

Max M. schrieb:
> Ich verstehe nicht, was:
> addwf PCL,F
>
> macht. Laut der Doku addiert addwf den Inhalt des W-Registers mit
> einem beliebigen anderen Register.

Eben - es addiert W auf den Programmzähler (bzw. auf die unteren 8 Bits 
davon), das Ergebnis ist ein berechneter Sprung vorwärts um W 
Programmspeicherstellen.

> Warum genau aus Register 15 und was
> muss da drinn stehen? 0F liegt zudem noch in einem nicht
> implementierten Bereich des PIC10F200.

Da ist nirgendwo ein "Register 15" im Spiel! Falls Du das ",F" so 
interpretierst: Bitte beschäftige Dich noch etwas mit den Grundlagen zu 
Deinem Controller! Hinter dem Komma steht das Ziel der Operation, das 
entweder "W" für das W-Register sein kann, oder "F" für das angegebene 
Register im Register-"F"ile. In diesem Fall soll also das Ergebnis der 
Addition nicht im W-Register, sondern im PCL landen, deshalb ",F"
Du kannst auch ",0" statt ",W" schreiben und ",1" statt ",F", 
offensichtlich im Gegensatz zu Dir, der Du ja auch lieber die 
Status-Flags mit Nummern, statt mit Namen bezeichnest, finde ich 
symbolische Bezeichnungen aber besser lesbar, als solch nichtssagende 
Nummern.

: Bearbeitet durch User
von Dieter W. (dds5)


Bewertung
1 lesenswert
nicht lesenswert
Max M. schrieb:
> Ich verstehe nicht, was:
> addwf PCL,F
>
> macht. Laut der Doku addiert addwf den Inhalt des W-Registers mit
> einem beliebigen anderen Register. Warum genau aus Register 15 und was
> muss da drinn stehen? 0F liegt zudem noch in einem nicht
> implementierten Bereich des PIC10F200.

Hier wird der Wert in W zum Wert im Register PCL addiert. Nach dem Komma 
steht das Ziel an dem das Ergebnis gespeichert wird, das kann W für WREG 
oder F für file (also hier PCL) sein.
PCL, also Program Counter low Byte zeigt auf diese Weise auf einen 
Tabelleneintrag, von dem aus mit retlw ein Wert im WREG zurückgegen 
wird.

Funktioniert allerdings nur wenn die Tabelle keine Page-Grenze 
überschreitet sonst kommt Blödsinn raus.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> pic schrieb:
>> SCL wird
>> normalerweise als reiner output angesteuert, in so einem Falle, das
>> vereinfacht vieles.
>
> Das ist doch nicht mehr I2C konform, dachte ich? Ist nicht jeder Pin
> Open-Drain und eben nicht push-pull?

In der Tat wäre das nicht konform. Deshalb macht man das tunlichst 
nicht. Es würde dann nämlich nur noch mit solchen Slaves funktionierten 
die garantiert keinen Gebrauch von Clock-Stretching machen, da fallen 
dann schon mal so gut wie alle Slaves weg die I²C auf einem µC 
implementieren, denn die ziehen üblicherweise nach jedem Byte den Takt 
solange auf Low bis die Interruptroutine kommt und sagt "is OK, habs 
gelesen, kannst ACK geben und den Takt wieder loslassen".

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Es gab mal eine Zeit, da quetschten sich ein Dutzend Leute in eine 
Telefonzelle, um sich und der Welt etwas zu beweisen. Telefonieren stand 
dabei nicht im Vordergrund, weshalb kein praktischer Nutzen bestand.

Heute gibt es kaum noch geschlossene Telefonzellen, also weicht man 
offenbar ersatzweise auf Zwerg-Mikrocontroller aus und versucht, damit 
Dinge zu erledigten, für die sie weder gedacht noch auch nur annähernd 
geeignet sind. Und um dem die richtige Würze zu geben, verwendet man 
dafür einen µC, den man nicht versteht.

Immerhin ist das weniger lebensgefährlich.

: Bearbeitet durch User
von pic (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Clock stretching, es gibt viele CPU welche dies nicht können, angefangen 
von Microchip bis zu RPI. Zudem wird hier iic langsam gefahren, 
15.15kbit/s was dazu beiträgt dass iic device welches clock stretching 
benutzen trotzdem an einem Master ohne clock stretching support 
funktioniert.

Der call level ist ein Problem, es gibt nur zwei call ebenen. Solltest 
du verzweifelt sein, gibt es ein SW stack mit mehr call/return ebenen, 
ansonsten einfach code besser planen.
Auch sollten 8bit Argumente nur in W dem Unterprogramm über geben werden 
und nicht schon vorher in einer Hilfe variable abgespeichert werden, 
dies braucht man nur wenn mehr als 8bit über geben wird.

von Max M. (maxmicr)


Bewertung
1 lesenswert
nicht lesenswert
A. K. schrieb:
> Und um dem die richtige Würze zu geben, verwendet man
> dafür einen µC, den man nicht versteht.

Mit irgendwas muss man doch anfangen? Ich weiß nicht, was daran schlimm 
ist, wenn man etwas nicht versteht? Ich habe vor, dieses Projekt 
durchzuziehen, danach verstehe ich den PIC10F200 hoffentlich 
einigermaßen.

pic schrieb:
> Auch sollten 8bit Argumente nur in W dem Unterprogramm über geben werden
> und nicht schon vorher in einer Hilfe variable abgespeichert werden,

Hm, nur muss ich dann in der Funktion den Wert aus dem W-Register 
trotzdem im RAM speichern da sonst z.B. logische Operationen nur bedingt 
möglich sind. Der PIC hat zudem keinen Stack auf den man die 
Übergabeparameter schieben kann so dass sich theoretisch jedes Register 
in irgendeiner Unterfunktion ändern kann wenn man nicht aufpasst. 
Deswegen hab ich ein Register für die wichtigsten Sachen definiert. Das 
würde ein effizienter Compiler sicher anders machen, aber bevor ich 
jedes Register so effizient wie möglich nutze, versuche ich erstmal, das 
Programm zum laufen zu kriegen.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
pic schrieb:
> Clock stretching, es gibt viele CPU welche dies nicht können, angefangen
> von Microchip bis zu RPI.

Der Bus Pirate mit seinem zu Fuss programmierten I2C auch nicht. Wobei 
mir nicht ganz klar ist, was daran so schwierig ist.

Wobei die Hardware-Module für I2C es normalerweise können, zumindest 
theoeretisch. Auch der RasPi-SoC hat das eigentlich vorgesehen, nur ist 
die Implementierung ein Schuss ins Knie.

von Dieter W. (dds5)


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> Mit irgendwas muss man doch anfangen? Ich weiß nicht, was daran schlimm
> ist, wenn man etwas nicht versteht? Ich habe vor, dieses Projekt
> durchzuziehen, danach verstehe ich den PIC10F200 hoffentlich
> einigermaßen.

Das ist ja auch durchaus in Ordnung, nur sollte man das Teil am Anfang 
nicht gleich bis auf das letzte Bit ausquetschen wollen.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> Mit irgendwas muss man doch anfangen?

Mikrocontroller dieser untersten Kategorie aller 8-Bit µC sind 
hauptsächlich auf dem Markt, um im Masseneinsatz einfachste Logik- und 
Timerfunktionen zu implementieren. Beispielsweise an Stelle eines '555. 
Anwendungen, wo der letzte Cent interessant ist, und das 6-Pin Gehäuse.

Wer damit I2C ansteuert, der muss sich schon fragen lassen, ob es ihm 
wirklich um eine Lösung geht. Oder darum, in voller Absicht etwas im 
Grunde sinnloses zu tun. Dieser µC hat eine für Open Drain ungeeignete 
Portstruktur (ohne LAT Register ist das haarig) und erlaubt nur extrem 
eingeschränkte Nutzung von Unterprogrammen. Kaum ein anderer nicht schon 
antiker 8-Bit PIC hat diese Einschränkungen.

von Thomas E. (picalic)


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
> Hm, nur muss ich dann in der Funktion den Wert aus dem W-Register
> trotzdem im RAM speichern

W zur Über- und Rückgabe von Parametern zu verwenden, ist üblich.
Es ist aber bzgl. Codegröße auch effizienter, z.B. am Anfang einer 
Subroutine einmal movwf einzubauen, als bei X Aufrufen der Subroutine 
X-mal vor jedem call einen movwf-Befehl einzufügen.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Apropos antik: Diese PIC10 sind im Grunde experimentelle Archäologie, 
ein Ausflug mit einer Zeitmaschine in die allerersten Jahre der 
Mikrocontroller.. Der Core ist in seiner Funktionalität nahezu identisch 
mit dem des ersten aller PICs, dem PIC1650 von 1977. Was nicht heisst, 
dass der Core von damals so genial gewesen sei, dass die Zeit ihm nichts 
anhaben kann.

: Bearbeitet durch User

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.