Uważam, że każdy pomysł jest pożyteczny i dziękuję - szczególnie gdy ktoś generuje ich dużo to często się trafi właśnie TEN fajny

ale .... no ale uważam - że te historie, wykresy, dane, ... nie nie nie panowie ... to już chyba totalny zbytek ... gdzie ktoś będzie analizował poprzednie kompilacje ? ... no chyba że założyć bazę danych dla każdego obrabianego projektu i śledzić te dane za każdą kompilacją ... ale .... to już zabawa w jakąś bazę danych ... nie nie ... brrrr - to nie dla mnie ...

nie wspomnę o poświęceniu niewspółmiernego czasu dla efektu - tak mi się wydaje (choć mogę się mylić)

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

No to może jakiś log w katalogu z projektem z informacjami o zajętości pamięci?

_________________
zapraszam na bloga http://bakcyl8bit.blogspot.com/

To już lepiej brzmi ...

ale z ciekawości niech się jeszcze inne osoby wypowiedzą czy to się w ogóle przyda ? .... czy tylko "będzie bo będzie" ? ok?

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

E tam, wystarczy checkbox i jeśli checked to wtedy zapis do jakiegoś pliku/ew. memo. Na zasadzie FIFO co by było tylko kilka ostatnich wpisów. Jeśli się nie przyjmie - usuniesz właściwość, a jeśli będą chcieli używać - możemy rozbudować o rzeczy, które userzy będą chcieli.




To zależy jak do tego podejść. Jeśli tylko tak jak wcześniej opisałem - to chwilkę tylko zajmie, jeśli coś bardzo rozbudowanego... to wiadomo.

Mi osobiście pomysł wydaje się również fajny i przydatny. Zaproponowane na obrazku rozwiązanie z cieńszym paseczkiem jest również świetny. Nie trzeba by było modyfikować do tego komponentów, a jedynie nałożyć jeden cienki pasek na drugi szerszy z procentami. No chyba, że będzie problem jakiś z wyświetlaniem ich itp., ale wydaje mi się, że nie powinno być.

Również rozwiązanie tego algorytmicznie byłoby proste. Wystarczy sprawdzać nazwę projektu. Jeżeli jest taka sama jak w poprzedniej kompilacji to przepisać wartość zajętości pamięci itp. do paska "chudego", a aktualną wartość tak jak jest teraz.

Zawsze to przyjemna dodatkowa informacja i chyba do zrobienia niezbyt dużym kosztem czasu.

Co do historii i wykresów to zgadzam się z Mirkiem. Potrzebne byłoby to w sumie najbardziej podczas optymalizacji kodu niż podczas samego jego pisania i testowania. Wkład pracy byłby dużo większy niż ta prostsza funkcjonalność, biorąc pod uwagę chociaż wyświetlenie tego optymalnie i czytelnie w gadżecie jak i zbieranie gdzieś danych czy to w plikach czy to w bazie danych.

Ale ogólnie co do samego pomysłu to ja jestem ZA!

------------------------ [ Dodano po: 23 minutach ]

Ewentualnie jeszcze dodać w tooltipie ogólnym na każdy pasek po najechaniu informację (jeżeli jest zmiana między kompilacjami) np. +1,5% lub -0,2% oprócz informacji samym "chudym" paskiem.

------------------------ [ Dodano po: 24 minutach ]

Albo w nawiasie za wartością procentową np. 23% (+0,4%) itp.

------------------------ [ Dodano po: 32 minutach ]

Ewentualnie :> przyszedł mi jeszcze jeden pomysł, że albo dodać przycisk, albo dodać menu po prawym kliknięciu na pasek z funkcją "zapamiętaj pozycje" lub coś podobnego i teraz od tej wartości liczone będą zmiany procentowe i za pomocą chudego paska zamiast od wartości z poprzedniej kompilacji. Wtedy można optymalizować i to dla każdej wartości z osobna - FLASH, RAM, EEPROM. Wadą rozwiązania jest to, że tylko w obrębie jednego projektu (bo zmiana na inny wyzeruje wartości) i jednego uruchomienia programu. No, ale w innym wypadku trzeba byłoby bawić się już w zapisywanie tego gdzieś co komplikuje całą sprawę.

