Hallo,

Eerst en vooral aan allen een gelukkig 2009.

Ik heb mij de telefoonprint van Picbasic in elkaar gesoldeerd, maar nu zit ik met volgend probleem.

Tijdens de test werkt alles goed, totdat ik de MT8870 (DTMF Decoder) insteek.

Van zodra die inzit werkt alles nog maar kan in niet meer programmeren (Bumblebee).

Ik moet er telkens de MT8870 uithalen, programmeren en terug inplaatsen.

Na 3x mijn soldeerwerk te controleren klopt mijn schema(ofwel kijk ik telkens over de fout).

Wat zou mijn fout kunnen zijn, of is dit normaal??

Dank

De data outputs van de 8870 zitten aan de RB6/7 lijnen van de PIC. Dat geeft ellende.
Je hoeft trouwens toch maar 1x te programmeren?

JE kunt de uitgangen van je PIC naar de DTMF decoder volgens mij wel voorzien van 10K weerstanden.

Pin me er niet op vast, maar zo heb ik ook sommige communicatielijnen "ontkoppeld" om invloeden van -in jouw geval de DTMF decoder- te voorkomen.

Op 3 januari 2009 23:17:47 schreef Arco:
De data outputs van de 8870 zitten aan de RB6/7 lijnen van de PIC.

Dit is hoogstwaarschijnlijk de oorzaak.
Vreemd dat me dat hier tijdens ontwerp en proto-type nooit is opgevallen (het signaal van de Galva-Wisp is bij mij blijkbaar sterker dan de MT8870), ik kan namelijk wél in circuit programmeren.
Ik heb daarvoor zelfs een voorziening op de telefoonprint zodat de 13V programmeerspanning de MT8870 niet kan beschadigen.

Als het ICSP helemaal niet wil lukken, kun je, zoals Fantomaz al schreef, een weerstand plaatsen tussen pin 12 van de MT8870 en PIC, en een weerstand tussen pin 13 van de MT8870 en PIC.
Weerstandswaarde 10k zal wel lukken maar ik denk dat 1k een betere waarde is.

Als ik tijd heb vandaag, zal ik hier nog eens de telefoonprint programmeren.

Ik heb nog eens even de PIC in de universele telefoonprint herprogrammeert.
Geen probleem zonder weerstanden.
Waar je wél op moet letten (en dat staat ook in het artikel) is dat je ná het programmeren de verbinding tussen PIC programmer en telefoonprint weer loshaalt (bijv. programmeer DIL-clip verwijderen), anders reageert de telefoonprint niet goed op binnenkomende nummers (de PIC programmer verminkt dan de DTMF code die uit de MT8870 komt).

Ik heb een weerstand van 1K tussen bijde banen gesoldeerd en het probleem is opgelost.

Ik ben nu een programmaatje aan het schrijven maar er zit toch ergens een hapering in.
Dit is een deel van mijn programma:

Case 158
Opdracht = 201
GoSub ZendBus
DelayMS 300
Opdracht = 223
GoSub ZendBus
DelayMS 300
Opdracht = 241
GoSub ZendBus
DelayMS 300
Verder1:
While 1 = 1
HSerIn 7, Verder1, [OntvangenData]
DelayMS 300
If OntvangenData = 01 Then
Opdracht = 224
GoSub ZendBus
DelayMS 5000
GoTo Verder2
Else
.....
EndIf
Wend
Verder2:
.....

Alles werkt tot ik aan de "Verder1"-lus begin.
Ik wil dus enkele opdrachten laten uitvoeren en vanaf Verder1 wil ik wachten totdat Opdracht 01 komt om verder te gaan.

Zie ik iets over het hoofd of is dit programmeertaaltje te ver gezocht?

Dank

Ja, dit programma moet in de telefoonprint.

Van zodra "Opdracht 158" binnenkomt zou ik drie opdrachten willen versturen (201, 223 en 241) en daarna blijven wachten tot opdracht 224 binnenkomt.

Is dit wel mogelijk?

Dit is zeker mogelijk, zoiets doe ik zelf ook.
Tip: probeer het eerst eens met de softwarematige variant, de instructie SEROUT/SERIN in plaats van HSEROUT/HSERIN.
Gewoon de poorten opgeven (ik meen PORTB.1 en PORTB.2).

Kijk voor hoe baudrate in te stellen even bij de HELP files van PIC Basic in Proton IDE, het staat in een tabel.
Begin met een lage baudrate (bijv. 1200 Baud).

EDIT:
Ik zie overigens het probleem niet echt.
Zet je code eens neer met lege regels tussen de blokken programmacode die bij elkaar horen.
Nu staat alles aan elkaar.
En plaats de code tussen code tags.

[Bericht gewijzigd door Frits Kieftenbelt op (22%)]

Ik heb nu enkel HSERIN naar SERIN veranderd en nu werkt dit?

Verder in mijn programma staat HSERIN en deze werkt wél.
Hoe komt dit dan dat dit in bovenstaand programmastuk niet werkt?

Ik heb het gehele programma van de site gecopierd en aangepast naar mijn wensen,
dus Baud en poortnamen zullen wel juist zijn.

Ik weet het niet precies meer maar het heeft iets met het inwendige van de PIC16F628A/16F648A te maken.
Bij mij werkte het ook niet en ben er toen wel achter gekomen maar heb het alleen nergens genoteerd en ben het alweer vergeten.
Bekijk het schema van het inwendige van de 16F628A/648A (in de datasheet) en dan kun je ontdekken waarom het niet (altijd) hardwarematig kan in combinatie met de telefoonprint.

Als je het per sé hardwarematig wil doen dan is daar wel een foefje voor door iets in de 16F628A/648A te togglen, maar dan moet ik eerst bekijken wat dat ook alweer was.

Als je het met de softwarematige variant (SERIN/SEROUT) ook redt zou ik het zo laten...