ATNEL tech-forum

Re: Programowy I2C - pytanie do przykładu z BB

2018-07-11T11:45:50+01:00

mirekk36 napisał(a):

Panie kochany to, że jakaś funkcja zwraca jakiś wynik to nie oznacza, że ZAWSZE i w każdym wypadku w kodzie trzeba z niego korzystać. Słyszałeś gdzieś o takiej zasadzie hmmm WYMOGU ? bo ja nie ...

No wiadomo, że nie trzeba. Tylko jak nic nie korzysta to "młody chirurg" uznał to za zbędne i wyciął. Nie sprawdzałem, ale wydaje mi się, że inaczej to już kompilator powinien się zbuntować, prawda?

mirekk36 napisał(a):

Czy jest sens WSZYSTKO to opowiadać i opisywać w książce dla początkującego, który chce zrozumieć w jak najszybszy sposób jak coś wysłać przez TWI

Oczywiście, że nie - myślałem raczej w drugą stronę - "Skoro na sprzętowym TWI nie ma, to może tutaj też nie musi być"

mirekk36 napisał(a):

a przekładając to na język C - to pewnie usuwasz część istotnych opóźnień dla programowej obsługi I2C które są typ płucem i połową jelit

Zrobiłem jeszcze raz od początku: Kod żywcem skopiowany z płyty - oczywiście działa. Jedyna zmiana jaką zrobiłem to u08 i2cPutbyte na void i2cPutbyte i wyciąłem jedną linijkę return (b==0). Efekt: nie działa. Ale wystarczy że w miejsce tego returna dam HDEL; i wszystko nagle ożywa Po prostu w życiu bym się nie spodziewał, że taki zwykły return może mieć aż takie znaczenie na czas! A skoro jego głównym działaniem jest zwrot rezultatu z funkcji (który mi nie był tutaj do niczego potrzebny) to najzwyczajniej w świecie z tamtąd wyleciał

Także dzięki za odpowiedź A to wszystko przez to, że zacząłem mieszać w kodzie, gdy wpadłem na pomysł, żeby połączyć te dwie biblioteki w jedną i przełącznikiem w stylu #define USE_TWI 1, warunkowo kompilować obsługę I2C na soft/TWI

------------
A co do ATB - w książce była mowa o kilku dniach na 1F, więc na 0,22F powinien około dzień wytrzymać. Sprawdzę to jeszcze i dam znać.

Statystyki: Napisane przez Scynk — 11 lip 2018, o 11:45

Re: Programowy I2C - pytanie do przykładu z BB

2018-07-10T21:59:27+01:00

Scynk napisał(a):

Żadnych przypisań, warunków, czy innych. Tylko, że jak to skasuję i zmienię na void i2cPutbyte to oczywiście przestaje działać Więc standardowe pytanie: co tu jest nie tak? Przy okazji analogiczna funkcja TWI_write również zwraca void.

Wybacz, że tak troszkę żartobliwie odpowiem

ale to tak jakby młody lekarz na I-szym roku studiów uczył się na zasadzie obserwacji a nie anatomii człowieka, no i po chwili pobieżnej obserwacji stwierdziłby, gdy rozkroję pacjenta to w środku są dwie nerki, gdy wytnę jedną z nich, to pacjent jeszcze działa, a gdy wytnę dwie to przestaje działać. Dodam że raz rozkroiłem pacjenta który analogicznie miał tylko jedną nerkę i wciąż działał

dobra koniec żartów ... Panie kochany to, że jakaś funkcja zwraca jakiś wynik to nie oznacza, że ZAWSZE i w każdym wypadku w kodzie trzeba z niego korzystać. Słyszałeś gdzieś o takiej zasadzie hmmm WYMOGU ? bo ja nie ...

W przypadku putbyte czasem choć rzeczywiście rzadko do typowego wysyłania danych może się przydać informacja o tym czy układ do którego coś wysyłasz w ogóle zareagował (odpowiedział ) - żeby mieć pewność, że w ogóle wysłałeś dane. Toż na tej podstawie można w ogóle sprawdzić czy docelowy układ w ogóle odpowiada - nie przyszło ci to na myśl ?

