Hlavní navigace

Názory k článku Šestnáctibitové mikrořadiče TI řady MSP430 – instrukční sada a periferní moduly

  • Článek je starý, nové názory již nelze přidávat.
  • 8. 11. 2016 9:50

    Pavel Vymetálek (neregistrovaný) 193.138.155.---

    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? :-)

  • 8. 11. 2016 12:12

    Pavel Tišnovský

    Taky 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á...

  • 8. 11. 2016 12:04

    Josef Pavlik

    Moc zajimava instrukcni sada. Bylo by zajimave si s tim nekdy pohrat. Skoda, ze uz me moc nebavi psat v assembleru. Rekneme si to uprimne, v C je to podstatne pohodlnejsi. Ale nekdy ti nezbude nic jinyho, aspon je to vetsi zabava.

  • 8. 11. 2016 19:21

    tisnik (neregistrovaný) ---.tmcz.cz

    ono je i to céčko pro MSP takové příjemné, nejsou tam moc velké speciality, jaké potkáš například na 51.

  • 9. 11. 2016 12:18

    Petr M (neregistrovaný) ---.145.broadband16.iol.cz

    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.