<p style="padding:0 0 0 0; margin:0 0 0 0;">diky moc za odpoved.</p>
<p style="padding:0 0 0 0; margin:0 0 0 0;"> </p>
<p style="padding:0 0 0 0; margin:0 0 0 0;">ja zacinal na PIC16C84 v assembleru, pozdeji v C, pokracoval na 89C2051 v assembleru a pozdeji v C, pak AVR v assembleru i C.... STM32 ucime v assembleru i C </p>
<p style="padding:0 0 0 0; margin:0 0 0 0;">takze bych to snad i dokazal, ale musim se priznat, ze RTFM kvuli studiu registru me uplne nebavi, zvlast kdyz tam neni o te posloupnosti vykonavani mnoho napsano..</p>
<p style="padding:0 0 0 0; margin:0 0 0 0;"> </p>
<p style="padding:0 0 0 0; margin:0 0 0 0;">takze jsem jeste jednou kouknul na ty hodiny a nakonec to vyresil prepnutim SYSCLK z PLL na HSI16 coz slo prikazem <span style="color: #333e48; font-family: Consolas, 'Courier New', monospace; font-size: 14px; white-space: pre;">RCC_CFGR &=0xFFFFFFF5;</span></p>
<p style="padding:0 0 0 0; margin:0 0 0 0;"> </p>
<p style="padding:0 0 0 0; margin:0 0 0 0;"> </p>
<p style="padding:0 0 0 0; margin:0 0 0 0;">perlicka ohledne STM32 - diplomant ma v konstrukci <span style="color: #002052; font-family: Arial, sans-serif; font-size: 13.3333px;">STM32H7A3ZIT6... ty nejsou... plan byl v nouzi vypajet ten MCU z nuclea </span><font face="Arial, sans-serif" color="#002052"><span style="font-size: 13.3333px;">NUCLEO-H7A3ZI-Q.</span></font></p>
<p style="padding:0 0 0 0; margin:0 0 0 0;"><font face="Arial, sans-serif" color="#002052"><span style="font-size: 13.3333px;">bohuzel nepredchazelo tomu dostatecne RTFM, a az kvuli nefunkcnosti celku jsme zjistili, ze Q na uplnem konci oznaceni MCU znamena vestaveny menic a tudiz uplne jiny pinout MCU..</span></font></p>
<p style="padding:0 0 0 0; margin:0 0 0 0;"><font face="Arial, sans-serif" color="#002052"><span style="font-size: 13.3333px;">to jsme fakt necekali...</span></font></p>
<p style="padding:0 0 0 0; margin:0 0 0 0;"><font face="Arial, sans-serif" color="#002052"><span style="font-size: 13.3333px;"><br />
</span></font></p>
<p style="padding:0 0 0 0; margin:0 0 0 0;"><font face="Arial, sans-serif" color="#002052"><span style="font-size: 13.3333px;">v.</span></font></p>
<p style="padding:0 0 0 0; margin:0 0 0 0;"> </p>
<p style="padding:0 0 0 0; margin:0 0 0 0;"><font face="Arial, sans-serif" color="#002052"><span style="font-size: 13.3333px;"><br />
</span></font></p>
<p style="padding:0 0 0 0; margin:0 0 0 0;"> </p>
<p style="padding:0 0 0 0; margin:0 0 0 0;"> </p>
<p style="padding:0 0 0 0; margin:0 0 0 0;"><span style="color: #333e48; font-family: Consolas, 'Courier New', monospace; font-size: 14px; white-space: pre;"><br />
</span></p>
<p style="padding:0 0 0 0; margin:0 0 0 0;">______________________________________________________________<br />
> Od: "Jan Waclawek" <konfera@efton.sk><br />
> Komu: "HW-news" <hw-list@list.hw.cz><br />
> Datum: 11.04.2023 14:45<br />
> Předmět: Re: stm32 registro trapeni<br />
></p>
Este aby som to trocha viac obkecal.<br />
<br />
Ten I2C v 'G4 (ako aj takmer vsetky ostatne moduly v takmer vsetkych STM32<br />
novsich ako cojaviem 5 rokov) maju dve casovacie domeny: pristup k<br />
registrom ma hodiny APBCLK z APB zbernice na ktorom je dany modul<br />
zaveseny, ale zvysok toho I2C stroja bezi z tzv. "kernel" hodin, ktore su<br />
v konkretnom pripade 'G4 volitelne v RCC medzi SYSCLK/HSI/APB. <br />
<br />
To znamena, ze medzi registrami a celym zvyskom toho I2C modulu su<br />
synchronizatory, inaksie povedane, zapis do registrov sa neobjavi okamzite<br />
v skutocnom pracovnom jadre toho modulu. U toho I2C modulu je to vidiet na<br />
blokovom diagrame na zaciatku kapitoly, ale aj v tom, ze niektore registre<br />
maju tuto poznamku:<br />
<br />
Access: No wait states, except if a write access occurs while a write<br />
access to this register is<br />
ongoing. In this case, wait states are inserted in the second write access<br />
until the previous<br />
one is completed. The latency of the second write access can be up to<br />
2 x PCLK1 + 6 x I2CCLK.<br />
<br />
pricom nie je jasne, co sa stane, ak sa rychlo za sebou zapise do dvoch<br />
roznych registrov s touto poznamkou.<br />
<br />
Z toho potom vyplyvaju prave rozne tie obvykle zle alebo vobec<br />
nedokumentovane podmienky ze "nemoze sa zapisat nieco prilis rychlo alebo<br />
v tomto a tomto poradi", rozne komplikovane erraty(*); no a tiez to, ze<br />
nejaky kod autorovi kniznice je "mne to funguje" ale pri pouziti "lepsej"<br />
optimalizacie prestane fungovat, atd.atd.<br />
<br />
wek<br />
<br />
<br />
(*) Napr.<br />
If the first of the two bytes is written in the I2C_TXDR<br />
register in less than two I2C kernel clock cycles after the TXIS/DMA<br />
request, and the ratio between APB clock<br />
and I2C kernel clock frequencies is between 1.5 and 3, the second byte<br />
written in the I2C_TXDR is not internally<br />
detected. This causes a state in which the I2C peripheral is stalled [...]<br />
<br />
_______________________________________________<br />
HW-list mailing list - sponsored by www.HW.cz<br />
Hw-list@list.hw.cz<br />
<a href="http://list.hw.cz/mailman/listinfo/hw-list">http://list.hw.cz/mailman/listinfo/hw-list</a><br />