Názory k článku
Herní konzole Uzebox (2) a nástroje pro programování mikrořadičů Atmel AVR

Zacinam laskovat s myslenkou postavit detem kapesni verzi. S LCD z ebay by to ani tolik moc nestalo, jen toho casu, kdyby bylo vic..
No dobre, tenhle prispevek k nicemu neni. Chtel jsem nejak ventilovat svou radost nad tim, ze nekdo v dnesni dobe jeste bastli takove uzasne vecicky a nekdo dalsi o tom pise. Diky.

No deti to asi neoceni
A pracujci clovek vetsinou uz nema cas na to aby si hral s necim takovymhle :(
Ale je to krasa

Moje decka se docela vyradi na starych hernich konzolich, ma to tu vyhodu, ze se dokazou hru "nahrat" samy (vymenou cartridge) a ty hry jsou jednoduse ovladatelne - to je ostatne problem vetsiny "detskych" her na Linuxu, ze se analfabet ;) skoro pres vsechna menu nedostane k vlastni hre...

lepsie je nintendo DS a ked sa lubi development, tak homebrew je mozny.
Sam mam na konte par hier (aj ked ako oficialny developer)

Dobrý den,

následující text se sice netýká mirokontrolérů AVR, ale předpokládám, že většina čtenářů článků pana Tišnovského má zájem i o další architektury MCU. Doufám tedy, že toto oznámení není příliš mimo zaměření a mravy tohoto fóra.

Společnost TexasInstruments pořádá ve dnech 4.4. a 5.4. jednodenní univerzitní kurzy na vývojových kytech, které registrovaným účastníkům poskytne k užívání pro účely výuky a akademických projektů.

V tuto chvíli zbývá několik míst na školení s MCU MSP430 a možná i několik míst na školení a kity Stellaris na bázi jádra ARM Cortex-M3.

Na školení se mohou v tuto chvíli ještě přihlásit postgraduální studenti, vedoucí předmětů a řešitelé univerzitních projektů. Z jednoho oddělení se mohou zúčastnit maximálně dva delegáti.

Pokud máte zájem a splňujete předchozí podmínky, vyplňte, prosím, údaje na následující stránce a odešlete je e-mailem na uvedenou adresu

http://e2e.ti.com/group/university_zone/european_university_program/f/258/t/96860.aspx

4.4.2011 Launchpad MSP-EXP430G2 (16-bit mikrokontroler MSP430)
<http://focus.ti.com/docs/toolsw/folders/print/msp-exp430g2.html>

5.4.2011 Stellaris EKS-LM3S8962 (32-bit mikrokontroler)
<http://focus.ti.com/docs/toolsw/folders/print/eks-lm3s8962.html>

Místo školení: Budova G, ČVUT FEL na Karlově náměstí

A existuje ktomu aj vyvojove prostredie, ktore sa da spustit na linuxe ?
Myslim aj vyvoj aj flash/debug.... Preferujem gcc/binutils based...

Alebo je k dispozicii iba nejake proprietarne ommedzene na win platformu.

Vdaka.

Ano, my všechny ARMy (zatím ne od Ti) i mnoho projektů s MPS430 programujeme jen z Linuxu a začínali jsme od čipů. Nikoliv od kytů. Na MSP430, když jsme první čipy dostali, jsme si naportovali JTAG flasher

http://ulan.git.sourceforge.net/git/gitweb.cgi?p=ulan/ulan-addons;a=tree;f=libs4c/jtag/msp430

V současné době je i rozumná podpora s JTAGem od MSP-GCC teamu

git clone git://mspdebug­.git.sourcefor­ge.net/gitroot/mspde­bug/mspdebug

Co se týče GCC, tak tak MSP-GCC

http://sourceforge.net/projects/mspgcc/

git clone git://mspgcc4­.git.sourcefor­ge.net/gitroot/mspgcc4/m­spgcc4

chodí pro MSP430 s adresním prostorem do 64kB dokonale. Pro MSP430X je využití adresního protoru nad 64kB zatím problém (experimentální záležitost nad GCC-3 a GCC-4). V projektu MSP-GCC je ale připravený merge na GCC 4.5 a potom přechod na 4.6. Takže to vypadá velmi slibně.

Teď na kombinaci CC2520 + MSP430F2618 zkouší jeden máš diplomant portovat TinyOS. Již se nám podařilo TinyOS nakonfigurovat a dát dohromady s novým GCC, že nám základní testy (blikání LED atd.) do 64 kB chodí.

Dál máme otestované OpenMSP v FPGA.

Někdy připravím pro naše studenty i DEB balíčky pro MSPčšé, aby byla instalace jednoduchá.

Pro ARMy máme na Linuxu všehno možné, bez systému

http://rtime.felk.cvut.cz/hw/index.php/System-Less_Framework

s Linuxem atd. Křížové překladače pro vše možné máme zde

