Panowie, ok - no ja wszystko rozumiem a najbardziej początkujące osoby, zresztą dlatego piszę książki.
Niestety jednego nie rozumiem. Kurczę no nie rozumiem.
Pomijam już to że w nocie PDF każdego procesora AVR jest to podane jak na talerzu, to także w książce jest to opisane jak byk. Ale mało tego, na płycie DVD są kody źródłowe do których zawsze można zajrzeć gdy sami coś robimy i nie wychodzi. Wtedy można podejrzeć jak się powinno robić i znaleźć swoje błędy. Ale nie lepiej napisać:
Cytuj:
Zachwalany przez kolege Mirka, PuTTY też nie działa a próbowałem już różnych terminali
Ja bardzo przepraszam ale nawet nie podpowiem gdzie jest błąd - w tym co kolega robi. Ja bym proponował wziąć książkę przed oczy, otworzyć notę PDF w rozdziale o USART i dokładnie poczytać. No przecież tak nie można. Kolega wkleja tu kod programu z takimi babolami że aż strach i ja nie wiem nawet czy to nie jakiś żart ?
proponuję przede wszystkim:
1. przejrzeć procedurę inicjalizacji w PDF
2. przejrzeć procedurę inicjalizacji w książce i poczytać o tym - poczytać po polsku przecież w książce
3. zajrzeć do procedur inicjalizacji na DVD
4. odpalić sobie wprost przykłady RS232 z DVD z książki zanim się swoje takie pierwsze próby zrobi
poza tym - ja tyle razy w książce piszę - i też nie rozumiem dlaczego połowa ludzi na świecie jak się czyta internet, to z uporem godnym podziwu jak ma coś przesłać sobie czy to przez RS323 czy RS485 czy drogą radiową czy przez BT - do terminala w windows to kurka wodna - nie ma to jak utrudniać sobie życie i przesyłać jakieś super kocie znaki nie z zakresu drukowalnych znaków ASCII tylko jakieś znaki sterujące o kodach ASCII poniżej 32 (poniżej kodu spacji) - no SZOK !!!
Kod:
USART_Transmit(0x10);
peeeewnie - po co wysyłać tam zaraz jakieś przyjazne dla człowieka, dla oka litery np:
Kod:
USART_Transmit('A');
czy
Kod:
USART_Transmit('B');
zamiast tego wysyłaj panie kolego jeszcze
Kod:
USART_Transmit(0x09);
i podobne .... i biorąc pod uwagę totalne błędy w inicjalizacji oczekuj, i spodziewaj się jakichś efektów w terminalach jak w książce.
No tak nie można - Panowie - no chociaż troszkę samokontroli - zupełne minimum. Jak mi coś nie wychodzi a czytam książkę, to najpierw próbowałbym do bólu robić coś DOKŁADNIE tak jak to jest w niej opisane, a nie wymyślać jakieś niestworzone rzeczy i pisać tak jakby może nawet z nutką pretensji że nic mi nie działa z tych kodów w książce.
Bardzo proszę Panie kolego - sprawdzić to co napisałem wyżej, zastosować się do tych porad, przetestować kody z DVD i wtedy się tu odezwać powołując się już na prawidłowe kody.
Bo po tym co kolega pokazał w inicjalizacji raczej wynika mi (tak mi się wydaje), że w ogóle kolega odpuścił sobie przeczytanie ze szczegółami opisu w samej książce (strona ok 262) - a szkoda - jak widać próby posługiwania się UART'em bez z kolei podjęcia próby zrozumienia podstaw w taki sposób jak podałem to w książce - tak się mogą kończyć.
zatem czekam na doczytanie, sprawdzenie właściwych kodów i wtedy zadanie pytania OK?
aha a dla testu zrób sobie program wysyłający co sekundę coś do termianala i bez żadnych dziwnych Waitkey - po co sobie życie utrudniać. Jak podstawowy test to podstawowy a nie tam dodatki i wszystko się plącze - tym bardziej że to waitkey też jest totalnie źle napisane
I jak kolega będzie dalej tak inicjalizował:
Kod:
DDRC = 0xFE;
PORTC = 0xFF;
a potem podłączał do tych pinów klawisze - to procek pójdzie z dymem i to wcale nie będzie dziwne
ile ja w książce poświęciłem miejsca i pisałem żeby tak nie inicjalizować pinów, co to za jakieś
Kod:
DDRC = 0xFE;
PORTC = 0xFF;
gdy później korzysta się z
(1<<PCx)eeeeeeh
-- dodano 22 cze 2012, o 22:39 --bartool napisał(a):
Rozwiązałem problem. Błąd wynikał ze źle ustawionych fusebitów. Sprawdziłem w mkavr calculator czy aby napewno jest ustawione 8MHz, zauważyłem, że jest zanzaczone wewnętrzny podział oscylatora przez 8.
Na pewno nie tylko w tym był błąd - inicjalizacja jest zrąbana - może koledze podpowie coś bit o nazwie URSEL ?