Mam problem z pamięcią programu kod



Daje taki wynik. Pierwszy przebieg jest OK drugi jest obcięty.



a przebiegi powinny być takie same i nie wiem gdzie mam błąd. Kod pilota podany wprost do zmiennej działa a odczytany z Flash tylko częściowo.
Nie było by problemu gdyby nie mój upór na tiny 13 (64b RAM) . Może się nie da a ja za bardzo kombinuję . Za wszelką pomoc Dziękuje

Próbowałem jeszcze zapisać kod jako liczbę binarnie a potem skonwertować na string ale to też nie działa . Wysyłane dane muszą być takie send("000000000001010100010100").

Przede wszystkim ATtiny13 ma tylko 64 bajty pamięci RAM. Ten kod jest wysoce nieoptymalny, szczególnie dla takiego małego mikrokontrolera.


To nie jest dobry pomysł. Definiujesz wskaźnik jako niezainicjowaną zmienną lokalną, a później używasz go jak tablicy znaków. Trudno przewidzieć, dokąd Ty w ogóle kopiujesz te znaki z tablicy we FLASH.
Powinno być na przyklad tak:
choć i tak nie wiadomo czy wystarczy pamięci RAM. Ewentualnie można jeszcze spróbować usunąć zupełnie linijki:


To nieprawda. Można przekazać do funkcji dane binarne, tylko trzeba ją odpowiednio zmodyfikować. Nawet byłoby to wskazane przy tak małym mikrokontrolerze. Ogólnie, tak jak napisałem, ten kod jest nieoptymalny, a tutaj liczy się każdy bajt pamięci RAM. Jak będziesz próbował ten kod rozbudować, to i tak pewnie zabraknie RAM. Moim zdaniem najlepiej byłoby to wszystko napisać od nowa z uwzględnieniem bardzo ograniczonych zasobów tego mikrokontrolera.

na dwa kody RAM u wystarcza. Dlatego napisałem że się uparłem na AtTiny13a. Co do kodu masz rację to przenosiny z arduino (AtMega328) a tam nie ma problemu z RAM.


ten kod to tylko do sprawdzenia czy działa

Ale jesteś pewien, czy tak Ci się wydaje?

To, że dwie tablice mają razem 50 bajtów, to jeszcze nie wszystko.
Każde wywołanie funkcji powoduje powiększenie stosu, który też jest w RAM.
Każde użycie zmiennej lokalnej (jeszcze w dodatku 16-bitowej, tam gdzie wystarczy 8-bitowa) wewnątrz funkcji zwykle powiększa stos.
Każde zagnieżdżenie (wywołanie funkcji wewnątrz funkcji) powoduje jeszcze znaczniejsze powiększenie stosu (na zasadzie kumulacji).
W Twoim kodzie z funkcji main() jest wywoływana funkcja send().
Wewnątrz funkcji send() jest wywoływana jedna z funkcji send0(), send1() lub sendSync().
Wewnątrz funkcji np. send0() jest wywoływana funkcja transmit().
Wewnątrz funkcji transmit() jest wywoływana funkcja delayus().
Łącznie poczwórne zagnieżdżenie.
We większości funkcji masz zmienne lokalne, które najprawdopodobniej znajdą się na stosie.
Zwykle każda funkcja korzysta z rejestrów, których zawartość musi być przywrócona po zakończeniu funkcji, więc są one zapamiętywane na stosie.

Nie twierdzę wcale, że nie masz racji. Być może tej pamięci jest wystarczająco dużo. Nie chce mi się tego dokładnie analizować i liczyć (może chodzić o pojedyncze bajty), ale pytanie jest takie: Czy Ty to dokładnie sprawdziłeś, czy tak sobie tylko założyłeś na podstawie szacunkowych obliczeń?
...bo to wcale nie jest takie pewne i oczywiste...


A sprawdziłeś, co będzie po usunięciu tych dwóch linii i zmianie char* k1; na char k1[25]; tak jak radziłem, czy po prostu założyłeś z góry, że to nie zadziała?
Nawet jeśli pamięci jest dosyć, to i tak char* k1; to ewidentny błąd, więc może nie zaszkodziłoby spróbować to zmienić.

Sprawdziłem i działa

Pierwszy przebieg z k6 drugi z k1 jako k1[25]





Czyli tak mogę zarezerwować pamięć powiedzmy dynamicznie jak rozumiem. Ponieważ po kompilacji samej zmiennej(stałej) k1[25] mam Data: 0 Bytes a przy kompilacji k1[25] i k6 mam Data 26 Bytes.

Dziękuję za pomoc

Chyba nie bardzo rozumiesz. Do dynamicznej alokacji pamięci służą np. funkcje malloc() i free() z biblioteki standardowej stdlib.h. Linijka char k1[25]; ma na celu po prostu zarezerwowanie 25 bajtów RAM na tablicę o nazwie k1. Miejsce, w którym zostanie tablica ulokowana (w sekcji .data, .bss czy na stosie) jest zależne od sposobu i miejsca zdefiniowania zmiennej.

Na wskazaniach zajętości pamięci obliczanych przez program avr-size zbytnio bym nie polegał. W tym przypadku zmienna (tablica) k1 zostanie najprawdopodobniej umieszczona przez kompilator na stosie, a stos nie jest uwzględniany przez avr-size. Gdybyś zdefiniował ją globalnie, wtedy zapewne zostałaby wliczona w zajętość RAM (w sekcji .bss, kiedy nie jest zainicjowana żadną wartością).

W tym przypadku problem polegał głównie na nieprawidłowym definiowaniu tablic, a właściwie braku ich definicji. Prawidłowe zdefiniowanie tablice powinno wyglądać tak:


To co zrobiłeś natomiast wygląda tak:


Oczywiście w procesie optymalizacji kompilator może np. pewne zmienne usunąć, więc nie zawsze będzie dokładnie tak, jak to opisałem powyżej, niemniej tak kompilator interpretuje intencje programisty.

Podejrzewam, że w trakcie kompilacji otrzymałeś od kompilatora warning o niezainicjowanym wskaźniku, który najprawdopodobniej zignorowałeś.

Dodatkowo kod jest tak nieoptymalny, że osobiście nie napisałbym w ten sposób programu nawet mając do dyspozycji kilka KiB RAM. Używanie 25 bajtów RAM dla zmiennej mieszczącej się w czterech bajtach, tym bardziej kiedy nie jest to uzasadnione uzyskaniem jakiejś innej korzyści (np. w postaci szybkości wykonywania kodu), nigdy nie jest dobrą praktyką. To samo zresztą dotyczy np. używania w pętli wykonującej się kilka razy iteratora 16-bitowego. No ale to temat poboczny, więc nie będę się tu nad nim zbytnio rozwodził