www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik PIC 12F675 + ADC-Eingang +Code +Dresden


Autor: Xor Wf (xorwf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Ihr!


Ein kleines Projekt, schematisch:

Dreh-Poti--->[ADC im PIC ]<========Datenleitung=====>[PIC mit EEPROM]



Ich stelle mir folgendes vor:

(1) Ein PIC12F675 für Wandlung von analogen Daten (Spannungswert 0... 
+5V DC). Zum Testen werden die Spannungswerte über eine Drehpoti 
eingegeben.

a) Dies entspricht auch dem Signal das anschliessend gemessen werden 
soll, somit sind Wandlungszeiten, Genauigkeiten und Korrekturen bekannt. 
Erfahrugnen und Tipps willkommen...

b)Spannungsstabilisierung (möglichst genauer Vref-Wert) wird dann WIE 
gemacht? (Besser als mit einem 7805 möglich?)

(2) Eine Möglichkeit die gewandelten Daten (Zahlenwerte) über 
2-Leitung-Datenleitung an einen anderen PIC (16F627 oä) zu übermitteln.
Hier bin ich leider völlig ahnungslos (da dies NICHT mein Fachgebeit 
ist) und hoffe hier auf Tipps und Hinweise.


(3) Code in ASM oder Tipps / Mitarbeit:

a)Datentransporte  Protokolle  Speicherung in exteren EEPROM,...
b)Vermeiden von Fehlern (Kennlinienkorrekturen mit look-up-table, oä),

Wer hat zB eine Temperaturerfassung mit dem 12F675 implementiert und 
könnte mir CODE schenken... ?

(4) Ich bin wohnhaft in Dresden.
Ich suche Mitarbeiter  Mitbastler  Freiwillige(n) im Bereich 
Elektronik für Schaltungsentwurf / -aufbau möglichst aus Dresden.
Durch ein Treffen können meine Ideen und Zeichnungen und Skizzen sicher 
in einem persönlichen Gespräch deutlich besser übermittelt werden.


Wer hat Lust mir dabei zu helfen?
Wer könnte sich vorstellen mit CODE und Erfahrung mich zu unterstützen?


Vielen Dank im Voraus.

Xor WF


{ Bitte bitte bitte nur dem "Thread"-relavante Information posten! Dies 
würde auch ANDEREN Lesern helfen! }

Autor: Carsten Pietsch (papa_of_t)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was soll denn später mal daraus werden? Temperaturdatenlogger? Wenn's 
nicht gerade ein PIC sein muß - bei vielen AVRs hast Du EPROM schon 
intern, und mußt nicht unbedingt in Assembler programmieren.. (will Dich 
aber nicht hindern :-)

Autor: Schoaschi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Eine Frage stellt sich mir da. Warum 2 PICs verwenden? Ich würde eher 
einen externen ADC nehmen und den mit einem PIC ansprechen.

Warum? Weil du dir es erstparst, 2 Programm für deine PICs zu 
Programmieren und ein externe ADC wohl etwas besser sein wird als der 
interne eines PIC12F. Weiters kannst haben externe ADCs eine höhere 
Auflösung(wenn gewünscht). Die Kommunikation kannst du dann über I2C 
oder SPI machen. Beides sollte kein Problem sein.

Als 2. PIC oder als "Master" würde ich einen PIC18F empfehlen.
Gründe:
+ Schneller und mehr Rechenleistung sowie mehr Speicher
+ Mehr Auswahl an Schnittstellen(SPI,UART,I2C,USB)
+ C-tauglich (Es gibt einen Gratis compiler dafür)
+ Bei ASM ersparst du dir die Bankumschaltung
usw.

Bezüglich der Referenzspannung: Nimm nicht die 5V eines 7805ers ;-) 
Nicht umsonst gibt es eigene Referenzbausteine.

mfg Schoasch

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Schoaschi

>+ Bei ASM ersparst du dir die Bankumschaltung
>usw.

Naja, PIC würde ich nicht nehmen wollen, aber das ist vielleicht etwas 
OT.

>Bezüglich der Referenzspannung: Nimm nicht die 5V eines 7805ers ;-)

