Błąd transmisji danych C++ do Arduino - brakujące 64 bajty w pamięci EEPROM 24LC32

Question

Witajcie. Piszę skrypt przesyłający dane do Arduino, a Arduino ma je zapisać w zewnętrznej pamięci EEPROM (24LC32). Chodzi o przesłanie tablicy zawierającej równo 4KB danych. Dla uproszczenia, na potrzeby testu wszystie dane w tablicy mają wartość 0x13. Problem polega na tym, że podczas odczytu...

n6210 · Answer

Na początek sprawdź, że jesteś pewny, że zapisujesz wszystkie dane poprawnie, bo ani nie czekasz jakiegoś stałego czasu po zapisie strony ani nie sprawdzasz czy eeprom już skończył (przynajmniej ja nie widzę czegoś takiego), a kolejne zapisy można wykonywać dopiero jak skończy zapis. Błędu zapisu z I2C też jakby nie obsługujesz a na coś trzeba by się zdecydować. To tak na pierwszy rzut oka.

Dodano po 2 [minuty]:

te różne prędkości dla odczytu i zapisu to celowo?

Promuję tematy:
12.02.2020 [AVR] Konwerter I2C slave na UART.

Konto nie istnieje · Answer

Owszem, to dwa osobne skrypty (ten do odczytu z eeprom służy jedynie aby srawdzić co się zapisało do pamięci, a odczyt trwa krócej więc i prędkość może być wyższa). Podrzuciłbyś jakiś sensowniejszy kod?

Zielonka · Answer

Witam
Nie możesz wysłać od razu 4kB do EEPROM-a. Pamięć potrzebuje ok. 5~10 ms na zapis jednej strony (256 bajtów). Czyli musisz wysyłać 256 bajtów i czekać aż dane się zapiszą.
Pozdrawiam
W.B.

Konto nie istnieje · Answer

Dokładnie rzecz ujmując, pamięć której ja używam (24LC32A) ma 32B na stronę oraz czas zapisu max 5ms (dane z noty katalogowej). Czyli co, wysyłam z PC do uC 32 bajty, zapisuje do eepromu, odczytuje z eepromu co się zapisało i wysyłam z powrotem do PC żeby sprawdził czy się zgadza z danymi wysłanymi?

Konto nie istnieje · Answer

Otóż to. W programie nie ma ani jednej linijki kodu, gdzie weryfikuje się poprawność wykonania komend dla Wire. Ciężko wtedy nawet zgadywać. Na leniwca można użyć całkiem dobrej biblioteki extEEPROM do obsługi zewnętrznych pamięci EEPROM po I2C albo przynajmniej sprawdzić, jak to się powinno robić (to już będzie bardziej pouczające)

Zielonka · Answer

Wstaw po zapisaniu każdej strony opóźnienie minimum 5 ms i zobacz co się stanie.

Konto nie istnieje · Answer

Ogólnie to obliczyłem, że przy prędkości transmisji 38400bps przesłanie 16B trwa 3,33ms więc po przesłaniu strony do uC wystarczy opóźnić transmisję kolejnych 16B o 2ms. Zapis do eeprom przy częstotliwości 400kHz to 0,32ms, a więc jakby to zsumować, od zakończenia przesyłania pierwszego bajtu po i2c do eeprom, do rozpoczęcia przesyłania następnego, mija mniej-więcej 5ms właśnie. I póki co to działa.

Co do tej biblioteki extEEPROM; no fajnie, uprości trochę kod, ale w czym ma mi ona pomóc? Będe mógł zapisać stronę danych np 32B na raz, ale to i tak odbije się na wydajności tego zapisu (a przynajmniej tak zrozumiałem z opisu).

Konto nie istnieje · Answer

Nie bardzo rozumiem, dlaczego uparłeś się na zapis/odczyt EEPROM bajt po bajcie. To na pewno nie jest wydajne rozwiązanie.

Konto nie istnieje · Answer

Dlaczego bajt po bajcie? Przecież napisałem, że 32 bajty na raz (w sensie, strona po stronie).
Nie zmieszczę całego kodu (4kB) w pamięci uC żeby go potem wgrywać z RAMu do EEPROMu. Wykombinowałem to w taki sposób, że przesyłam po kolei 32 bajty do pamięci uC, a potem wgrywam jako stronę do EEPROMu. Trochę pozmieniałem i teraz czas opóźnienia nadajnika wynosi 1.5ms, natomiast prędkość transmisji 57600bps, a więc jedna strona jest wgrywana co ~6ms, a więc uC ma czas żeby przesłać dane do pamięci, a ona aby je zapisać. Całość transmisji trwa niecałą sekundę, a więc akceptowalnie.

Myślę tylko nad tym mechanizmem weryfikacji poprawności zapisanych danych.

Konto nie istnieje · Answer

Dlatego, że nie korzystasz z funkcji Wire.write(const uint8_t *data, size_t quantity) oraz Wire.requestFrom(uint8_t address, uint8_t quantity).

Konto nie istnieje · Answer

Teraz korzystam z tej biblioteki extEEPROM: Kod: C / C++Zaloguj się, aby zobaczyć kod O to chodziło?

Konto nie istnieje · Answer

Tak. extEEPROM::write() zwraca wartość różną od zera, jeżeli zapis się nie powiedzie - warto to sprawdzać.

Konto nie istnieje · Answer

W jakim sensie nie powiedzie? Że nie będzie mógł w ogóle zapisać czy sprawdza co zapisał?

Konto nie istnieje · Answer

