STM32 generic board

[mikikg]

Zato sam i linkovao, porucio par komada da vidim nasta to lici.
U svakom slucaju bar meni odgovara ovakva plocica gde sem napajanja i oscilatora nema nista vise od periferija i gde su sve ostale nozice slobodne za koriscenje.
M4 je odlican procesor, vrlo ozbiljna masina nakrcana sa dobrim periferijama, puno Flash/RAM, za neke zahtevnije projekte ...

[yugaja]

Porucio i ja odmah, nek se nadje, izgleda da ima sve pinove izvucene...



Evo jedne slicice, s stola, zanimljivije je tako, bar meni da u nesto gledam, sa slicnim tj istim MCUom samo  144 pins. Ploca je musava, malo iseckana, jbg razvoj...


Npr ovde koristim DAC za sintezu nekog waveforma.... ~ half wave rectified @60Hz, skoro bez zauzeca samog jezgra. Onda pored imam user interface plocu sa preko 150 LEDova i 20tak tastera, comm preko SPI-ja, to vrtim jako brzo,  korisitm DMA pa imam 16 frameova, tj mogu da podesavam osvetljaj svake diode individualno kroz 16 nivoa, bez da se trosi procesorsko vreme...

Onda neverovatno mocan ADC modul sa  sekvencierima i insert kanalima, koristim sve SPI portove,  tri USARTa,  USB..


Stigao sam do 250Kb flesa, a i tu je nekih 60kB rezervisano za firmware jednog 32f103, koji moze da dobije update na terenu iz glavnog M4 MCUa, ako je potrebno.  I sve to za 10$ na komad.

Jako puno flesa i rama ima, za neke ovakve primene je bahacenje... Samo neka multimedija moze da potrosi te resurse lagano.

[npejcic]

Možda nisam baš pogodio topic ali ima veze sa STM32 pa ne zamerite što pišem ovde.

Radim ovih dana na jednom STM32 projektu i nikako da razumem i rešim kako radi HAL biblioteka pri radu sa UART-om. Ideja je da se koriste ugrađeni mehanizmi, konkretno:
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)

Još uvek verujem da negde ja grešim, pa bih podelio sa vama iskustvo, verujem da može biti poučno. Problem jesam rešio, ali ne na način kako HAL koncept nalaže.

Kao i do sada što sam radio koristim UART RX interrapt, u njemu cirkularni buffer i sakupljam podatke. Kasnije to u main petlji analiziram i to radi fenomenalno ukoliko koristim ovaj način kodiranja:

------------ VERZIJA KOJA RADI ------------------

Code:

void USART2_IRQHandler(void)
{
  /* USER CODE BEGIN USART2_IRQn 0 */
    unsigned char data;
    
  /* USER CODE END USART2_IRQn 0 */
  // HAL_UART_IRQHandler(&huart2);
  /* USER CODE BEGIN USART2_IRQn 1 */

    ////if (!U2STAbits.FERR && !U2STAbits.PERR && !U2STAbits.OERR)
    if((USART2->ISR & UART_FLAG_RXNE) != RESET)    
    {
        data = (uint8_t)(USART2->RDR); /* Receive data, clear flag */

        UART2Autoreset = 20; // x 10 ms = 200ms
        rx_buffer1[rx_wr_index1] = data;
        if (++rx_wr_index1 == RX_BUFFER_SIZE1) rx_wr_index1 = 0;
        if (++rx_counter1 == RX_BUFFER_SIZE1)
        {
            rx_counter1 = 0;
            rx_rd_index1 = rx_wr_index1;
        }
    }
    
    
  /* USER CODE END USART2_IRQn 1 */
}

U inicijalizaciji pokrećem interapte sa __HAL_UART_ENABLE_IT(&huart2, UART_IT_RXNE);

------------ VERZIJA KOJA NE RADI ------------------
Međutim, čemo onda HAL ako moram da se spustim na ovakav nivo komunikacije?

