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! }
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 :-)
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
@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
Ich bin aus der Umgebung von Dresden. Und auch vom Fachgebiet ;-)
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... ?
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
@ 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.
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
@ 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.
@ 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
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
@ 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.
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ß
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...
@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
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
@ 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.
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
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
....nun noch die pdf-Datei mit dem vereinfachten Schema der Idee....
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?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010053 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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.