_________________
.

No to słuchajcie - w takim razie zrobiłem wersję 1.0.16



Już wyjaśniam co nowego:

1. pojawiają się MAX wartości dla każdej pamięci o ile występuje w ogóle jej zajętość > niż 0%
2. pojawiają się te ciemniejsze PASKI na dole każdego ProgressBar'a które oznaczają stan procentowy poprzedniej kompilacji

ale Uwaga! ... nie są zapamiętywane te stany dla różnych projektów jak na razie (i nie wiem czy to zrobię) ... na chwilę obecną działa to bieżąco ... czyli jeśli pracujemy nad projektem i co chwilę coś przekompilujemy to dla OKA mamy informację jak było w przedostatniej kompilacji

to tyle - zapraszam do testowania bo w tych nowych opcjach może się pojawić jeszcze jakiś BUG, wtedy proszę o INFO.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

O jak szybko nowsza wersja

Po krótkich testach:
1. Informacja MAX pamięci u mnie w ogóle się nie pojawiła. Sprawdzane na kilku projektach, różnych prockach.
2. Przy zmianie projektu na inny i kompilacji pozostają "chude" paski z poprzedniego projektu. Chyba powinny za pierwszym razem być wyzerowane?
3. Przy małych zmianach i małej ilości zajętego np. RAMu nie da się za bardzo odczytać różnic z samych pasków. Może jednak warto dodać ten zapis w nawiasach o procencie zmiany. Dodatkowo słabszym kolorem i może jeszcze z checkboxem w opcjach dla osób, które chciały by tę informację wyłączyć :>

Tak poza tym to zmiany bardzo mi się podobają! Dziękuję, że jeszcze rozwijasz gadżet

_________________
.

Wydaje mi się że to kwestia kontrastu monitora, bo te napisy zrobiłem takie blado-szare - one nie mogą się NIE pojawić ... Ale zrobię je ciemniejsze - ok.



Racja przy zmianie projektu mogę przecież złapać ten moment i je wyzerować - poprawimy



to fakt



nie wiem czy nie będzie już za dużo napisów i czy nie przestanie to być w ogóle czytelne dla oka na szybko - ale sprawdzę



eeeeeh



nie ma za co przecież dobre pomysły i mi samemu się przydają - więc z chęcią rozwijam

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Nawet jak dałem większy kontrast to nic nie było widać. Dodatkowo na dwóch monitorach sprawdzane było Ja ich nie widzę nawet słabych.

------------------------ [ Dodano po: 9 minutach ]

Sprawdzone na Luna i Kepler i rezultat taki sam

_________________
.

Wartości MAX pojawiają się tylko wtedy gdy jest zajęty EEprom, w przeciwnym razie wartości tych nie ma.

_________________
Migracja z punktu B do punktu C
Pozdrawiam

matw ma racje. Jak dodałem coś do eeproma to pojawiły się wszystkie wartości MAX



Jednak o ile Flash i RAM jest ok to EEPROM chyba wyszedł trochę za duży!

I jak już szlifować program to fajnie by było zrobić odstępy tysiąca w wartościach max tak jak są podawane te normalne wartości z lewej strony :>

------------------------ [ Dodano po: 2 minutach ]

Dodałem więcej zmiennych w EEPROM, aby było więcej niż 1 bajt (aktualnie 4 - 0.8%) i wartość maksymalna jest cały czas taka sama jak na screenie.

_________________
.

Mi z kolei MAX RAM przekłamuje, ale dla ATmega32.


Ale, ale....
W tym samym projekcie jak zużyję więcej RAM-u to już jest poprawnie.


@misiulu, weź powyżej 1% zużyj pamięci EEprom i sprawdź.

_________________
Migracja z punktu B do punktu C
Pozdrawiam

Mnie na tą chwilę starczy wcześniejsza wersja bez bajerów w postaci ostatniej zapamiętanej wartości, gdyż dla mnie to musiał bym mieć jak w github, dostęp do poszczególnych wersji.

