No i niestety tym razem padło na mnie
Potrzebuję ryby
Jestem wyjątkowo uodporniony na asemblera, a staram się coś poprawić pod względem prędkości.
Poniżej kod, który należałoby zastąpić wstawką asemblerową. Kluczowy problemem dla mnie jest przekazanie wartości poprzez wskaźnik.
Pokrótce chodzi o zmianę stanu pinów na PORTB, w zależności od wartości bitu (0, 1) w bajcie.


Jeśli ktoś miałby chwilkę i trochę chęci, to bardzo proszę o wsparcie.
W razie pytań jestem do dyspozycji
Dzięki z góry.

PS
Oczywiście przeglądnąłem poradniki z magick ledami, ale nie pomogły mi

ja tak z marszu sam nigdy nie pamiętam ale wtedy też sam zaglądam do swoich poradników - a czy widziałeś może ten ?

https://www.youtube.com/watch?v=4jIIOERYnwY

Poza tym, kod który pokazałeś można jeszcze nieco zoptymalizować w C a co za tym idzie także w asemblerze ...

Ale zanim coś zaproponuję to zapytam bo nie pamiętam ? czy ty piszesz dobrze programy w asemblerze ? czujesz się w nim jak ryba w wodzie? Dlaczego pytam? Bo jeśli nie do końca czujesz się dobry w ASM to niestety swoją wstawką możesz to niechcący zrobić np gorzej (dłużej) niż to zrobi sam C ....

dlatego kolejne pytanie - czy sprawdzałeś plik *.lss i jak wygląda kod tej funkcji po kompilacji do ASM ? czy uważasz, że można go skrócić ? Moim zdaniem jest dość bardzo optymalny proszę:


no ale dobrym przemyśleniem kodu w C - można go jeszcze ciut stuningować przypomnę twoja funkcja wygląda oryginalnie tak:



jak chodzi o to co wyżej pokazałem w ASM z pliku *.lss

No to teraz powiedz mi też czy korzystasz w ogóle np z programu Eclipse Gadget bo on też już na pierwszy rzut oka pomaga oceniać pewne nasze działania w C w aspekcie tego jak to wygląda później w ASM we flashu - zobaczmy ile pokazuje zajętości flasha w byle testowym programie pustym prawie z tą funkcją:



no to teraz pomyśl - w KAŻDYM warunku IF() odwołujesz się jakby bezpośrednio do pamięci za pomocą wskaźników *data oraz *data1. Oczywiście jak widać po kodzie ASM na górze kompilator i tak był mądry i wrzucił na początku te dane do rejestru, czyli sam zoptymalizował twoje podejście - chodzi o ten fragment:



i później jak widzisz - już całość leci tzn jest sprawdzane z rejestru r24 a nie z RAM więc DUŻO szybciej oczywiście później jest gdzieś przeładowany znowu na potrzeby *data1

ale może by tak od razu w C to zrobić, żeby kompilator zauważył, że my sami mocno kombinujemy w celu polepszenia kodu że tak powiem, to może jeszcze lepiej uda się wymyślić mu dla nas swoją optymalizację ?

w takim razie napiszmy twoją funkcję od nowa ale właśnie na tych zasadach jak to "za twoimi" pleckami zrobił kompilator w ASM



teraz widzisz co zrobiliśmy ? idąc w ślad za kompilatorem w ASM sami powołujemy sobie jedną zmienną ze specyfikatorem "register" aby dać znać kompilatorowi (poprosić go) - te stary - powołaj oddzielny rejestr i wrzuć do niego najpierw daną z *data i dalej porównuj już szybciej na tym rejestrze ... zaś w środku funkcji przeładujemy do niego *data1

no to LU! - i proszę najpierw rzut oka na Eclipse Gadgeta i banan na twarzy - micha się cieszy bo jak widzimy -12 bajtów to znaczy, że pewnie będzie lepiej (choć wiadomo - nie zawsze tak musi być)



no ok to zajrzyjmy do pliku *.lss do ASM


nie wiem jak ty - ale moim zdaniem kod nie tylko jest krótszy więc zaoszczędzamy od razu ileś dodatkowych cykli zegara bo jest też bardziej optymalny od poprzedniego.

Owszem i tak obydwa pięknie posługują się NAJKRÓTSZYMI instrukcjami

