+- HomeMade (http://sp-hm.pl)
+-- Dział: Oprogramowanie (/forum-84.html)
+--- Dział: Technika programowania mikroprocesorów (/forum-85.html)
+--- Wątek: Programowanie ARM, nauka, środowiska programistyczne IDE (/thread-2692.html)
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SP5FCS - 30-07-2016 20:46
Wiem, że w naszym gronie jest wielu kolegów ze sporą wiedzą i doświadczeniem w programowaniu w C, dlatego wszelkie uwagi w trakcie kursu są cenne, oby było ich coraz więcej.
O makrach warto było napisać ponieważ często spotykamy je w wielu kodach i warto znać ten mechanizm aby w pełni zrozumieć przeglądane kody. Zgoda, to samo można zrobić funkcją inline ale początkujący programiści nie bardzo wiedzą jaka jest różnica pomiędzy zwykłą funkcją, funkcją static a funkcją inline.
Ze względu na małe zainteresowanie kursem mam taką propozycję:
1/ Zróbmy jakiś konkretny, prosty przyrząd, sterownik (np. miernik SWR, miernik mocy typu OZ2CPU, prosty sterownik do radia, prosty analizator obwodów z TFT typu NA02, analizator antenowy typu VK5JST, inne propozycje). Może praktyczne zastosowanie modułu i gotowy kod przyciągnie dodatkowych kolegów chętnych do zbudowania i testowania takiego urządzenia.
Do takiego projektu potrzebujemy:
- konfigurację i obsługę GPIO (mamy);
- kanał szeregowy (mamy);
- wyświetlacz (prawie gotowy);
- przetworniki ADC (do zrobienia);
- obsługa DDS lub Si5351 (do zrobienia);
- panel dotykowy (do zrobienia).
Może ktoś z Kolegów ma już opanowane brakujące elementy lub większe fragmenty kodu możliwe do przeniesienia na DiscoF429. Dużą zaletą takiego podejścia jest pokazanie sposobu połączenia obsługi wielu układów peryferyjnych w jednym programie. Fajnie byłoby opracować kilka praktycznych aplikacji na ten moduł i zamieścić na forum.
2/ Warto byłoby do modułu DiscoF429 dorobić płytkę bazową (złącza 2mm -> 2,54mm) + pola do lutowania + dadatki. Przy pojedynczych połączeniach kabelki są OK ale w miarę ich przybywania staje się to bardzo niewygodne. Na takim module możemy umieścić dodatkowe elementy: buzer, złącza enkoderów, złącze klawiatury, rejestry szeregowe, bufory dla ADC, złącze pod DDS, itd. do ustalenia.
Proszę o opinie na ten temat, czy znajdą się chętni do realizacji takiego pomysłu.
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SQ8MVY - 31-07-2016 12:08
(30-07-2016 20:46)SP5FCS napisał(a): ....Warto byłoby do modułu DiscoF429 dorobić płytkę bazową (złącza 2mm -> 2,54mm) + pola do lutowania + dadatki. Przy pojedynczych połączeniach kabelki są OK ale w miarę ich przybywania staje się to bardzo niewygodne....
Ciekawa propozycja. Jednak przy analizie kosztów wykonania takiej "bazy", można przy okazji spojrzeć na takiego gotowca.
Co prawda, nie ma na takiej bazie dodatkowych układów, ale jest dostęp do zwykłych złącz 2.54mm z pogrupowanymi sygnałami interfejsów stm-a.
Złącza szpilkowe na stm429I-Disc1 są w normalnym rozstawie 2.54mm
No cóż, cicho, pusto, jakoś bez ruch w poście..
Więc wkleję takie małe coś. Prostą obsługę zintegrowanego LCD. Na chwilę obecną komunikacja tylko przez SPI, ale pędzonym chyba na max prędkości.
Komentarzy w przykładzie jest chyba dosyć dużo.....
Może będzie jakiś odzew.....
[attachment=11272]
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SP5FCS - 03-08-2016 15:19
Demo Pawła to duży krok do przodu pozwalający nam wreszcie wyświetlać efekty pracy programu. W mojej obsłudze wyświetlacza zamiast makra zastosowałem funkcje static inline do sterowania pinami CS, WRX (DCX). Efekt jest identyczny a kod jak dla mnie bardziej czytelny. Warto jawnie opisać stany na pinie WRX-DCX (Data, Command) aby nie trzeba było pamiętać co jest czym ustawiane.
Typ inline oznacza, że ciało funkcji będzie wstawiane do programu w każde miejsce wywołania funkcji. Funkcja nie jest wywoływana tak jak tradycyjne funkcje poprzez skok, nie jest generowany klasyczny prolog i epilog funkcji. Koszt w kodzie i czasie wykonania takiej funkcji jest dokładnie taki sam jak tego co znajduje się w środku funkcji.
Typ static oznacza, że jest to prywatna funkcja tylko dla moduły wyświetlacza, funkcja nie jest dostępna w innych modułach programu.
Kod:
//////////////////////////////////////////////////////////////////////////////////////////
// aktywacja kontrolera LCD
inline static void lcd_cs_on(void)
{
LCD_CS_GPIO->ODR &= ~ LCD_CS_PIN;
}
//////////////////////////////////////////////////////////////////////////////////////////
// blokowanie kontrolera LCD
inline static void lcd_cs_off(void)
{
LCD_CS_GPIO->ODR |= LCD_CS_PIN;
}
//////////////////////////////////////////////////////////////////////////////////////////
// dane dla kontrolera LCD
inline static void lcd_wrx_data(void)
{
LCD_WRX_GPIO->ODR |= LCD_WRX_PIN;
}
//////////////////////////////////////////////////////////////////////////////////////////
// rozkaz dla kontrolera LCD
inline static void lcd_wrx_command(void)
{
LCD_WRX_GPIO->ODR &= ~ LCD_WRX_PIN;
}Zamiast funkcji sprint warto napisać własną aby działała szybciej, dla częstotliwości można usunąć dodatkowo obsługę liczb ujemnych.
Nie musimy wtedy wczytywać dodatkowego modułu <stdio.h>.
Kod:
//////////////////////////////////////////////////////////////////////////////////////////
// wyswietla liczbe int32 w postaci cyfr
// wspolrzedne X, Y dla cyfry jednosci, kolejne cyfry na LCD w lewo
void lcd_int32( uint16_t x, uint8_t y, int32_t value)
{
uint8_t n = 0;
char buf[9];
char znak = '+';
if (value < 0)
{
znak='-';
value = 0 - value;
}
buf[n++] = '\000'; //ogranicznik wyswietlania cyfr
do {
buf[n++] = (value % 10) + '0'; //kolejne cyfry od najnizszej pozycji
value = value / 10;
} while (value != 0);
buf[n] = znak;
while (buf[n] != '\000')
{
lcd_char_16x24(x-(n*16), y, buf[n]); //wg. wymaganego fontu
--n;
}
}Na zdjęciu demo obsługi wbudowanego wyświetlacza ILI9341, symulacja prostego sterownika radia. Górną częstotliwość możemy zmieniać enkoderem, dolna "udaje" skaner. Niebieski klawisz przywraca skaner do nastawy 3700khz. Na dole ekranu przykłady kolorowych ikon. W tym programie jest wszystko z poprzednich zadań. Paczka z projektem w załączniku ( trzy fonty + kilka ikon).
Na bazie takiego "szkieletu programu" możemy spokojnie zrobić pierwszy prosty przyrząd, tylko zainteresowania ciągle brak.
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SP6LUN - 03-08-2016 16:42
Przetwornik AC na Discovery może pracować z prędkością 2400000 pomiarów na sekundę.
Stosując "undersampling" można by pokusić się o prosty odbiornik na 80m (na początek DSB)
Potrzebny byłby filtr pasmowy, wzmacniacz w.cz+zabezpieczenie wejścia przetwornika, antena, słuchawki, Discovery i program.
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SP6IFN - 03-08-2016 17:26
Cytat:Na bazie takiego "szkieletu programu" możemy spokojnie zrobić pierwszy prosty przyrząd, tylko zainteresowania ciągle brak.Adamie!
To okres wakacyjny pewnie ma w tym swój udział. Koledzy z qToxa obiecali mi że zainteresowanie się zwiększy po okresie wakacyjnym. Ja na bazie dotychczasowych wiadomości usilnie ćwiczę, przerabiam i kombinuję jak mogę, bo zależy mi na tym kursie.
(03-08-2016 16:42)SP6LUN napisał(a): Przetwornik AC na Discovery może pracować z prędkością 2400000 pomiarów na sekundę.Tutaj już jest radio, w zakładce ARM RADIO http://weaksignals.com/ ale górna częstotliwość to 900 kHz
Stosując "undersampling" można by pokusić się o prosty odbiornik na 80m (na początek DSB)
Potrzebny byłby filtr pasmowy, wzmacniacz w.cz+zabezpieczenie wejścia przetwornika, antena, słuchawki, Discovery i program.
Rysio!
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SP5FCS - 08-08-2016 14:36
(03-08-2016 16:42)SP6LUN napisał(a): Przetwornik AC na Discovery może pracować z prędkością 2400000 pomiarów na sekundę.
Stosując "undersampling" można by pokusić się o prosty odbiornik na 80m (na początek DSB)
Propozycja kusząca ale nie na tym etapie kursu, ponieważ taki projekt jak ARM_SDR wymaga dużo więcej wiedzy niż sam procesor czy język C. Do tego dochodzi kodek, filtry, DSP, demodulacja, automatyka itd. Na bezpośrednie samplowanie pasma 80m to nawet ten STMF429 podkręcony do 200Mhz nie wystarczy. Te próbki trzeba potem obrobić aby było z czego wygenerować sygnał akustyczny. Koledze I2PHD udało się osiągnąć na tym module jedynie 900kHz, dlatego raczej należy pomyśleć o przesunięciu pasma w dół, może tak jak sugerował Piotr SP9FKP w okolice pośredniej 465kHz.
Moim zdaniem na tym etapie nauki to zbyt ambitny projekt, szczególnie że chętnych do tworzenia kodu nie widać. W tej chwili trzeba rozpracować kolejne peryferia modułu i być może na tym co już mamy zrobić coś prostszego.
----------------------------------------------------------------------------------------------------------
Według specyfikacji czasów wyświetlacz ILI9341 powinien poprawnie pracować przy zegarze SPI do 10MHz. Testy na module Pawła i moim wykazały, że chodzi spokojnie przy 21 a nawet 42MHz. Przy obsłudze poprzez SPI zegar ma największy wpływ na czas obsługi elementów graficznych.
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SP6LUN - 08-08-2016 18:15
Mój moduł chodzi tylko na 21MHz. Przy 42MHz biały ekran.
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SP5FCS - 08-08-2016 18:41
Andrzej napisz coś więcej:
która wersja Disco, jakie demo, czy uruchamiasz pod deggugerem czy już zaprogramowany moduł poprzez włączenie zasilania. Zauważyłem że czasem pod debbugerem są problemy a samodzielnie moduł działa OK.
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SP6LUN - 08-08-2016 19:17
Mój moduł to Disc1. Na razie jeszcze nie uźywam debugera. Wgrywam binarkę przez zamapowany dysk.
Program to Demo_IL9341.
Jeżeli mój moduł okaże się jedynym niedziałającym przy spiclk=42MHz, będę szukał przyczyny - może zasilanie?.
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SP5FCS - 08-08-2016 19:43
Z Twoim modułem wszystko jest OK.
Moje demo pracuje tylko do 21MHz, Pawła pracuje również na 42MHz. Masze funkcje trochę się różnią sposobem sterowania wyświetlacza i oczekiwania na wolny bufor SPI, stąd ta różnica. Pierwotnie uruchamiałem SPI z zegarem 10MHz ponieważ na tym samym SPI chciałem robić próby z rejestrami szeregowymi na 74HC595. Drugą przyczyną może być ustawiony poziom optymalizacji kompilatora, dla bardzo szybkich funkcji trzeba wyłączyć optymalizację kodu.