Mijn eerste pic progje

Ik zal er als ik tijd voor heb ff naar kijken. Maar ik garandeer je niks aangezien ik me er helemaal in moet gaan verdiepen om te kijken of het klopt.

Zelfs al zou het programma werken, bouw het best eerst effe op een breadboard. Er zullen steeds aanpassingen nodig zijn aan de hard- en/of soft-ware. Indien je een schema kan opbouwen van nul zonder 1 fout te maken, ga je nog veel geld kunnen verdienen.

Daar zegt sven idd iets heel belangrijks. Ikzelf zit ook heel vaak nog mijn programma's tig keer aan te passen omdat ik iets over het hoofd had gezien. (ondanks dat dat laatste niet vaak gebeurt )

mag ik even een offtopic vraagje stellen? Wat is in vredesnaam het verschil tussen CALL en GOTO??

Op do 24-10-2002 23:21:46 schreef sven:
Zelfs al zou het programma werken, bouw het best eerst effe op een breadboard. Er zullen steeds aanpassingen nodig zijn aan de hard- en/of soft-ware. Indien je een schema kan opbouwen van nul zonder 1 fout te maken, ga je nog veel geld kunnen verdienen.

met de hardware zit ik niet zo in. dat is niet meer zo nieuw allemaal voor mij. Ik studeer nu al mijn 3de jaar elektronica. Het software deel, dat is wat anders. dat is wel nieuwer. Maar ik snap het principe. dat programmatje dat ik gemaakt heb, het zal niet optimaal zijn, en misschien kan het veel eenvoudiger.
Ik zal het proberen op een breadboard. maar dan zal ik eerst nog wat extra componenten nodig hebben. En dat zal maar voor volgdende week zijn. want ik ga voor een groot weekje op vakantie

Op vr 25-10-2002 00:02:11 schreef Bastiaan:
Daar zegt sven idd iets heel belangrijks. Ikzelf zit ook heel vaak nog mijn programma's tig keer aan te passen omdat ik iets over het hoofd had gezien. (ondanks dat dat laatste niet vaak gebeurt )

zolang ik het praktisch niet kan uittesten, kan ik geen fouten ontdeken om ze dan eruit te kunne halen. daarom dat ik dit hier even vraag. Als jullie zeggen dat het nooit zal werken dit programmatje, dan heeft het geen zin dat ik verder er aan werk. Ik wil gewoon weten of ik op goede weg ben of net niet.

alvast bedankt voor de moeite

[Bericht gewijzigd door sille op vrijdag 25 oktober 2002 13:09:00 ]

Op vr 25-10-2002 12:49:57 schreef Bernd:
mag ik even een offtopic vraagje stellen? Wat is in vredesnaam het verschil tussen CALL en GOTO??

Met GOTO laat je de controller springen naar een bepaald regel.

Met CALL laat je de controller springen naar een bepaalde regel en tegelijk slaat die in zijn geheugen (stack) op waar die vandaan kwam. Dus met een CALL kun je weer teruggaan naar waar je vandaan kwam, omdat die dat heeft onthouden. Met GOTO kan dat niet.

Waarom gebruik je dan niet altijd CALL zou je je misschien afvragen. Nou dat komt omdat de controller maar een 7 level diepe stack heeft. Oftwel hij kan maar tot 7 niveau's diep het terugkeeradres onthouden. Als je het dus niet nodig hebt moet je GOTO gebruiken.

CALL gebruik je vooral bij routines die je vaak moet aanroepen. Zoals bijvoorbeeld wachtlussen. En aangezien je die telkens vanuit een ander stukje programma aanroept is het makkelijk dat die weer terug kan gaan naar waar die vandaan kwam (en dat is telkens weer anders natuurlijk).

aha tja wist ik niet... met basic programmeren op mn ti83 hebje geen call, alleen maar goto en label... dus ik ben wel gewend of ook lussen te doen met goto en lbl. Bedankt voor de info... zal ns toepassen in mn proggies

Op 24 oktober 2002 22:28:49 schreef sille:
En aangezien ik enorm sukkel met de simulatie modus van MPLAB. weet ik dus niet of het werkt.

MultiSIM 2002 is te vinden op het net, indien iemand Ultiboard 2002 ook weet staan gelieve mij te verwittigen...

MultiSIM is EASY en gebruiksvriendelijk..

/MODbreak, dit soort requests van jou zijn NIET toegestaan. gelieve je hier aan te houden.
en daarbij is deze post vrij offtopic
maar omdat je nieuw bent is het je vergeven
lees wel eerst ff de FAQ door

[Bericht gewijzigd door Jeroen Boere op dinsdag 12 november 2002 14:18:24 ]

Je kunt ook een AVR nemen een stuk eenvoudiger te programmeren, en sneller

Op 11 november 2002 22:40:45 schreef RoBSki!:
Je kunt ook een AVR nemen een stuk eenvoudiger te programmeren, en sneller

Nou ik ken die PIC's goed en ben dus nu ook met AVR bezig. Maar het programmeren is wel een tikkeltje lastiger dan PIC hoor. Niet dat ik er moeite mee heb, want ik kan zelfs 32-bits dingen van Motorola programmeren. Maar voor beginners is de PIC zeker makkelijker vind ik. Minder instructies, beter overzicht van de mogelijkheden, enz.

Ik zie dat de gebruiker nooit zijn code kan veranderen.
Dat is jammer.

Op 11 november 2002 23:13:38 schreef elektron_:
Ik zie dat de gebruiker nooit zijn code kan veranderen.
Dat is jammer.

Welke gebruiker en waar zie je dat?

