Witam
Jest to mój pierwszy post na tym forum, więc chciałbym się ze wszystkimi przywitać . Słyszałem że panuje tutaj miła atmosfera, a akurat tak się złożyło że mam pewien problem - czemu by nie spróbować? Zawsze to jakaś alternatywa dla elektrody.
Piszę sobie mały program wykorzystujący EEPROM, USART i kilka innych rzeczy. Zasadniczo mój problem polega na ostrzeżeniach jakie wypluwa mi kompilator. Wiem że Pan Mirek prezentował kiedyś pełną obsługę komunikatów ASCII przez USART, jednak dla mnie póki co jest to zbyt "ciężkie" rozwiązanie, i chciałbym się ograniczyć do niezbędnego minimum. Potrzebuję wysłać z komputera krótkie komunikaty zawierające łącznie 11 bajtów. Pierwsze 2 z nich odpowiadają za proste sprawdzenie czy coś się nie pomieszało , następne 8 to dane, które zostaną zapisane pod odpowiednim indeksem tabeli (indeks określony przez ostatni bajt komunikatu). Próbuję zapisać te 8 bajtów do jednej zmiennej 64-bitowej, po prostu po kolei "przyklejać" je co raz dalej. Takie coś wyskrobałem:



Do wstawiania kodu używamy znacznika 'syntax' zamiast znacznika 'code' - to tak na przyszłość...

Przeczytałem, że dla większych liczb trzeba ręcznie rzutować typ, bo kompilator domyślnie rzutuje na int (http://atnel.pl/domyslna-promocja-do-typu-int.html), jednak mimo rzutowania na uint64_t dostaję ostrzeżenia o przesuwaniu "poza zakres" zmiennej. Przykładowo, wysyłając z komputera następujący ciąg bajtów:
13, 10, 255, 148, 160, 7, 74, 88, 177, 140
W pamięci EEPROM (tam przechowuję wartości 64-bitowe, czyli wyniki ze "sklejania") zapisuje się coś takiego: 0x8CB1FFFFFFFFFFFF, a do komputera wracają takie bajty: 00 00 00 00 00 00 00 8C.

Czy ktokolwiek wie jak można to rozwiązać? Domyślam się że mam gdzieś błąd w sklejaniu (a także rozcinaniu, bo wartości odczytane z komputera i EEPROMu różnią się), ale nie mogłem nic znaleźć na ten temat...

Pozdrawiam serdecznie!
mopsiok

_________________
Więcej dziwactw na: www.youtube.com/user/mopsiok

Strasznie skomplikowałeś z tymi przesunięciami. Tak się nie pisze kodu.
O ile zrozumiałem zamysł, to możesz to zrobić znacznie prościej tak:

_________________
ATB 1.03, Win XP SP3, ECLIPSE Indigo 3.7.2

Należałoby pozmieniać trochę rzeczy, ale tak, masz rację. To tylko funkcja testowa, docelowo jej nie będzie, więc nie chciałem wprowadzać pętli która mogłaby coś pomieszać. Wygląda na to że rozwiązałem swój problem. Tak wyglądało pojedyncze przesuwanie bajtu:

Powinno natomiast wyglądać tak:

Jednak kompilator prawdę Ci powie - ośmiobitowy element buforu faktycznie nie obsłuży przesunięcia o 56 bitów .

Wprawdzie odpowiedzi się nie doczekałem, ale i tak wypada podziękować. Miło tu u Was, chyba zostanę na dłużej .

_________________
Więcej dziwactw na: www.youtube.com/user/mopsiok

Poprawiłem swój kod bo zauważyłem błędy.

_________________
ATB 1.03, Win XP SP3, ECLIPSE Indigo 3.7.2

Witam ponownie!
Przygnało mnie tu z powrotem, znowu problem z przesunięciami (tak myślę). Projekt który realizuję ma za zadanie również kodować dane w Manchesterze. Widziałem kilka przykładów takiego kodowania, ale były dość skomplikowane, a ja potrzebuję najprostszego rozwiązania. Popełniłem coś takiego:



Kod poniżej "kreski" znajduje się w timerze 4kHz. Timer sam w sobie pracuje poprawnie, sprawdzałem. Problem polega na tym, że ten kod jeszcze kilka godzin temu naprawdę działał , a teraz go opętało i wysyła tylko 0 i 1 na zmianę. Sama idea była taka, by zapisać całą ramkę danych w jednej zmiennej (proba), a potem odczytywać po kolei każdy bit i sprawdzać czy jest 0 czy 1. W zależności od tego wysyłać odpowiedni bit na podstawie aktualnej połówki bitu (za każdym wykonaniem kodu połówka się przełącza z 0 na 1 i 1 na , aktualnie wysyłany bit jest zwiększany raz na 2 wykonania kodu).
Nie mam pojęcia co może być nie tak. Znowu podejrzewam przesunięcie bitowe, przecież kod pod nim jest tak trywialny że chyba nie może uczynić nic złego ^^.

Pozdrawiam i proszę o jakieś nakierowanie, czy coś... to mnie doprowadza do szaleństwa >.<
mopsiok

//Edit
Udało mi się podejrzeć sygnał bezpośrednio po załączeniu zasilania i pierwsze 16 bitów jest nadawane poprawnie, czyli na pewno jest to wina błędu w <<. Jakby ktoś był tak dobry i rzucił na kod swoim fachowym okiem, to byłbym bardzo wdzięczny .

_________________
Więcej dziwactw na: www.youtube.com/user/mopsiok

proszę bardzo - moja porada to zakończ jak najszybciej te zabawy z uint64_t .... dlaczego w ogóle korzystasz z takiego typu w tym przypadku ? czyżby dlatego że chcesz przesyłać za jednym zamachem 8 bajtów ??? jeśli tak to właśnie szaleństwo bo pomyśl co się stanie jak będziesz chciał przesłać np 12 bajtów ??? typów ci zabraknie ... tak się nie robi ....

za to robi się to tak jak WSZYSTKO w C, czyli

zrób sobie podstawową funkcję do przesyłania jednego bajtu ew max słowa. Ale trzymajmy się bajtu ...

jak zrobisz przesyłanie jednego bajtu - to pomyśl - koniec szaleństwa i wyrywania włosów z głowy - od teraz sama ekstaza bo teraz możesz sobie przesyłać ile tylko bajtów zechcesz jakąś byle nadrzędną funkcją rozumiesz ?

to jest właściwa droga

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Dzięki za odpowiedź.
Myślałem nad tym, i początkowo nawet zamierzałem tak zrobić, ale potem doszedłem do wniosku, że i tak będę musiał operować na 64 bitach (docelowo dane będę dekodować ze strumienia bitów wysłanych w Manchesterze, potem je zapisywać w eepromie i następnie wysyłać z powrotem), więc tak czy siak będę musiał wykonywać jakieś przesunięcia bitowe, i znowu mnie to doprowadzi do obecnej sytuacji. Tak mi się przynajmniej wydawało wtedy, może się okazać że wcale nie xD. Jak teraz patrzę na całość to zaczynam podejrzewać że obsługa zmiennych 64-bitowych będzie tak samo skomplikowana jak rozwiązanie tego w sposób który zaproponowałeś, spróbuję więc skorzystać z Twojego doświadczenia i pójdę tą drogą . A jak później zrealizować odczyt w tym systemie - tym już się będę martwić potem .

Dzięki raz jeszcze, postaram się wrzucić kod jak już coś zmaluję, może ktoś skorzysta.

_________________
Więcej dziwactw na: www.youtube.com/user/mopsiok