Cześć!
Dzisiaj zacząłem się bawić w/w zestawem i nie rozumiem co się
dzieje. Poprzerabiałem bibliotekę do LCD(wcześniej bez kłopotu działała
na 401disco). I nie działa. Myślałem że upaliłem porty bo nawet miganie
diodą nie dawało efektów, ale nic nie spaprałem tym razem od strony
elektrycznej.
I tak próbuję się dostać do portów za pomocą biblioteki STDperiph,
jak i ustawiać je rejestrami i nic.
No więc się wk... zarejestrowałem na mbed.org wybrałem, jakieś
miganie ledem i działa, dopisałem parę linijek i uart chodzi bez problemu.

Tu mam pytanie, co robię źle że na "normalnych" bibliotekach,
Nucleo nie działa?

Z góry dzięki za porady.


--
Pozdrawiam
Bo(o)t manager

do góry

Dnia Thu, 10 Nov 2016 22:16:17 +0100, Bo(o)t Manager napisał(a):

Jednak chyba upaliłem porty, po kiego griba ma to wyjścia kompatybilne z
arduino, jak podłączenie zwykłego lcd tft 2,4(o którym tu mowa kiedyś
była) upierd... sporą ilość pinów. Część pinów z portu A i B działa, a
część nie.



--
Pozdrawiam
Bo(o)t manager

do góry

"Bo(o)t Manager" <b...@u...wp.pl> wrote:
> Dnia Thu, 10 Nov 2016 22:16:17 +0100, Bo(o)t Manager napisa?(a):
>
> Jednak chyba upali?em porty, po kiego griba ma to wyj?cia kompatybilne z
> arduino, jak pod??czenie zwyk?ego lcd tft 2,4(o kt?rym tu mowa kiedy?
> by?a) upierd... spor? ilo?? pin?w. Cz??? pin?w z portu A i B dzia?a, a
> cz??? nie.

Hmm, nie mam Nucleo ale bawilem sie innymi plytkami z prockami STM.
Te piny gdzie STM mowi ze mozna dac 5V u mnie spokojnie pracowaly z 5V.
Shield z lcd tft 2,4 jest wewnetrznie 3.3V, wiec malo szans na
spalenie czegos. Dokladniej, ja swojego nie probowalem podlaczyc
do Ardunio 5V, bo wtedy HC245 zasilane z 3.3V dostalby 5V na
wejscia. Sygnalizacji 3.3V wszystko dzialalo OK (z Arduino 3.3V
i z STM). Wiec jak porty sie spalily to raczej bylo cos wiecej
niz dolaczenie sprawnego modulu lcd.

Co do programu to moja szklna kula mowi ze zrobiles blad. Jaki?
W 10 linijkach kodu masz z 50 okazji zeby cos zepsuc. Jak nie
pokazesz kodu to nikt nie wie co u Ciebie sie dzieje. A propo,
w takiej sytuacji najszybciej daje odpowiedz debuger: patrzysz
jaka czesc sie wykonuje i wiesz czy program dotarl tam gdzie
trzeba czy moze padl gdzies przy inicjacji. Jak pada to
krokujesz, zakladasz breakpointy czy usuwasz kod az wiesz
na czym pada (i to poprawiasz). Jak nie pada to z debugera
testujesz operacje wejscia/wyjsca. Jak zapisy do rejestrow
portu sa ignorowane to pewnie port nie ma zegara. Jak rejestr
wyjsciowy jest OK to patrzysz na kofiguracje pinow. Jak
i z konfiguracji pinow odczytujesz co nalezy a napiecia na
porcie nie ma pewnie port spalony.

P.S. W roznych seriach STM inicjowanie procka jest bardzo
podobne, ale jest dosc roznic zeby program nie dzialal
na innej serii.

--
Waldek Hebisch

do góry

Dnia Fri, 11 Nov 2016 17:55:44 +0000, antispam napisał(a):

[ciach]
> Co do programu to moja szklna kula mowi ze zrobiles blad.
[ciach]

Oto prosty kod:
/**

****************************************************
**************************
* @file main.c
* @author Ac6
* @version V1.0
* @date 01-December-2013
* @brief Default main function.

****************************************************
**************************
*/


#include "stm32f30x.h"
//#include "stm32f30x_gpio.h"

