W tym temacie można zadawać pytania dotyczące wykładu i zadań z przedmiotu “Systemy wbudowane” edycja 2018.
Jak powinniśmy odmierzać czas w zadaniu 1 z listy 2?
Dokładnie tak, jak we wcześniejszych zadaniach - używając makra _delay_ms.
Czy dobrze rozumiem, ze podczas delay mamy wykonywac inne czynnosci? Np podczas reprezentowania wczesniej podanych wcisniec przycisku mamy moc podawac do bufora nowe?
Jesli tak to czy mozna prosic o wskazowke jak mamy obejsc zatrzymanie calego programu?
Czy wcisniecia maja byc reprezentowane na diodzie w takich samych odstepach czasu jak byly podawane?
Czy na podanie wejscia powinien byc okreslony czas czy tez mamy czekac, az od odstatniego wcisniecia uplynie sekunda?
- Nie. Jak mówiłem na wykładzie - makro
_delay_msgeneruje pętlę aktywnego czekania. Wszystkie operacje potrzebne do wykonania zadania 1 z listy 2 należy wykonać pomiędzy opóźnieniami. Opóźnienia powinny być oczywiście istotnie krótsze niż 1 sekunda, ale nie muszą być bardzo krótkie - ludzki czas reakcji z punktu widzenia mikrokontrolera jest bardzo długi! - Tak.
- Nie. Program ma działać w czasie rzeczywistym bez trybów pracy.
Myślę, że coś Pan przekomplikowuje. Wzorcowe rozwiązanie zadania jest naprawdę minimalną modyfikacją programu przykładowego “zapalanie diody przyciskiem”. Podpowiedź do zadania praktycznie je rozwiązuje.
Mam małe pytanie odnośnie przełączników.
Czy powinno być tak, że przełącznik łączy te nóżki co są obok siebie?
To znaczy te bliżej siebie?
Przycisk wpięty w płytkę stykową zwiera razem każdą kolumnę, a włącznik jest pomiędzy kolumnami. Patrz np:
Na stronie SW na SKOSie w sekcji “Do przeczytania” zarówno w obecnym jak i ubiegłym tygodniu jest rozdział 14 dokumentacji ATmegi. Wydaje mi się, że wspominał Pan, że jeden z nich jest niewłaściwie podany i powinniśmy przeczytać coś innego. Jeśli dobrze pamiętam, to czy mógłby Pan to poprawić?
Rozdział 14 jest ciągle obowiązujący. Dopisałem do pierwszego wykładu rozdziały 2, 7 i 8 jako wprowadzenie do architektury AVR.
W zadaniu pierwszym mamy wczytywać dane z pamięci flash, ale powoduje to znaczące lagi, przez które melodia nie gra jak trzeba. Skoro dostępy do pamięci są takie wolne to co z tym zrobić?
Nie są wolne, instrukcja odczytu bajtu z pamięci flash zajmuje tylko o połowę więcej niż zwykły odczyt z pamięci RAM (3 cykle zamiast dwóch). Takich dostępów trzeba w tym zadaniu wykonać ledwie kilka w ciągu sekundy. Jeśli ma Pan jakiś problem z prawidłowym generowaniem dźwięku, czasy dostępu do pamięci flash na pewno nie są z nim związane.
Ma Pan rację, przez to że miałem zmienne w 16 bitach, ucinał mi część danych i powstawały artefakty
Czy mógłby ktoś podpowiedzieć, w którym miejscu należy w Makefile’u dodać informację, żeby avr-gcc dolinkował i2c.c do głównego programu, np. zad1.c?
skompiluj sobie oddzielnie i dodaj w OBJ nazwa.o
Podpiąłem układ eeprom 24c04 tak jak na schemacie z zadania 1 z listy 7.
Po wrzuceniu na płytkę kodu przykładowego (odczyt EEPROM I2C) program wypisuje
I2C EEPROM write request failed, status: 20
Zgodnie z dokumentacją kod 0x20 oznacza:
SLA+W has been transmitted; NOT ACK has been received
(SLA to slave address, R/W to read/write, w tym przypadku write)
Czyli jeżeli dobrze rozumiem przesłany adres urządzenia (w kodzie eeprom_addr) jest błędny.
Zgodnie z dokumentacją powinien on mieć wartość 0b10100000 czyli 0xa0 tak jak w kodzie przykładowym. Próbowałem też łączyć się inkrementując adres aż zwróci 0x18 (bruteforce) ale nie udało mi się znaleźć adresu dla którego zostanie zwrócone 0x18.
Ma ktoś pomysł jak to naprawić?
//EDIT
i2cCheck(0x08, “I2C start”) mi przechodzi jakby co
Eeprom mi nie do końca stykał na płytce stykowej