Reaktivlicht mit PIC

fekon · 21 März 2006

In diesem Thread wurde das Thema "Reaktivlicht mit µC" ja ausführlich beleuchtet. Es basiert auf dem hier geschilderten Prinzip.
Da es bei µCs mit PIC und Atmel ähnlich ist wie mit Garmin und Magellan bei GPSr, möchte ich eine Variante für PICs vorstellen.
Dieses Programm ist für den 12F675 geschrieben:

Code:

	list P=PIC12F675
	include "p12f675.inc"

i equ 0x20
dunkel_z equ 0x21
	
Init
	bcf STATUS,RP0	; Bank0
	movlw 0x07		; digitale Ein/Ausgänge, kein Komparator
	movwf CMCON
	bsf STATUS,RP0  ; Bank 1
	movlw B'001010' ; kein A/D auf GP0+2
	movwf ANSEL
	clrf dunkel_z
;Ende Init


st	movf dunkel_z,w ;dunkel_z steigt nicht über 245 (willkürlich gewählt)
	addlw D'10'
	btfss STATUS,C
	incf dunkel_z,f ;nicht zu hoch zählen (Überlauf!)
	
	bsf STATUS,RP0   	;0+2 out
	movlw B'111010'
	movwf TRISIO
	movlw B'10001101' ;WDT postscaler 1:32
	movwf OPTION_REG
	bcf STATUS,RP0
	bsf GPIO,0 			;lade LED
	bcf GPIO,2
	bsf STATUS,RP0		;0 Eingang
	movlw B'111011'
	movwf TRISIO
	bcf STATUS,RP0
    sleep
	btfsc GPIO,0        ;hell oder dunkel?
	goto st				;dunkel -> nochmal messen

hell
	movf dunkel_z,w
	addlw D'240'  ;256-240=16 > 16 * 32 * 18 ms =~10s
	bnc noblink   ;erst nach 10s Dunkelheit wieder blinken
blink
	movlw 5		;5 mal blinken
	movwf i
	bsf STATUS,RP0
	movlw B'111010' ;Ausgänge!
	movwf TRISIO
	BCF STATUS,RP0
	bcf GPIO,0
l1	bsf GPIO,2       ;LED an       
	sleep            ;Pause
	bcf GPIO,2       ;LED aus
	sleep            ;Pause
	decfsz i,f       
	goto l1
noblink	
	clrf dunkel_z    ;hell ist nicht dunkel
	bsf STATUS,RP0
	movlw B'10001111' ;WDT postscaler 1:128
	movwf OPTION_REG
	sleep             ; Pause 2,3s

	goto st
	
	
	END

Die Programmiersprache ist Assembler (und der Stil sicher nicht der sauberste). Da das Programm den Watchdogtimer und den internen Oszillator nutzt, sollte man die Konfigurationsbits entsprechend setzen. Der 12F675 ist nicht der stromsparendste PIC, aber ich hatte ihn gerade hier liegen. Wer Informationen zu PICs sucht, der wird hier fündig.

Wer ohne großes Hintergrundwissen ein Reaktivlicht aufbauen will, dem empfehle ich die CMOS-Variante von gomerffm oder das Atmelreaktivlichtkochbuch von Ralf. Getestet habe ich sie allerdings beide nicht.

GdE-||-Striker · 30 März 2006

Der Stromsparenste ist der 12F675 nicht. Dafür ist die Verfügbarkeit hier in München gut. Die etwas sparsameren 12F635 und 12F683 sind in München nicht zu bekommen (Bürklin, Unrat, S&H, etc.). Bleibt halt noch die Alternative bestellen. Ich glaube ich habe 635er bei Reichelt gesehen.

Respekt das Du das in Assembler gelöst hast. Da wäre ich (<= C- und C++-Junkie) sicher viel zu faul zu gewesen

fekon · 30 März 2006

GdE-||-Striker schrieb:
Respekt das Du das in Assembler gelöst hast. Da wäre ich (<= C- und C++-Junkie) sicher viel zu faul zu gewesen

Isch 'abe gar keinen C-Compiler...

Aktuelles Projekt ist ein Reaktivlicht mit 10F202 im SOT23 mit SMD-LED. Wenn ich das Ding so sparsam bekomme, wie ich will, dann wird das ein sehr kleines Reaktivlicht.

GdE-||-Striker · 31 März 2006

Google einfach mal nach BoostC Compiler bzw. SourceBoost IDE. Ist alles OpenSource, fallen also keine Kosten an. Funktionieren tuts einwandfrei. Die Sourceboost IDE klinkt sich auch in das MPLAB von Microchip ein. Was es leider nicht gibt - oder ich noch nicht entdeckt habe - ist ein Tool das einem die Hardware Konfig vorgeneriert. Also sowas wie Dave für die Infinion C164 µC.

fekon · 3 Nov. 2006

Ich habe die 12F675-Version mal wieder hervorgekramt.

GdE-||-Striker schrieb:
Der Stromsparenste ist der 12F675 nicht.

Naja, im sleep-mode geht es. Allerdings muss man die Brown-Out-Erkennung abschalten. Mit einer leicht erweiterten Software (prüft tagsüber seltener) habe ich folgende Werte erreicht:
Tag: 2µA @ 3V
Nacht: <5µA @3v (schwankt etwas).
Da sollten die Batterien fast ewig halten (zumindest solange nicht dauernd jemand das Ding auslöst).

doc-database · 23 Juli 2009

Hallo Forumgemeinde,
ich habe mir erlaubt, den Quellcode aus Post#1 für den Pic 12F683 umzuschreiben, allerdings mit etwas anderer Funktion.
Den "unsauberen" Quellcode habe ich übernommen, aber es funktioniert.

Code:

