Hallo,
nun kämpfe ich schon den 4ten Tag mit dem sprut Frequenzzähler, der mir
als halbfertiges Projekt mit Platine zugelaufen ist
https://www.sprut.de/electronic/pic/projekte/frequenz/freq_uni_628.htm
Ich habe mehrmals erfolglos, auf unterschiedlichen, neuen PIC 16F628A
Exexemplaren die auf der Homepage zur Verfügung gestellte HEX Datei
mittels PICkit 3 Clone auf einem 64bit WIN10 Rechner mit dem standalone
PICkit 3 Programmer mit externem Programmieradapter (ZIF-Sockel)
geflasht. Der Brennvorgang läuft ordnungsgemäß und Verify wird
bestätigt.
Allerdings läuft das Programm auf der Platine nicht, erkennbar daran,
dass das zweizeilige Display nur in der ersten Zeile Recktecke zeigt.
Typisch für ein LCD, das NICHT mit einem steuernden Prozessor verbunden
ist; es befindet sich sich im Grundzustand - im 1-zeiligen Mode. Weiters
leuchtet KEINE der 3 LEDs, welche den jeweilig aktiven Eingang
signalisieren.
Es existieren mehrere Erfolgsbericht zum Nachbau im Internet allerdings
auch eine "etwas" ältere Problembeschreibung mit den selben Symptome,
die bei mir auftreten Beitrag "PIC 16F628A Problem (Frequenzzähler von sprut)".
Im ersten Schritt habe ich den Teil der LED Ansteuerung über Taster am
Steckbrett nachgebaut, aber auch hier ohne Erfolg. Kleine eigene,
adäquate Testprogramme in C laufen mit dem beschrieben Setting am
Steckboard problemlos.
Nun wollte ich die ebenfalls vorhanden Assembler Sourcen verwenden,
mußte aber feststellen, dass es sich um MPASM Code handelt der nur bis
MPLABX v5.35 unterstützt wurde. Grundsätzlich besteht die Möglichkeit
MPASM in MPLAB XC8 PIC Assembler umzuwandeln erfordert allerdings
Eingriffe in den Code, welche ich mangels ausreichender Assembler
Erfahrung vermeiden will
https://www.circuitbread.com/tutorials/mpasm-to-mplab-xc8-pic-assembler
Seht ihr eine Möglichkeit den Code doch noch zum Laufen zu bringen?
DANKE
Wolfgang
Wolfgang schrieb:> Seht ihr eine Möglichkeit den Code doch noch zum Laufen zu bringen?
Wenn es für dich eine unüberwindliche Hürde ist, eine Assemblerquelle
von MPASM nach MPLAB XC8 zu portieren, dann eher nicht. BTW: war XC8
nicht C-Compiler? Ich benutze PIC16 schon seit langem, verwende aber
keine Software von Microchip dafür, sondern nur meine eigene.
Nebenbei gesagt: Das Projekt von Sprut stammt ursprünglich aus 2005 und
wurde 2015 modernisiert, soweit es auf der Seite lesen kann. Aber für
2005 und erst recht für 2015 ist das Ganze schon ziemlich altbacken, um
nicht zu sagen, daß da der Kalk aus allen Ritzen rieselt.
Aber was stört dich daran, die PIC's in Assembler zu programmieren? Ich
hab vor etwa 10 Jahren mal einen Taschen-Frequenzzähler mit einem
PIC16F617 gebaut, ist ein Reziprok-Zähler und kommt daher ohne
irgendwelche Umschaltung zwischen Periodenmessung und Normalmessung aus,
schafft locker 7 gültige Stellen (das hängt aber vom Referenzoszillator
ab), kommt in der Praxis bis 100 MHz (deswegen der betreffende PIC) und
paßt in jede Hosentasche. Und die Firmware ist in Assembler geschrieben.
Die hatte ich sogar hier mal gepostet. Suche mal nach "Count100
Quellen.zip". Die Schaltung hat es hier auch mal gegeben, die hieß
"Frequenzzähler.zip"
Gib dir mal etwas Mühe, sowas schaffst du auch.
W.S.
Habe nun für Assembler Sourcen MPASM unter MPLABX v5.35 verwendet, alles
ok durchgelaufen und mit PICkit 3 gebrannt - leider ebenfalls KEIN
Erfolg.
Kann es am Brenner liegen? Habe hier nur noch alten, original PICkit 2,
läuft aber nicht unter WIN 10 :-(
Wolfgang schrieb:> Kann es am Brenner liegen?
Woher soll unsereiner das wissen?
Aber ich hätte da ein paar einschlägige, aber leider nur recht
allgemeine Tips für das Brennen von eingelöteten PIC's auf der Ziel-LP:
- schau nach, ob das Reset-Pin sauber bedient wird (0..VCC für den
Normalfall, so etwa 13 Volt beim Programmieren)
- schau nach, ob der Oszillator so wie gedacht schwingt
- sind die Konfigurationsbits richtig gesetzt?
- schau nach, ob alle Pins des PIC saubere Signale bringen bzw. kriegen
und keine Kurzschlüsse vorhanden sind (in der Ziel-LP)
W.S.
Ich empfehle ein PicKit3 von Ali, einen PIC der vom MCC Codeconfigurator
unterstützt wird und die Microchip Programmierumgebung. Dort kannst ja
auch den bestehenden ASM Code einbinden.
Ein Simulator für Programm gibts auch dazu.
Half mir persönlich gut.
Nachdem ich mich nun mehrere Tage erfolglos auf den PIC konzentriert
habe, habe ich heute die Strategie gewechselt.
Ich habe ALLES in Frage gestellt und nach extensivem messen mit dem
Oszilloskop auch die Kabel getestet. Dabei habe ich festgestellt, dass 3
Anschlüsse des zehnpoligen LCD Steckers defekt sind! Nach Tausch des
Kabels hat der Zähler sofort funktioniert.
Ich habe gelernt, dass meine Hypothese zur Funktionsweise des Programms
falsch war. Ich nahm an, dass es auch läuft wenn das LCD nicht
angeschlossen ist und habe mich nur auf die Eingangsumschaltung als
Testfall konzentriert. Aber offensichtlich liest der Controller auch
Daten aus dem Display und „hängt sich auf“, wenn kein LCD vorhanden ist
– ein zeitintensivere Lernprozess aber ich bin trotzdem froh, dass ich
die Herausforderung lösen konnte.
Noch froherer Ostern
Wolfgang 😊
Wolfgang schrieb:> Aber offensichtlich liest der Controller auch> Daten aus dem Display und „hängt sich auf“, wenn kein LCD vorhanden ist
Ja, gut möglich, ich hab zB. so'n Scheiß programmiert (weil ichs
kann...;). Da wird evtl. das Busy-Bit blockierend abgefragt, dann
hängt das Programm beim schreiben auf das LCD hängen.
Man könnte dann, zB. diese abfrage durch eine simple Pause von 2ms
ersetzen. performantmäßig bringt das kaum nen Einbruch, quasi Null. (mit
etwas mehr Aufwand wirklich ~0)
Wolfgang schrieb:>> Aber offensichtlich liest der Controller auch> Daten aus dem Display und „hängt sich auf“, wenn kein LCD vorhanden ist
Steht auch so im Source Code (Datei lcd.asm)
1
; darauf warten, daß das Display bereit zur Datenannahme ist
Nur als Ergaenzung:
Es gibt noch einen Frequenzzaehler basierend auf den PIC16F628
https://www.qsl.net/dl4yhf/freq_counter/freq_counter.html
Kaufen laesst es sich auch - als Clone
https://www.ebay.de/itm/233061553477?hash=item36438d1545:g:jQcAAOSwa3lcHdBS
=====================================================
Ich habe selbst schon mit asm-Code LCD-Displays angesteuert und am
Anfang vom Didplay zurueckgelesen.Aber mal ehrlich:fuer die meisten
Projekte moechte man einfach Daten ausgeben und den Cursor
positionieren.Dazu braucht man keinen bi-direktionalen Datenverkehr.....
Dieter schrieb:> Steht auch so im Source Code (Datei lcd.asm)> ; darauf warten, daß das Display bereit zur Datenannahme ist> LcdBusy> ...>> Die entsprechende Funktion hat keinen Timeout.
Einen pull-down Widerstand an D7 anschließen löst das Problem.