To że przy sprzętowym TWI tego nie pokazałem nie oznacza, że nie można odczytać statusu - tyle że tam odczytu dokonuje się z jednego z rejestrów modułu TWI ... Statusów zwrotnych informacji przy sprzętowym TWI masz (można byłoby powiedzieć "bez liku") wystarczy zajrzeć do PDF'a i poczytać w tabelce w rozdziale o TWI ... Czy jest sens WSZYSTKO to opowiadać i opisywać w książce dla początkującego, który chce zrozumieć w jak najszybszy sposób jak coś wysłać przez TWI i nie przebijać się przez dziesiątki stron PDF'a albo książki ? No właśnie podstawowe informacje masz w Bluebooku - udało ci się odpalić - więc jeśli to masz za sobą - to zawsze mi się wydaje, że dalej już czytelnikowi będzie dużo łatwiej dochodzić tego co dalej robić, jak przechodzić w coraz bardziej zaawansowane metody obsługi I2C/TWI. Przecież w Bluebooku nie opisałem np jak odbierać czy wysyłać dane I2C/TWI za pomocą przerwań tak jak to miało miejsce w przypadku RS232(UART) - i czy to oznacza wg ciebie, że nie da się na przerwaniach tego zrobić ? W książce nie opisałem jeszcze wielu rzeczy o i2C/TWI jak np komunikacji z punktu widzenia układu SLAVE - i co ? myślisz że się nie da bo nie opisałem ? I samym I2C/TWI jeśli chodzi o wszystkie możliwości a szczególnie przykłady np komunikacji MULTI MASTER - to można by spokojnie całą książkę napisać Tylko, że jakbyś do niej zajrzał to by cię jako całkowicie początkującego pewnie odrzuciło - bo nie wiedziałbyś w co ręce włożyć, żeby kurczę na jej podstawie zrobić TAK PROSTĄ rzecz jak przesłanie czy odebranie kilku bajtów po I2C/TWI. Temat jest bardzo rozległy - mówię ci a tak w rzeczywistości w 99% przypadków aplikacji z użyciem I2C/TWI i tak każdy korzysta właśnie z trybu master i w taki mega uproszczony sposób - żeby np "pogadać" sobie z układami peryferyjnymi jak RTC, EEPROM czy jakieś inne układy np zewnętrzne ADC itp

No i kolejna sprawa - bierzesz sobie programową implementację I2C i próbujesz "wyciąć z kodu tę nieszczęsną nerkę" czyli zwracanie tego rezultatu z ACK - pisząc, że po wycięciu ci nie działa - i nie zadajesz sobie nawet minimum trudu aby analizując ten kod na podstawie opisu w książce chociażby - próbować dojść dlaczego tak się dzieje? Od samego wycięcia ? .... toż gdy ty piszesz że wycinasz samo zwracanie ACK - prawdopodobnie przy okazji nerki usuwasz jeszcze niechcący pacjentowi dodatkowo płuco i połowę jelit i dziwisz się że umiera ? ... a przekładając to na język C - to pewnie usuwasz część istotnych opóźnień dla programowej obsługi I2C które są typ płucem i połową jelit a może i coś więcej - ale to tylko można się domyślać na podstawie tak lakonicznego opisu operacji nad pacjentem

----------------------------------

odnośnie ATB 1.05a i kondensatora żelowego - to może nie wystarczy aż na kilka dni - bo kilka to dość szerokie pojęcie no ale tą dobę do powinien wytrzymać co najmniej ... Na pewno nie godzinę albo dwie czy trzy.

Kwestia tylko czy testujesz to dobrym kodem czy tym z wycinankami ? Spróbuj kodem z Bluebooka z lekcji o TWI gdzie jest odczyt zegarka i daj znać. Jeśli nadal będzie po godzinie się zerował to może coś być nie tak albo z kondkiem albo nie wiem - ale wtedy możesz oczywiście podesłać do nas zestaw do sprawdzenia i ew naprawy ... Tylko wtedy pisz już na maila do mnie.

------------------------ [ Dodano po: 1 minucie ]

przy okazji polecam ci dwa webinary 4-ty i 6-ty

https://mirekk36.blogspot.com/2018/07/a ... .html#more

z tej tematyki

Statystyki: Napisane przez mirekk36 — 10 lip 2018, o 21:59

Programowy I2C - pytanie do przykładu z BB

2018-07-10T19:43:55+01:00

Witajcie!
Przerabiam sobię po kolei niebieską książeczkę i dzisiaj po raz pierwszy przyszło mi na obsługę I2C - RTC + EEPROM (rozdział 4.10). Ze sprzętowym nie było większych problemów, bo tam wszystko działało „od razu”. A z programowym męczyłem się dosyć długo, ale koniec końców zadziałało. Nie wiem tylko dlaczego...
A to wszystko przez to, że na bazie kodów z książki/płyty potem zawsze jakoś staram się wymyślić coś swojego i je poprzerabiać trochę. I tu pojawił się tzw. zonk Funkcja i2cPutbyte na końcu zwraca 0 lub 1 w zależności od flagi ACK. Jednocześnie nigdzie w kodzie nie mogę znaleźć miejsca gdzie jakakolwiek inna funkcja korzystałaby z tego. Wszystkie wywołania tej funkcji są w stylu:
[syntax=c]i2cPutbyte(device);
i2cPutbyte(adr);[/syntax]
Żadnych przypisań, warunków, czy innych. Tylko, że jak to skasuję i zmienię na void i2cPutbyte to oczywiście przestaje działać Więc standardowe pytanie: co tu jest nie tak? Przy okazji analogiczna funkcja TWI_write również zwraca void.

I jeszcze mała poboczna sprawa: Na zestawie ATB 1.05a jest kondensator 0,22F do podtrzymania RTC. Ponoć to może starczyć nawet na kilka dni, a po około godzinie bez zasilania zegarek był wyzerowany. Trzeba mu wysłać jakąś specjalną komendę żeby „poszedł spać”, czy przyczyna leży gdzieś indziej?
Pozdrawiam wszystkich

Statystyki: Napisane przez Scynk — 10 lip 2018, o 19:43