sbi
cbi

na potrzeby banglowania bitami - więc nawet poprzednia wersja nie jest taka zła - no ale ta ciut lepsza

czy można jeszcze to jakoś zoptymalizować pisząc to od nowa i w całości tylko jako wstawkę ASM ? nie wiem - pewnie można - ja już dawno nie ćwiczyłem asemblera więc nie wymyślę nic na gwałt ale też mam przeczucie, że no krócej się już nie da

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

Uwaga na koniec, jeśli ta funkcja wykonuje się szybko - a tobie brakuje czasu to może też (być może - tak się tylko domyślam) być tak, że dookoła tej funkcji masz jakiegoś czaso-pożeracza - tzn np nieoptymalnie zorganizowaną jakąś pętlę gdzie tę funkcję wywołujesz itp itd

_________________
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 ]

Na razie dzięki za szczegółowy opis, temat podejmę dopiero wieczorem.
Na szybko:
- temat asemblera do tej pory "odrzucałem", ale czasem podglądam .lss i poradniki i coś za mgłą jest
- Gadżeta używam, ale rzadko, bo niestety nie chce u mnie działać z workspace, który jest na dysku sieciowym i gdy jestem zmuszony przerzucam projekty na dysk lokalny.
- kod, który piszę na pewno jest mało optymalny ale projekt na nim oparty muszę kończyć wreszcie i stąd desperackie próby "przyspieszenia", choć to trochę w ramach takiego testu i ostatecznej próby wzięcia byka za rogi (tzn asm)
- poradniki o asm oglądałem, ale niestety poddawałem się szybko, być może po tym wątku przełamię się

Ale ta funkcja którą tu pokazałeś WCALE nie jest mało optymalna ... sporo osób robi to w pętli, przy okazji przesuwając bit w zmiennej - i sprawdzając go ... ale to zawsze jest o wiele bardziej czasochłonne niż rozbicie tego na IF() jak zrobiłeś ponieważ to da o wiele optymalniejszy kod więc w jakiś sposób podświadomie to czujesz

_________________
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 ]

Pisząc w asm, każdą z ośmiu sekwencji trwającą 5 lub 6 taktów zegara:

można zastąpić (przy założeniu, że wszystkie bity ustawiamy na jednym porcie i żadna procedura obsługi przerwania nie modyfikuje w międzyczasie rejestru PORTB):

Dodatkową zaletą takiego rozwiązania w niektórych przypadkach może być to, że wszystkie bity portu są zmieniane jednocześnie.
Niezależnie od tego, czy tu jest to istotne, czy nie, myślę że tu może się znaleźć pole do popisu dla asemblera.

Niestety wstawek inline assembler nie lubię pisać, więc nie wyręczę w tym względzie
Można zamiast tego skorzystać z mojego poradnika (Miksowanie kodu C i ASM przy użyciu GCC) i napisać taką funkcję w osobnym pliku.

_________________
AVR-GCC - dane w pamięci FLASH

Ja sobie tak myślę że skoro i tak wykorzystujesz 4bity (młodsze) portu które są obok siebie to zamiast robić to na ifach, mógłbyś przypisać starszą połówkę *data po odwróceniu bitów bezpośrednio do portu. Jak szybko to zrobić? zrobic lookup table z 16 wartosciami np:

uint8_t tab[16] =
{
0 ,
8 ,
4 ,
12 ,
2 ,
10 ,
6 ,
14 ,
1 ,
9 ,
5 ,
13 ,
3 ,
11 ,
7 ,
15

};

wtedy odwołujesz się po indeksie i masz odwrócony bajt.

A bo właśnie tego nauczyłem się z poradników, głównie tych o magic ledach
Bardziej pisałem o "reszcie kodu"
Zresztą, za niedługo, całość opublikuję na forum,to będzie można się zastanowić nad dodatkowymi optymalizacjami.
Sprzęt już działa, ale próbuję wycisnąć jeszcze co się da.

Dzięki Panowie, na razie skupię się na tym co napisał Kolega andrews.
Podejmę kolejną próbę przerobienia poradnika o wstawkach asemblerowych, bo czuję, że ten sposób podejścia do asemblera chyba mi najbardziej pasuje.
Spróbuję napisać plik .S z funkcją bazową tak by był czymś w rodzaju biblioteki do reszty projektu.