...ab ins EEPROM-aber wie???

[PICture]

@ schaun

Heutzutage gilt die Gleichung billig=einfach nicht mehr.

Vor mir liegt gerade ein billiger Handsender mit MC68HSR705J1A (HCMOS Microcontroller Unit). Und was er kann, kann man sich nach Kurzschauen ins Datenblatt ziemlich leicht vorstellen.

http://www.datasheetcatalog.com/data...HC705J1A.shtml

@ Shunth

Ich bin selber PIC-Benutzer und habe in meinem laufendem Projekt schon das Problem von einscannen und wiedergeben von beliebigen digitalen Impulssequenzen gelöst. Bloß das ich die Sequenzen in Flash speichere.

Wenn die Frequenz der Impulse fest und bekannt ist, braucht man nur mit einer bestimmter Frequenz einscannen und wiedergeben.

MfG

[Shunth]

Hallo,
@PICture
nun das wäre ja am Ende auch egal ob ins EEPROM oder ins Flash hauptsache irgendwo hin. Die PIC Lösung wäre mir am liebsten weil ich die Programmer u.s.w. da hätte. Lass mich etwas von deinen Wissen - wissen!

@Wkrug
auch eine verwertbare Idee. Die Sendefrequenz kenne ich ja (433) oder meinst du den Kanal? Weiß nicht mit welchen Kanalraster die arbeiten. 250 KHZ??? Wenn du von zwischenspeichern ins RAM redest, von welchen µC sprichst du? AVR? Also erstmal vielen Dank für die Tips und nun bauen wir mal......

MfG

[PICture]

Hallo Shunth!

Ich denke, das das empfangene Signal, das bisher schon die LED steuert, eine richtige Pegel hat und direkt durch ein PIC-Port eingescannt werden kann. Dazu braucht man nur ein Port-Pin.

Die Frequenz der eingescannten Impulsen ist auch wichtig, danach richtet sich die Pause zwischen den Einlesungen ins RAM. Den Inhalt des RAMs wird danach ins EEPROM kopiert.

Da das EEPROM bei PICs nur max. 256 Bytes groß ist, bei längeren Impulsfolgen als 8 x 256 = 2048 wird es nicht reichen. Ich habe Flasch nehmen müssen, weil ich 8 x 1024 gescannte Werte speichere.

Damit ich nicht zu viel darüber schreibe, schau, bitte, in Wiki:

https://www.roboternetz.de/wissen/in.../PIC_Assembler

Alles was noch unklar wäre, versuche ich dir zu erklären. Als beste Methode, hat sich ein Dialog in der Form: Frage-> Antwort erwiesen, weil dann nur das wichtige behandelt wird.

Also mach dir Gedanken über Realisierung und stell, bitte, konkrete Fragen!

MfG

[Shunth]

Hallo,

ja, werde ich machen (lesen!) Das mit den PIC habe ich schon verstanden. Interessant zu wissen wäre ja wie ich den PIC in den Modus bekomme das er an PORTA auf das Signal wartet und dann in diesen Moment auch schreibt. Verstehst du? Bislang habe ich die Programme entwickelt und in den PIC geladen...... (ich sehe mein Verständnis über PIC ist noch sehr ausbaufähig...)
Ach, Assembler????????? lieber C/C++

MfG

[PICture]

Wenn Du C/C++ benutzt, dann kann ich dir nur mit PADs und selbstverständlich mit der Elektronik helfen. Ich finde den PAD als universelle "Programmiersprache" optimal. Danach kann man das in beliebige Programmiersprache wandeln.

Das Einlesen kannst du mit einem externem Interrupt (z.B. INT0) und das Senden z.B mit einer Taste starten. Das Programm ist wirklich nicht kompliziert. Für Programmentwicklung würde ich dir den "PIC Trainer" empfehlen.

MfG

[Shunth]