;**********************************************************************
;   This file is a basic code template for assembly code generation   *
;   on the PIC12F683. This file contains the basic code               *
;   building blocks to build upon.                                    *
;                                                                     *
;   Refer to the MPASM User's Guide for additional information on     *
;   features of the assembler (Document DS33014).                     *
;                                                                     *
;   Refer to the respective PIC data sheet for additional             *
;   information on the instruction set.                               *
;                                                                     *
;**********************************************************************
;                                                                     *
;    Filename:	    Reaktivlicht_Geoclub.asm                          *
;    Date:          23.07.09                                          *
;    File Version:                                                    *
;                                                                     *
;    Author:                                                          *
;    Company:                                                         *
;                                                                     *
;                                                                     *
;**********************************************************************
;                                                                     *
;    Files Required: P12F683.INC                                      *
;                                                                     *
;**********************************************************************
;                                                                     *
;    Notes:                                                           *
;	 LED's: 	Mess LED: 	GP0 = Anode, GP2 = Kathode				  *
;				LED grün:	GP1		Anzeige Dunkelheit				  *
;				LED rot	:	GP4		Anzeige Helligkeit				  *
;				LED gelb:	GP5		Anzeige Dauer Pause				  *
;                                                                     *
;**********************************************************************

	list      p=12F683        ; list directive to define processor
	#include <p12F683.inc>    ; processor specific variable definitions

	errorlevel  -302          ; suppress message 302 from list file

	__CONFIG   _FCMEN_ON & _IESO_OFF & _CP_OFF & _CPD_OFF & _BOD_OFF & _MCLRE_ON & _WDT_OFF & _PWRTE_ON & _INTRC_OSC_NOCLKOUT 

; '__CONFIG' directive is used to embed configuration word within .asm file.
; The lables following the directive are located in the respective .inc file.
; See data sheet for additional information on configuration word settings.




;***** VARIABLE DEFINITIONS
i				EQU		0x7C
dunkel_z		EQU		0x7D
w_temp        	EQU     0x7E        ; variable used for context saving 
status_temp   	EQU     0x7F        ; variable used for context saving


#define BANK0	bcf STATUS,RP0
#define	BANK1	bsf	STATUS,RP0
#define	TAKT	B'00000001'	; 31kHz LFINTOSC

#define	CMP_OFF	B'00000111'		; CMCON0: CMP off
#define	messA			GPIO,0
#define	LED_gn			GPIO,1
#define messK			GPIO,2
#define	LED_rt			GPIO,4
#define	LED_ge			GPIO,5
;**********************************************************************
	ORG     	0x000             ; processor reset vector
	goto    	main              ; go to beginning of program
	

	ORG     	0x004             ; interrupt vector location
	movwf   	w_temp            ; save off current W register contents
	movf		STATUS,w          ; move status register into W register
	movwf		status_temp       ; save off contents of STATUS register


; isr code can go here or be located as a call subroutine elsewhere


	movf    	status_temp,w     ; retrieve copy of STATUS register
	movwf		STATUS            ; restore pre-isr STATUS register contents
	swapf   	w_temp,f
	swapf   	w_temp,w          ; restore pre-isr W register contents
	retfie                    ; return from interrupt

Init


main

	;Takt
	Banksel	OSCCON
	movlw	TAKT
	movwf	OSCCON

	BANK0
	movlw	CMP_OFF
	movwf	CMCON0
	BANK1
	movlw	B'001000'		; kein A/D auf GP0 & 2
	clrf	ANSEL
	clrf	dunkel_z		;nicht zu hoch zählen (Überlauf!)
st
	movf	dunkel_z,w ;dunkel_z steigt nicht über 245 (willkürlich gewählt)
	addlw	D'10'
	btfss	STATUS,C
	incf	dunkel_z,f ;nicht zu hoch zählen (Überlauf!)

 	BANK1					;0+2 out
   	movlw B'111010'
   	movwf TRISIO

   	bcf STATUS,RP0
   	movlw B'00000001' ;WDT postscaler 1:32, ON
   	movwf WDTCON
	Banksel GPIO
   	bsf messA          ;lade LED
   	bcf messK
   	BANK1		      ;0 Eingang
   	movlw B'111011'
   	movwf TRISIO
   	bcf STATUS,RP0
	
    sleep
   	btfsc messA        ;hell oder dunkel?
   	goto dunkel           
	goto	hell

dunkel
	Banksel	TRISIO	; LED_rt 5
	movlw	B'101111'
	andwf	TRISIO,1

	Banksel GPIO
	movlw	B'010000'
	iorwf	GPIO,1
	goto sl
	
hell
	Banksel	TRISIO	; LED_gn 1
	movlw	B'111101'
	andwf	TRISIO,1

	Banksel GPIO
	movlw	B'000010'
	iorwf	GPIO,1
	goto sl

sl
	bcf STATUS,RP0
   	movlw B'00001001' ;WDT postscaler 1:512, ON
   	movwf WDTCON

	Banksel	TRISIO
	movlw	B'011111'
	andwf	TRISIO,1

	Banksel GPIO
	movlw	B'011111'
	andwf	LED_gn
		
	sleep
	
	movlw	B'100000'
	iorwf	LED_gn

	goto st
	



	END                       ; directive 'end of program'

Funktion: Diode zwischen GP0 und GP2 "mißt" die Helligkeit (siehe Post1). Entsprechend wird die LED grün oder LED rot gesetzt.

chrysophylax · 19 Feb. 2010

Nachdem jetzt schon mehrere Rückfragen per PN kamen, recycele ich mal diesen alten Thread (der meines Erachtens recht gut paßt), ziehe eine dicke Trennlinie

------------------------------------------------------------------------------------------------------------

