STM32H7 a LL

Jaroslav Buchta jaroslav.buchta na hascomp.cz
Čtvrtek Listopad 22 06:10:35 CET 2018


Njn, myslel jsem tak do konce roku, asi nebude, smirim se s HAL...
V noci jsem zkousel vygenerovat kod s HAL a s pouzitim ETH a zarazila 
mne dalsi vec - .ld soubor pro GCC nema definovany sekce 
RxDecripSection, TxDecripSection, RxArraySection, furt mi vrtalo hlavou, 
jak se pocita s pouzitim jinych pameti nez DTCM

ve zdrojaku jsou pouzity
ETH_DMADescTypeDef DMARxDscrTab[ETH_RX_DESC_CNT] 
__attribute__((section(".RxDecripSection"))); /* Ethernet Rx DMA 
Descriptors */
ETH_DMADescTypeDef DMATxDscrTab[ETH_TX_DESC_CNT] 
__attribute__((section(".TxDecripSection")));   /* Ethernet Tx DMA 
Descriptors */
uint8_t Rx_Buff[ETH_RX_DESC_CNT][ETH_MAX_PACKET_SIZE] 
__attribute__((section(".RxArraySection"))); /* Ethernet Receive Buffers */

po prekladu podle map souboru jsou promenne v RAM s bazi 0x20000000, coz 
asi nebude fungovat, jestli chapu dobre, ETH DMA (asi nejen) nemuze 
fungovat s DTCMRAM, ale asi jen s RAM-D1 od 0x24000000

  .RxArraySection
                 0x20000080     0x17e0 Src/ethernetif.o
                 0x20000080                Rx_Buff

.RxDecripSection
                 0x20001860       0x60 load address 0x080109bc
  .RxDecripSection
                 0x20001860       0x60 Src/ethernetif.o
                 0x20001860                DMARxDscrTab

.TxDecripSection
                 0x200018c0       0x60 load address 0x08010a1c
  .TxDecripSection
                 0x200018c0       0x60 Src/ethernetif.o
                 0x200018c0                DMATxDscrTab
                 0x20001920                . = ALIGN (0x4)

.bss            0x20001920     0x3aa0 load address 0x08010a7c
                 0x20001920                _sbss = .
                 0x20001920                __bss_start__ = _sbss
  *(.bss)
  .bss           0x20001920       0x1c c:/ac6/systemworkbenc


Neco jsem opomenul nekde nastavit, je to chyba nebo je to vlastnost ve 
stylu do-do?
Jen mne trosku desi, ze kdyz k tomu jeste nejsou ani LL knihovny, jak 
asi ten HAL bude fungovat, pokud by uz tady byl problem ;-)

Ten procesor je celkem delo, IMHO se nabizi presunout cast kodu do ITCM 
RAM, idealne tam hodit tabulku vektoru a obsluhy ISR, s tim by asi nebyl 
problem, ale vrta mi hlavou, jak tam dostat standardni knihovny C, 
vsechny, pripadne jen vybrane.
Jde to nejak snadno v GCC nastavit? Asi by ale vzniknul problem, pro 
ostatni kod, ze volani vsech funkci by byla dlouha, otazka je, jestli by 
to vadio. Nebo v ISR nepouzivat knihovni fce, ale to ne vzdy jde.


Dne 21.11.2018 v 21:14 Jan Waclawek napsal(a):
> No tak to zrejme nebude do par tyzdnov, ked tam pise ze
>
> Unfortunately, there was a delay to deliver this version which cannot be
> available publicly before the end of the year.
>
> Teda ak par je 2. ;-)
>
> wek
>
> ----- Original Message ---------------
>> Ano, to uz jsem nasel, nasel jsem i hezky obrazek od STM s diagramem, ze
>> to bude v 18Q4, bohuzel jsem tento nenasel na strankach STM ale jen v
>> nejakem foru
>> https://community.st.com/s/question/0D50X00009Xkia8SAB/release-date-of-the-stm32h7-ll-lowlayer-api
>> .
>> Ale 18Q4 uz mame za pulkou, kdyz se to tak vezme ;-)
>> Trosku mi to zkomplikuje zivot jestli to nebude do par tydnu, budu muset
>> predelat program docela dost, nepocital jsem s takovou komplikaci :-(
>>
>> Dne 21.11.2018 v 20:57 Jan Waclawek napsal(a):
>>> https://community.st.com/s/question/0D50X00009XkbYxSAJ/stm32cubeh7-missing-the-ll-lowlayer-api
>>>
>>> najnovsia odpoved od Amel (neda sa dat priamy odkaz)
>>>
>>> wek
>>>
>>>
>>>> chapu dobre, ze pro tuto radu uz nejsou a nebudou podporovany LL
>>>> knihovny uz vubec pro nic?
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list




Další informace o konferenci Hw-list