int main(void)
{
uint16_t i;
uint16_t x;
RCC->AHBENR |= RCC_AHBENR_GPIOAEN;
RCC->AHBENR |= RCC_AHBENR_GPIOBEN;
RCC->AHBENR |= RCC_AHBENR_GPIOCEN;
GPIOA->MODER |= GPIO_MODER_MODER1_0 | GPIO_MODER_MODER2_0 |
GPIO_MODER_MODER3_0 | GPIO_MODER_MODER4_0 | GPIO_MODER_MODER5_0;
GPIOB->MODER |= GPIO_MODER_MODER8_0 | GPIO_MODER_MODER9_0 |
GPIO_MODER_MODER10_0 | GPIO_MODER_MODER3_0 | GPIO_MODER_MODER2_0;
GPIOC->MODER |= GPIO_MODER_MODER8_0 | GPIO_MODER_MODER9_0 |
GPIO_MODER_MODER13_0 | GPIO_MODER_MODER4_0 | GPIO_MODER_MODER5_0;


while (1)
{
GPIOA->ODR = i;
GPIOB->ODR = i;
for(x = 0; x < 6400; x++){}
GPIOA->ODR = 0;
GPIOB->ODR = 0;
for(x = 0; x < 6400; x++){}
i++;

}
}

****************************************************
*****************************

I na nim część portu A i B działa, a druga nie. Wiem wszystkie
piny portów nie są włączone, ale GpioB 2 i 3 są włączone a nie działają.
Pobawię się nim jeszcze, ale nie wiążę z nim większych nadziejii.





--
Pozdrawiam
Bo(o)t manager

do góry

"Bo(o)t Manager" <b...@u...wp.pl> wrote:
> Dnia Fri, 11 Nov 2016 17:55:44 +0000, antispam napisa?(a):
>
> [ciach]
> > Co do programu to moja szklna kula mowi ze zrobiles blad.
> [ciach]
>
> Oto prosty kod:
> /**
>
> ****************************************************
**************************
> * @file main.c
> * @author Ac6
> * @version V1.0
> * @date 01-December-2013
> * @brief Default main function.
>
> ****************************************************
**************************
> */
>
>
> #include "stm32f30x.h"
> //#include "stm32f30x_gpio.h"
>
> int main(void)
> {
> uint16_t i;
> uint16_t x;
> RCC->AHBENR |= RCC_AHBENR_GPIOAEN;
> RCC->AHBENR |= RCC_AHBENR_GPIOBEN;
> RCC->AHBENR |= RCC_AHBENR_GPIOCEN;
> GPIOA->MODER |= GPIO_MODER_MODER1_0 | GPIO_MODER_MODER2_0 |
> GPIO_MODER_MODER3_0 | GPIO_MODER_MODER4_0 | GPIO_MODER_MODER5_0;
> GPIOB->MODER |= GPIO_MODER_MODER8_0 | GPIO_MODER_MODER9_0 |
> GPIO_MODER_MODER10_0 | GPIO_MODER_MODER3_0 | GPIO_MODER_MODER2_0;
> GPIOC->MODER |= GPIO_MODER_MODER8_0 | GPIO_MODER_MODER9_0 |
> GPIO_MODER_MODER13_0 | GPIO_MODER_MODER4_0 | GPIO_MODER_MODER5_0;
>
>
> while (1)
> {
> GPIOA->ODR = i;
> GPIOB->ODR = i;
> for(x = 0; x < 6400; x++){}
> GPIOA->ODR = 0;
> GPIOB->ODR = 0;
> for(x = 0; x < 6400; x++){}
> i++;
>
> }
> }
>
> ****************************************************
*****************************

Inicjowanie wyglada OK. Petle opozniajace sa podejrzane: w zasadzie
kompilator moze taka petle usunac. gcc kiedys obiecywal ze takie
petle zostana i gcc-5.3 wydaje sie ze faktycznie je zostawia. Ale
z tego co pamietam niektore wersje gcc je usuwaly...

Zmienna i jest niezainicjowana i zasadzie kompilator moze Ci
legalnie zepsuc program jak mu sie podoba, ale wyglada ze z
gcc-5.3 to dziala jak chcesz.

--
Waldek Hebisch

do góry

Dnia Sat, 12 Nov 2016 03:52:47 +0000, antispam napisał(a):

[ciach]
>
> Inicjowanie wyglada OK. Petle opozniajace sa podejrzane: w zasadzie
> kompilator moze taka petle usunac. gcc kiedys obiecywal ze takie petle
> zostana i gcc-5.3 wydaje sie ze faktycznie je zostawia. Ale z tego co
> pamietam niektore wersje gcc je usuwaly...
>
> Zmienna i jest niezainicjowana i zasadzie kompilator moze Ci legalnie
> zepsuc program jak mu sie podoba, ale wyglada ze z gcc-5.3 to dziala jak
> chcesz.