Očekivao sam da njihov primer radi isto dobro, ali avaj, dobijam svaki 5, 9, 12, 3 random... bajt i često mi se kompletno zaglavi UART RX interrupt. Da li je neko imao iskustva, jer iako sam rešio problem rekoh da pitam da li ja negde grešim sa HAL pristupom? Još jedna stvar koja mi se ne sviđa je što, ako sam dobro razumeo, interapti se gase kada se nalazimo u Callback funkciji, pa ih je potrebno ponovo uključiti na izlazu iz ove funkcije???

Evo dela koda koji mi NE RADI a preporučen je od strane STM-a:

Code:

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)
{
    if(huart->Instance == USART2)
    {
        rx_buffer1[rx_wr_index1] = aRxBufferU2[0];
        if (++rx_wr_index1 == RX_BUFFER_SIZE1) rx_wr_index1 = 0;
        if (++rx_counter1 == RX_BUFFER_SIZE1)
        {
            rx_counter1 = 0;
            rx_rd_index1 = rx_wr_index1;
        }
    }
    HAL_UART_Receive_IT(&huart2, (uint8_t *)aRxBufferU2, 1);

}

U inicijalizaciji pokrećem interapte sa  HAL_UART_Receive_IT(&huart2, (uint8_t *)aRxBufferU2, 1);

[mikikg]

Ako ti nesto znaci, evo ti moja verzija bez HAL-a, to je sa DMA za TX, RX i kraj paketa se radi preko IDLE interapta.

U prilogu je fajl sa definicijom pinova i funkcijama za prijem, u main() samo ovo trebas da pratis:

Code:

//kada stigne paket sa KBD
if (UART_KBD_rx_ready == 1) {
 UART_KBD_rx_ready = 0;
 //radi nesto sa primljenim paketom ...

 //duzina paketa u: UART_KBD_RX_packet_len;
 //primljeni karakteri u: UART_KBD_RX_buff;
}

//kod slanja, napuniti UART_KBD_TX_buff i pozvati ne-blokirajucu funkciju KBD_dma_transmit_buffer(len);

Ta postavka mi radi odlicno, promenljive duzine paketa, ASCII / HEX ne pravi problem ...

[npejcic]

Kao što vidim u tvom kodu i ti si radio "low-level" pristup. Tako i meni radi i to jako dobro.
Ono što mi je problem, to je HAL koncept. Rekoh da budem po "propisu" i da koristim HAL koje preporučuju, i koji mi ne radi, tako da je to bila moja ideja.
Hvala u svakom slučaju.

[mikikg]

Ja sam par puta naleteo na neke koske sa tim HAL bibliotekama, posle toga sam digo ruke od HAL-a i presao sve na low-level, tu bar znam tacno sta se desava i sta sam pisao ...
Da li je code "portabilan", to ne brinem mnogo, to prepakovati za neki drugi MCU je 5 minuta posla samo brojeve pinova da izmenim ...

HAL i CubeMX su zgodni bar meni "informativno", tj ako negde zaglavim sa nekom konfiguracijom na low-level nivou, odradim to isto sa HAL privremeno u nekom test programu i posle u debugeru pogledam tacno kako su postavljeni registri za tu periferiju pa onda to isto uradim rucno

PS: Ovaj code je kompatibilan 100% i za RS-485 ako se koristi MAX13487 koji ima automatsku DE (Driver Enable) kontrolu. Za obicne MAX485 se tu negde stavja TX_ON / TX_OFF za DE pin.
PS2: U mom primeru sam pratio Framing Error i Noise Error, vrlo korisna stvar jer odmah prepoznas da ima nekih gresaka, promasen Baud Rate, start/stop bits ili vec neki problemi na HW nivou.
PS3: Sav Code koji se tice ISR-a i baratanja tim flagovima u sustini mora tako da se pise, tu nista ne pomaze HAL, moras svakako da nadgledas neke low-level registre.

[gorankg]

Očekivao sam da njihov primer radi isto dobro, ali avaj, dobijam svaki 5, 9, 12, 3 random... bajt i često mi se kompletno zaglavi UART RX interrupt. 

