Skocz do zawartości

vp32

Użytkownicy
  • Zawartość

    19
  • Rejestracja

  • Ostatnio

Reputacja

0 Neutralna

O vp32

  • Ranga
    2/10

Ostatnio na profilu byli

Blok z ostatnio odwiedzającymi jest wyłączony i nie jest wyświetlany innym użytkownikom.

  1. A co ogólnie sądzie o pierwszym sposobie działania?
  2. Hej Potrzebuję podpowiedzi, bo przyznam że nie wiem jaka jest dobra praktyka w takiej sytuacji. Jest układ, który ciągle nadaje po RS232 dane w zależności od naciśniętego przycisku (wewnątrz tego układu). do tego nie ma dostępu mam tylko dane po RS W paczce danych która nadlatuje (to już w moim układzie) wyłapuje bajt który odpowiada za stan tych przycisków. Teraz w zależności od stanu dwóch bitów muszę zmanić stan dwóch przekaźników. Dane te lecą non stop tylko zmienia się stan bitu w zależności od tego czy dany przycisk jest wciśnięty. Mając wyłapany bit jak prawidłowo powinna wyglądać zmiana stanu portu. Wydaje się ze najprostszą metodą było by proste przepisane stanu tego bitu na port, ale upraszczając to, czy coś takiego z programistycznego puntu widzenia jest prawidłowe: while(1){ PORTB |= (1<<PB5); } bo to co opisałem wyżej sprowadzało by się do ciągłego wpisywania albo 1 albo 0 do portu. Ma to sens? Zastanawiam się czy porty wyjściowe moga być tak traktowane, czy lepszą praktyka byłoby wyłapanie zmiany i dopiero wpisanie. Tylko jak programowo wykryć zmianę stanu?
  3. A czy to prawda że adresy w SP nie mogą być dowolnymi adresami. Mówię tak ogólnie o wpisywaniu adresu do SP. Bo zauważyłem że nie da się wpisać do SP dowolnej wartości, zawsze LSB jest zero na dwóch pozycjach tj. .........00 Szukałem czy jest gdzieś o tym napisane w dokumentacji ale nie znalazłem.
  4. Z lektury PM0056 po części narodziły się pytania i wątpliwości. Aby nie było problemów z działaniem przerwań wyrównanie powinno być włączone poprzez ustawienie na 1 bitu STKALIGN. Tylko w debugerze widać że ten bit jest cały czas wyzerowany. Nawet STMCubeMX go nie ustawia przy inicjacji. Co prawda ARM pisze że wartość początkowa (po resecie) tego bitu powinna być 1 (tak zaleca) to nawet w uC które mają najnowszą rewizję ten bit jest zero. Ciekawe czy jakbym sam na starcie ustawił ten bit (pomimo że sami programiści STM pisząc kod do wygenerowania tego nie robią) to byłby jakiś błąd a może to nie ma zupełnie znaczenia. Szkoda że nic na ten temat STM nie pisze. Jeszcze jedna taka sprawa. A może dwie. 1. Chcę się upewnić czy dobrze rozumiem. to wyrównanie do 8 bitów czy 4 bajtów oznacza że adres w SP wskazujący na wierzchołek stosu jest odpowiednio wielokrotnością bajta, np wyrównanie oznacza adres w SP = 0x23FFFFE0. i 2. czy to nie jest tak że adres SP zawsze jest zwiększany o 4 bo dostęp do stosu jest zawsze 4 bajtowy?
  5. Tak ogólnie to trochę zacząłem szukać bo wydaje mi się że temat dość istotny (chyba) a raczej przemilczany. Nie udało mi się znaleźć informacji co się stanie jak nie będzie tego wyrównania, kiedy mogę to sprawdzić i się "przejechać" na tym. Druga sprawa ten atrybut interrupt wyrównujący stos przy przerwaniu. Przecież na stos jest odkładane kilka rejestrów sprzętowo zanim zostanie wykonany kod przerwania, więc jaki jest sens wyrównywać stos po odłożeniu na nim czegoś co powinno zostać wyrównane przed początkiem odkładania. To nie AVRy gdzie trzeba było to robić ręcznie. Wg opisu w technical reference jeśli bit STKALIGN jest ustawiony to uC przy wchodzeniu do przerwania sam wyrównuje stos ale jednocześnie w rejestrze xPSR ustawia bit 9 informując że wyrównał stos. natomiast wg dokumentacji STM32f103 ten it w xPSR jest zarezerwowany, nie ma takiego bitu. PS. taka prośba od innej strony. próbuje pozbierać dokumantacje od ARM na temat rdzenia i natknąłem sie na mur pewny, może mi pomożesz. Jakie są nazwy doakumentyów opisujących całość łacznie z podziałem na referencje, bo są Technical Reference Manual Cortex-M3 z podziałem na rewizje Generic User Guide Cortex-M3 Devices tu chyba bez rewizji Architecture Reference Manual Armv7-M tu też chyba bez rewizji (popraw jeśli się mylę) Ale wydaje mi się że powinno byc jeszcze Technical Reference Manual ARMv7-M i Architecture Reference Manual Cortex-M3? tych nie moge znaleźć.
  6. Z tego co doczytałem z datasheet STM32F103C8 bazuje na 3 rewizjach, piszą że można to odczytać z obudowy (ale nie mogę dojść o czym mówią tak zamieszali to kodowanie) oraz można odczytać rejestr SCB->CPUID, więc mogą się zdarzyć pierwsze wersje Gdzie znalazłeś opis tego atrybutu na stronach ARM. Może o to Ci chodzi, bo ja znalazłem coś takiego Support of a 4-byte aligned stack (CCR.STKALIGN == ’0’) in ARMv7-M is deprecated PS. nie do końca również rozumiem ich skrót myślowy (patrząc po debugerze ten bit zawsze jest zero)
  7. Sprzętowe wyrównanie jest od którejś tam rewizji r1p0 chyba ale w r0p0 w ogóle jej już nie ma więc sprzęp nie wyrówna. Co wtedy się dzieje i w ogóle co będzie jak nie będzie tego wyrwnania? funkcja oryginalna void SysTick_Handler(void) { HAL_IncTick(); } i po wygenerowaniu asm SysTick_Handler: 08000be8: push {r7, lr} 08000bea: add r7, sp, #0 187 HAL_IncTick(); 08000bec: bl 0x8000d34 <HAL_IncTick> 191 } 08000bf0: nop 08000bf2: pop {r7, pc} A teraz po dopisaniu atrybutu interrpt __attribute__((interrupt)) void SysTick_Handler(void) { HAL_IncTick(); } po wygenerowaniu asm SysTick_Handler: 08000be8: mov r0, sp 08000bea: bic.w r1, r0, #7 08000bee: mov sp, r1 08000bf0: push {r0, r3, r7, lr} 08000bf2: add r7, sp, #0 187 HAL_IncTick(); 08000bf4: bl 0x8000d44 <HAL_IncTick> 191 } 08000bf8: nop 08000bfa: mov sp, r7 08000bfc: ldmia.w sp!, {r0, r3, r7, lr} 08000c00: mov sp, r0 08000c02: bx lr To samo jest dla każdego przerwania. mam tu SysTick bo w CubeIDE od razu po wygenerowaniu kodu działa przewanie
  8. Wytłumacz mi jak możesz jakoś prosto po co to wyrównywanie stosu i co to w ogóle znaczy? Standard to jedno ale to ma czemuś służyć, czemu? Sprawdziłem, ten atrybut nie jest ignorowany przez GCC. dodaje parę linii kodu na początku i na końcu przerwania.
  9. Cześć Próbuję zrozumieć co to jest stack aligment w tych uC i związany z tym bit STKALIGN w rejestrze SCB->CCR O co ogólnie chodzi z tym wyrównaniem podczas wchodzenia do przerwania Druga sprawa to (w związku z tym wyrównaniem) dodawanie atrybutu interrupt do nazwy przerwania np __attribute__((interrupt)) void TIM3_IRQHandler(void) {} Podobno dla gcc i STM32F103 jest to konieczne ale pliki generowane prze CubeMX lub CubeIDE tego nie dopisują? PS. do rewizji jeszcze dojdę z pytaniem za chwile, ale najpierw po kolei zakładając ze mam przy sobie jakiś procek ze starą rewizją. Tak coś doczytałem ale widać nie do końca.
  10. Tak sobie czytam o różnicach pomiędzy dwoma rdzeniami, starszym M0 a nowszym M0+. Podają że jednym z ulepszeń jest zmniejszenie czasu obsługi GPIO i dwóch do jednego cyklu zegarowego. Ale to jest tylko takie ogólnikowe stwierdzenie. Czy spotkał się ktoś z Was z szerszym opisem tego. Chciałbym zobaczyć jak to wygląda wewnętrznie z przebiegami. W AVRach w każdej nocie katalogowej było pokazane na przebiegach zegarowych jak to działa. Nie mogę znaleźć czegoś podobnego w STM32. Widział ktoś taki opis?
  11. Pewnie Was to nie zainteresuje, ale nie lubię zostawiać tematów w powietrzu. Odłożyłem całość na jakiś czas (nie maiłem siły walczyć z wiatrakiem). Powróciłem do "zabawy" parę dni temu. Nie wiem o co chodzi ale teraz na starych plikach zadziałało jak trzeba. Osobiście nie lubię takich czeskich filmów, ale wytłumaczyć sobie tego nie potrafię. W każdym razie wracam do żywych. Co prawda wolę trudzić się z programem i uC niż walczyć z IDE, bo chyba nie ma nić gorszego niż walka ze środowiskiem.
  12. Zealota możesz mi jeszcze pomóc. Jestem w SystemWorkbench zrobiłem jak pisałeś i zmieniłem w pliku cfg. to teraz mi coś takiego wyskakuje. Swoją drogą jak na to wpadłeś co zrobić z plikiem cfg?
  13. A ja się chyba poddaje Juz nie mam pomysłu co jest nie tak. Trochę się rozpisałem ale to poszło w niepamięć (del) nie będę się żalił. W skrócie system chyba mi upalił karę sieciową na kablu po instalacji sytemu 64bit na laptopie. Dobrze że wifi działa. Upgrade na płytce od Kamami cofnął ją do wersji V1 Musze się z tym przespać.
  14. Dobra, dzięki za motywację. Mam nadzieję że jak piszesz do roboty to nie chodzi o "daj sobie spokój i nie pytaj" bo.... Zealota -> instalacja tych środowisk była spowodowana dość prostą sprawą, testem, chciałem zobaczyć jak każde środowisko wygląda i jak się z nim pracuje. Jak ni działał mi debugger to chciałem zobaczyć czy to wina jakiś ustawień programu czy sprzętu. CubeIDE mi się dość podoba, jest przyjazny, ale ma ta wadę która mnie zniechęca do tego - system 64bitowy. ja wiem, powiecie w dzisiejszych czasach 64bity to podstawa i nie warto instalować 32 bitowego sytemu. Może to kwestia przekonania się ale na razie musi zostać 32. Tak wracając do tematu. Jak udało mi się połączyć poprzez ST-LINKa z płytką, debugger pracuje. tylko czy na pewno ja to dobrze rozumiem. Coś tam na szybko skrobnąłem (odczyt pinu i wartość odczytana na inny pin) . Pytanie czy jak jest debugger włączony to wartości odczytane i zapisane na porcie powinny się pojawiać na żywo w rejestrach na zielono. w tych miejscach co się podświetlone na żółto .Wg mnie tak. lecz żadnej reakcji nie mam w oknach rejestrów. nawet ustawienie pułapki nic nie daje. Jeszcze nie wiem co jest nie tak. Uprzedzając pytanie - nacisnąłem "zieloną strzałkę w prawo" Resume (F8)
  15. Ale w sensie że mam głupie problemy, czy ze to takie proste as ja taki głupi i nie ogarniam, czy z tymi STMami tak zamotali ze mało kto wie o co chodzi? Ktora wersja prawdziwa - wszystkie? Wiem ze ja potrzebuje odrobinę cierpliwości od Was - please o to
×
×
  • Utwórz nowe...