Te pętle to tak bym widział czy miga, nie są ważne, z "riserczu" wychodzi
że mam 2 piny upalone PB2 i PB3. Jak patrzyłem w pdf'a to nic na nich nie
wisi(jakieś peryferia czy coś).
ATSD to straszny rozpiździaj mają w złączach, D0-D9 to aż trzy
porty PA , PB i PC, a najlepsze jest to, że piny nie są poustawiane po
kolei.
D9 - PC7
D8 - PA9
D7 - PA8
D6 - PB10
D5 - PB4
D4 - PB5
D3 - PB3
D2 - PA10
D1 - PA3 - uart - No to jeszcze mogę zrozumieć.
D0 - PA2 - uart - j.w.

I jak tu szybko 8 bitów wystawić na D2 - D9?

--
Pozdrawiam
Bo(o)t manager

do góry

"Bo(o)t Manager" <b...@u...wp.pl> wrote:
> Dnia Sat, 12 Nov 2016 03:52:47 +0000, antispam napisa?(a):
>
> [ciach]
> >
> > Inicjowanie wyglada OK. Petle opozniajace sa podejrzane: w zasadzie
> > kompilator moze taka petle usunac. gcc kiedys obiecywal ze takie petle
> > zostana i gcc-5.3 wydaje sie ze faktycznie je zostawia. Ale z tego co
> > pamietam niektore wersje gcc je usuwaly...
> >
> > Zmienna i jest niezainicjowana i zasadzie kompilator moze Ci legalnie
> > zepsuc program jak mu sie podoba, ale wyglada ze z gcc-5.3 to dziala jak
> > chcesz.
>
>
> Te p?tle to tak bym widzia? czy miga, nie s? wa?ne, z "riserczu" wychodzi
> ?e mam 2 piny upalone PB2 i PB3. Jak patrzy?em w pdf'a to nic na nich nie
> wisi(jakie? peryferia czy co?).

No, wewnatrz chipa to sporo wisi, do PB2 rozne analogowe zabawki,
do PB3 timery, SPI i USART.

> ATSD to straszny rozpi?dziaj maj? w z??czach, D0-D9 to a? trzy
> porty PA , PB i PC, a najlepsze jest to, ?e piny nie s? poustawiane po
> kolei.
> D9 - PC7
> D8 - PA9
> D7 - PA8
> D6 - PB10
> D5 - PB4
> D4 - PB5
> D3 - PB3
> D2 - PA10
> D1 - PA3 - uart - No to jeszcze mog? zrozumie?.
> D0 - PA2 - uart - j.w.
>
> I jak tu szybko 8 bit?w wystawi? na D2 - D9?

Znam bol. Ale mieli ograniczenia: srodowisko Arduino mocno
uzywa timerow, wiec na nogach gdzie Atmega ma timery
musialy tez byc timery. Podobnie z nogami do SPI.
Jak rozumiem PCB do Nucleo jest praktycznie takie same
dla roznych procesorow, wiec wskakuja ograniczenia
z wszystkich 10+ procesorow ktore moze miec Nucleo.
Ogolnie procesory STM maja nogi nie po kolei.
Mozliwe ze daloby sie to zrobic lepiej, ale nie
znam wszystkich ograniczen (np. jak inny rozklad nog
wplynolby na zaklucenia).

A propo: juz w Atmedze linie sa rozdzielnie na dwa
porty, wiec zapis do LCD to 4 zapisy do portow
(2 na sygnal WR i dwa do ustawienia danych).

A propo2: jak sie popatrzylem na opis interfejsu do LCD
to wersja przez SPI wydaje sie znacznie bardziej
sympatyczna. Szybkosc transmisji troche mniejsza,
ale dostatecznie duza. Transmisje SPI mozna podpiac
do DMA, wiec obciazenie procka jest bliskie zera.
Nie wiem dlaczego tyle modulow wybiera interfejs
rownolegly...

--
Waldek Hebisch

do góry

Dnia Sun, 13 Nov 2016 04:02:14 +0000, antispam napisał(a):

[ciach]
> No, wewnatrz chipa to sporo wisi, do PB2 rozne analogowe zabawki,
> do PB3 timery, SPI i USART.

Może i coś wisi, ale powinno działać, nie ma tam żadnych zworek.


> Znam bol. Ale mieli ograniczenia: srodowisko Arduino mocno uzywa
> timerow, wiec na nogach gdzie Atmega ma timery musialy tez byc timery.
> Podobnie z nogami do SPI.

