Fórum témák

» Több friss téma
Fórum » ARM - Miértek hogyanok
 
Témaindító: gtk, idő: Jún 26, 2007
Lapozás: OK   73 / 177
(#) cpt.zoltan.simon válasza cimopata hozzászólására (») Aug 17, 2016 /
 
Én 3+1 dolgot csinálnék.
1: Priorizáld a megszakításokat.
2: Használj egymásba ágyazott megszakításokat.
3: Ne használd (ott) a CUBEMX-et.

Még valami: Nem tudom mit kell osztani mennyivel de én:
Ha pl mérek valamit sokszor, akkor a mérések száma kettő hatványa.
Ezután az átlagolás az osztás szintén kettő hatványa.
Ez így valójában azt jelenti, hogy szorzok kettővel-néggyel stb (léptek balra), osztáskor jobbra. Azaz segítem a processzort.
A hozzászólás módosítva: Aug 17, 2016
(#) cimopata válasza cpt.zoltan.simon hozzászólására (») Aug 18, 2016 /
 
A kettő hatványaival való mérésre még gondoltam én is. Most nekiálltam írogatni a programot cubemx-nélkül ami kissé megnehezíti a dolgot mivel a cube azért sok miden beállítás legenerál.
Ha a cube-al generált programba akarok bele írni akkor meg egyszerűen nem hajlandó menni a program így kicsit bele ásom magam a részletekbe.

Rögtön meg is akadtam az elején leszedtem az STM-es clock generátort ami megcsinálja a system_stm32f0xx.c fájlt, hogy legalább az órajellel ne kelljen bajlódni.

Az a durva hogy összehasonlítottam a sima kimenet billegtetését amit a cube generált azzal amit a xls. generált és a cube-os 2x gyorsabb 300ns a másik meg 600ns.

Ennyi a kód:[code=c][#include "stm32f0xx.h"



int main(void)
{
volatile uint32_t dly;

RCC->AHBENR |= RCC_AHBENR_GPIOBEN;
GPIOB->MODER |= GPIO_MODER_MODER6_0;

GPIOB->OSPEEDR |= GPIO_OSPEEDR_OSPEEDR6;
//GPIOB->PUPDR |= GPIO_PUPDR_PUPDR6_0;
while (1)
{

GPIOB->ODR = GPIOB->ODR | 0x40; // PB6 bekapcsol

GPIOB->ODR = GPIOB->ODR & 0xFFBF; // PB6 kikapcsol
}
/code]

A cube-osnál sok egyéb van de a main-ben ugyan ez.
Miért lehet gyorsaságban különbség? A Mhz- beállítások ugyan azok. Bár az excelben a bekarikázott rész nem állítható a cube-ban igen és az 48Mhz.
A hozzászólás módosítva: Aug 18, 2016
(#) toto válasza cimopata hozzászólására (») Aug 18, 2016 /
 
A cubeMX-hez nem értek, de ha a regisztereket közvetlenül írogatod, akkor az ODR regiszter olvasás-bitműveletek-írás módszertől van gyorsabb is egy láb billengetésére:
Idézet:
„For atomic bit set/reset, the ODR bits can be individually set and/or reset by writing to
the GPIOx_BSRR or GPIOx_BRR registers (x = A..F).”
(#) cimopata válasza toto hozzászólására (») Aug 18, 2016 /
 
Tudom, hogy az gyorsabb azzal az eredmény 75ns vs 220ns-lett a Cube MX javára.

Nem tudom miből adódhat ekkora különbség.
(#) kapu48 hozzászólása Aug 18, 2016 /
 
Mit gondoltok, 8MHz-vel túl lehet húzni 1 STM32F103-ast?
Károsodás nélkül?
A hozzászólás módosítva: Aug 18, 2016
(#) kapu48 válasza cimopata hozzászólására (») Aug 18, 2016 /
 
Mert lehet állítani 3 féle GPIO sebességet.

És utána kellene nézned mire állította neked?
  1. /* Output Maximum frequency selection ----------------------------------------*/
  2. typedef enum
  3. {
  4.   GPIO_Speed_10MHz = 1,
  5.   GPIO_Speed_2MHz,
  6.   GPIO_Speed_50MHz
  7. }GPIOSpeed_TypeDef;
(#) kapu48 válasza kapu48 hozzászólására (») Aug 18, 2016 /
 
Már 1 órája megy 10* szorzóval 80MHz-vel.

Hiba nélkül semmi langyosodás.
Azt hiszem így hagyom!
(#) ha1drp válasza kapu48 hozzászólására (») Aug 18, 2016 /
 
Mások is kipróbálták, mindjárt 128MHz-ig húzták.
(#) cimopata válasza kapu48 hozzászólására (») Aug 18, 2016 /
 
Ez a kimenetek slew rate sebessége. Nem a meredekséggel van baj hanem hogy tovább tart neki elvégeznie.
(#) wbt válasza kapu48 hozzászólására (») Aug 18, 2016 /
 
Na, ez jó! A magok általában nagyon bírják a túlhúzást de a perifériák szoktak téveszteni, leginkább az EEPROM írás, de lehet, hogy az is megy... Megy közben timer-ed vagy USART vagy valami élérzékeny periféria? (pl. I2C).
(#) kapu48 válasza cimopata hozzászólására (») Aug 18, 2016 /
 
Ennek utána mértem!

És igazad lett, a GPIO_Speed_2MHz vagy GPIO_Speed_50MHz beállításnál.
Ugyanazt az impulzus szélességet mértem, ezzel a rutinnal:

  1. /*******************************************************************************
  2. * Function Name  : TIM2_IRQHandler
  3. * Description    : This function handles TIM2 global interrupt request.
  4. * Input          : None
  5. * Output         : None
  6. * Return         : None
  7.  
  8. *******************************************************************************/
  9. void TIM2_IRQHandler(void)
  10. {
  11.          if (TIM_GetITStatus(TIM2, TIM_IT_Update) != RESET)
  12.   {  
  13.        
  14.                         GPIOB->BSRR = BSET10;           // Set PB10 /                                                                                                          
  15.                         GPIOB->BSRR = BRES10;   // Reset PB10           OUT 41ns impulzus              
  16.                         prescalerVal[3]++;                      //Időhúzás, mert különben egybe vette logic analizátor 24MHz-en
  17.                         GPIOB->BSRR = BSET10;           // Set PB10 /                  
  18.                         GPIOB->BSRR = BRES10;   // Reset PB10           OUT 41ns impulzus               /
  19.                        
  20.  
  21.   }
  22.                 //TIM_ClearITPendingBit(TIM2, TIM_IT_Update);
  23.                 TIM2->SR = (u16)~TIM_IT_Update;         // Clear TIM2 update Interrupt source          
  24. }



Ezért csak az első mérésről teszem ide a képet:


Most már ezt is tudom!

ui,: Elég gyenge a kép, de kinagyítva látszik a 2db, 41ns impulzus.
A hozzászólás módosítva: Aug 18, 2016
(#) kapu48 válasza wbt hozzászólására (») Aug 18, 2016 /
 
Igen Megy közben Systick int 10KHz-n, 2 timer 4KHZ-n, USART 115200 baud hibátlanul!
A hozzászólás módosítva: Aug 18, 2016
(#) kapu48 válasza ha1drp hozzászólására (») Aug 18, 2016 /
 
Most olvasom, hogy az USB nem mükszik emelt órajellel!

Aki botloadert használ az ne kísérletezzen!
A hozzászólás módosítva: Aug 19, 2016
(#) cimopata válasza kapu48 hozzászólására (») Aug 18, 2016 /
 
2-10 vagy 50Mhz ennek ott van értelme ahol szeretnénk csökkenteni a nagy dU/dt-t ami esetlegesen áramköri zavarokat okozhat hosszabb vezetékekben.
(#) kapu48 válasza ha1drp hozzászólására (») Aug 18, 2016 /
 
Csak ők GD32-est huztak 128Mhz-re, az alapból tud 108MHz-t!

Bővebben: Link
(#) ha1drp válasza kapu48 hozzászólására (») Aug 19, 2016 /
 
Hát ez, "bluepill" stm32 szerintem , de én is kíváncsi vagyok kipróbálom.
(#) ha1drp válasza ha1drp hozzászólására (») Aug 19, 2016 /
 
Egy gyors SPI (ILI9341 TFT ) és i2c tesztre futotta 128MHz-en. Eddig úgy tűnik minden rendben fut.
(#) kapu48 válasza ha1drp hozzászólására (») Aug 19, 2016 /
 
Olvasom, hogy a Kínából jött STM32-ők, hamisítottak.
Valójában GD32-esek vannak a címke alatt.

Ezért bírják a csúcs hajtást!

Ez igen, amit az LCD-vel produkál!!
(#) ha1drp válasza kapu48 hozzászólására (») Aug 19, 2016 /
 
Köszi az infót, akkor lehet megpróbálkozom az USB résszel is, akkor kiderül mi a típusa valójában.
(#) kapu48 válasza ha1drp hozzászólására (») Aug 19, 2016 /
 
Az USB az reménytelen!
ADC még mükxik: PLL 14* és ADC Presc/ 8 beállítással!
Az Timerk-nél, DMA-nál 112MHz …
Mikor USB-t akarsz használni vissza veszed a PLL szorzót!
A hozzászólás módosítva: Aug 19, 2016
(#) kapu48 válasza kapu48 hozzászólására (») Aug 19, 2016 /
 
Itt (1)egy arduinos példa rá:
Bővebben: Link

Egyébként lehetséges, hogy a Kínai ARM-okban van nagyobb USB elő osztó is?
De mire azokat a dokumentációkat lefordítják legalább angolra!?
(Csak találgatok!)
A hozzászólás módosítva: Aug 19, 2016
(#) csatti2 válasza kapu48 hozzászólására (») Aug 19, 2016 /
 
Azért ne essünk már hanyatt attól. Ez is F103-on fut (csak nem hajtom túl): videó
(#) kapu48 válasza csatti2 hozzászólására (») Aug 19, 2016 /
 
TFT test, ARM 72MHz, 8bit databus??

Az előző SPI-n teljesített hasonlóan!

A kettő rendszer külön súlycsoport!
(#) csatti2 válasza kapu48 hozzászólására (») Aug 19, 2016 /
 
A kínai GD32-es példányokban 0 wait state-es flash van. Már az órajel emelése nélkül is el lehet érni néhány százalékos gyorsulást (állítólag akár 10%-ost is) ennek a beállításával.
Egyébként nem biztos, hogy hamisat veszel. Olyan F103-ast is normális áron vettem, amiből nincs is GD32-es kivitel. A GD32 pedig állítólag hivatalos ST partner, lehet licenszelik az F1-es sorozatot.
(#) csatti2 válasza kapu48 hozzászólására (») Aug 19, 2016 /
 
Az megvan, hogy én teljes képernyőt írok és SD kártyát is olvasok közben? Mind1, ne vitatkozzunk ezen.
(#) kapu48 válasza csatti2 hozzászólására (») Aug 19, 2016 /
 
Ez jó hír!
Pláne ha még az USB Prescale osztót is hozzá állítják az emelt órajelhez!

Csak nem értem! Miért STM logót szitáznak rá, ha a magja GD gyártmány?
(#) csatti2 válasza kapu48 hozzászólására (») Aug 19, 2016 /
 
Próbáld meg levenni a flash latency-t 0-ra az inicializáláskor. Ha rendesen fut a programod, akkor valszeg GD32 a cucc.
(#) kapu48 válasza csatti2 hozzászólására (») Aug 19, 2016 /
 
Távol áll tőlem a vitatkozás!
Te valószínűleg sokat dolgoztál, mire összejött ez a teljesítmény!

A másik meg csak megemelte az órajel szorzót!
(#) csatti2 válasza kapu48 hozzászólására (») Aug 19, 2016 /
 
Annyira sokat azért itt még nem dolgoztam rajta, csak portoltam némi kódot ATXMega-ról ARM-ra és kíváncsi voltam mit bír a vas.
(#) icserny válasza kapu48 hozzászólására (») Aug 20, 2016 /
 
Idézet:
„Egyébként lehetséges, hogy a Kínai ARM-okban van nagyobb USB elő osztó is?”

Igen, van: 1, 1.5, 2 és 2.5-es szorzó. Utóbbi kettővel 48 x 2 = 96 Mhz vagy 48 x 2.5 = 120 MHz frekvencián lehet az USB működését remélni. A 120 MHz kicsit fölötte van a GD32 specifikációjának, de szobahőmérséklet környékén ez nem okozhat gondot. Bővebben: Roger Clark - GD32F103: A STM32F103 on steroids!
Következő: »»   73 / 177
Bejelentkezés

Belépés

Hirdetés
XDT.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem