Kurs STM32L4 – #12 – zewnętrzna pamięć EEPROM (I2C)

[Gieneq]

@ethanak faktycznie ciekawe, czyli kod z kursu w C++ by nie przeszedł. Coś rodzaju tego:

void mehh(uint8_t *aw, int cnt){
	uint8_t k = 0;
	while(cnt--)
		k = *aw++;
}

void meh(void * aa, int cnt){
	mehh(aa, cnt);
}

W C się skompiluje, bez ostrzeżenia. W C++ wyrzucił błąd:

argument typu "void *" jest niezgodny z parametrem typu "uint8_t *"

 

[ethanak]

Bo C++ wymaga bezwzględnej zgodności typów - co przy portowaniu kodu z C na C++ może doprowadzić do traumy. Ostatnio przy portowaniu swojego kodu stwierdziłem, że "const " to powinienem mieć pod jakimś łatwym skrótem klawiszowym, a głupi strtol który miał przesunąć wskaźnik na buforze const char * wymagał jawnego rzutowania na char ** z const char ** (przynajmniej ja nie znalazłem lepszego rozwiązania).

No ale nic dziwnego - to jednak dwa różne języki.

[Elvis]

Długa dyskusja się wywiązała, więc pozwólcie że napiszę kilka słów. Po pierwsze warto zrozumieć czym różni się wartość od wskaźnika - wartość to np. Bajt (uint8_t), int, albo cała struktura. Typ zmiennej określa ile pamięci jest potrzebne do jej przechowywania oraz jak wykonywać operacje na niej. Różne typy mogą zajmować różną ilość pamięci, więc np. Przypisując wartoś zmiennej 32-bitowej do zmiennej 8-bitowej możemy część danych stracić, bo po prostu się nie zmieszczą. Natomiast wskaźnik jest tylko adresem w pamięci, w stm32l4 to zawsze 32-bitowa liczba, a więc każdy typ wskaźnikowy w pamięci wygląda tak samo. Przypisanie wskaźnika do int na wskaźnik do skomplikowanej struktury nie spowoduje żadnej utraty danych, typy mają nas tylko ustrzec przed używaniem wskaźnika do niepoprawnych danych.

To oznacza, że void* jest wskaźnikiem na dowolny typ, po prostu przechowuje jakiś adres w przestrzeni adresowej procesora (nie musi to nawet być RAM). Kompilator bez problemu pozwoli na przypisanie wskaźnika dowolnego typu na void*, bo taka operacja oznacza tylko utratę informacji o typie, nic złego się nie dzieje. Problemem jest natomiast przypisanie void* z powrotem. Takie przypisanie może oznaczać błąd w programie, jeśli przez pomyłkę użyjemy wskaźnika z innym typem.

I tutaj dochodzimy do filozofii, albo raczej decyzji projektowych. Język C na początku wcale nie posiadał kontroli typów, przyjęcie więc że programista wie co robi było więc jak najbardziej sensowne. Nawet po wprowadzeniu kontroli typów, pozostała możliwość przypisywania void* do dowolnego wskaźnika. Natomiast C++ od początku większą wagę przywiązywał do statycznej typizacji, więc konieczne jest użycie jawnego rzutowania.

Czyli w C można napisać:

int x = 5;
int *px = &x;
void *pv = &x;
px = pv;

W C++ ostatnia linijka spowoduje błąd i konieczne będzie jawne rzutowanie, czyli nielubiane:

px = (int*m)pv;

Albo zalecane chociaż dyskusyjnie piękne:

px = static_cast<int*>(pv);

Przykładowe kody były pisane w C, więc jawne rzutowanie nie było konieczne, ważniejsze jest jednak wyjaśnienie, dlaczego używamy void* zamiast uint8_t*. Użytkownik biblioteki powinien mieć możliwość wysyłania i odbierania dowolnych danych, dlatego void* oraz const void* są tutaj o wiele lepszym wyborem. Taki typ jest również używany w standardzie Posix do odczytu i zapisu (read/write). Wywoływana funkcja działa na bajtach, więc wykona sobie jawną lub niejawną konwersję na uint8_t, ale nie powinno to obchodzić użytkownika.

Natomiast dlaczego HAL używa uint8_t* jako parametrów wiedzą pewnie tylko autorzy tej biblioteki. Moja prywatna teoria jest taka, że firmy produkujące świetny hardware, niekoniecznie są ekspertami w tworzeniu oprogramowania (i odwrotnie). Nie można mieć wszystkiego. Ale nie jest to mankament, który uniemożliwiałby korzystanie z zalet dostępnych bibliotek, po prostu taki folklor.

PS. Z góry przepraszam za błędy, post był pisany z telefonu, co nie jest aż takie wygodne jak się wydaje.

[Gieneq]

2 godziny temu, Elvis napisał:

Natomiast dlaczego HAL używa uint8_t* jako parametrów wiedzą pewnie tylko autorzy tej biblioteki. Moja prywatna teoria jest taka, że firmy produkujące świetny hardware, niekoniecznie są ekspertami w tworzeniu oprogramowania (i odwrotnie).