und spalte mich mit meinem Projekt aus dem "normalen" Reaktivlicht-Thread ab. Ihr dürft mich gerne nachbauen (in 1-2 Wochen müßte ich auch mit der Doku soweit sein), aber das, was ich da gebaut habe, hat außer in der Funktion mit dem hier gängigen Atmel-Reaktivlicht aber auch überhaupt nichts gemein außer der Funktion.

Ich wurde bereits mehrfach gefragt, ob und wie man mit gewohnter Entwicklungsumgebung (AVRStudio, Bascom, STKxxx oder AVRISPMKII) Inhalt in die von mir genutzen Bausteine bekommt - die lapidare Antwort heißt: Gar nicht.

Die Prozessoren der Firma Atmel sind etwas völlig proprietäres. Die Entwicklungsumgebung (AVRStudio) funktioniert nur für Atmels, die Programmiergeräte (STKx00, AVRISPMKII, ...) funktionieren nur für Atmels, die Programmcodes in Assembler funktionieren nur für Atmels.

Die Prozessoren der Firma Microchip sind etwas völlig proprietäres. Die Entwicklungsumgebung (MPLab) funktioniert nur für Microchips, die Programmiergeräte funktionieren nur für Microchips, die Programmcodes in Assembler funktionieren nur für Microchips.

Von denen ist keiner "normal", weil es in der Microcontrollerwelt kein "normal" gibt. Jeder von beiden hat spezielle Tools und Programmiergeräte, die völlig proprietär nur für deren Hardware funktionieren. Programmcode (insbesondere in Assembler) ist nicht ohne weiteres von Einem auf den Anderen übertragbar.

Die Anfrage kam schonmal, da hab ich den Vergleich mit Autos gezogen: Es wird in der Werkstatt sehr lustiges Augenbrauen-Runzeln geben wenn man mit einem BMW in eine Mercedes-Werkstatt fährt und sagt "ich hätte gerne den Blinker vom Daimler Modell blafaslblubb in meinen BMW eingebaut, der sieht so hübsch aus". Da paßt vorne und hinten aber auch gar nix zusammen. Nur weil beide Autos die gleiche Funktion erfüllen (Menschen mit mangelndem Selbstwertgefühl von A nach B zu befördern) heißt das noch lange nicht, daß man fröhlich Teile zwischen ihnen hin- und hertauschen kann.

Exakt so ist das mit Programmen, Entwicklungsumgebungen und Programmiergeräten für Atmels und Microchips auch.

Und die beiden sind nicht die Einzigen, es gibt noch dutzende weiterer etablierter Standards für Microcontroller, die alle auch wieder eine völlig eigenständige Insellösung des betreffenden Herstellers sind und überhaupt nicht kompatibel zu irgendwas anderem.

Es gibt einige wenige Universal-Programmiergeräte (z.B. Advantech Labtool im professionellen Bereich oder Ponyprog im Hobbybastelbereich), die fast beliebige Controller beliebiger Hersteller programmieren können, dann muß man sich aber immer noch mit den völlig unterschiedlichen Entwicklungsumgebungen rumschlagen...

Ich glaube auch nicht (und möchte vor allen Dingen auch nicht), daß irgendwelche revolutionären Ereignisse stattfinden werden, wenn ich meine Hard- und Software veröffentliche.

Außer mir treibt sich im Geoclub-Elektronik Bereich noch höchstens ein Mensch rum, der auch mehr auf PICs als auf AVRs steht (nach dem, was ich bisher gelesen habe), wir sind da also die absolute "Exoten-Fraktion". Mit den beiden Firmen und ihren Produkten ist es ein bißchen wie mit der Volksfront von Judäa und der jüdäischen Volksfront - im Grunde zielen beide auf den gleichen Markt und unterscheiden sich nur in Marginalien, aber es entfachen sich frenetische Glaubenskriege, welche Produktfamilie denn besser ist. Was auch wieder völlig identisch ist zu der Frage, ob ein Daimler besser ist als ein BMW:

"Kommt drauf an, was man damit machen will". Wenn die heutigen Computerkinder nur das Wort "Assembler" hören - gibt’s einen entsetzen Aufschrei - die wollen alle bunte Java-Kacke mit der Maus zusammenklicken, "Assembler" war doch das, was kurz nach den Lochkarten mal ne Weile angesagt war.... Da werde ich wenig Zielgruppe finden...
Ich glaube auch nicht, daß ich großartig Leute bekehren möchte, oder daß sich gar Leute bekehren lassen. Und ganz ehrlich: Wenn irgendwas mit dem Schaltungsnachbau oder der Programmierung nicht klappt, dann wäre ich der Einzige, der in der Lage ist, zu supporten.

Für Atmel-Prozessoren treiben sich mindestens 5-10 Mann im Forum rum, die sich damit halbwegs auskennen. Ich glaube, den Schuh will ich mir gar nicht anziehen.
Wer selbst mehr aus der PIC-Ecke kommt (undoder gar diesen Assembler-Dialekt spricht) wird meine Lösung nachbauen (so er sie denn unter den Unmengen Atmel-Infos findet), wer hobbybastelt und froh ist, daß er einen halben Satz BASIC fließend sprechend kann, wird bei der AVR-Lösung mit dem deutlich besseren Support im Forum bleiben....

Ich hab das Ganze auch weniger für die Welt gemacht, sondern mehr als Spielprojekt zu meinem eigenen Vergnügen, wenn jemand was davon hat darf er es gerne mitnutzen, aber das war nicht unbedingt Ziel der Sache. Noch weniger Böcke hab ich auf klassischen Schwanzlängenvergleich - das gibt nur böses Blut wenn irgendwer meint, die eine oder die andere Schaltung wäre warumauchimmer besser. Alles eine Frage der Sichtweise.....