Oh, Gott. Auch das noch Ich hatte mal neben C Python zu verstehen versucht. Ne, ich schau mir das PAD mal an. Also ich würde sagen, ich krame mal in der PIC Kiste rum... So, ich habe noch paar 16F84 da. Sollte erstmal gehen,oder? Meine Experimentier Platine ist auch Griffbereit. Fangen wir mal an.....kurze Skizze der Schaltung@PICture? Ich verspreche dir mir selbst auch Gedanken zu machen. Also eine Grundidee zum Einlesen mit Schalter. (den Schalter könnte ich dann mit den Transistor koppeln da der ja die jetzige LED steuert. Aber der schaltet Masse hoch. Hm, gut kann man den PIC ja am Port sagen, oder was denkst du??

MfG

[PICture]

Ja, der PIC 16F84 sollte sicher für das kleine Programm und die einfache Hardware reichen.

Es muss noch ein Kriterium festgelegt werden, wann das Einscannen beendet werden soll oder werden immer 8 x 64 = 512 scan gespeichert. Ob die übrige 4 RAM Speicherstellen fürs Programm reichen, muß man prüfen.

Laut meiner erster Schätzung werden nur 3 Portpins benötigt, davon nur INT ist durch Hersteller des PICs festgelegt und die zwei andere können frei gewählt werden.

Im Code habe ich meine Vorstellung skizziert. Die Software wird leider nicht so trivial sein.

Übrigens, das Thema eignet sich besser fürs "PIC Controller" Forum.

MfG

                          INT 6.-----.
     vom Empfänger >-----------|     |
                              ?|     |
     zum Sender    <-----------|PIC  |
                      _/      ?|16F84|
     Taste         -o/  o------|     |
                               '-----'

              Start (INT)

              |
              V
               _   ___     _
              | |_|   |___| |_

         Scan _|_|_|_|_|_|_|_|

     Register  1 0 1 1 0 0 1 0

[wkrug]

@Shunth
Meine Angaben bezogen sich auf einen ATMEL AVR Controller - sollte natürlich auch mit PIC möglich sein.
Wegen des RAM Speichers würd ich zu einem ATMEGA 32 tendieren, obwohl der ansonsten natürlich völlig überdimensioniert ist.

Ich weiß jetzt nicht welches HF Teil du benutzt. Wenn es einen Squelch oder RSSI Ausgang hat könnte man den zum Starten bzw. Stoppen der Aufzeichnung verwenden. Das kann man durch Pollen oder per Interrupt machen.
Eventuell wäre es sinnvoll die 5 oder 10 Impulse vor dem Ansprechen des Squelch Ausgangs auch mit aufzuzeichnen, damit man wirklich alle Impulse kriegt.
Also ständig in einen Ringpuffer aufzeichen, wenn ein Start Signal kommt den aktuellen Pufferzähler - 10 als Startzeiger verwenden.

[Shunth]

Hallo,

Danke für eure Mühen mit meinen "Projekt" Ich denke den Versuch mit einen PIC zu probieren, da ich dafür alles da habe. (Testplatine, Brenner, PIC u.s.w.) Atmel liegt mir schon lange am Herzen nur dafür ist der Aufwand etwas "übertrieben" aber interessant zugleich. Danke,@wkrug. (es sei denn das Projekt läuft mit ner Fun-Karte da hätte ich auch alles da)
Also mein Empfänger ist nix besonderes. Ist etwas umgebaut aus einer alten Funkklingel. Habe die Antenne und die Anpassung etwas geändert. Erstaunlicherweise zeigt er eben(optisch mit einer LED) immer an wenn mein Nachbar sein Tor öffnet. Sicher ist irgendwie eben abgestimmt und würde bestimmt auch leuchten wenn ein anderer mit der Frequenz sendet. (bisher vielleicht Glück gehabt)
@PICture
jetzt weiß ich was du mit PAD meinst. Ja sicher in C stricke ich das dann irgendwie. Also testen wir das mal mit den 16F84. Mit der Zeit, ja ich weiß auch nicht so recht wie man das Fenster setzen sollte. Du hast schon Recht, irgendwann muß ja gestoppt werden......
MfG

[PICture]

Am einfachsten wäre immer den ganzen RAM zu beschreiben, vor allem wenn die Länge des gesendeten Codes nicht immer gleich ist.

Es muss auch ermittelt werden welche Modulation benutzt wird. Hoffentlich die einfachste, also 100% AM.

Sehr vorteilhaft wäre, wenn du den Code z.B. auf einem Display siehst, dann kann man die Scanfrequenz varieren und anpassen. Es geht auch mit Matrix LCD, wenn man eigene Zeichen programmiert. Durch ändern der Startadresse (Verschieben) lässt sich dann das ganze RAM anschauen. Und damit würde ich anfangen, sonst tappst du in dunklem.

Wenn du einen gleichen Sender wie dein Nachbar hast, brauchst du bei Erstellung des Programms nicht warten bis er was sendet. Du kannst dann am Ende auch das ganze bei dir ausprobieren.

Es wäre natürlich super, wenn du die Frequenz der Impulse schon kennst, da die Scanfrequenz genau doppelt und sehr stabil seien muss.

MfG