Erik
In order to succeed you must fail, so that you know what not to do the next time.
Hallo allemaal,
Ik ben in jal bezig met 1-wire en softwarematige usart op een 16f84a op 4mhz(4mhz omdat de 1-wire lib hardcoded delays in asm heeft).
Nou heb ik voordat ik echt aan dit project ben begonnen eerst met het 1-wire protocol gewerkt om te proberen. Dit ging allemaal prima en ik kon mooi een i-button(ds1990a) uitlezen en deze werd in de eeprom weggeschreven.
Nou heb ik dus een control unit gemaakt waarmee ik usart commando's naar de 16f84a stuur. Dit gaat ook allemaal prima ik krijg mooi data toegezonden en verstuurd van de 16f84a. Echter het probleem ontstaat wanneer ik dus de 16f84a het commando geeft dat hij een ibutton in moet lezen. Hij gaat prima alles uitvoeren maar ik krijg als response FFFFFFFFFFFFFFFF ofterwijl hij leest niks. Als ik daarna weer andere commando's stuur voert hij die prima uit. De code voor het 1-wire gebeuren heb ik gewoon rechtstreeks uit mijn werkende sample gekopieerd(gebruikmakend van de libraries van meneer P. Pemberton) en dit is haast zo simpel dat er weinig tot niets aan kan mankeren. Zou het dus zo kunnen zijn dat de pic het simpelweg niet aankan(software usart en uitlezen van ibutton) en de timings verkeerd gaan?
Ik kan namelijk niet iets anders bedenken waarom het niet zou werken. De commando structuur werkt prima, en als ik het stukje 1-wire code zonder usart gebeuren de ibutton laat inlezen en in het eeprom laat wegschrijven is er niks aan de hand. Ik heb helaas geen scoop dus ik de timings ook niet nameten. Maar daarom mijn vraag KAN het dat de pic hiervoor te traag is en zou het misschien het proberen waard zijn om alle timings te vervangen zodat de micro op 20mhz kan functioneren ?
Groeten Erik
Videomodulator
AKA Naftebakje @Tweakers.net --- Zonder dwarsliggers geen spoor
Waarom gebruik je de hardwarematige USART niet?
En hoe zit dat nu met je commando verzenden en antwoord krijgen, het is me helemaal niet duidelijk wat je daar doet. PC vraagt om ibutton uit te lezen, wat doet de PIC dan?
Gewoon uitlezen en dan zelf een antwoord zenden, of laat je de PC direct na de vraag weer vragen naar het resultaat? Als het het laatste is: vertraging steken tussen de vraag zelf en het vragen naar het antwoord, ff uitproberen hoeveel er nodig is, eventueel pas je nog je programma aan zodat de PIC zelf zegt dat ie klaarstaat voor het volgende commando.
Erik
In order to succeed you must fail, so that you know what not to do the next time.
16f84a heeft geen interne usart maar hij hangt niet aan een pc maar een andere 16f628a.
Aan die 16f628a hangt een lcd met een aantal knoppen. Ik selecteer vanuit een menu bijv het commando, lees een i-button in. de 16f628a stuurt dan het commando: ":a" naar de 16f84a. Door de dubbele punt weet de 16f84a dat ik een functie wil uitvoeren en met de a geef ik aan welk commando. de 16f84a gaat dan naar een if elseif mogelijkheid en voert de code uit die bij het ontvangen commando hoort. Indien bij dat commando een antwoord hoort die teruggestuurd dient te worden blijft de 16f628A net zolang in een loop zitten tot hij het benodigde antwoord krijgt.
Maar als ik nou het commando ":a" stuur dan gaat hij netjes naar het subje toe waar hij naartoe moet gaan en start de inlees procedure. Alleen inplaats van dat de inleesprocedure het goede antwoord geeft geeft hij dezelfde tekens als dat hij geeft wanneer de timings niet in orde zijn. Daarom was mijn eerste idee ook meteen van kan het niet zijn dat die pic het niet aankan.