Da li u ovoj verziji koja ne radi (a kad ne zaglavi  ) dobijaš u prijemu korektan broj bajtova?

[npejcic]

@mikikg
Očigledno da je najbolje tako. Koristiti CubeMX da generiše inicijalizaciju i podešavanje pinova i slično, a zatim uraditi sve na već uobičajeni način. Gledati registre i low-level kodiranje.

U uređaju imam tri UART-a, jedan je za GSM modul gde su mi paketi promenljive dužine, tu ne bih radio sa DMA. Drugi komunikacija sa PC bi mogla tako jer imam fiksne dužine paketa 32By, a treći koristim za slave uređaj opet paketi iste dužine 256By. Možda i tu DMA. U svakom slučaju očigledno da je zaključak da HAL framework može da ne radi kako treba.

@gorankg
Nažalost ne. I kada radi primi svega par bajtova, često i svega jedan i onda zaglavi. To sam mislio da ću rešiti ponovnim initom interapta komandom
HAL_UART_Receive_IT(&huart2, (uint8_t *)aRxBufferU2, 1); ali nije se ništa promenilo.

[gorankg]

Ovo:

Code:

rx_buffer1

treba da je definisano kao volatile. Kako je kod tebe?

[npejcic]

Jeste volatile.

Problem je što se posle prijema jednog ili par bajtova više ne javljaju interapti. Gledano i STLINK debugerom. Desi se jednom i onda stane. MCU više ne uskače u interapt rutinu, odnosno
Callback.

[gorankg]

Ovo je izgleda poznat problem, na više strana se piše o tome. Ovaj lik ima neko rešenje mada ja ne kapiram najbolje šta je radio:

https://community.st.com/thread/42107-st...-revisited

[npejcic]

Gorane hvala na trudu i vremenu.

Ovo je rešenje sa foruma, a poklapa se sa Mikijevim i mojim iskustvom:
"Here is the solution. Yank out all the HAL UART code, and replace it with LL USART equivalents."

Očigledno da je ST neverovatno loše odradio ovaj deo i to godinama unazad... nikako da reše. Ja sam pomislio da je nešto do mene. Malo je veći problem što je ovo, iz mogu ugla, nešto što MORA da radi, ali očigledno da imaju baš bugovit HAL deo na nivou debakla.

Šta je lik sa foruma uradio, izbacio je HAL kod koji sam i ja pokušao da koristim i prešao na novi koncept koji ST zove LL (low-layer API).
Evo ovde detalja u vezi HAL vs LL API:
https://community.st.com/thread/32362

[npejcic]

A evo još jednog detalja koga nisam do sada primetio za LL API u CubeMx-u, što je verujem prava stvar

Možete da izaberete koji koncept biblioteka želite da se koristi pri generisanju koda...

[mikikg]

Usrecio si se i sa jednom i sa drugom bibliotekom : )

Ne vredi, ili ce da pisemo na low-level kao nekad sto smo sve inace i pisali ili da programiramo u Python ili JavaScript, sve izmedju odprilike da ne pije vodu
Mozda kompromis sa nekim FreeRTOS ili slicno, ali te njihove biblioteke su overkil potpun za nas, samo prave pometnju.

[npejcic]

Ma da... ST trenutno ima četiri tipova biblioteka, Standard Peripheral Libraries, HAL, Snippets, Low-Layer... deluje da ni oni više nisu sigurni šta je najbolje rešenje. Da ne pričam o pometnji koju su uneli.

Izgleda da je low-level ipak dugoročno gledano najbolje rešenje. Recimo ovo što sada radim je pokušaj da uradim "rapid-development" na jednom starom projektu koji mi je na PIC24FJ128GA106 sa kojim sam zaglavio jer je 90% pun, pa eto rekoh da probam da portujem kod na STM32L071 i to brzo Ali avaj, nemože to baš tako lagano.

[gorankg]