No cóż nie obejdzie się bez dodatkowej płytki :(

> Jak rozumiem PCB do Nucleo jest praktycznie takie same dla roznych
> procesorow, wiec wskakuja ograniczenia z wszystkich 10+ procesorow ktore
> moze miec Nucleo.
> Ogolnie procesory STM maja nogi nie po kolei.
> Mozliwe ze daloby sie to zrobic lepiej, ale nie znam wszystkich
> ograniczen (np. jak inny rozklad nog wplynolby na zaklucenia).
>

Dla mnie to trochę dziwne, ale może jest jak piszesz.
[ciach]

> A propo2: jak sie popatrzylem na opis interfejsu do LCD to wersja przez
> SPI wydaje sie znacznie bardziej sympatyczna. Szybkosc transmisji
> troche mniejsza,
> ale dostatecznie duza. Transmisje SPI mozna podpiac do DMA, wiec
> obciazenie procka jest bliskie zera.
> Nie wiem dlaczego tyle modulow wybiera interfejs rownolegly...

Też są na spi, ale przeważnie są droższe. Kto wie może się kiedyś skuszę.




--
Pozdrawiam
Bo(o)t manager

do góry

On 2016-11-13 05:02, a...@m...uni.wroc.pl wrote:
> A propo2: jak sie popatrzylem na opis interfejsu do LCD
> to wersja przez SPI wydaje sie znacznie bardziej
> sympatyczna. Szybkosc transmisji troche mniejsza,
> ale dostatecznie duza. Transmisje SPI mozna podpiac
> do DMA, wiec obciazenie procka jest bliskie zera.
> Nie wiem dlaczego tyle modulow wybiera interfejs
> rownolegly...
A czy narzut na inicjowanie transmisji nie zabije wydajności? Bo to jest
zdaje się fajne jak masz duże bloki do przesłania. Zresztą nawet
przy większych blokach najpierw trzeba przygotować dane (co trwa)
a potem można je dopiero wysyłać.

Czy jest jakaś opcja o której nie wiem żeby wrzucenie 1 lub kilku
bajtów do bufora i wymuszenie wysłania tych bajtów było
porównywalne czasowo z ustawieniem po kolei tych bajtów
na port równoległy? Wydaje mi się to mało prawdopodobne.

do góry

kriters <k...@o...pl> wrote:
> On 2016-11-13 05:02, a...@m...uni.wroc.pl wrote:
> > A propo2: jak sie popatrzylem na opis interfejsu do LCD
> > to wersja przez SPI wydaje sie znacznie bardziej
> > sympatyczna. Szybkosc transmisji troche mniejsza,
> > ale dostatecznie duza. Transmisje SPI mozna podpiac
> > do DMA, wiec obciazenie procka jest bliskie zera.
> > Nie wiem dlaczego tyle modulow wybiera interfejs
> > rownolegly...
> A czy narzut na inicjowanie transmisji nie zabije wydajno?ci? Bo to jest
> zdaje si? fajne jak masz du?e bloki do przes?ania. Zreszt? nawet
> przy wi?kszych blokach najpierw trzeba przygotowa? dane (co trwa)
> a potem mo?na je dopiero wysy?a?.
>
> Czy jest jaka? opcja o kt?rej nie wiem ?eby wrzucenie 1 lub kilku
> bajt?w do bufora i wymuszenie wys?ania tych bajt?w by?o
> por?wnywalne czasowo z ustawieniem po kolei tych bajt?w
> na port r?wnoleg?y? Wydaje mi si? to ma?o prawdopodobne.

Przy kilku bajtach chyba najlepiej wrzucac do rejestrow SPI.
Wtedy to bedzie gdziec 1/2 czy 1/3 tempa transmisji
rownoleglej. Ale jesli myslisz o zapisie w "losowe"
miejsce na ekranie to trzeba najpierw manipulowac
liniami CS i D/C, potem ustawic adres, czyli jest spora
strata w porownaniu z transmisja blokow.

Dokladniej dla ILI9341 maksymalny zegar SPI to 10 MHz, czyli
800 ns na bajt przy transmisji szeregowej. Przy transmisji
rownoleglej minimaly cykl zapisu trwa 66ns czyli niby duzo
szybciej. Ale to sie tlumaczy na co najmniej 3 zapisy
do portow na ARM (dane + dwie zmiany na linii W/R),
a przy mniej dogodnym rozmieszczeniu nog 4 lub 5.
Jak szybko to 5 zapisow potrwa to zalezy od konkretngo modelu,
ale 300ns wydaje sie rozsadnym oszacowaniem. Niektore
modele prockow maja FIFO w SPI, np. w STM32F030 mozna
wrzucic 4 bajty do SPI i sprzet przypilnuje zeby wszystkie
poszly. Co do "wymuszenia wyslania": jak sie czeka
na koniec transmisji (np. zeby uzyc to samo SPI z innym
urzadzeniem) to trzeba czekac ile twa transmisja, czyli
dluzej niz tansmisja rownolegla.

--
Waldek Hebisch

do góry