Warum? Soooo schlecht sind die gar nicht. Die gibs als +/-4% und +/-2% 
Versionen. Die interne Referenz vom AVR ist auch nicht besser (+/- 
5,4%). Bei geeigneter Messchaltung (Brückenschaltung, ratiometrische 
Messung) hätte es sogar den Vorteil, dass der Fehler der 
Referenzspannung=Versorgungsspannng rausfällt.

MfG
Falk

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin aus der Umgebung von Dresden. Und auch vom Fachgebiet ;-)

Autor: Xor Wf (xorwf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, Danke für die erten Rückmeldungen.

@ papa-of-t:
Bitte, PICs, bitte.

@  Schoaschi:
Warum zwei PICs:
1) Ziel: Ausfallsicherheit. Verschieden Sensoren... Ein Logger mit 
EeProm
2) Ziel: Modularer Aufbau. Plug-n-Play-Idee wurde erhofft...
zB:
Heute wird Temperatur gemessen (dann ein 0-100Grad-ADC-Pic) an den 
LoggerPIC.
Und morgen wird eine Distanz (oder ein anderes analoges Signal) erfasst 
und auch an den LoggerPIC gehängt...


ADC-Auflösung:
Anfangs geht es noch mit 10 bit ohne weiters...


Datenübertragung /Protokol:
Ich habe Vor eine maximal 20m lange 4-adrige Leitung änlich Telefonkabel 
zu verwenden.
Belegung: Spannung = 12VDC, Gnd, TX, RX.

Daraus erfolgt auch das jeder PIC sich am LoggerPIC per "Name" anreden 
lässt.. Kennung, Bussytem, CAN, ... ?


LoggerPIC:
OK, ich nehme den 18Fxxx, wenn du meinst.
a) Ich träume ja von Speicherung auf SD-RAM oder USB-Stick.
Wäre herrlich wenn ein Pic direkt darauf meine Werte Schreiben könnte. 
WER hat sowas schon hingekriegt? Welcher Aufwand / Welche Kosten ?
b) Könnte der 18Fxxx auch Daten an ein  ähnlich wie ein  als ein MODEM 
senden ?


@ Falk:
Mach mir doch bitte mal einen Vorschlag für eine 12VDC -> 5VDC 
Spannungsquelle / link zu einem Datenblatt... ?

Autor: Schoaschi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Erklär dein Projekt einmal etwas genauer. Durch die Tatsache, dass du 
das ganze etwa über eine Distanz von 20m verteilt aufbauen willst, sind 
SPI und I2C schon mal hinfällig. Da würde sich eventuell die 4-20mA- 
Schnittstelle anbieten.

Loggen die PICs beim Sensor selbst auch mit und übergeben dann immer 
alles an den Haupt-PIC?

Als Referenzspannungsquelle würde ich eventuell eine 
4.096V-Referenzspannungsquelle verwenden. Vorausgesetz der benötigte Pin 
ist noch frei und der Spannungsbereich ist ausreichend.

Auf SD-Ram Speichern?! Du meinst wos SD-Karte oder? USB-Stick kannst du 
dir eher abschmincken. Denn da musst du ja einen USB-Host 
programmieren... und das wird wohl nicht so einfach sein.

Die Ansteuerung einer SD-Karte solle aber nicht all zu schwierig sein. 
Hier auf der Seite wurde dieses Thema schon des öfteren durchgenommen 
und auf der Fernando Heitor Seite gibts ja auch ein paar Threads 
darüber.

mfg Schoasch