Głównie wtedy, kiedy pojawi się błąd na I2C czyli zapis się nie powiedzie. extEEPROM::write() nie wywołuje funkcji odczytu EEPROM w celu weryfikacji. Może natomiast zwrócić EEPROM_ADDR_ERR, kiedy zostanie źle zaadresowana pamięć.

Zielonka · Answer

Po zapianiu jednej strony pamięci EEPROM z I2C musisz czekać, aż dane się zapiszą. Jeżeli chcesz robić to wydajnie to zastosuj w projekcie EEPROM z SPI.

Konto nie istnieje · Answer

No tak, ale zapis do cache-u pamięci trwa chwilkę (~0,7ms przy 400kHz), a z niej do EEPROM 5ms. Uwzględniłem to.

Konto nie istnieje · Answer

Używasz częstotliwości 400 kHz dla I2C. Jakie wartości mają rezystory pull-up dla SDA i SCL? Czy na tej linii I2C masz podpięte jeszcze jakieś inne układy?

Konto nie istnieje · Answer

Chwilowo jest tylko pamięć, docelowo będzie jeszcze druga oraz inny układ, który obsługuje taką prędkość. W zasadzie rezystorów nie dałem w ogóle (są zapewne wewnątrz pamięci).

Konto nie istnieje · Answer

Jeżeli szyna I2C ma docelowo pracować z prędkością 400 kHz sugerowałbym dobór rezystorów pull-up dla SDA i SCL:
http://ww1.microchip.com/downloads/en/Appnotes/01028B.pdf

aj123 napisał:
są zapewne wewnątrz pamięci

Chodzi Ci o to, że zamontowane na module z taką pamięcią? Bo w samej pamięci to ich nie ma.

Konto nie istnieje · Answer

No popatrz, sądziłem że są wbudowane w chip pamięci. U mnie pamięć jest podłączona bezpośrednio przewodami do arduino do arduino i działa :d No nic, wstawię np 4,7k i powinno być okej.

Konto nie istnieje · Answer

Owszem, może działać. Pytanie tylko, czy wiesz z jaką faktyczną prędkością działa szyna I2C w takim wypadku tzn. jak wolno

Konto nie istnieje · Answer

Okej, podpiąłem całość pod oscyloskop i pomierzyłem linię zegarową.
Masz rację, choć spodziewałem się gorszych wyników

Bez rezystorów ~300kHz, z rezystorami 400kHz.
W sumie zastanawiam się dlaczego? Przecież uC wymusza stan niski/wysoki na linii, do tego z konkretną częstotliwością. Prędzej spodziewałbym się tutaj jakiegoś 'burdelu' w postaci desynchronizacji niż obniżenia częstotliwości do stabilnej wartości.

Konto nie istnieje · Answer

Wszystko zależy od całkowitej pojemności szyny I2C. Im większa, tym prędkość mniejsza przy stałej wartości rezystora pull-up. Jak podłączysz więcej układów I2C do tej samej szyny i też bez rezystorów podciągających, to prędkość bardziej spadnie. Ale robi to tak szybko na ile pojemność linii oraz wartość rezystancji pull-up na to pozwala.

Konto nie istnieje · Answer

Jak rozumiem, w takim wypadku dane będą tracone? Bo uC mając zadaną częstotliwość szyny 400kHz 'myśli', że z takową odbywa się transmisja, a w rzeczywistości jest inna. Swoją drogą, podciągnąłem te szyny rezystorami 10k bo takie akurat miałem pod ręką i co prawda częstotliwość zmierzona wynosiła 400kHz, ale sam kształt napięcia daleki był od prostokąta; bardziej przypominał piłę. Jak rozumiem, zmniejszając wartość tych rezystorów poprawię sytuacje?

Konto nie istnieje · Answer

Tak, zbocza będą bardziej strome. Dodano po 3 [minuty]: Mogą być utracone z wielu powodów np. kiedy będziesz chciał wysyłać dane szybciej niż pozwala na to szyna I2C i bufor wyjściowy. To jest ta kwestia, o której pisałem w poście #6.

tzok · Answer

Tak w skrócie, to drivery linii I2C są driverami typu OD, czyli wymuszać mogą wyłącznie stan niski, a za istnienie stanu wysokiego odpowiada właśnie rezystor podciągający... owszem - można użyć wewnętrznych pull-upów po stronie ATMegi, ale nie są one wystarczające do przełączania z szybkością 400 kHz.

Konto nie istnieje · Answer

Okej, rozumiem. W takim razie jakie najmniejsze rezystory mogę zastosować? Nie widzę nigdzie w nocie pamięci parametru w stylu sink current.

Konto nie istnieje · Answer

W nocie, do której link podałem w poście #20 jest (strona 6):

tzok · Answer

4,7 kΩ, ew. 3,3 kΩ, minimalna dopuszczalna wartość to ok. 1,6 kΩ (przy logice 5 V).

Błąd transmisji danych C++ do Arduino - brakujące 64 bajty w pamięci EEPROM 24LC32

How do I reliably send 4 KB of data from a PC through Arduino to a 24LC32A EEPROM so the last bytes are not lost?

Post #1

Post #2

Post #3

Post #4

Post #5

Post #6

Post #7

Post #8

Post #9

Post #10

Post #11

Post #12

Post #13

Post #14

Post #15

Post #16

Post #17

Post #18

Post #19

Post #20

Post #21

Post #22

Post #23

Post #24

Post #25

Post #26

Post #27

Post #28

Post #29

Post #30

Podsumowanie tematu