Poczekam jeszcze z 2-3wersje przed ściągnięciem .


Mirku kawał świetnej roboty, naprawdę programik jest super .

No sprawdziłem i wynik poprawny się pojawił dopiero powyżej 10 bajtów czyli u mnie > 2,0%. Mówię o EEPROM

------------------------ [ Dodano po: 2 minutach ]

No ale sprawdziłem dla ATTINY25 i tam dla 1 bajta - 0,8% EEPROMU podaje prawidłowo.

------------------------ [ Dodano po: 4 minutach ]

Jeżeli chodzi o RAM to dla Atmegi88PA dla 1 bajta 0,1% podaje mi prawidłowo 1024 :/

_________________
.

Widzę coraz większe postępy i sugerowane dodatkowe funkcje. Odnośnie zapamiętanej ostatniej wielkośc wsadu skompilowanego kodu - tak jak teraz jest oki ale przydałoby się tak żeby cyferkowo pokazało różnice... dla mnie to dosyć ważna funkcjonalność podczas optyminimalizowania kodu libsów np jaki IF albo działanie obliczanie można sprawdzić czy jest najbardziej optymalne w stosunku do poprzedniej kompilacji..
Odnośnie swądu jaki snują malkontenci że opcja ta czy tamta jest niepotrzebna... moim zdaniem lepiej w ogóle nie używać programów narzędziowych np eclipse bo można kompilować i pisać nawet w notatniku.

eeeeh było PEŁNO BUG'ów - przepraszam - ale tak to bywa

w takim razie nowa wersja 1.0.17

pozbawiona BUGów - ale też bez wartości MAXymalnych bo mam problem z ich obliczaniem niestety przy małych procentach zajętości pamięci ... tak naprawdę z odtworzeniem maksymalnej wartości na podstawie ilości zajętych bajtów oraz wartości procentowej podanej z jednym miejscem po przecinku..... Dla zajętości bajtów np RAM dla ATmega32 działa powyżej 10 bajtów a jak się zejdzie w dół to wychodzą głupoty dlatego ZNIKNĘŁY na razie wartości MAX ......... chyba że ktoś wpadnie na pomysł jak je wyliczać



------------------------ [ Dodano po: 2 minutach ]

