Názory k článku Šestnáctibitové mikrořadiče TI řady MSP430 – instrukční sada a periferní moduly
-
Pavel Vymetálek (neregistrovaný)
Jako vždy, super čtení. Jen tak dál. Těsím se na pokračování. Díky.
Přemýšlel jsem proč právě u této architektury popisujete periferie, I2C apod. a mám pocit, že to proto, že TI má ve svých datasheetech popsánu obšírně i "teorii" srozumitelně a přehledně. Je to tak nebo jinak? :-) -
Pavel TišnovskýZlatý podporovatelTaky děkuji za feedback.
Je to trošku jinak - ten popis instrukční sady mi připadl na článek krátký (mám nastavený určitý osobní limit :-), tak jsem tam zpočátku chtěl přidat všechno, včetně watchdogů, PWM atd., ale to zase bylo dlouhé. Takže volba padla na paralelní a sériovou komunikaci, ta je snadno uchopitelná a praktická...
-
Petr M (neregistrovaný)
Ono ve srovnání s 8051 je C příjemný všude :) Jenom to segmentování paměti na CODE, RAM, SFR, XCODE, XRAM, BOOL,... A předej parametry na zásobníku se 128B RAM :Q. Jo, to už je lepší 8052, kde se dá zásobník přehodit do IRAM (128B) a RAM zůstane celá, pokud to nepřeteče.
Ale práce s MASP430 na úrovni HAL/BSP je v C taky utrpení. K čemu mám ale obrovskou výhradu, jsou hlavičkový soubory k procesoru. Za ty bych věšel za genitálie, protože:
1) Člověk může zapomenout na to, že by registry periferie měl jako strukturu a přistupoval k periferce přes ukazatel. Použití například dvou časovačů znamená psaní dvou ovladačů. protože registry jsou prostě makra :(
2) Makra pro registry jsou složeny z maker složených z maker,.. A například v C::B to tak dokonale zmate našeptávač, takže z jméno registru vybleje ještě podrtžítko. A proklikat se k hodnotě je nadlidský úkol.
3) Bitový pole pro registry jsou makra. Název těchto maker nijak nekoresponduje ani s registrem, ani s periferkou. Kdo má vědět, že ABC1 je pátý bit registru DEF perifetky UVW3? A jestli jde použít u na UVW2? Normální je přece ho pojmenovat UVW_DEF_ABC1.
4) Pokud je v registru nějaká hodnota, která je na několik bitů, tak jsou tam dvě sady maker. Jedna pro jednotlivý bity, druhá pro hodnoty. Odlišují se jedním podtržítkem a vznikají z toho zbytečně chyby typu "hodina s osciloskopem".
5) Pokud už člověk chce použít hodnotu, nenajde "UART_PARITY_NONE" nebo "UART_PARITY_ODD", ale prostě číslovaný hodnoty stylem PAR_0, PAR_1,... a domysli si při čtení kódu, co to znamená a piš jenom podle manuálu.
6) Všechny komentáře se týkají kompilátoru, typu procesoru a toho, kdy ten soubor byl vyblit. Přitom Doxygen ještě nikoho nezabil a moderní IDE přímo dokážou jako nápovědu zobrazit tuto dokumentaci.A dál bych jim vytknul:
7) Naprosto debilní ovládání přerušení. Tím debilním myslím, že přerušení není součást periferky (na úrovni HW). Takže i když si člověk vyrobí vlastní strukturu pro periferku a vyhraje si s tím, ještě musí bokem držet informace, na které adrese je který bit jako maska přerušení. S omezením RAM, ROM i výkonu je toto navíc potřeba přepínat už v čase kompilace pomocí sady maker a když se jedno makro poplete, tak se člověk diví.
8) Zatím u každé použité periferky jsem softwarově řešil něco, co by jinde šlo řešit hardwarem.Takže když můžu, dám tam místo něj Cortex-M.