Um von daher die Baustellen ein wenig auseinanderzuhalten, werde ich Fragen und Infos zu meinem Lösungsansatz in Zukunft in diesem Thread beackern und mich aus dem "altbekannten" Atmel-Tiny-Thread halbwegs raushalten um zu verhindern, daß sich irgendwer nach meiner Stückliste Teile kauft, mit denen er am Ende nichts anfangen kann...

chrysophylax.

chrysophylax · 2 März 2010

So, ich wäre dann auch mit meiner Komplettdoku durch - wer sich für meine Variante der PIC-Magnetbake bzw. des Reaktivlichts interessiert, kann sich das Ganze hier ansehen...

chrysophylax.

chrysophylax · 22 Juni 2010

"Man kann auch mal Glück haben - oder: Neues vom Poolservice"

Nachdem meine ersten 10 Platinen inzwischen bestückt und unters Volk verteilt sind (lustigerweise noch keine einzige in einer Dose von mir selbst), hab ich den Versionsstand aus dem letzten Post dann mal bei einer eh fälligen Poolservice-Bestellung mitlaufen lassen und gleich einen Sechser im Lotto gelandet....

Irgendwie hatte ich einen Produktions-Zeitslot erwischt, in dem außer mir niemand Platinen haben wollte, und so hat der Lieferant mal spaßeshalber (und ohne mich vorher zu fragen) den gesamten Rest des Pizzablechs mit meinen Magnetbaken-Platinchen vollgepflastert und mich anschließend gefragt, ob ich denn die komplette Übermenge zum halben Preis mitnehmen würde, oder ob man die überzähligen Platinchen zerschreddern soll...

Ich hab natürlich alle genommen und hab jetzt für Kosten eines Appels und eines Eis mehr Platinen für Magnetbaken und Reaktivlichter, als ich jemals in meinem Leben in die Landschaft bringen kann. Der Schaltungs- und Softwarestand ist immer noch wie gehabt, ich hab nur nach den Erstmustern ein paar kleinere Anhübschungen, Symmetrierungen und gaaaanz wichtig ( :roll:

) ein paar hüsche Creative-Commons-Logos ins Kupfer gebracht.

Wenn also jemand Magnetbaken oder 7Segment-Reaktivlichter mit PICs ausprobieren möchte... Ich hätte reichlich.

Ansonsten wollte ich die Gelegenheit einfach mal nutzen um "der Horde hier" Mut zu machen, auch mal selbst statt der Sauerei im heimischen Keller einen Poolservice anzutreten, das ist gar nicht so teuer und erst recht nicht so schwierig, wie man sich denkt. Und die Ergebnisse sind einfach klasse (siehe beigefügtes Bild).

Dabei auch gleich ganz viel explizite und begeisterte Werbung für Meggi und ihren tollen Service, ich bin mit der Firma weder verwandt, noch verschwägert, noch beteiligt, sondern einfach nur ausgesprochen zufriedener Kunde.

chrysophylax.de

Lion251 · 16 Aug. 2010

Chrysophylax: schön dass ich hier noch einen PIC-Fan finde!
Erst mal kurz vorstellen: Ich bin Henk de Leeuw ("Heinrich der Löwe") aus Niederlande, Elektronik-Bastler und Geocacher.
Ich hatte schon länger vor auch mal ein Reaktivlicht zu bauen, aber wußte gar nicht, wie das auf Deutsch hieß, oder dass schon sehr lange Threads darüber geschrieben waren.
Wenn ich mit Mikrocontrollern bastle, dann sind das eigentlich immer PICs.
Von einem befreundeten Geocacher aus Deutschland hatte ich schon erfahren, dass er ein funktionierenden Entwurf für ein "Autoresponder" (so nannte ich das noch) mit Atmel-Prozessor habe, aber ich wollte doch mal versuchen, selber so etwas zu bauen (und dann mit PIC!).
Erst habe ich nicht geglaubt, dass man den LED so "mißbrauchen" könne, dass er auch als Sensor dient, aber nach einige Experimente schien das doch zu funktionieren.
Letzte Woche, als ich fast etwas funktionierendes hatte, habe ich dann dieses Forum gefunden, und eine gaaaanze Menge dazugelesen.

Und jetzt habe ich etwas funktionierendes!
Mit PIC10F222, winziger SOT23-6, 512 Flash-Wörter, 23 Bytes RAM.
Morse-Ausgabe funktioniert, aber Speicherung der Morse-Werte komplett anders, als ich hier im Forum gefunden habe.
Morse-Empfang sollte auch funktionieren, habe ich aber noch nicht getestet.
Lichtdetektion mit dem Sende-LED, als Kondensator geschaltet der durch den Foto-Strom entlanden wird.
Gemessen wird das mit einem A/D-Wandler.
Glücklicherweise hatte ich hier im Forum noch nicht gelesen, dass das mit LED als Fotozelle nich so gut funktioniert, sonst hätte ich vielleicht den Mut aufgegeben.
Alles in Assembler programmiert; vielleicht werde ich den Code hier noch mal veröffentlichen; es sind aber mittlerweile insgesamt so rund 10 Seiten geworden...
Stromverbrauch: 4uA bei 3V, 5 uA bei 4V.
Das ist eigentlich nur Watchdog-Timer Verbrauch; der Prozessor (4 MHz) schläft normalerweise 99,95% der Zeit. Ein anderer PIC (vor allem die neuen mit XLP) wäre sparsamer gewesen, aber diese war vorhanden, und bei 4 uA sollte eine 2430 Knopfzelle mit 250 mAh schon mehrere Jahre aushalten.