Pięknie 

@Elvis dzięki za obszerne wyjaśnienie 

[Hub]

Pomimo iż ustawiłem wszystko tak jak w kursie oraz dodałem kod z kursu(powyższy) to dalej mikrokontroler nie łączy się z eprom(w debbugerze test i result obie mają wartość 0 '\0')

uint8_t test = 0x5A;
HAL_I2C_Mem_Write(&hi2c1, 0xA0, 0x10, 1, &test, sizeof(test), HAL_MAX_DELAY);
 
HAL_Delay(5);
 
uint8_t result = 0;
HAL_I2C_Mem_Read(&hi2c1, 0xA0, 0x10, 1, &result, sizeof(result), HAL_MAX_DELAY);

 

[Treker (Damian Szymański)]

@Hub witam na forum  Zacznijmy od początku, czy sprawdziłeś podwójnie poprawność połączeń? Czy na 100% są rezystory podciągające przy I2C? Warto również sprawdzić inne miejsce na płytce stykowej, bo czasami układy scalone nie łączą na nich zbyt dobrze. Do tej pory nikt nie zgłaszał takich problemów, więc na początek doszukiwałbym się problemów w połączeniach sprzętowych.

[FlasSo]

Do czego w tym ćwiczeniu służy kondensator? 

[Treker (Damian Szymański)]

@FlasSo kondensator filtruje zasilanie dla zewnętrznej pamięci. Nie jest konieczny, ale to taka standardowa dobra praktyka, aby przy układach scalonych dodawać takie kondensatory.

[aimeiz]

Ja mam ten sam problem. Na analizatorze stanów logicznych pojawia sie tylko pojedynczy impuls LOW na szynie SCK. szyna SDA ma na stałe stan LOW. Myślałem że mam uszkodzone Nucleo, wiec przerzuciłem się na i2c2 zmieniając oczywiście zmienną w komendach zapisów i odczytów i podłączenia do nucleo.

Od czasu gdy powstał kurs, kilkakrotnie zmieniła się wersja CUBE_IDE. Obecnie jest 1.18.0 Build: 24413_20250227_1633 (UTC).

Może potrzebna jest jakaś komenda startu I2C.
Jest jeszcze kwestia zasilania układu EEPROM. Ja zasilam z 3.3V, to chyba prawidłowo. Oporniki 4.7k prawidłowo podciągają porty procesora do 3.2V - mierzone miernikiem, tyle że po uruchomieniu programu szyna SDA stoi jak drut na LOW.

Próbowałem jeszcze coś takiego:

  HAL_I2C_DeInit(&hi2c2);  // Reset I2C w razie problemów
  HAL_Delay(1000);
  HAL_I2C_Init(&hi2c2);    // Ponowna inicjalizacja
  HAL_Delay(1000);

 if (HAL_I2C_IsDeviceReady(&hi2c2, 0xA0, 3, 5000) != HAL_OK) {
      printf("EEPROM not responding!\n");
  } else {
      printf("EEPROM ready!\n");
  }

Program czeka na odpowiedź eeproma. Skróciłem timeout żeby coś odpowiedział i dostałem
EEPROM not responding!

Na analizatorze to samo - pojedynczy impuls zegara. Chyba stm powinien coś więcej wysłać, aby otrzymać odpowiedź z eeprom a nie tylko pojedynczy impuls zegara??

Aktualizacja:

W końcu zadziałało.

Winna jest rozpiska NUCLEO. Ma przesunięte opisy portów z lewej strony

Edytowano 10 marca przez aimeiz

[aimeiz]

Widzę z treści kursu, że do pokazania przebiegów, użyty został Analizator Stanów Logicznych z oprogramowaniem Saleae Logic 1.2.18.
To oprogramowanie oryginalnie służy do dość kosztownych analizatorów firmy Saleae, ale w granicach 30._ PLN można kupić uproszczonego klona - 8 kanałów, który znakomicie działa z tym programem. Kilka lat temu kupiłem z ciekawości, znakomicie się sprawdza i w zupełności wystarcza na potrzeby tego kursu i projektów z STM32, ESP... czy Arduino. Wykresy które pokazywałem są co prawda z innego analizatora i programu DSView. Analizator lepszy, 16 kanałów i do 400Ms/s, no i o ponad rząd wielkości droższy, ale oprogramowanie chyba uboższe. Tan prościutki analizatorek gorąco polecam. Koszt niewielki a sporo więcej da się pojąć obserwując przebiegi i zależności miedzy nimi. Zresztą ten droższy analizator też.

[MisiuPora]

@aimeiz

Nie do końca rozumiem co było nie tak w twoim projekcie, mam podobny problem co ty i właśnie się zastanawiam czy to jest kwestia podłączenia do złych pinów, ale ta rozpiska NUCLEO którą podałeś nie jest w ogóle dostępna w dokumentacji

Ja znalazłem taką