Elektroda.pl
Elektroda.pl
X
PCBwayPCBway
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Procesor AVR, klawiatura matrycowa i diody.

janbernat 27 Lut 2012 19:24 6508 65
  • #61
    janbernat
    Poziom 38  
    No i widzisz- a ja wyciągnąłem inne wnioski :D
    Zachowanie elektryczne układów WE/WY procesorów nawet z tej samej rodziny jest różne i nieco nieobliczalne.
    Procesorów- bo układ jest ten sam.
    A co by było gdyby taka klawiatura była na oddzielnej płytce podłączonej raz przez taśmę 5cm a innym razem 25cm.
    No i klawiatury są różne.
    Bo przy zastosowaniu diod dla AT32 wystarczyły trzy nop-y w pierwotnym programie Twojego autorstwa.
    A dla AT644pa 16 nop-ów albo delay_us(1) co na jedno wychodzi.
    Teraz dalej- zastosowanie oporników zamiast diod zupełnie rozwiązało sprawę- Twój program działał z jednym nop-em synchronizacji bez problemów.
    Ale temat założyłem ze względu na tę różnicę działania układów WE/WY.
    To że michalko12 i Ty napisaliście przy tym programy rozwiązujące potrzebę stosowania oporników nastąpiło niejako przy okazji rozbioru problemu na części pierwsze.
    No i mamy rozwiązania- bez diod, bez oporników- a zwarcia wyjść nie może być z zasady.
    Krytyczna okazała się kolejność wystawiania stanów na poszczególne piny.
    Ale dzisiaj zaczął mi się kołatać w głowie taki tekst- "kompilator może zmienić kolejność wykonywania instrukcji jeśli uzna że ta kolejność nie ma znaczenia a z jakichś przyczyn da bardziej optymalny kod".
    No i przypomniałem sobie- to z książki tmf.
    Tak że nie zamykam tematu- czy to już jest wstępny objaw paranoi czy też uzasadniona ostrożność- nie wiem.
    A rozwiązania z noty ATmela nie zastosuję na razie- jeden pin więcej i obsługa deboucingu przez wystawienie przerwania z drgających styków- to na razie nie.
  • PCBwayPCBway
  • #62
    tadzik85
    Poziom 38  
    Nie o to rozwiązanie mi chodziło a sposób odczytu klawisza. To czy będziesz miał wykrywania naciśnięcie klawisza na ext-int to inna bajka.

    Tam wszystkie kolumny są zerowane i sprawdzane jest który wiersz jest zerem.
    Potem wszystkie wiersze są zerowane i odczytywana jest kolumna która jest zerem i otrzymujemy wynik. Zwarcie wyjść i tym samym stanie logicznym to już dużo mniejszy problem. Odczyt nawet szybszy.

    Mój kod ma tą zaletę, że jest "łopatologiczny" i nie wymaga dekodowania klawiszy.

    Ale faktycznie procesor procesorowi nie równy. Odkrywanie tych różnic to dobra rzecz, lecz kod powinien być od nich uniezależniony.
  • PCBwayPCBway
  • #63
    janbernat
    Poziom 38  
    Bardzo sobie cenię "łopatologiczność" Twojego kodu.
    Gdybym miał się użerać z niezrozumiałym zachowaniem sprzętu i "zakręconym" kodem to już bym ciepnął to wszystko i zamiast uczyć się C zajął bym się czymś innym.
  • Pomocny post
    #64
    tmf
    Moderator Mikrokontrolery Projektowanie
    janbernat napisał:

    No i mamy rozwiązania- bez diod, bez oporników- a zwarcia wyjść nie może być z zasady.
    Krytyczna okazała się kolejność wystawiania stanów na poszczególne piny.
    Ale dzisiaj zaczął mi się kołatać w głowie taki tekst- "kompilator może zmienić kolejność wykonywania instrukcji jeśli uzna że ta kolejność nie ma znaczenia a z jakichś przyczyn da bardziej optymalny kod".
    No i przypomniałem sobie- to z książki tmf.
    Tak że nie zamykam tematu- czy to już jest wstępny objaw paranoi czy też uzasadniona ostrożność- nie wiem.


    Trochę się zgubiłem, a wątek zrobił się długi, więc odniosę się tylko do tego jednego stwierdzenia. To prawda, kompilator może przestawić kolejność instrukcji, ale nie tych odwołujących się m.in. do IO. Powodem jest to, że porty (generalnie rejestry IO) są zdefiniowane jako wskaźniki z atrybutem volatile, a on zapobiega zmianie kolejności.
  • #65
    janbernat
    Poziom 38  
    No właśnie tego zapomniałem dopisać.
    Ale żeby uściślić- każdy rejestr jest volatile.
    A wpisy do tych rejestrów mają być w określonej kolejności.
    Czyli kolejności tych volatile kompilator nie zmieni?