Und jetzt das wichtigste: taugt es ein bisschen?
Ich habe gestern die erste Versuche "im Freien" gemacht.
Mit einem "Heitech" LED-Lampe von 2 Euro konnte ich es bis 30 Meter Entfernung zuverlässig auslösen.
So eine Lampe ist aber ein Cacher unwürdig.
Mit eine 3W LED-Leuchte (Ultrafire WF-501B, Cree XR-E Q5, aber nur 700 mA Stromverbrauch aus einer 18650 LiIon Batterie) ging das schon besser: 300 Meter ohne Probleme.
Mit eine vergleichbare Leuchte mit aspherischer Linse (sodass man eine quadratische Abbildung vom LED-Chip projiziert, ziemlich guter Thrower) hätte das weit über ein km sein müssen, aber dann konnte ich (auch wegen der stärker werdende Regen, die das Licht verstreute) mein Fahrrad, wo ich das Reaktivlicht auf dem Gepäckträger platziert hatte, nicht mehr sehen.
Und das mit nur zwei Bauteile!
Das Ganze ist fast genausogroß wie der LED selber.
Vorerst bin ich also ziemlich zufrieden

Ich habe den Test übrigens gemacht mit uralten (>20 Jahre) klaren roten LEDs, die ich noch liegen hatte.
Mittlerweile habe ich noch eine ganze Serie an modernen LEDs bestellt; mal sehen, was die bringen.
Wahrscheinlich sind die neuen bei noch größerer Entfernung sichtbar; auch mal sehen, wie lichtempfindlich die sind.

Wenn ich noch mehr Erfahrungen und vielleicht Bilder habe in den nächsten Wochen, sollte ich dann einer neuen Thread eröffnen? Letztendlich ist das hier zwar auch ein Reaktivlicht mit PIC, aber wieder mit komplett anderer Software als die von Chrysophylax oder Fekon. Andererseits ist das auch ein PIC-Licht, und sollte nicht verwirrt werden mit den hier üblicheren AVR-Lichter.

chrysophylax · 16 Aug. 2010

Toll ! Ich bin nicht mehr quasi-alleine

! Von den 10ern hab ich hier auch irgendwo noch ein Einsteiger-Set rumfliegen, konnte mich bisher aber nie aufraffen, mit denen mal was zu machen...

Ich bin mal gespannt auf Schaltpläne - und wenn möglich bzw. genehmigt natürlich auch den Quellcode...

chrysophylax.

Lion251 · 16 Aug. 2010

"Schaltplan" ist sehr einfach: Pin1 (AN0) und 2 (Gnd) an Masse, Pin3 (AN1/GP1) Anode LED, 4 (GP2): Kathode LED, 5 (Vcc) und 6(/MClr): V+ (2.5-5V)
Die Pins sind so ausgelegt, dass man den PIC direkt mit Pin 3 und 4 an den LED löten kann, und die Batterie-Drähtchen an 1&2 und 5&6.
Ein Tropfen Zweikomponentkleber macht dann die Verbindungen wasserfest, sodass man es ohne Probleme draussen verwenden kann.
Pin 6 (/MCLR) kann eventuell auch offen bleiben, Pin1 (AN1) mit einem 1 kOhm Widerstand nach Masse statt direkt, und ein 470 Ohm Widerstand in Reihe mit dem LED. Dann kann man das Ding auch erneut programmieren.

Hat den 10F-Einsteiger-Set auch ein Prozessor wo man debuggen kann?
Die 6-Pin PICs haben aus Platz- und Kostengrunden keine Debug-Schaltung an Bord, sodass ich, falls etwas schief geht (und das geht es manchmal doch :???:

) auf den Emulator zurückgreifen muss, oder versuchen muss, den PIC über Blinksignale sein Rätsel zu entlocken.

Quellcode schicke ich gerne als ZIP per PN. Erst noch einigen Wantze ausbügeln...
Die Version mit der ich gerade teste, habe ich so gemacht, dass sie bei einem Helleigkeitssprung die Größe des Sprunges quasi-logarithmisch als Blinksignale ausgibt.
Also: A/D-Unterschied 2 (Minimalgröße für Lichtdetektion): 2x blinken,
3: 3x blinken,
4-5: 4x,
6-7: 5x,
8-11: 6x,
12-15: 7x, usw.
Wenn das Signal zweimal so groß wird, kommen also zwei Blinks dazu.
Wenn also der LED mindestens zehnmal leuchtet, weiss man also, dass die Lampe aus ein viermal so großer Entfernung die Schaltung auch noch auslösen wird. Sehr nützlich beim Testen!

Mir ist übrigens aufgefallen, dass die AD-Wandler des PICs sehr gut und stabil sind.
Von AD-Wandlern kenne ich eigentlich, dass die immer etwas rauschen, vor allem, wenn die auf ein Prozessor-Chip liegen. Meistens zittert das letzte Bit (oder auch mehr...) etwas.
Wenn ich aber morgens zwischen 5 und 7 Uhr, als die Sonne aufkommt, die AD-Werte anschaue, dann geht das 8, 8, 8, (Dunkelwert), 9, 9, 9, 9, 10, 10, 10, 10, 10, 11, 11, 11, usw.
Kein einziges Zittern im letzten Bit, kein Wert wird übersprungen.
Daher kann ich ruhig als Auslöseschwelle einen Unterschied von nur 2 nehmen.
Bei 'natürliche' Lichtübergänge ist der Maximalsprung zwischen aufeinanderfolgenden Werte ja maximal 1.
Und, ehrlich gesagt, braucht man das bei ein Konverter mit nur 8 Bit auch.
Da sind diese Controller auch wirklich das Minimalste, mit dem man noch etwas vernünftiges anfangen kann.

chrysophylax · 17 Aug. 2010