Autor: Xor Wf (xorwf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Schoaschi /  @ alle Leser:

Stelle Dir mal folgendes Szenario vor:

An einer "Telefonbuchse" wird ein "Temp-0-100Grad-"-Sensor 
angeschlossen. Dann geht am anderen Ende das Datenloggen weiter wie 
vorher, nur wird nun in den Speicher anstelle von 
"Sensor-002-Nicht-Vorhanden" nun "Sensor-002-375" gespeichert. Und das 
geht (also das die Werte auf die SD-Speicherkarte geschrieben werden) 
automatisch.
Und dann habe ich genug gemessen, und ziehe den Sensor-Baustein ab. Nun 
will ich vielleicht mal Blutdruck messen, stecke also den nächsten 
Sensor dran. Nun wird anstelle von "Sensor-017-Nicht-Vorhanden" ein 
"Sensor-017-12070" gespeichert.

...und so weiter...

Und wenn in einem Jahr die SD-Karte voll ist, dann fängts von vorn an 
oder was auch immer... Es geht um die Aufzeichnung von Daten durch 
"intelligente" Sensoren, die sich "Anmelden" und "Erkannt" werden 
können. Dass ich dem "Cheffe"-Baustein (also, dem Datenlogger- und 
Kommunikationsbaustein) die "clients" vorher anmelde ist klar.

Dann gilt dass
Sensor-001-Zimmernummer,
Sensor-002-Temperatur,
...
...
Sensor-017-Blutdruck,

im Program werden diese dann entw. als belegte (Rückmeldung durch 
Verbindung) Daten oder "Sensor-???-Nicht-Vorhanden" durch eine 
Subroutine angesprochen.

In etwa in der Art. Habe dieses Beispiel frei erfunden und hoffe die 
IDEE wird einigermassen klar.


Ich glaube ich bin im ersten Posting zu technisch vorgegangen... 
vielleicht hilft diese "Umschreibung" der Verständlichkeit.



Gut.

Bleibt offen:
1)"Sensor"
Kann ein 12F675 soweit "intelligent" gemacht werden, dass der sich bei 
anstecken am System zu erkennen gibt, wartet bis er gefragt wird, dann 
sein ADC-Wert den er dann schonmal zwischenzeitlich ermittelt hat, dem 
Hauptrechner-Pic meldet und wieder Schlafen / Wandeln geht...

2)"Datentransport"
Kann mit wenig Aufwand an Technik ein Datenübertragung von bis zu 20 m 
durch ein Teleonkabel oä gebastelt werden?

3)Datenlogger---->SD-Karte
ok, hier bieten sich andere Webseiten an, haben auch recht ausführlich 
darüber berichtet... Nun ist nunmal so dass ich mich nicht damit 
auskenne. Ich denke das mir DA jemand helfen sollte....



Müsste das Projekt als Ganzes sehen, könnte es aber auch in kleinere 
Baugruppe aufteilen... Wer mir hier was helfen kann  mitmachen möchte  
schon was fertiges hat, könnte sich nun melden...


@ Matthias:
Du bist aus DD? Super. Also: ich mache mal ein paar Schemas fertig und 
lade die hier hoch. Dann könne alle anderen und auch DU mal reinschauen 
und "Gegensteuern" oder Rückmeldung machen.
Nochmals: Ich habe kaum bis gar keine Ahnung von E-Technik... Nehmt mir 
Unbekanntes nicht übel...


Danke.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Xor Wf wrote:

> Bitte, PICs, bitte.

Woher kommt denn dieser PIC-Wahn ?
Bist Du im PIC Proggen der absolute Super-Guru ?

Ich fasse ja PICs nur mit ner Kneifzange an und drücke dann kräftig zu, 
bis sie zerplatzen.


Bevor Du Dich in Einzelheiten verzettelst, kläre erstmal 
grundsätzliches.

Welche Datenrate ist denn überhaupt notwendig, z.B. 16Bit/10s.

Davon hängt dann ab, welche Übertragung und wie groß das Speichermedium 
sein soll.

Art der Stromversorgung (Batterie oder Netz).

Solle Daten nur aufgenommen, wenn verbunden.


Peter