http://rtime.felk.cvut.cz/hw/index.php/Cross_compilers

Na FTDI máme navržený i JTAG od 1.8 V do 5V pro ARMy i FPGA.

Ot Ti z ARMů zatím kolegové používají jen Omap. Stellarisy zatím sám napoužívám a asi se k nim bez nějaké podpory/placeného projektu nedostanu. ARM-ELF toolchain z RTIME pochopitelně Cortex-M3 umí a je možné, že jeden bývalý student na Stellaris používá. Avšak jako obvykle nic moc zpětná vazba a spolupráce. Sami jsme teď plně zaneprázdněni v oblasti malých MCU LPC 17xx od NXP. Kódy v našich repository podporují i Atmel SAM a LPC 21xx, LPC23xx, FreeScale 683xx, Hitachi H8S.

Obecně máme zájem na budování know how a atom, aby se pořád neřešil návrh kola od začátku. Přitom striktně pro své vlastní nověji zakládané projekty používám pouze open sopurce nástroje. Těch pár na Delphi a 8051 assembleru od Intelu založených v devadesátých letech, bych strašně rád přeportoval. 8051 již pokrývají naše projekty na LPC a na Delphi sháním někoho, kdo by pomohl s portací na FPC/Lazarus.

Myslim, ze ne jen ja bych v tomto smeru uvital klidne nejaky clanek na rootu. Sice vam verim ze MSP430 nekomu nekde funguje, ale kdyz vidim jaky chaos v tom ma samotne TI (na kazdy typ jiny programator), tak pokud se tim zivite, nemate cas zkouset zda ta a ta kombinace msp-gcc a dana rada MSP430x funguje a jina ne, nemluve o programatorech s "onchip" debuggerem atd.

MMCH: Pro Omap3 ma TI i vlastni linuxovou distribuci arago linux zalozenou na OE, ale prijde mi ze umira dost na ubyte.

Tiež sa pridávam k budúcim čitateľom článkov o OMAP, vrátane popisu workflow s DSP na 138-ke,
na čo sa môj zatiaľ nezapojený BeagleBoard XM veľmi teší.

proc autori nepouziji napr. atmega640, ktera ma 8kB SRAM? vyresily by se tim nektere problemy spojene s grafickym rezimem. jsem si temer jisty, ze kdyz by se podivali na stranky atmelu, urcite najdou cip s kombinaci 64/128kB FLASH a +8k SRAM.

Mozna je to z 'historickych' duvodu - tedy kdyz projekt vznikal, 640 jeste nebyla k dispozici

Ano, existuju aj procesory AVR s lepsimi parametrami, napriklad moj oblubeny ATMega1284P, ktory ma 128 kB flash a 16 kB RAM, ktory je do velkej miery s ATMega644 kompatibilny. Otazna je castokrat realna dostupnost tychto cipov.

Priznam se, ze presne nevim, jestli 640 jiz byla v dobe navrhu Uzeboxu dostupna.

Na druhou stranu by to zvyseni SRAM na 8 nebo i 16 kB stejne nebylo dostatecne pro graficke rezimy s 256 barvami a navic kdyby byla cela bitmapa v SRAM, byly by operace s jednotlivymi pixely docela pomale (napriklad takovy scrolling cele obrazovky). A rezimy s mene nez 256 barvami zase vykreslovaci rutina nebude stihat posilat na D/A pokud bude horizontalni rozliseni moc velke - uz takto je Uzebox i diky pretaktovani cipu na hrane, kdy se to taktak dari vykreslit bez ztraty synchronizace ci posunu pixelu.

Takto vlastne autori docela elegantne presunuli tu casove narocnou praci se "serializaci" bitmapy na vykreslovaci subrutiny, ktere se tak jako tak musi 25x za sekundu spoustet.

Co by ale bylo mooc pekne a uzitecne, by bylo presunuti dlazdic do SRAM - takto to melo resene osmibitove Atarko a autori her se v te dobe pekne vyradili na runtime zmene map znaku (=dlazdic).

Napriklad ve hre Boulder Dash posun pozadi na uvodnim screenu neni nic jineho, nez zmena pouze osmi bajtu v pameti, kam je smerovana rutina pro vykreslovani znaku (to resil ANTIC). Ta zmena se da ustihat dokonce i v Basicu ;-)

Mate pravdu jde, ale aby to bylo uzitecne, tak je dobre mit alespon tech 8 kB SRAM. Je to sice uz dost na hrane s rychlosti ale je to resitelne.

To se můžeme rovnou ptát, proč nepoužít nějaký malý arm nebo něco podobého. Tam se najdou brouky ve stejné ceně nebo i levnější s řádově větším výkonem, velikostí flash i sram. Dokonce něco takového na malém arm cortex M1 i existuje, kdy jsem to linkoval pod článek o grafice Atari 2600 (tuším).