Lion251 schrieb:
Hat dein 10F-Einsteiger-Set auch ein Prozessor wo man debuggen kann? Die 6-Pin PICs haben aus Platz- und Kostengrunden keine Debug-Schaltung an Bord, sodass ich, falls etwas schief geht (und das geht es manchmal doch ) auf den Emulator zurückgreifen muss, oder versuchen muss, den PIC über Blinksignale sein Rätsel zu entlocken.

Keine Ahnung, liegt seit bald 10 Jahren originaleingeschweißt in Folie irgendwo rum. Man kommt ja zu nichts

. Aber ganze ehrlich: Der Simulator ist ne Granate - was man mit dem alles machen kann - da blieben bisher nur sehr wenige Wünsche offen. Gerade auch analoge Geschichten lassen sich durchaus damit durchackern, wenn man sich ein entsprechendes Stimulus-File zusammenschreibt. In der Firma haben wir diverse Excels, die Megabytegroße komplexeste analoge Signalformen als Stimulus-File für den PIC-Simulator generieren um die eine oder andere Firmware-Funktion zu testen - das geht prächtigst. Fürs Reaktivlicht hab ich mir bisher noch nicht die Mühe gemacht, mal Sonnenaufgang und Sonnenuntergang und ein Taschenlampenanleuchten als Stimulus zu generieren - das ging bisher immer relativ stressfrei ohne. Aber ich hab ja auch ne 7Segment-Anzeige zum debuggen

Lion251 schrieb:
Quellcode schicke ich gerne als ZIP per PN. Erst noch einigen Wantze ausbügeln...

Ich meld mich ! Bin ja neugierig....

Lion251 schrieb:
Mir ist übrigens aufgefallen, dass die AD-Wandler des PICs sehr gut und stabil sind. Von AD-Wandlern kenne ich eigentlich, dass die immer etwas rauschen, vor allem, wenn die auf ein Prozessor-Chip liegen.

Kann ich bestätigen. Selbst wenn man die Dinger weit ausserhalb ihrer Spezifikation quält stehen die wie ne eins - ohne, dass man den Prozessor während der Wandlung schlafen legen muss oder anderes Brimborium treiben muss. Da er nach dem Prinzip der schluckweisen Annäherung arbeitet kann man ihn sogar gnadenlos vor Ende der Wandlung abbrechen und sich sicher darauf verlassen, dass die bis dahin gewandelten MSBs auch garantiert stimmen. Da bin ich von der Volksfront von Judäa auch deutlich anderes gewohnt *läster*

chrysophylax.

chrysophylax · 25 März 2011

Was ich nicht für möglich gehalten hätte ist dann doch passiert: Es hat sich tatsächlich mal jemand gemeldet, der ein Reaktivlicht meiner Bauart selbst umprogrammieren möchte. Mit der Anleitung, die ich diesem Menschen geschrieben habe kam er dann zu Potte, und da sowas vielleicht mal wieder vorkommt hab ich mir die Erlaubnis eingeholt, das Ganze hier als "Frage-Antwort-Spiel" zu veröffentlichen für den Fall, dass weitere Menschen eine Anleitung brauchen, wie man denn in meinen PIC Software reinbekommt. Daher grabe ich mal diesen Thread wieder aus und führe mal ein wenig Monolog mit mir selbst - im Zweifelsfalle einfach ignorieren....

Frager schrieb:
Moinsen,
ich konnte bei eBay eines von deinen Reaktivlichtern ergattern und möchte gerne die Koordinaten ändern. Wie auf deiner Homepage und im Forum beschrieben gibt es nicht wirklich viele die sich mit PIC auskennen. Ich gehöre zu den Vielen und zu den noobs der Programmierung überhaupt.
Folgendes habe ich bis jetzt gemacht:
PICkit2 besorgt
Kabel gelötet und erfolgreich angelötet
Software (PICkit2 V2.61 und MPLab IDE 8.68) auf mein Netbook gebügelt.
MPLab gestartet und eingestellt auf PICkit2 und 16F690
PIC ausgelesen und funktioniert. Also Kommunikation funtzt.
Mit PICkit2 den 16F690 ausgelesen und als HEX File gespeichert geht auch.
Und was kommt jetzt?
Kannst du mir da ein wenig "unter die Arme greifen".

chrysophylax · 25 März 2011

Damit hast du die größten Hürden die man so finden kann (und bei denen es auch am Schwierigsten ist, per Mail Händchen zu halten) alle schon erfolgreich umschifft.
Als nebenbei-Bescheid: Der Baustein ist (meine ich) per Default in meiner Software lesegeschützt, so dass du für den Flash-Bereich nur Müll bekommst. Nur der EEPROM-Bereich sollte gültige Daten enthalten. Ist aber auch wurscht weil definitig unglücklich, da mit einem Hex-Editor drin rumzurühren..... Das möchtest du nicht.

Frager schrieb:
Und was kommt jetzt?
Kannst du mir da ein wenig "unter die Arme greifen".

Ja klar, kein Thema. Die anzuzeigenden Koordinaten sind hardcodiert in der Software eingebaut, um diese zu ändern musst du die Software neu durch die Entwicklungsumgebung jagen, das dürfte die bequemste Möglichkeit sein.

Die Software gibt’s als Quellcode im ZIP-Archiv auf meiner Webseite.

Das Verzeichnis speicherst du dir "wohin", wo du es im Pfad halbwegs flott wiederfindest. Dann öffnest du in MPLAB das Projekt (Projekt, nicht Datei) W006S001.mcp in diesem Pfad. Mit etwas Glück sind die Pfadangaben alle relativ, und du siehst links im Projektbaum die Datei "W006S001.asm" als Quellcode. Mit etwas Glück ist in einem grösseren Editor-Fenster auch schon der Quellcode offen zum drin rumeditieren.