Autor: Xor Wf (xorwf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ alle hier...

Ich habe soeben (1 Uhr 21 !) mal ein paar Schemas gezeichnet. Schlicht 
aber einfach... Sind als PDF da... Hierüber bitte meckern und 
rückmelden...


@  Peter Dannegger (peda)
Pic mit Kneifzange? Nich wenn man wirklich was vor hat.

Super-Guru? Nein, leider nicht. Sonst wäre auch eine ja so merkwürdige 
Sache nicht hier im Netz angefragt worden.



Zum Projekt:

Datenrate:
Natürlich habe ich mir keine grossen Gedanken über Übertragungsraten und 
so gemacht. Wie auch, wenn mir noch nicht klar ist ob es denn überhaupt 
geht.

Stromversorgung:
hm, ich denke Netz, vorerst.

Datenaufnahme:
ja, ab dann wenn verbunden. ZB könnte man schlecht Temperatur messen 
wenn der Patient gerade im OP ist oder so... aber wenn der wieder da 
ist, dann kanns ja losgehen.
Es werden in etwa alle 30 Sekunden / 1 Minute Werte erfasst. Also bei 10 
Sensoren kommen dann etwa folgende Datenmengen zustande.


Datenmenge:
...weit unter 100 MB pro Jahr (nach meiner Schätzung...)


Danke für eure Antworten und Hilfe soweit.


Autor: Xor Wf (xorwf)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Schemas als PDF !

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Xor Wf

>Warum zwei PICs:
>1) Ziel: Ausfallsicherheit. Verschieden Sensoren... Ein Logger mit
>EeProm
>2) Ziel: Modularer Aufbau. Plug-n-Play-Idee wurde erhofft...

>Datenübertragung /Protokol:
>Ich habe Vor eine maximal 20m lange 4-adrige Leitung änlich Telefonkabel
>zu verwenden.
>Belegung: Spannung = 12VDC, Gnd, TX, RX.

Du brauchst ein Bussystem. Im einfachsten Fall reicht RS485 + einfaches 
selbstgestricktes UART Protokoll. CAN kann auch gehen ;-)

>b) Könnte der 18Fxxx auch Daten an ein  ähnlich wie ein  als ein MODEM
>senden ?

Sicher, alles "nur" eine Frage der Programmierung.

>Mach mir doch bitte mal einen Vorschlag für eine 12VDC -> 5VDC
>Spannungsquelle / link zu einem Datenblatt... ?

Kommt auf den benötigten Strom sowie Randbedingungen an. Wenns nur eine 
Handvoll mA sind würde ich einfach nen 78L05 nehmen und gut.

MFG
Falk

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Xor Wf wrote:

> Super-Guru? Nein, leider nicht. Sonst wäre auch eine ja so merkwürdige
> Sache nicht hier im Netz angefragt worden.

Und warum dann die Beschränkung auf PIC ?

Es gibt doch viele schönere und einfacher programmierbare MCs.


> Es werden in etwa alle 30 Sekunden / 1 Minute Werte erfasst. Also bei 10
> Sensoren kommen dann etwa folgende Datenmengen zustande.

Alle Minute ein 16Bit-Wert is ja kein Akt, das kriegste noch dicke in 
nem EEPROM unter.

Sollen denn nun mehrere gleichzeitg oder immer nur ein Sensor gemessen 
werden.


Peter

Autor: Xor Wf (xorwf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Falk:
Ok, dann muss die Datenübertragung über RS485 gemacht werden. Ich werde 
das so annehmen und nun Informationssammlung gehen und versuche zu 
verstehen wie das gemacht wird, was ich brauche, Bausteine, Schaltbilder 
und so suchen...
Aber kurz vorweg gefragt: Schemas angesehn? Also geht das 
RS485-Protokoll und Netz mit 4-adrigem Kabel (Sicherheitskabel) ?


@ Peter:
JA, die Daten werden fortlaufend gemessen und geloggt (vom Haupt-Pic). 
Es könnte sein das ich ganz viele "AAAAAAA"-Hex-Werte habe, weil ein 
Senor nicht da ist (und hex-AAAA geschrieben wird) oder das eben Werte 
eingeschrieben werden (wenn Sensor-Pic angeklemmt wurde).

Wenn nun ein Sensor-Pic angeklemmt wird, macht der sich zuerst bekannt 
und wenn er der zweite gleiche Sensorbaustein am Bus ist wird eben 
zurückgemeldet das die rote LED zu blinken hat, also Problem!
Fall ok, dann loggt der (für sich allein) das analoge Signal. Also keine 
grosse Sache. Dann wird er abgefragt und sendet das was er vorher 
gewandelt und geloggt hat. Dann ist für bis zur nächsten Abfrage "Sleep" 
angesagt. So in etwa...



Von den Daten her ist das nicht so viel, also im schlimmsten Fall etwa 
so.
Annahmen:
a) alle Sensor-Bausteine haben einen ADC aktiviert.
b) 10 Senorbausteine hängen am Bus.
c) alle 30 Sekunden ein Wert aufnehmen.