aha i teraz - gdy jest MAŁA różnica w bajtach pomiędzy poprzednią kompilacją a obecną to pokazuje się ta druga wartość procentowa (bo nie widać dokładnie różnicy w długości pasków ... ale gdy są takie same to znika ta druga wartość - więc mam nadzieję że to i dla was będzie WYGODNE ... bo mi to już pasuje

zobaczcie sobie na zdjęciu wyżej na FLASH - o tym piszę

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

No super fajnie widać jak przy nawet jednej zmiennej jak zmienia się FLASH i RAM

Mirku, a zastanawiałeś się czy nie lepiej dać zamiast stanu poprzedniego w procentach, różnicę? Tak by od razu było wiadomo czy -0,5% czy +0,8%. Teraz trzeba to samemu obliczać po każdej kompilacji.

Widzę, że jeszcze po przełączeniu projektu na inny, paski i wartości liczbowe pozostają z poprzedniego projektu i poprzedniej kompilacji

_________________
.

nooo i nie wytrzymałem i zrobiłem teraz jest w wersji 1.0.18 elegancko



nie trzeba - bo teraz widać jeszcze lepiej różnicę w bajtach a NAWET o ile dokładnie bajtów się różni !



teraz mam nadzieję, że już nie zobaczysz

eeeeh to chyba na dzisiaj ostatnia wersja



------------------------ [ Dodano po: 2 minutach ]

Kurczę - sorki nie mówię tego żeby się chwalić - bo i tak nie mam czym - przecież to dzięki WASZYM pomysłom - ale teraz ten gadżet jest przynajmniej jak dla mnie już MEGA użyteczny - no teraz przeciwnicy gadżetu chyba nie powiedzą - że to tylko powielanie informacji z Eclipsa z Consoli - tu teraz jest już MINI analiza dla oka

ale oczywiście każdy może mieć własne zdanie

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

No nie widzę cacy działa hehe

Teraz to już chyba dokładniej się nie da Wszystko widać przy zmianach i czasem, aż człowiek nie zdawał sobie sprawy, że zmiana jednej zmiennej z 32bit na 16bit zmieniła 2b ramu i aż 48b FLASH

No nie wiem bo znalazłem jeszcze jeden malutki BUG:

Mianowicie po rozwinięciu listy czy to od procesorów, czy od częstotliwości po sekundzie część listy chowa się pod okienko gadgetu i nie można wybrać wartości z niej . W przypadku procków jest to mniej uciążliwe bo można se listę przewinąć tak, aby wskazany procek był ponad okienkiem i go wybrać. W przypadku częstotliwości już tych dolnych wartości nie

_________________
.

Niestety w programie jest BUG.
Program "kradnie" myszkę tzn. odpalam program typu EAGLE, robię zooma scrollem i po chwili okazuje się, że zoom nie działa bo okno EAGLE staje się nieaktywne. Tak samo dzieje się z przewijaniem stron w przeglądarce.

_________________
Czekamy na RedBook'a!

TAK sorki już tego kradnącego BUG'a nie ma - pobierzcie proszę jeszcze raz tą samą wersję - ... ręka mi się omsknęła .... nie dość że solony BUG kradł myszkę (bydlę) .. to jeszcze trzeba się było z nim siłować żeby zamknąć program z TRAY'a .... uuuf dałem mu w ŁEB

------------------------ [ Dodano po: 2 minutach ]



Dobrze prawisz człowieku .... zgadza się ... teraz fajnie wszystko widać

Uprasza się o nie używanie wulgaryzmów rezasurmar

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Teraz wydaje się działać wszystko jak należy

Jak już się czepiać (przepraszam z góry za to) bo w sumie to nic nie znacząca pierdoła, ale może niektórym może nie pasować to, że teraz w części podającej różnicę powinno być duże B - bajt, bo skrótem małe b to może mylić z bitami, chociaż wyżej jest słownie napisane bytes więc można pomyśleć, że to skrót od tego

Jak mówiłem sam nie wiem czy dobrze piszę, więc proszę mnie poprawić jak coś

_________________
.

sorki to już się nie powtórzy .... tak mnie jakoś ten bug wkurzył - ale co racja - to racja

------------------------ [ Dodano po: 5 minutach ]



No dobra można pobrać jeszcze raz programik z dużymi literkami B

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

A ja myślałem, że to mój Windows (bo ma już trochę za uszami) główny winowajca

_________________
Migracja z punktu B do punktu C
Pozdrawiam

Teraz dopiero jak są te nowe opcje zobaczyłem jaki to BAJER z tą informacją o poprzedniej kompilacji bo często np ja robię tak (nie wiem jak wy?), że:

np chcę sobie sprawdzić na szybko co mi zajmie mniej miejsca we FLASH czy np konstrukcja



czy może



itd ... wcześniej trzeba było kilka razy komentować jedno i drugie - a teraz odpada już co najmniej jedna kompilacja w takiej przekładance do sprawdzania ..... MNIAAAM

------------------------ [ Dodano po: kilkunastu sekundach ]

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

No może więcej roboty z tym wyliczaniem, ale wpadłem na coś takiego. Wiadomo, że ktoś to może ulepszyć, albo podsunie mu to drogę do jeszcze lepszego rozwiązania . Może być tak, że nie będzie to działać w każdym przypadku , ale ogólnie może się przyda

Wiadomo, że tak jak liczone było w programie z proporcji używając liczby bajtów i procentów z jednym miejscem po przecinku to brakowało rozdzielczości w wyniku, szczególnie przy małych wartościach. Również trzeba było jakoś przybliżony wynik do wartości faktycznego EEPROMu, FLASHu i RAMu porównać, aby móc go w programie wypisać bo wartości były czasami ze sporym błędem.

Także moja propozycja jest taka, aby pójść od góry zamiast od dołu wyliczać z proporcji
Mianowicie sprawdziłem na atmelu jakie kombinacje wartości FLASHu itp. mają 8 bitopwe AVRy.

FLASH [w kilo bajtach]:

• 256
• 192
• 128
• 64
• 40
• 32
• 16
• 8
• 4
• 2
• 1
• 0,5

RAM [w kilo bajtach]:

• 32
• 16
• 8
• 4
• 2
• 1
• 0,5
• 0,25
• 0,12
• 0,06
• 0,03

EEPROM [w bajtach]:

• 4096
• 2048
• 1024
• 512
• 256
• 128
• 64

Jak widać, aż tak dużo tego nie ma (mogłem oczywiście coś pominąć)

Oczywiście do obliczeń warto wziąć wartość w bajtach, czyli przeliczyć FLASH i RAM.

Także algorytm polegałby na sprawdzaniu po każdej wartości z listy wyżej, jaki mamy wynik w bajtach (wartość zaokrąglona do pełnych bajtów) uwzględniając procent wypluty przez eclipsa i porównaniu go z wynikiem zajętości w bajtach również z eclipsa.

[Wzór]
ilość bajtów faktycznie zajętych z eclipsa == ( wartość z listy w bajtach * procent zajętości z eclipse ) -> wynik zaokrąglony do pełnych bajtów

np. Dla procesora ATTINY prosto z eclipsa
FLASH:

4096 * 5,6% = 229,376 ~ 229
2048 * 5,6% = 114,688 ~ 115
1024 * 5,6% = 57,344 ~ 57

Wartość z eclipsa zajętości w bajtach to 114.
Także pasuje wartość druga (2048) z różnicą wynoszącą 1. Dalsze wartości są o wiele dalej.

Z kilku obliczeń dla różnych wartości i procków wynik po zaokrągleniu, albo zgadza się co do bajtu (przy niskich wartościach zajętości), albo jest o 1 większy przy wartościach dużo większych od pojedynczych bajtów.

Dlatego jakby zrobić margines błędu nawet kilka bajtów to przedziały są wystarczająca duże, aby wykryć jaka to jest faktyczna wartość tego FLASHu itp.

Przy okazji wtedy, dzięki listom, mamy gotową wartość w bajtach do wypisania w gadgecie.

Tak samo można liczyć FLASH, RAM i EEPROM.

No to tyle jeżeli chodzi o pierwszy na szybko pomysł

------------------------ [ Dodano po: 6 minutach ]

A no i z racji tego, że dodane zostały nowe pola tekstowe z różnicami w bajtach to teraz paski mają więcej odstępu między sobą, to może warto byłoby troszkę je rozszerzyć? Były by chyba czytelniejsze i wtedy procenty na nich troszkę odsunąć od górnej krawędzi

Ale nie chce dostać po łbie więc już nic nie piszę

_________________
.

eeeeeś ... no pobrać jeszcze raz wersję 1.0.18 i sprawdzić tłustsze paski

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

hehe, widzę, że Mirek szaleje jak zawsze - chwała mu za to

Mirku, update super, tak 3maj

Jakby narzekali, że Gadget jest za ciężki, zawsze możesz go skompresować UPX'em. Najnowsza wersja po spakowaniu zajmuje 380 928 BAJTÓW, to nawet mniej niż plik spakowany do ściągnięcia (460 758B). Oryginał waży 945 152B

A co do MAX wartości - ok to też jest jakiś pomysł - ale chodzi mi po głowie jeszcze jeden - ale to na później

------------------------ [ Dodano po: 1 minucie ]



Nie - no nie panowie a cóż to jest dzisiaj 923kB w czasach gdy byle program "hello world" napisany w C# waży kilkaset MEGABAJTÓW no bo trzeba w to wliczyć DOT NET .... a tutaj? ... żadnego kociego dot neta nie trzeba

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Noo i nie mam już do czego się przyczepić :/

Wszystko czytelnie i funkcjonalnie.

Sama przyjemność z korzystania

_________________
.