Wenn nicht, kannst du auf "W006S001.asm" bei den Sourcefiles doppelklicken, spätestens dann sollte sich ein Editorfenster öffnen.

Ich bemühe mich immer, deutlich mehr Prosa und erklärenden Text als "echten" Programmcode zu schreiben, von daher dürften mehr als 50% Quelltextes beschreibender Kommentar sein. Wenn du magst lies es durch abends zum Einschlafen, wenn du meinst drin rumrühren zu müssen geschieht das auf eigene Gefahr

.

Das Ganze ist bewusst so angelegt, dass auch Leute, die von der Microcontrollerei undoder Assembler keine Ahnung haben, sich neue Inhalte programmieren können. Dazu ist alles, was in irgendeiner Form konfigurationsrelevant ist, in einem eigenen Programmblock ganz am Ende als Konstanten zur Ablage im EEPROM vordefiniert.

Spannend für dich wird’s ab dem Bereich "Sonstiges: EE-Speicher". So grob ab Zeile 1000, du kannst aber auch einfach danach suchen. Das EEPROM fängt mit dem Befehl ".org 0x2100" an.

Die ersten spannenden Zeilen dürften ungefähr so aussehen:

Code:

	subtitle "Sonstiges: EE-Speicher"
	page

	org 0x2100
; Generelle Konfigurationsparameter
EEGLOB
	de b'00000111'
;       |||||||+- 1= Reaktivlicht, 0= Magnetbake
;       ||||||+-- 1= "Alive-Blink" im Tagmodus Reaktivlicht
;       |||||+--- 1= Überbügeln Mittelwerte nach Koordinatenausgabe ("Testmodus")
;       ||||+----
;       |||+-----
;       ||+------
;       |+-------
;       +--------
EEDCTR
	de 10	; jede wievielte Messung wird im Dunkelmodus in die Mittelwertbildung 
		; einbezogen ?
EEDLEV
	de 32	; Schwelle, unter der in Nachtmodus ("Dunkel") gewechselt wird
EEHLEV
	de 64	; Schwelle, über der in Tagmodus ("Hell") gewechselt wird
EETRIG
	de 4	; Helligkeitssprung nach oben für Auslösung
EETRCTR
	de 0,0	; 16Bit-Zähler für Anzahl Auslösungen
EETACTR
	de 0,0	; 16Bit-Zähler für Anzahl Tage

; Parameter rund um die Zeichenausgabe
EEKOORD
	de LOW(EEENDE)-LOW(EEKOORD)-3	; Anzahl Zeichen
	de 60   ; Leuchtzeit * 10ms (die das Zeichen leuchtet)
	de 5	; Pausenzeit * 10ms (zwischen den Zeichen)

Im ersten Konfigurationsbyte mit hübscher ASCII-Malerei daneben kannst du dir bitweise zusammenkonfigurieren, ob du eine Magnetbake oder ein Reaktivlicht möchtest und ob mit oder ohne Lebenszeichen-Blitz im Tagmodus.

Anschliessend kommen diverse Konfigurationsparameter betreffend die Mathematik der Reaktivfunktion - wenn du irgendwann firm in dem Ding bist kannst du da auch mal drin rumspielen, ansonsten würde ich sie eher so lassen....

Spannend für dich wird’s ab "Parameter rund um die Zeichenausgabe". Als erstes Byte die Anzahl der auszugebenden Zeichen - wird automatisch zur Kompilierzeit errechnet, kannst du ignorieren. Die Leuchtzeit und Pausenzeit dürften für dich wieder relativ interessant sein.

Die Angaben musst du mit dem Faktor 10ms multiplizieren, d.h. eine Leuchtzeit von 60 heißt 600ms Leuchtdauer für jedes anzuzeigende Zeichen.

Anschliessend folgt die anzuzeigende Botschaft zeichenweise hintereinander. Vor der Botschaft kommt als Vorlage zum guttenbergen auskommentiert ein Fundus an Zeichen, die schonmal in Benutzung waren und die du wenn du sie benutzen willst einfach zeilenweise kopieren kannst.

Dran denken nach dem kopieren vor der Kopie das Kommentarzeichen ";" zu entfernen.

Code:

; eigentliche Zeichen, vorher Templates zur Verwendung mit Kopierpaste

; gängige Zeichen für Anzeige:

;	de 0xc0; "0"
;	de 0xf9; "1"
;	de 0xa4; "2"
;	de 0xb0; "3"
;	de 0x99; "4"
;	de 0x92; "5"
;	de 0x82; "6"
;	de 0xf8; "7"
;	de 0x80; "8"
;	de 0x90; "9"
;	de 0x88; "A"
;	de 0x83; "b"
;	de 0xa7; "c"
;	de 0xc6; "C"
;	de 0xa1; "d"
;	de 0x86; "E"
;	de 0x8E; "F"
;	de 0x82; "G"
;	de 0x89; "H"
;	de 0xe1; "J"
;	de 0xc7; "L"
;	de 0xab; "n"
;	de 0xc8; "N"
;	de 0xaf; "r"
;	de 0x87; "t"
;	de 0xe3; "u"
;	de 0xc1; "U"

;	de 0xbf; "-"
;	de 0xff; " "
;	de 0x7f; "."

	de 0x89; "H"
	de 0x88; "A"
	de 0xc7; "L"
	de 0xc7; "L"
	de 0xc0; "0"
	de 0xff; " "
	de 0xe1; "J"
	de 0xc1; "U"
	de 0x86; "E"
	de 0xaf; "r"
	de 0x82; "G"
	de 0x86; "E"
	de 0xc8; "N"
EEENDE
	end

Es handelt sich bei diesem Quelltext also um ein Reaktivlicht, welches den geistreichen Text "Hallo Jürgen" ausgibt, sobald man es anleuchtet. Tip: Änder erstmal nur ein auszugebendes Zeichen zum Üben, und wenn das klappt kannst du dich langsam steigern....