Daten im EEPROM: [Zeitwert] [sensor-1 --- adc-wert]  .... [sensor-10 --- 
adc-wert]


Zeitwert:
365 Tage/a  24 std  60 Min * 2 = ~ 1 mio Werte
=> 2^20 ~ 1 mio => 20 bit für Zeitwert

Sensorkennung:
10 stück => 4 bit reicht!

10 bit ADC-Wert:
10 bit plus (?) extras 6 bit

Ergibt: 20 + 10 *( 4 + 10 + 6) = 220 bit pro Datenerfassung.

also 395 x 10^6 Bit / Jahr, was sicher mit 128 MByte Speicher gehen 
sollte...


Sind die Schemas übersichtlich genug?


Danke Euch.


Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nun, das erste Bild in deinem PDF ist OK. Der Rest ist zu zeitig!

Zuerst muss man sich Gedanken über die notwendigen Funktionen machen:
-Welche Datenmengen sind zu übertragen? Wieviel, wie oft...
-Welche Spannungsversorgung steht zur Verfügung..
-Wie erfolgt die "Adressierung" der Module
-Wie erfolgt die Übertragung der Datenmengen..
-Ist Handshake erforderlich...
-Welches Bussystem wird dazu verwendet..
...
(einiges ist sicher beantwortet)


=>läuft auf einen Art Pflichtenheft raus.
Hier sollte lieber etwas mehr Zeit eingeplant werden, weil alles was 
jetzt vergessen wird, das ist später nicht (sehr schwer) 
implementierbar..

Habe mit jemand etwas Ähnliches an Laufen, da ist schon ne Weile 
Planungsphase vergangen-Bis ich das erste BE rausgesucht habe

PS: Realisieren von Bussystem ist nicht so einfach wie es klingt: 
"Anstecken-fertig"

Gruß

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach übrigens:
Ich hab zwar nicht ganz Peters Einstellung zu den PICs
(..Ich fasse ja PICs nur mit ner Kneifzange an und drücke dann kräftig 
zu,
bis sie zerplatzen....)
aber ich bevorzuge auch AVR's..

Falls Interesse an einer gemeinsamen Realisierung besteht, dann sollte 
man sich mal treffen. Sowas über Foren zu diskutieren ist recht mühsam..
Und ICQ ist auch nur bedingt geeignet...

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Xor Wf

>Ok, dann muss die Datenübertragung über RS485 gemacht werden. Ich werde

Muss nicht, es bietet sich aber sehr an.

>das so annehmen und nun Informationssammlung gehen und versuche zu
>verstehen wie das gemacht wird, was ich brauche, Bausteine, Schaltbilder
>und so suchen...

http://www.maxim-ic.com/appnotes10.cfm/ac_pk/14#30

>Aber kurz vorweg gefragt: Schemas angesehn? Also geht das

Ja.

>RS485-Protokoll und Netz mit 4-adrigem Kabel (Sicherheitskabel) ?

Ja. Aber da hab ich was gesehen wie Blutdruck, Patientennummer. Dir ist 
hoffentlich klar, dass im medizinischen Umfeld massive 
Sicherheitsanforderungen bestehen? Von rechtlichen Dingen und 
Zertifizierung mal ganz zu schweigen.

MfG
Falk




Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na wenn da 10 Sensoren gleichzeitig quatschen sollen, würd ich CAN 
nehmen, da hast Du den ganzen Protokoll-Ärger schon vom Hals.

Z.B. der AT89C51CC02 (SO-24) ist sehr gut geeignet.
Den kannst Du dann auch gleich über den CAN-Bus flashen (interner 
CAN-Bootloader).


Ich würd dann auch nen Maxim 1wire-Seriennummerchip draufsetzen, dann 
hat jeder seine weltweit einmalige Nummer und ne Kollision ist 
ausgeschlossen.

Bzw. für Temperatur gleich nen DS18B20 und Du hast Seriennummer + 
Temperatur ohne den Umweg über Analog.


Peter

