Przekazywanie danych do kości pamięci

[atmega]

Dziwna nazwa , ale już spieszę z tłumaczeniem o co biega.

Otóż chce zapisywać na kości pamięci leżącej koło kontrolera pewne potrzebne mi nastawy oraz dane do nich . Zajmuje to dość sporo pamięci więc nie dam rady umieścić tego wewnątrz maszynki . Teraz problem : Wysyłając dane z PC w programie napisanym np . w Pythonie ( po szeregowym ) do maszynki ( np. ATmega32 ) która przechwyci daną i np. umieści w kości zewnętrznej tylko ,że zostaje sprawa szybkości tego przekazu a odbieranej danej od komputerka. W sensie czy jeśli masowo będę słać bajty z komputera, to maszynka złazy ten bajt odebrać , przesłać go dalej i bezpiecznie odebrać kolejny bajt ? Przykładowo dla nieulotnej eeprom ?

[K_o_n_r_a_d]

Otóż chce zapisywać na kości pamięci leżącej koło kontrolera pewne potrzebne mi nastawy oraz dane do nich .

Co to znaczy "leżącej"? Inaczej odpoczywającej?

W sensie czy jeśli masowo będę słać bajty z komputera, to maszynka złazy ten bajt odebrać , przesłać go dalej i bezpiecznie odebrać kolejny bajt ? Przykładowo dla nieulotnej eeprom ?

Jaka znowu "maszynka"?

Odpowiedzieć na to pytanie nie da się nie mając podstawowych danych - ile będzie bajtów do zapisu i w jakim czasie, jaka prędkość transmisji itp. Sam zapis do EEPROMu trochę trwa - ile dokładnie to musisz zajrzeć do datasheeta konkretnej pamięci.
Jeśli chodzi o samą transmisję to jeśli napiszesz program tak aby sobie uK z tym poradził to na pewno sobie poradzi, jeśli nie to nie. W zależności od prędkości być może będzie potrzebne buforowanie transmisji itp.
Tak więc jedynym ograniczeniem będzie fizyczna możliwość zapisu do pamięci.
Akurat mam przed sobą notę pamięci EEPROM produkcji Microchipa 24AA1025/24LC1025/24FC1025 i wg niej zapis trwa typowo 3ms na stronę lub bajt. W tej pamięci strona ma 128 bajtów. Więc maksymalna prędkość zapisu do tej pamięci to ponad 42,6kB/s

[atmega]

Dzięki za odpowiedź.

Oczywiście ( bądź nie ) , pisząc maszynka miałem na myśli mikrokontroler . A więc dane , a w zasadzie jedna nastawa + odpowiednie dla niej dane może zawierać się w ok. 1 kB i jeśli byłaby to tylko jedna to spokojnie mógłbym to zrobić na pamięci wewnętrznej , ale takich "paczek" winny jestem zamieścić ok 7. Prędkość transmisji jest oczywiście do ustalenia ( aczkolwiek z samym przesyłem danej to zakładam ,ze problemu nie będzie a jedynie odstęp między kolejnymi bajtami w których procek miałby ten bajt przesłać dalej ).
I właśnie jak najlepiej to wykonać ? Buforować wszystkie dane najpierw , następnie całość przesłać ? Buforować fragmentami , a może jakaś forma odpowiedzi od procesora po przyjęciu danej ?

Z góry dzięki za odpowiedź , i pozdrawiam

[K_o_n_r_a_d]

Ja zrobiłbym to tak, że kiedy otrzymam 1 bajt to od razu przekazuję go dalej (do zapisu), po co czekać na następne, jednocześnie jeśli pojawi się następny jeszcze podczas zapisu poprzedniego to go buforuję. Jak tylko aktualnie przekazywany dalej bajt zostanie przesłany w całości zaczynam to samo z następnym z kolejki.
Sytuacja, w której będzie w ogóle wykorzystywany bufor będzie miała miejsce tylko wtedy, kiedy transmisja pomiędzy pamięcią a uK będzie wolniejsza niż transmisja pomiędzy uK a komputerem. W takiej sytuacji należy dobrze dobrać wielkość bufora i prędkość transmisji, aby nie zgubić danych, które się nie zmieszczą w buforze.
Całe buforowanie i obie transmisje oczywiście najlepiej zrobić na przerwaniach.
W zależności od długości "paczek" można całość podzielić i po każdej "paczce" jako potwierdzenie przesyłać sumy kontrolne.

[atmega]

Dzięki za odpowiedź .

Rozumiem więc, że teoretycznie im niższy BAUD tym mniejsza wielkość bufora który ewentualnie wyłapywałby bajty które nie nadąża , zgadza się ? Teoretycznie też przy najniższym BAUD'dzie nie byłoby żadnych konfliktów dla prędkości pamięci która wymieniłeś.
A sam przesył bajtów z bufora to nie widzę za specjalnie możliwości zrobienia na przerwaniach a jedynie w głównej pętli jakiś warunek o nie-pustym buforze .

Dzięki serdecznie za to ,zę pomagasz .