Sida 2 av 2
Postat: 20 juni 2007, 15:34:07
av Icecap
Att börja med interrupt kan verka "skrämmande", jag var också tveksam i sin tid (började 1982 med Z80) men när man väl fattar det är det skitenkelt.
Jag använder MikroC till ett par enkla projekt då där inte finns större hastighetsproblem och jag behövde något "quick-and-dirty" men jag är inte speciellt förtjust av Mikroelektronika heller. Jag har faktisk inte ens läst deras manual, det finns en massa funktioner som kan skriva till LCD osv. men det är inte ens i närheten av att jag tänka på att använda dom då jag inte VET hur de fungerar helt exakt.
Även i dessa enkla projekt finns det ett problem som jag inte har löst, jag har å andra sidan bekämpat symptomen ganska effektivt så jag vill inte lägga mer tid på det: skiten fungerar = hands off!
Postat: 20 juni 2007, 16:21:54
av H.O
Hej,
Snabbt inlägg här bara: Det verkar som att en del blandar ihop basic kompilatorn från MikroElektronika med den från MicroEngineering Labs - det är INTE samma. Om jag fattar rbrakhya rätt så är det PicBasicPRO från MicroEngineering Labs han använder.
Några saker att kolla:
Är pinnarna satta i analog mode?
Är komparatorerna avstängda?
Finns det andra funktioner multiplexade på samma pinnar som måste stängas av?
/H.O
Postat: 20 juni 2007, 16:28:58
av sodjan
Helt korrekt ! Jag blandade ihop dom. Skit...
Men synpunkterna på *Mikroelektrinikas* manualer kvarstår dock...
Det jag länkade till var dock PB-Pro, helt rätt. Inte PB (utan pro) som
rbrakhya hänvisade till, jag var först i fel manual och letade...
Och att man inte kan använda någon Basickompilator som en ursäkt för
att inte läsa på ordentligt om processorerna gäller fortfarande...
Postat: 20 juni 2007, 16:38:24
av v-g
BASIC är en ren återvändsgränd vad gäller programmering tycker jag. Assembler _ÄR_ inte svårt. Grundstommen(=templates) till alla processorer finns
här där ser man lite hur det ska vara uppbyggt. Sen snattar man några exempel från forumet/nätet eller var som helst och kör på. Tar inte mer än 3-4 kvällar innan man är såpass att man kan leta sig till svaren själv.
Det som kan vara knixigt är att man _måste_ lära sig hur displayer etc fungerar vilka signaler osv de vill ha. Dvs
läsa databladet. Men istället så kan man ju felsöka när det inte fungerar
Sen har jag en fundering, hur "vet" kompilatorn om man ändrar klockfrekvensen för att justera
delay_ms()? Håller den reda på klockfrekvensen _alltid_ eller?
Postat: 20 juni 2007, 16:51:23
av rbrakhya
H.O:
Är komparatorerna avstängda?
Ska kolla det!
Postat: 20 juni 2007, 16:54:51
av BJ
"hur displayer etc fungerar..."
Det här skulle kunna passa på många ställen, men jag skriver det här.
Det finns faktiskt en sak som brukar vara otydligt i många datablad. Det är var i flödesschemat som man kan börja titta på upptaget-biten när man ställer in skärmen:
"...kan inte kontrolleras före den här instruktionen."
"...kan kontrolleras efter den här instruktionen."
Det fattas alltså en kommentar. Det har jag sett i flera datablad. Det brukar gå att komma igång ändå, men helt självklart är det inte. Ett enkelt sätt att komma förbi det är att bara köra med fördröjningar tills skärmen är helt inställd.
Postat: 20 juni 2007, 16:55:13
av sodjan
*Ingen* kompilator kan veta vilken frekvens man tänker köra på
om man inte talar om det för den. Ibland sker det via kompilator
direktiv (#-prylar), ibland sker det via inställningar i IDE'n (sämre
enligt min personliga uppfattning).
Det samma gäller naturligtsvis för assembler i de fall man har
kod som t.ex räknar ut värden för baudrate register. Även där
måste man någonstans ange vilken frekvens man tänker köra på.
Postat: 20 juni 2007, 17:01:24
av v-g
sodjan:Alltså måste man även där räkna på hur olika hastigheter påverkar tiden. Mao precis som assembler.
Postat: 20 juni 2007, 17:03:29
av Icecap
BJ: Du har rätt och det är anledningen till att jag har lagt ut den PDF-fil på min hemsida som jag fick tiggat från Sharp. Den innehåller hela timingsförloppet under initieringen, vara sig i 4-bit eller 8-bit läget.
Och ja, tiggat! Jag skrev till Sharp och frågade om de hade en PDF som visade detta då jag hade sett den nångång, som svar kom den fil och det var rätt grej.
Jag använder i övrigt inte alls denna "busy"-bit, jag skriver och väntar en liiiiten stund, fungerar bra.
Postat: 20 juni 2007, 17:10:25
av sodjan
Jo, fast i C, Basic o.s.v så ligger beräkningen i själva funktionen,
så man behöver inte göra det själv så att säga. Man får samma
funktion om man skriver ett macro i assembler som gör samma sak...
Om jag förstog rätt med vad du menade...
Postat: 20 juni 2007, 18:57:34
av BJ
Icecap: Jag tittade på din pdf-fil. Men det är ju likadant där...
Kod: Markera allt
0 0 0 0 1 1 * * * * <-- Busy flag can't be checked before
execution of this instruction.
Wait 100 μs or more
0 0 0 0 1 1 * * * * <-- Busy flag can't be checked before
execution of this instruction.
Busy flag can be checked after
the following instructions are completed.
och så vidare
Det man inte ser är om det går direkt efter den andra instruktionen (om vi kallar dom 1 och 2 här). Det står ju bara
"inte före 2."
"men efter (dom som kommer sen)".
Vart tog "efter nummer 2" vägen? Ska man gissa?
Men som du skrev så fungerar det ju med fördröjningar.
Postat: 20 juni 2007, 19:07:10
av sodjan
> men efter (dom som kommer sen)".
Vilket betyder "inte före dom som kommer sen"
vilket är det samma som "inte efter nr 2"...
Klart som korvspad...
Postat: 20 juni 2007, 19:09:19
av BJ
Ja, det blir det ju... Tack.
Postat: 21 juni 2007, 06:38:29
av BJ
Jag kom på en sak...
Om man tänker på vad instruktionerna gör så blir det lite mer självklart.
"Nummer 2" är ju "Ställ in data-bredden", del 3 av 3. Innan dom 3 delarna är färdiga så kan man ju inte läsa rätt antal bitar (4 eller 8 ) från skärmen. Därför måste man använda fördröjningar efter alla 3.
Bara man funderar lite...
Tillägg: Alltså borde det vara en "Wait 100 μs or more" till, om allt ska vara rätt.