Izgleda da je low-level ipak dugoročno gledano najbolje rešenje. Recimo ovo što sada radim je pokušaj da uradim "rapid-development" na jednom starom projektu koji mi je na PIC24FJ128GA106 sa kojim sam zaglavio jer je 90% pun, pa eto rekoh da probam da portujem kod na STM32L071 i to brzo Ali avaj, nemože to baš tako lagano.

Lakše bi bilo da si uzeo veći PIC  
Stvarno je bezveze stvar sa tim HAL. Dal je moguće da im ne radi "glupi" UART!?

[mikikg]

Pogledaj ovaj link, kolega je to stavio jer je imao slicne probleme, dole na dnu stranice ima i video sa detaljnim uputstvom kako sve da se potera.
http://elco.crsndoo.com/mediawiki/index....M32_USART1

[mikikg]

Ja sam pre neki dan se bio zaglavio sa I2C, ali mojom krivicom, nisam "poslusao" osciloskop i dekoder koji su mi uporno signalizirali da mi fali tamo neki ACK u protokolu ...
Kada sam resio da ga poslusam, onda nisam znao gde tacno treba ACK da postavim u programu, onda sam isao metodom "brute force" i iz 4-5 pokusaja sam nabo gde treba da se postavi i onda je sve proradilo kako treba ...

Slicno radim po principu "brute force" i za ostale periferije kada se zaglavim negde, znaci idem i "klikcem" redom registre po periferiji preko debugera, u jednom trenutku se "nesto desi", "aha u tom grmu lezi zec" ...
Mora da se snalazimo, takavm nam posao

BTW: Posto sam se igrao sa FRAM, nisam znao vise sta da stavljamu slobodne memoriske lokacije pa sam napravio counter za broj reseta/reboot-a MCU (imam i brojac "radnih minuta") samo da vidim koliko to ja puta za jedan projekat uploadujem/resetujem MCU.
Dosao sam do vrlo zanimjiv brojki, recimo za jedan relativno prost projekat se to svodi na oko 500 puta u toku nedelju dana!
Ako tu brojku pomnozimo sa vremenom potrebnm za upload programa dobijamo vreme koje gubimo samo na te stvari, a ako u tu situaciju onda dodamo recimo Microchip kome treba jedno x10 vise vremena da usnimi program u MCU nego kod ARM dobiju se "zabrinjavajuce" brojke za vreme koje gubimo na te stvari.
Takodje me je ovo interesovalo zbog broja upisa u STM-ov Flash, proizvodjac garantuje oko 10.000 upisa, dakle ovim tempom moze relativno brzo da se stigne do limita.
Naravno, ovi moji brojaci su brojali i RESET (bez usnimavanja) pa je situacija malo bolja ali usvakom slucaju je zgodno da imamo neke okvire o kojim brojkama se radi.

[mikikg]

BTW: Posto sam se igrao sa FRAM, nisam znao vise sta da stavljamu slobodne memoriske lokacije ...

Ni ovi nisu znali sta da stave u slobodan ROM : ), pa stavili par skrivenih slika zaposlenih koji su radili na dizajnu Apple SE racunara, nasli hakeri posle 25 godina
http://weddingphotography.com.ph/12012/s...years-ago/

[npejcic]

Izgleda da je low-level ipak dugoročno gledano najbolje rešenje. Recimo ovo što sada radim je pokušaj da uradim "rapid-development" na jednom starom projektu koji mi je na PIC24FJ128GA106 sa kojim sam zaglavio jer je 90% pun, pa eto rekoh da probam da portujem kod na STM32L071 i to brzo Ali avaj, nemože to baš tako lagano.

Lakše bi bilo da si uzeo veći PIC  
Stvarno je bezveze stvar sa tim HAL. Dal je moguće da im ne radi "glupi" UART!?

  Da znaš da si u pravu.
Ali rekoh napredak tehnologije i ako nemaš ARM-a u uređaju nisi "trendy"

  Šalu na stranu, ovakve projekte vidim kao edukaciju sebe da uradim nešto novo i da budem u toku sa novim pravcima razvoja embedded elektronike.

