Skocz do zawartości

Elvis

Użytkownicy
 Wyświetl profil  Zobacz aktywność

  • Zawartość

    2425

  • Rejestracja

  • Ostatnio

  • Wygrane dni

    167

Posty napisane przez Elvis

  1. · Edytowano przez Elvis

    A ja się wtrącę, chociaż wcale nie po to żeby komukolwiek przyznawać lub ujmować rację.  Chciałbym tylko wyjaśnić kilka spraw zanim osoby zaczynające przygodę z Raspberry Pi lub innymi komputerami jednopłytkowymi zupełnie się pogubią.

    Tematem tej dyskusji jest robienie tworzenie kopii zapasowej zawartości karty SD - a to można zrobić na wiele sposobów. Typowe obrazy kart mają rozszerzenie .img i zawierają dokładną kopię - sektor po sektorze całej karty. Taki obraz jest dość duży, ponieważ zawiera zarówno ważne dane, jak i ogromne ilości samych zer umieszczonych w nieużywanych obszarach pamięci. Jego zaletą jest prostota użycia - wystarczy włożyć kolejną kartę do czytnika i nagrać obraz. W ten sposób dostajemy dokładną kopię zawartości karty, niejako niezależnie od systemu (możemy tak skopiować zarówno obraz Raspbiana, Windowsa IoT, czy Androida), ale również niezależnie od platformy (tak samo przygotujemy i nagramy obraz np. dla Odroid-N2, czy STM32MP1). Wadą takiego rozwiązania jest wspomniana wielkość obrazu, która odpowiada wielkości karty. Co prawda taki obraz można bardzo skutecznie skompresować, ale "goły" plik będzie miał wielkość zbliżoną do pojemności pamięci, czyli powiedzmy 16GB, 32GB itd.

    Natomiast metoda zaproponowana przez kolegę @ethanak działa zupełnie inaczej - zamiast kopiować wszystko co jest na karcie i tworzyć dokładny obraz, kopiujemy tylko pliki. To znacznie bardziej przypomina postępowanie na standardowym komputerze, bo w końcu robiąc backup naszych super-fajnych projektów najczęściej kopiujemy tylko pliki, a nie cały obraz dysku, który zawiera terabajty zer, albo nieużywanych danych. Stosowanie takiej metody wymaga jednak nieco więcej wiedzy i bywa trudniejsze przy odzyskiwaniu obrazu.

    Warto natomiast zapamiętać, że w przypadku Raspberry Pi cały obraz systemu jest przechowywany w postaci plików - więc można zastosować obie metody. Każda ma wady i zalety, o których warto byłoby podyskutować, ale w znacznie spokojniejszej atmosferze.

    Są również dostępne platformy, gdzie nie wszystkie dane są zapisywane w postaci plików - i wówczas metoda zaproponowana przez kolegę @ethanak-a nie zadziała, albo raczej nie całkiem. Ale w przypadku Raspberry Pi, rsync jak najbardziej nadaje się do tworzenia kopii zapasowej karty - i za jego pomocą można skopiować tylko zmienione pliki, nie zachowując ogromnej ilości niepotrzebnych danych.

     

    • Lubię! 2

  2. @PrimeSoul przeklikałem cały przykład w najnowszym CubeMX 5.4.0 i wszystko działa poprawnie - chociaż używam aktualnie Atollica zamiast OpenSTM32. Wcześniej te same przykłady robiłem na CubeMX 5.3.0 używając OpenSTM32 i ten przykład działał bez problemu.

    Sprawdź, czy na pewno wybrałeś poprawnie wszystkie opcje odnośnie DMA, w szczególności kierunek: "Memory To Peripheral"

    pwm09.thumb.png.7c7d6be9fdc4fb73bb30bb29cd0a606a.png

    Jak przystało na programistę mogę spokojnie napisać "u mnie działa" 😉

    • Lubię! 1

  4. Skoro za pomocą LED-a i multimetru widzisz, że pin jest poprawnie sterowany, to nie musisz nic w kodzie zmieniać - przecież działa poprawnie.

    O ile rozumiem problem jest albo z działaniem samego programu, albo sterownikiem silnika. Jeśli podłączysz diodę i uruchomisz program, to działa / miga poprawnie?

    Pytanie pomocnicze: z czego zasilasz silnik oraz bluepill?

  5. Pierwsze pytanie - czy używasz płytki Nucelo-103rb, czy czegoś innego? Chodzi mi głównie o to czy używane piny są wolne.

    Druga sprawa - próbowałeś testować diodą led lub multimetrem? Warto zacząć od czegoś prostego, upewnić się że sterowanie pinem działa i dopiero wtedy podłączyć silnik.

    I ostatnie pytanie - testowałem na Nucleo103rb kod sterujący PA15, inicjalizacja taka jak u Ciebie, tylko z dwoma linijkami o których pisałem wcześniej - mógłbyś sprawdzić czy taki program działa poprawnie?

    Jeszcze jedno pytanie - napisałeś: "wstawiając breakpointy i przeglądając ODR można zauważyć, że stan na pinie zmienia się," - jak rozumiem to znaczy że zmienia się wartość w rejestrze ODR, co w sumie jest oczywiste - ale czy testowałeś stan pinu?

    • Lubię! 1

  6. Może i faktycznie CubeMX, jakoś się zapatrzyłem na "Korzystając z kursu STM32 F1 HAL #4".

    W każdym razie PA15 został wybrany nieco niefortunnie. W datasheecie jest taka informacja:

    pa15.thumb.png.97e5f172805fc0e07a38d2d7a4899296.png

    Jak widać domyślnie ten pin jest używany przez interfejs JTAG.

    Dlatego może nie działać jeśli go odpowiednio nie skonfigurujemy. Po pierwsze wybierając piny trzeba sprawdzić do czego są podłączone oraz w dokumentacji upewnić się, czy to na pewno zwykły pin, a nie jakiś "specjalny". W tym przypadku pewnie najłatwiej byłoby skorzystać z innego pinu i po sprawie.

    Natomiast jeśli bardzo chcemy używać PA15, a JTAG nie jest nam potrzebny, trzeba zmienić jego funkcję na GPIO: 

    	 __HAL_RCC_AFIO_CLK_ENABLE();
	 __HAL_AFIO_REMAP_SWJ_NOJTAG();

    Właśnie dlatego pytałem o kod konfigurujący pin - bo jeśli tego wywołania w nim nie ma, to PA15 ma prawo nie działać. Tzn. działa, ale jako JTDI i stan ODR nie ma najmniejszego znaczenia.

    Z tego co widzę CubeMX nie wyłącza JTAG-a, więc możliwe że to była przyczyna całego zamieszania.

    • Lubię! 1

  8. 11 godzin temu, RFM napisał:

    No i jakoś nie pochwaliłeś sie projektem z ARM (oczywiście, chodzi o projekt na tyle zaawansowanym, że AVR nie dałby rady).

    Z tego co pamiętam, reguły PPF na forum zabraniają takich osobistych przepychanek, przechwałek itd. Proponuję użyć google, skoro o [Imię i nazwisko usunięto], czyli RFM / es2 / InspektorzeGadget można wszystko wyszukać - zarówno doświadczenie zawodowe, wykształcenie, jaki i projekty, którymi się tutaj przechwala  - to i o mnie można. Wystarczy tylko chcieć.No chyba że poznanie obsługi google to też rok ciężkiej pracy 🙂

  9. Tak jak wcześniej myślałem, ten temat wcale nie służy opisaniu akceleratora, czy jak ten sterownik wyświetlacza się nie nazywa, tylko przechwalaniu się i budowaniu własnego ego.

    Nie zamierzam się do tego przyłączać, bo to chyba niezgodne z nową polityką forum (PPF), chociaż czasem faktycznie ciężko się powstrzymać. A odpowiadając możliwie ogólnie, żeby nie być posądzonym o personalne wycieczki - tak pracowałem z różnymi mikroprocesorami i mikrokontrolerami, w tym opartymi o rdzenie ARM. Wiem jakie narzędzia się do tego używa i jak skomplikowane jest to zadanie.

    Więc jeszcze raz napiszę - przesiadka z atmegi na stm32 to nie jest skomplikowane zadanie. Zaletą stm32 jest bardzo rozbudowana rodzina układów, więc jak ktoś pozna małe i proste jak chociażby stm32f2, zawsze może zająć się trudniejszymi - jak chociażby wspomniany stm32h7, albo stm32mp1. Ale jeszcze raz podkreślam - to nic trudnego, a już na pewno poznanie tych układów nie upoważnia nikogo do przechwalania się, ani ubliżania osobom używającym Arduino.

  10. ARM nie ma peryferiów, bo to nazwa firmy. Nawet Cortex-M3 prawie peryferiów nie ma - raptem NVIC, SysTick, pewnie kilku teraz nie pamiętam. Cała reszta to dzieło firmy ST (czy tam STMicroelectronics), w zależności od wybranego układu modułów jest więcej lub mniej, ale nie demonizujmy - przez 3 lata to można się nauczyć własne moduły projektować.

    Moim zdaniem przesiadka z atmegi na stm32 to nic specjalnie trudnego. Wymaga trochę wysiłku, ale w żadnym wypadku to nie jest tytaniczne wyzwanie, a opanowanie peryferiów stm32 to wcale nie powód do dumy i chwały. Po prostu kolejny mikrokontroler, ani najtrudniejszy, ani najłatwiejszy do opanowania.

  11. · Edytowano przez Elvis

    W sumie to offtopic, ale jedna rzecz nie daje mi spokoju:

    18 godzin temu, RFM napisał:

    Fakt, że przejście na ARM to ok roku intensywnej (10..16 godzin dziennie, przez 6..7 dni w tygodniu) pracy ale później pisanie programu to przyjemność.

    Rok to 52 tygodnie, mnożąc przez 6 dni i 10h daje to 3120 godzin, czyli w przeliczeniu na typowy etat 160 godzin miesięcznie - 20 miesięcy. Przyjmując 16 godzin i 7 dni w tygodniu to już 5824 godziny, czyli 36 miesiące, a więc 3 lata pracy na pełny etat...

    I tak się zastanawiam, dlaczego opanowanie prostych ARM Cortex-M zajęło aż tak dużo czasu? Dla porównania studia inżynierskie to ok. 2000-2500 godzin, a znam niejednego studenta, który pisze całkiem sprawnie programy na STM32. To kwestia talentu, zdolności, czy całe to oszacowanie potrzebnego czasu to jedna wielka bajka?

    • Lubię! 2

  12. Dodatek w postaci modułu ISD nie jest zbędny, jest ważnym elementem projektu. Ten sam projekt można zrealizować na mnóstwo sposobów, jedne są lepsze, inne gorsze - ale które są jakie zależy od kryteriów oceniania. Czasem lepsze jest to co wymaga mniej elementów, ale innym razem to co jest np. bardziej bezawaryjne, albo łatwiejsze (szybsze) do implementacji. Nie można tak odgórnie zakładać, że coś jest złe bo mi się nie podoba, albo jest do niczego bo ja bym to inaczej zrobił. W sumie tak podchodząc do tematu można każdy projekt skrytykować, a chyba nie o to chodzi.

    Projekt kostki nie będzie produkowany seryjnie, powstał aby zrealizować pewną funkcjonalność i z tego co pisze autor - spełnia oczekiwania.

  16. To może ja trochę źle zrozumiałem. Jeśli to linia zasilania 3.3V to powinno być ok, zrozumiałem że chodzi o zwykły pin GPIO, co pewnie też by działało, ale raczej krótko. Jedyne o co bym się obawiał to ew. zakłócenia, ale bez oscyloskopu ciężko sprawdzić co tam się dzieje. Jak będzie się malinka resetowała to pewnie coś jednak siało.

    • Lubię! 1

  17. Nadal nie jestem pewien czy taki pomiar pokazuje chwilowe zmiany, ale nawet zakładając że Imax jest 63mA i nie generowane są żadne impulsy napięciowe, czy prądowe to w przypadku RPi mamy:

    Cytat

    A maximum of 16mA per pin with the total current from all pins not exceeding 50mA

    Więc ja zostanę przy moim zdaniu, że długo takie połączenie nie podziała 😞

  18. Bardzo mocno odradzałbym podłączanie wentylatora bezpośrednio do GPIO jakiegokolwiek mikroprocesora. Po pierwsze 55 mA to duży prąd dla pinu, który nie jest przystosowany do dostarczania prądów - ma sterować napięciowo, a nie cokolwiek zasilać. Druga sprawa to sam sposób pomiaru. Zmierzona wartość to prąd średni w czasie pracy. Podczas uruchamiania pewnie był większy - jako test proponuję zmierzyć prąd przy zatrzymaniu wiatraczka palcem. Co więcej każdy silnik potrafi generować spore zakłócenia, które trafią bezpośrednio do skomplikowanego procesora... Moim zdaniem to przepis na uszkodzenie malinki.

  22. Ta dyskusja już dawno nie ma sensu, albo chociaż związku z tematem watku - więc może prośba do moderatora o wydzielanie tej zaciętej dyskusji do oddzielnego tematu? W każdym razie moje podsumowanie jest takie: oryginalny kod działa tak samo z const, jak i z define. Natomiast ogólnie lepiej używać define niż const, a najlepiej constexpr. Chyba że ktoś ma inne zdanie, ja chętnie dowiem się czegoś nowego 🙂

    • Lubię! 1

  23. To chyba udało ci się w końcu oszukać kompilator. W sumie to wiara w moc optymalizacji jest ułomna, a jak widać na załączonym obrazku nawet prosty program może przechytrzyć kompilator.

    A tak z ciekawości - gdyby zamiast const użyć constexpr to kod byłby taki sam w obu przypadkach? Może należy jednak polubić C++11 albo wrócić do stylu C.

    • Lubię! 1

  25. Proponuję przeprowadzić następujący test:

    Po pierwsze należy porównywać programy wynikowe, a nie efekty pośrednie działania kompilatora. Wobec tego przykłady należy trochę zmienić - żeby się kompilowały i nie były puste:

    test1.c 

    