Autor: Xor Wf (xorwf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Matthias

Bus:
Wenn du meinst das das mit "anstecken - Fertig !" nicht geht, dann frage 
ich mich warum es denn doch geht... PNP war ein Sprung in der Geschichte 
von win311 nach win95... und was ich hier vor habe (mit den begrenzten 
Bausteinen, die vorher deklariert werden !) ist noch eine Generation und 
10 Stufen leichter (denke ich). Also, ich bin mir recht sicher das das 
geht! Ausserdem kam bei meinem Orakel (andere nennen es göögle) raus, 
dass die unsere Weltpolizei (oder wie die sich eben nun nennen...) sowas 
auch schon mit pics gemacht haben, wobei die eher an andere Ziele für 
den Einstatz gedachte haben werden... komisch wo das orakel einen 
hinführen kann...


Bin nun aber schon dabei was einfaches auch per "selber gestrickt" 
machen... Für ein paar bits an Daten kann man das ja mal machen...
Sobald ich da was hingekriegt habe poste das mal.
Das Zustansdiagramm ist schon erstellt und (finde ich) ist recht 
"clever" für eine 3-adrige Datenleitung ! 2 war mir zu kompliziert, da 
ich keine Ahnung von der Materie habe....

2^2 sind 4 Zustände... zu wenig !

2^3 sind 8 Zustande. Also kommen vor:
Bus-Open, Master-Call, Slave-Call, Error-Sign, High-Signal, Low-Signal, 
Acknowledge und Read-Data. Hat RS232 denn mehr? Ist für ein Modem noch 
mehr nötig?...

Damit sind auch asynchrone (oder wie heisst das wenn Master und Slave 
nich die gleiche interne / exteren OSC-Werte haben und Daten senden) 
Datenübertragung möglich. Die Daten (eines lahmen slaves) bestimmen die 
Geschwindigkeit, und der Master kann damit umgehenn (weil nach meinem 
Schema nun eine Leitung auch als CLK-Signal genutzt werden kann.. ). 
Sobald ich soweit bin male ich wieder ein Schema und Code, ist glaube 
ich, besser zu verstehen.

Dresden:
Wenn du aus DD bist, dann ist das super-ok. Und wenn du was mit Pic und 
dem hier schon recht ausführlich besprochenen Projekt noch was zu tun 
haben willst (also wenn es dir nicht als "dumm" oder "umöglich" 
erscheint) dann könnten wir uns ja mal treffen. Ist ja bald Wochenende. 
Ich lasse mal meinen email hier aufleuchten, kannst ja mal hinmailn....

blink
     xorwf ät freenet punkt de
blank



@ Falk:
Beispiel:
Das mit den Patienten und so sind "Beispiele" damit ich eine "modulare 
Datenerfassung" irgendwie als Idee aus meinem Kopf in diese Forum 
kriegen kann... Hätte auch eine Wetterstation oder eine Modellbahn 
wählen können...

RS485:
Habe nachgeschaut, und klingt gut.



@ peter:

CAN:
Ja, habe ich auch drüber nachgeacht... habe mich aber entschieden (wenn 
es nicht klappt dürft ihr mich als "dumm und unbelehrbar" bezeichnen) 
alles auf PIC-basis und per Protokoll zu schaffen. DAS MUSS irgendwie 
gehen...

Seriennr:
GENAU das könnte ein 12F629 / 12F675 oder sogar nohc "kleinere" PIC 
hinkriegen... haben ja genug ROM um sich ihren "eigenen Namen" zu 
merken... DAHER pics...

TempBaustein:
Ich informiere mich und werde darüber nachdenken. Danke für deinen Tipp.




Ich denke ausserdem dass dieser Thread nun sehr lang(wierig) wird und 
viele den Faden verlieren könnten. Ich werde im laufe des Wochenendes 
mal alles Zusammefassen und als PDF hier hochladen. Geht dann als 
"unfinished business".

Danke für eure Geduld und Mühe.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Xor Wf wrote:

> CAN:
> Ja, habe ich auch drüber nachgeacht... habe mich aber entschieden (wenn
> es nicht klappt dürft ihr mich als "dumm und unbelehrbar" bezeichnen)

Ich hatte nur den Eindruck, daß Du bisher noch nichts mit Protokollen 
gemacht hast und wollte Dir nur einige Mannjahre an Protokollentwicklung 
und Fehlersuche ersparen.

Gerade Anfänger unterschätzen das total. Ich hab sowas mal mit I2C 
gemacht und auch total unterschätzt (über das 10-fache der 
veranschlagten Zeit gebraucht).
Und auch noch hot-plugging, na dann viel Glück.


> alles auf PIC-basis und per Protokoll zu schaffen. DAS MUSS irgendwie
> gehen...

Vergiß da mal den PIC, ein Protokoll muß man von der Hardware 
abstrahieren und in C schreiben.
D.h. Du hast die Hardware, die nur die Bits und Bytes schaufelt und dann 
das Protokoll als extra Softwareschicht.
Wenn Du alles miteinander vermanscht, siehst Du hinterher nicht mehr 
durch (und erst recht kein anderer).


> Seriennr:

Der Seriennummernchip erspart Dir, selber jedem Gerät ne eigene Nummer 
vergeben zu müssen, das macht schon der Hersteller (weltweit einmalige 
48Bit).
Die Dinger sehen aus, wie ein 0603 SMD-Widerstand.


> GENAU das könnte ein 12F629 / 12F675 oder sogar nohc "kleinere" PIC
> hinkriegen... haben ja genug ROM um sich ihren "eigenen Namen" zu
> merken... DAHER pics...

Also ROM benutze ich schon seit 1995 nicht mehr, sondern Flash.
Und da wüßte ich nicht, daß die PICs besonders viel davon hätten.
So ein 8-Pinner AVR hat ja schon 8kB, das reicht dicke.
Flash ist heutzutage nicht mehr der limitierende Faktor.


Peter

Autor: Xor Wf (xorwf)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute!

Also, ich habe mal zusammengefasst was nun bis nun geht / nicht geht.
Siehe angehängte pdf-datei. Gelb = geht.

Die (gewünschte) Funktion kurz erklärt:

pic 12 F 675 , gp2 als analog-in, gp4 hat eine led, gp5 hat einen 
Taster.

Spannung ran
confix
(main)
wenn sw1 gedrückt wurde, den (neuen) AD-Wert holen (adc-Schleife)
den (neuen) AD-Wert als Ton (soundy-Schleife) ausgeben
(zurück nach main)


Hierzu wurde code (adc1d.asm) angehängt.

a) Wenn ich die "incf datx,f"-Stelle in main nicht auskommentiere, aber 
die "call adc" stelle auskommentiere, macht der pic einen Tonanstieg 
(per Lautsprcher überwacht) sobald ich sw1 drücke... als 
adresh-Simulation... )
Folglich geht die soundy-Schleife. Also könnte jeder adresh-Wert über 
datx-Wert als Ton erkannt werden.
Könnt ihr somit auch testen...

