[es2]

Nie mam czasu aby sprawdzić dlaczego Arduino ma problem z kompilacją. Podejrzałem jak mam zadeklarowane FreeRam - word FreeRam;
W Arduino zdaje sie jest typ word - unsigned int.
Jak tez już pisałem, Arduino to badziewie, bo wystarczy uzyć debugera i nie trzeba się bawić w jakieś funkcje. Proponuję zaimportować do AS7 i tam pod debugerem sprawdzić. Niestety, do AVR z DW najtańszy debuger kosztuje 450zł, to nie ARM gdzie to samo to 13zł. Może lepiej porzucić UNO i inne wynalazki, i używać AVR z JTAG, gdzie debuger to 30..50zł.

Narzędzia do AVR są drogie, to był jeden z powodów, dla których zrezygnowałem z AVR. Lista powodów jest długa i po dłuższym używaniu ARM, nie dostrzegam zalet AVR. W nielicznych wypadkach AVR ma przewagę, układy o małej liczbie wyprowadzeń (ale debugery drogie) i szeroki zakres napięć zasilania (i wolna praca przy małych napięciach). Do AVR ,ze względu na koszty, mam tylko jeden debuger dla DW i JTAG (Dragon) i dwa JTAG (klon ICE ale jest wolny, więc trzymam w razie awarii Drgona) i jeden do TPI czy jak on tam ma w postaci klona. Do ARM mam jakieś z 15 debugerów, w tym 3 oryginały ST-LINK V2-1, kilkanaście klonów ST-LINK V2 i kilkanaście na płytkach NUCLEO i DISCAVERY. Właśnie, ORYGINALNE płytki startowe, z programatorem to koszt ok 50zł..Porównaj to do ceny oryginału choćby UNO a trzeba by porównywać do kilku płytek MEGA.

[Automatyk231]

Niestety nie stać mnie na taki debuger. Nie mam możliwości jego kupna. Wygląda na to , iż taki stan rzeczy z wyświetlaczem musi pozostać - mimo wszystko dziękuje wszystkim za chęć pomocy

[es2]

Niestety nie stać mnie na taki debuger.

To pozostaje jedna z możliwości:
- uczyć się aby rozwiązać problem.
- kupić MEGA, włączyć JTAG, bo jak znam życie jest wyłączony w fuses zamiast w sofcie, dolutować druty do JTAG, bo MEGA go nie ma (poco, przecież początkujący to geniusze i debugera nie potrzebują) i kupić/zrobić klona JTAG-ICE.
- użyć płytki z ARM,Arduino wspiera trochę ARM, tyle, ze w ARM, problemu braku pamięci raczej nie będzie. ARM przeważnie mają 20..64kB, czasem 128 czy więcej, nieliczne 16, czy 8kb (4kb przypominam sobie w STM, ale nie używał bym takich maluchów). Można więc przyjąć, że min RAM w ARM to 16kB, porównaj to do UNO a nawet MEGA.

Jeśli chcesz zostawić program działający z błędem (błąd niewątpliwie jest) to licz się z tym, że go już raczej nie rozwiniesz i nie może on tworzyć bazy do rozwoju innych projektów. Najlepiej, aby nie kusiło, zachowaj HEX i zniszcz wszystkie kody źródłowe, albo ostatecznie dokładnie opisz jaki jest problem, bo jak użyjesz tych kodów za jakiś czas, to błąd się ujawni.

[Automatyk231]

Szczerze powiedziawszy na obecną chwilę nie mam innego wyjścia niż po prostu pozostawić ten problem i uczyć się dalej - mój promotor nie ma o arduino kompletnie pojęcia więc dlatego zwróciłem się tutaj o pomoc. Dziękuje jeszcze raz z całego serca za zainteresowanie i chęć pomocy

[kaczakat]