Volgens mij ontbreekt er iets zeer essentieels in je code, tenzij je dit met hardware reeds doet: ontdenderen van je toetsen. Als je hier nog niet aan gedacht hebt, of het begrip zelfs niet kent; bij indrukken en loslaten van een toets krijg je het zogenaamde 'dender'-verschijnsel; Allemaal piekjes achter elkaar die je u-controller inleest als zijnde toets aan/uit aan/uit etc. Op deze manier zal de processor altijd de verkeerde code lezen en zal de deur dus niet opengaan, ook als je correcte code intoetst.
ALs je dit met hardware wilde oplossen vergeet dan deze opmerking. De software oplossing komt er op neer dat je een lijn twee maal scant met daartussen een pauze van bijvoorbeeld 200us; de dender is dan achter de rug. Als de twee gescande waardes gelijk zijn is de toets-status (aan of uit) geregistreerd.

Nog een puntje; ik snap niet helemaal hoe je je toetsen aansluit op de u-processor. Heb je wel eens gehoord van een diodematrix? Werkt altijd correct en efficient met je lijnen. Een matrix van bijvoorbeeld vier x vier toetsen (=16) kun je uitlezen met 8 lijnen. Een matrix van 8x8 (=64) toetsen kun je uitlezen met 16 lijnen etc...

Als het allemaal wat ingewikkeld overkomt, komt dat waarschijnlijk omdat ik net wakker ben en mijn uitdrukkingsvaardigheid nog wat de wensen over laat.
Anyways, succes met je project!

Op 12 november 2002 11:46:08 schreef DIY:
Nog een puntje; ik snap niet helemaal hoe je je toetsen aansluit op de u-processor. Heb je wel eens gehoord van een diodematrix? Werkt altijd correct en efficient met je lijnen. Een matrix van bijvoorbeeld vier x vier toetsen (=16) kun je uitlezen met 8 lijnen. Een matrix van 8x8 (=64) toetsen kun je uitlezen met 16 lijnen etc...

Ik zat ook een beetje met deze vraag:
Je leest PortA in maar deze heeft maar 5 bits.

Hier is een mooie samenvatting over allerlei methodes van key-input,input:
http://oase.uci.kun.nl/~mientki/PIC/Projects/Pic_switch.htm

Ik zie dat de gebruiker nooit zijn code kan veranderen.
Dat is jammer.

zoals ik in mijn vraag geschreven had was dit programmatje nog maar een begin. ik had er in vermeld dat ik later een functie wou inbouwen zodat de gebruiker de code zou kunnen veranderen. Ik had dit graag met een '#' of '*' gedaan, maar de 74ls147 laat mij niet toe om met meer dan 0-9 tekens te werken

Op 12 november 2002 11:46:08 schreef DIY:
Volgens mij ontbreekt er iets zeer essentieels in je code, tenzij je dit met hardware reeds doet: ontdenderen van je toetsen. Als je hier nog niet aan gedacht hebt, of het begrip zelfs niet kent; bij indrukken en loslaten van een toets krijg je het zogenaamde 'dender'-verschijnsel; Allemaal piekjes achter elkaar die je u-controller inleest als zijnde toets aan/uit aan/uit etc. Op deze manier zal de processor altijd de verkeerde code lezen en zal de deur dus niet opengaan, ook als je correcte code intoetst.
ALs je dit met hardware wilde oplossen vergeet dan deze opmerking. De software oplossing komt er op neer dat je een lijn twee maal scant met daartussen een pauze van bijvoorbeeld 200us; de dender is dan achter de rug. Als de twee gescande waardes gelijk zijn is de toets-status (aan of uit) geregistreerd.

toen ik er vorige week nog es zat op te kijken, zag ik ook in dat ik problemen ging krijgen met contactdender (het begrip komt mij bekend voor ) Daarom heb ik ook es gezocht of ik dit softwarematig kon oplossen ipv condensatortjes en weerstandjes. Ik had er aangedacht om wanneer de PIC een verandering aan de ingang zag, nog bv 100µs te wachten voor dat hij de data in zou lezen.

Aan de andere kant komt de ingang van een TTL ic (74ls147), en denk ik dat het zou kunnen dat de uitgangen dan al gebufferd waren en de dender niet meer aanwezig zou zijn

Nog een puntje; ik snap niet helemaal hoe je je toetsen aansluit op de u-processor. Heb je wel eens gehoord van een diodematrix? Werkt altijd correct en efficient met je lijnen. Een matrix van bijvoorbeeld vier x vier toetsen (=16) kun je uitlezen met 8 lijnen. Een matrix van 8x8 (=64) toetsen kun je uitlezen met 16 lijnen etc...

Ik wou het eerst op deze manier oplossen, maar toen ik een display ging kopen, merkte ik op dat het al op een print was bevestigd, en dat er 14 uitgangsprintbaantjes waren. dus kon ik de matrix op mijn buik schrijven, en gaan zoeken naar een decimaal naar bcd converter.

Ik zou normaal alle componenten deze week moeten hebben die ik besteld heb, en dan kan ik eindelijk beginnen bouwen en testen! iedereen al bedankt om te reageren.
khou jullie op de hoogte !

Sille

Op 12 november 2002 23:16:00 schreef sille:
zoals ik in mijn vraag geschreven had was dit programmatje nog maar een begin. ik had er in vermeld dat ik later een functie wou inbouwen zodat de gebruiker de code zou kunnen veranderen.

Je hebt gelijk.
Hier is misschien iets voor jou.
Hier bespreekt men het toets-dender probleem+ oplossing ?(debounche)
http://www4.tpg.com.au/users/talking/Testing_page3.html

[Bericht gewijzigd door elektron_ op donderdag 14 november 2002 20:12:33 ]

Ik heb PIC software debounce functies als je wil, ons project is namelijk zo goed als afgerond en de debouncing werkt perfect (en is maar enkele lijnen).

Hint: laatste post was op 14 november 2002