Nun die Frage zum ADC:
b) Ich hoffe das die Initialisierungen am Anfang ok sind. Alle microchip 
und spruts und sonstige Foren sind abgegrast, und dennoch geht es 
nicht...


c) Wo liegt der Fehler in der ADC-Schleife?
(i) In der Initialisierung?
(ii) Ist die "time for aqu" nicht lang genug?
(iii) Ist die "fertig"-Erkennung nicht richtig? beide Möglichkeiten 
(über "adif" oder über "done" scheitern... warum???
(iv) wie sollte die sache denn anders gemacht werden?


Wer könnte mir hier Tipps geben? Codeschnipsel mit funktionierender 
ADC-Schleife?

Danke für die Mühe.

xorwf


Autor: Xor Wf (xorwf)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
....nun noch die pdf-Datei mit dem vereinfachten Schema der Idee....

Autor: Severino R. (severino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt (eher: gab) von Microchip ein "PICkit 1 Flash Starter Kit", das 
mit einem PIC12F675 bestückt ist.
Dazu gibt es auch Beispielprogramme.
Unter
http://www.microchip.com/stellent/idcplg?IdcServic...
kannst Du die "PICkit™ 1 All Lessons" herunterladen.
Darin befindet sich ein Assembler-Programm atod.asm, welches die 
Verwendung des AD-Wandlers erklärt. Möglicherweise wird der AD-Wandler 
auch noch in anderen Beispielen verwendet.

Severino

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.