Jak podejrzewasz RAM - być może, choć wątpię, to zmień sobie wyświetlacz na LCD 2x16 lub zamień UNO na MEGA, koszt takiego rozwiązania to 10-40zł. Nawet jakbyś miał Atmel ICE (zresztą za 2 stówki w Farnell, wystarczy mieć kogoś znajomego z NIP EU), Dragona (dziś już demode), czy jakiś stary procek i jtaga to i tak Ci to nic nie da. Trzeba się sporo więcej nauczyć niż wymaga Arduino. A tym bardziej właśnie warto mieć jak chcesz się uczyć wewnętrznej budowy i superoptymalizacji, jak robisz jakiś program typu wymiana rozrządu przez rurę wydechową podczas skoku na bangi. Z Arduino to akurat jest bardzo opcjonalne. Nie pasuje UNO to bierz MEGA, kod w 99% będzie działał tak samo. Zresztą jak sobie zainstalujesz Atmel Studio 7 to masz tam symulator, wrzuć sobie jakiś kod z Internetu i spróbuj go ogarnąć co się dzieje. Więc przestań żałować, że nie masz możliwości kupna. Zanim użyjesz jakiejkolwiek biblioteki do ekranu ogarnij wszystkie możliwe funkcje, a dopiero potem baw się w łączenie w całość.
Tak zerkając już sporo uzyskać. A co dopiero gdy zajrzeć do tworzenia menu, zarządzania czasem. Arduino do takiej pierdoły spokojnie wystarczy, po to zostało stworzone, ale trochę też się trzeba nauczyć. Adafruit buforuje cały ekran i od razu łyka 1024b,potem lecą animacje i mega pierdół, używa UART (+200b) - nie tak łatwo zeżreć 2kb. Na bibliotece ASCI w przykładach gość ma gierkę 2D i stację pogody, działa na 4kb procku z 256b RAM.
Niestety nawet jak masz już dużą wiedzę techniczną to i tak trzeba się pobawić od poznawania typów zmiennych, co można ugrać, czemu raz dajesz define, a czasem przypisujesz int do pinu, migania led, i wszystkimi tymi "pierdołami" w kursach, bo w każdym z nich jest kawałek wiedzy ogólnej i za chwilę niezbędnej.
Jak @error105 Ci wskazał, że to może być inny ekran to nic nie zadzwoniło? Wystarczy jedna błędna komenda i program leży, bo ekran już nie ruszy bez kolejnej inicjalizacji/resetu. A to pewnie tylko w setup, czyli zostaje reset. Jak nic nie pokazuje to sprawdź czy wisi program - migaj ledem z boku w jakimś przerwaniu, używając millis czy timera z biblioteki. Jak ekran umiera to wina biblioteki, a procek sobie działa. Oleda można zasilać z pinu procka, bierze poniżej 20mA, przypisz sobie przycisk, do przycisku funkcję, niech robi reset zasilania, ponowną inicjalizację i start ekranu. Jest to wina ekranu to go wywal, kup oleda SSD czy zwykly LCD. Tak samo można wyrzucać informacje co się dzieje w programie używając UART. Możesz mieć swojego malutkiego Samuela L Jacksona, który Ci będzie śpiewał co zrobił procek na UART (z makrem F(), żeby nie zjadało ramu) "Tararara, zgasiłem led", "Tararara, odświeżyłem ekran", itp. W Twoim programie testujesz ekran używając tylko ekranu i tego czarnego robaczka, którego w ogóle nie znasz.

[es2]

Właśnie!, Jak picze @kaczakat, biblioteka OLED pożera 1kb, a wolnej pamięci jest 1,4 z 2kb.Znów coś nie gra, prawda? Arduino to nie HAL i tam funkcji DeInit nie ma9przynajmniej nie spotkałem).
Co do migania ledem, to nie w przerwaniu. Przerwanie może działać a program główny wisi. Miganie robi sie w petli głównej, aby było zauważalne, można użyć millis (choć są lepsze sposoby) i migać np co pół sekundy.

[kaczakat]

On nie używa TEJ biblioteki od Adafruit, która zjada 1024b, wspomniałem tylko, że w Tamtej działa grafika i debug na UART pomimo zbuforowania całego ekranu. Jemu się po prostu wiesza wyświetlacz, bo albo ma inny chip niż biblioteka przewiduje, albo źle jej używa, albo oled jest walnięty. Albo wszystko powyższe - pech początkującego, który wyskakuje z nożem na strzelaninę.

[Automatyk231]

Haha dobre porównanie zauważyłem że OLED wiesza się również w innych momentach- jak mu się podoba to sie zawiesza... A tak naprawdę nie mam kogo innego zapytać o to ponieważ nikt nie ma o tym wiedzy spróbuję zainwestować w inny wyświetlacz może

[error105]

Kup sobie kilka oledow na AliExpress na sterowniki SH i SSD i tyle. Poczekasz miesiąc a koszt zamknie się w max 20zl

[es2]

spróbuję zainwestować w inny wyświetlacz może

A jakie właściwie informacje musisz am wyświetlać? Grafika jest konieczna? Musi być OLED czy LCD wystarczy?

Są fajne wyświetlacze OLED, zgodne z popularnym HD44780 ale mogą wyświetlać także grafikę. Rozdzielczość 100x32 lub (alfanumeryczny) 2x16. Interfejs równoległy 4 i 8 bit oraz szeregowy SPI 4W (nie miałem okazji wypróbować go).
W trybie graficznym, zapomnij oo badziewiarskich konwerterach I2C na PCF8574 jeśli już to FAST i2C 16-bit. Wtedy wysłane 100x32/8 bajtów zajmie 54ms (może da się przyspieszyć do 27ms ale pewny nie jestem), na PCF "tylko" 144ms.
Naturalnie po co kombinować z I2C jeśli w SPI cały ekran graficzny prześlesz w niecałą ms. W trybie równoległym, 8-bit 200us, 4-bit 400us ale przez magistralę XRAM, jak GPIO to kilka razy wolniej.

Oczywiście obliczenia sa teoretyczne, mogłem się pomylić. Wyświetlacz wypróbowałem w praktyce w trybie 8-bit zarówno w trybie alfanumerycznym (są 3 zestawy znaków i 8 własnych) jak i graficznym.