void digitalWrite(int a, int b)
{
        volatile int xa = a;
        volatile int xb = b;
}

#define PIN 2

int main(void)
{
    digitalWrite(PIN,1);
}

    test2.c 

    void digitalWrite(int a, int b)
{
        volatile int xa = a;
        volatile int xb = b;
}

const int PIN =  2;

int main(void)
{
    digitalWrite(PIN,1);
}

    Kompilacja: 

    avr-gcc -Os -c test1.c 
avr-gcc -Os -c test2.c 
avr-gcc -Os -Wl,--gc-sections -mmcu=atmega328p -o test1.elf test1.o
avr-gcc -Os -Wl,--gc-sections -mmcu=atmega328p -o test2.elf test2.o

    Teraz można porównać co wyszło: 

    elvis@raider:~/blink_test/test$ avr-size test1.elf 
   text	   data	    bss	    dec	    hex	filename
    178	      0	      0	    178	     b2	test1.elf
elvis@raider:~/blink_test/test$ avr-size test2.elf 
   text	   data	    bss	    dec	    hex	filename
    200	      0	      0	    200	     c8	test2.elf

    Jak widać po danych nie ma nawet śladu, ani w segmencie data, ani bss. Co ciekawe wersja z const daje większy plik wynikowy - ale to już taki urok kompilatora 😞

    Można zawsze wygnerować faktycznie użyte pliki i popatrzeć czym się różnią: 

    elvis@raider:~/blink_test/test$ avr-objdump -d test1.elf > test1.s
elvis@raider:~/blink_test/test$ avr-objdump -d test2.elf > test2.s

    Po stałej PIN w obu przypadkach nie ma śladu, natomiast faktycznie kompilator trochę gorzej się zachował po zobaczeniu const. W każdym razie używanie const nie powoduje zużycia pamięci RAM, ta zmienna, która była widoczna w plikach .o jest usuwana przez linker, bo nie jest do niczego potrzebna.

    • Lubię! 1
×
×
  • Utwórz nowe...