Pogledaj ovaj link, kolega je to stavio jer je imao slicne probleme, dole na dnu stranice ima i video sa detaljnim uputstvom kako sve da se potera.
http://elco.crsndoo.com/mediawiki/index....M32_USART1

Da, ima smisla probati. Sutra sam pored uređaja, nadam se da ću imati vremena da probam i javljam rezultate. Hvala.

Ja sam pre neki dan se bio zaglavio sa I2C, ali mojom krivicom, nisam "poslusao" osciloskop i dekoder koji su mi uporno signalizirali da mi fali tamo neki ACK u protokolu ...
Kada sam resio da ga poslusam, onda nisam znao gde tacno treba ACK da postavim u programu, onda sam isao metodom "brute force" i iz 4-5 pokusaja sam nabo gde treba da se postavi i onda je sve proradilo kako treba ...

Slicno radim po principu "brute force" i za ostale periferije kada se zaglavim negde, znaci idem i "klikcem" redom registre po periferiji preko debugera, u jednom trenutku se "nesto desi", "aha u tom grmu lezi zec" ...
Mora da se snalazimo, takavm nam posao

BTW: Posto sam se igrao sa FRAM, nisam znao vise sta da stavljamu slobodne memoriske lokacije pa sam napravio counter za broj reseta/reboot-a MCU (imam i brojac "radnih minuta") samo da vidim koliko to ja puta za jedan projekat uploadujem/resetujem MCU.
Dosao sam do vrlo zanimjiv brojki, recimo za jedan relativno prost projekat se to svodi na oko 500 puta u toku nedelju dana!
Ako tu brojku pomnozimo sa vremenom potrebnm za upload programa dobijamo vreme koje gubimo samo na te stvari, a ako u tu situaciju onda dodamo recimo Microchip kome treba jedno x10 vise vremena da usnimi program u MCU nego kod ARM dobiju se "zabrinjavajuce" brojke za vreme koje gubimo na te stvari.
Takodje me je ovo interesovalo zbog broja upisa u STM-ov Flash, proizvodjac garantuje oko 10.000 upisa, dakle ovim tempom moze relativno brzo da se stigne do limita.
Naravno, ovi moji brojaci su brojali i RESET (bez usnimavanja) pa je situacija malo bolja ali usvakom slucaju je zgodno da imamo neke okvire o kojim brojkama se radi.

I ja sam se jednom preračunavao oko broja upisa u FLASH mem i da li smo na granici da oštetimo FLASH mem prilikom razvoja jednog uređaja.
Došao sam do neke brojke da je rad na tom projektu zahtevao oko par hiljada upisa. Nisam dostigao cifru od 10k. Takođe ova brojka je uglavnom minimalna količina upisa u FLASH mem, tako da je to u proseku značajno više.
Jednom mi se desilo da sam greškom u PIC18F452 upisivao na 100ms parametre u interni njegov EEPROM (proizvođač 1,000,000.00 upisa) i mašina radila par meseci i javio se operater da mu gubi podatke koje podesi. Pogledao sam u kodu i shvatio šta se dešava, otišao na teren zamenio MCU i sve uredno. Tom prilikom sam izračunao da je EEPROM bio upisan oko 1,600,000.00 puta
Od tada nikada mi se nije desilo nešto slično. Tako da mislim da nije problem, ionako za razvoj planiraš bar nekoliko MCU ako se desi tako nešto

BTW: Posto sam se igrao sa FRAM, nisam znao vise sta da stavljamu slobodne memoriske lokacije ...

Ni ovi nisu znali sta da stave u slobodan ROM : ), pa stavili par skrivenih slika zaposlenih koji su radili na dizajnu Apple SE racunara, nasli hakeri posle 25 godina
http://weddingphotography.com.ph/12012/s...years-ago/

Čoveče, kakav duh su imali ti ljudi osamdesetih... u danjašnje vreme mnogo je lakše "prošvercovati" multimediju i u MCU od mikrotalasne pećnice, za razliku od 1986. godine
Baš sam se oduševio.