Wenn du mit Änderungen fertig bist F10 zum komplett durchkompilieren (hoffentlich ohne Fehlermeldung), anschließend stellst du unter "Programmer" dein PICkit2 ein und kannst den Inhalt in das Reaktiv-Platinchen übertragen...

chrysophylax · 25 März 2011

Frager schrieb:
OK die Daten entpackt und mit MPLab das Projekt geöffnet.
Die Koordinaten angepasst und kompiliert.
----------------------------------------------------------------------
BUILD SUCCEEDED

YES!!!!

Also Programmer Pickkit2 eingestellt und program angeklickt.

Kurzes Blinken von der Busy LED des Pickkit2 und eigentlich fertig.

Kabel ab, Batterie dran. Ich lebe noch Zeichen gibt es, aber das wars.
Nix mehr aufwachen und Koordinaten anzeigen.

Egal wie, über Hilfe von deiner Seite bin ich dankbar.

chrysophylax · 25 März 2011

Frager schrieb:
Kabel ab, Batterie dran. Ich lebe noch Zeichen gibt es, aber das wars.
Nix mehr aufwachen und Koordinaten anzeigen.

Das hört sich doch gut an - so als ob das Gerät genau das tut, was es soll. Das Lebenszeichen (wenn als Konfigurationsbit gesetzt) gibt es sinnigerweise nur tagsüber, wenn du dir ein Reaktivlicht zusammenkonfiguriert hast.

Wenn du also regelmässige Lebenszeichen-Blitze siehst (je nach Betriebsspannung ca. alle 15s), dann heißt das, dass das Reaktivlicht nach dem Anlegen der Spannung korrekterweise erkannt hat, dass es Tag ist und sich schlafen gelegt hat.

Wenn ein Reaktivlicht im Tagmodus ist und schläft, dann braucht es mindestens 16 "Lebenszeichen-Blitze" á ca. 15s = 240s = 4min völlige Dunkelheit, damit es aufwacht, in den Nachtmodus geht und "scharf" = "aktivierbar" wird. Den Nachtmodus erkennt man daran, dass auch keine Lebenszeichen-Blitze mehr kommen, wär ja auch doof, dann würden die Leute evtl. das Reaktivlicht nachts nur anhand des Lebenszeichen-Blitzes finden können.

Klappt nachts und draussen wunderbar, ist aber zum Testen etwas anstrengend und führt regelmässig dazu, dass Leute meinen "das Ding funktioniert nicht", weil sie der Meinung sind, dass meine Software sich genau so verhalten müsste, wie das die Software aus dem geoclub tut. Tut sie aber nicht, was die 2 schlichten Gründen hat dass ich a) damit Schummeln und Fehlauslösungen deutlich reduziere, und b) mein Reaktivlicht tagsüber wirklich in Hardware schläft (und nicht wie im geoclub durch einen Watchdog aufgeweckt wird) und dadurch nur ca. 10% des Stromverbrauchs der geoclub-Varianten ohne Lebenszeichen-Blitz hat und 50% des Stromverbrauchs der geoclub-Varianten mit Lebenszeichen-Blitz.

Zum Programmieren und debuggen (was die meisten Menschen drin im Hellen machen) kann man sich kurzerhand C2 deutlich verkleinern, das ist die Zeit die das Ding in Hardware schläft zwischen zwei Lebenszeichen-Blitzen. Auf meinem Entwicklungs-Board hab ich üblicherweise da 100nF oder 47nF. Auch wenns so aussieht: Das ist KEIN klassisches RC-Glied, BLOSS NICHT an R13 spielen. Teufels Küche und so.

Das kurze Fazit des langen Texts: Leg dein fertig programmiertes Reaktivlicht einfach mitsamt Batterie für 5min in eine dunkle Schublade, und sobald du die Schublade öffnest, wird es auslösen.

Direkt nach der Auslösung gibt es eine Totzeit von 20-30s, während der keine erneute Auslösung möglich ist. Während dieser Totzeit wird die Umgebungshelligkeit gemessen und gemittelt, wenn es weiter dunkel ist bleibt das Reaktivlicht im Nachtmodus und ist anschliessend wieder auslösbar, wenn es ihm zu hell ist (weil es z.B. nur aus einer Schublade gezogen wurde) geht es direkt in den Tagmodus und schläft für mindestens 4min inaktiv.

Frager schrieb:
Egal wie, über Hilfe von deiner Seite bin ich dankbar.

Wir kriegen das irgendwie gedeckelt.

chrysophylax · 25 März 2011

"Bescheid" aus der Erzählerperspektive: Es stellte sich dann letztendlich raus, dass der "Frager" beim zusammenbauen des Bitmusters für die Konfiguration ob Magnetbake oder Reaktivlicht einfach ein Zeichen verrutscht war, da durch unterschiedlich lang eingestellte Tabstops auf unseren Rechnern meine schöne ASCII-Malerei nicht genau bündig unter der entsprechenden Binärdarstellung war.

Kaum war das richtiggeschoben, ging alles so, wie es sollte....

Reaktivlicht mit PIC

fekon

Geocacher

GdE-||-Striker

Geomaster

fekon

Geocacher

GdE-||-Striker

Geomaster

fekon

Geocacher

doc-database

Geonewbie

chrysophylax

Geomaster

chrysophylax

Geomaster

chrysophylax

Geomaster

Anhänge

Lion251

Geocacher

chrysophylax

Geomaster

Lion251

Geocacher

chrysophylax

Geomaster

chrysophylax

Geomaster

chrysophylax

Geomaster

chrysophylax

Geomaster

chrysophylax

Geomaster

chrysophylax

Geomaster