Aby aspon nekdo podekoval tak ja tedy urcite dekuji. Z me strany mam spis radsi kdyz je aplikace stavena od "zacatku" tudis HAL a IAP asi moc neocenim do doby nez se nekde doctu k cemu to je dobre (cos asi vsichni krome me vedi), ale ve zdrojacich od HAL a IAP neni ani kousek komentare. Pokud je nekde popis tak me prosim nasmerujte.(prosim ne tam kde slunce nesviti 8-)). Beru si sebou na chatu NB se stazenym syslessem. Kdyz to pujde tak zkusim LpcEurobot (LPC2119) a LPC1768 (MBED). A v praci pak v tejdnu jeste zkusim Lpc2364. Jirka 2.7.10, Pavel Pisa <pisa@cmp.felk.cvut.cz>:
Provedl jsem bezohledné úpravy v syslessu. Pravděpodobě je tam dost chyb. Všichni, kdo si neodzkoušeli GCC-4.4.x mohou mít ve svých projektech problémy a nebudu je řešit. Jsem ochoten řešit pouze potíže reportované proti GCC-4.4.4 a vyšší zkompilovaným s NewLib 1.18.0 s našimi opravami nebo aktuální mainline verzí z CVS, která je již obsahuje. Toolchain je k dispozici z http://rtime.felk.cvut.cz/hw/index.php/Cross_compilers ftp://rtime.felk.cvut.cz/debian/pool/arm-elf/
Kontroloval jsem pouze kompilaci pro hiddemo-lpc2364 config.target -> board/arm/lpc2364-12/config.lpc2364-12
a bare LPC17xx bez jakékoliv rozumné aplikace config.target -> board/arm/lpc17xx-common/config/config.bare
nazdar2364-ram a usbhid-flash se mi pro hiddemo-lpc2364 kompiluje v pořádku, bohužel dál to spadne v nějaké obskurní aplikaci, které chybí správné podmínění configem
make[omk]: binary-pass in app/arm/test222 make[5]: *** No rule to make target `/home/pi/repo/rtime/rtime-git/sysles-build/hiddemo-lpc2364/app/arm/test222/can_btr.c',
Co je to za šrot?
Kvůli podpoře LPC17xx jsem do RTIME sysless přidal LT_TIMER z uLanu.
Obecně podpora LPC17xx je spíše podle pravidel uLanu než RTIME sysless. Je potřaba zvážit přidání
sysless/arch/arm/mach-lpc21xx/libs/hal sysless/arch/arm/mach-lpc21xx/libs/iap
a
sysless/arch/arm/mach-lpc23xx/libs/hal sysless/arch/arm/mach-lpc23xx/libs/iap
Dále LPC17xx vychází z původního konceptu uložení ldscriptů v BSP v adresáři board. Je pravda, že pro "tightly copuled SoC" jako je LPC by bylo dobré hlavní část dát někam do mach-xxxx tak jak je to u LPC21xx a LPC23xx, ale BSP by stejně měla být dána svoboda a finální rozhodnutí o velikostech pamětí atd. Opět je potřeba ochota a investice na sjednocení.
Aby jsme se posunuli dál, bylo by dobré aby vznikly ty další testovací buildy. Asi by měly existovat i testovací aplikace pro každý machine ve stylu nazdar2364 (až na to jméno, kde souhlasím s Michalem v potřebě používat angličtinu).
Dál by bylo potřeba otestovat Markovu podporu LPC13xx proti změněnému kódu základu ARMu a v rozumné době vyčistit tak, aby byla přijatelná.
V LPC17xx chybí asi lpc17xx.h nebo LPC17xx.h. Petře ?
Bohužel RTIME sysless je pro mě nepoužitelný do té doby, dokud se neudělá vyčistění i s ochledem na mé potřeby. Pro ostatní má pomoc velký význam v tom, že pak budu třeba i já tento fork sysless původě založeného na ARM, m68k a h8s základu vyvinutému v PiKRONu i tam moc použít a nebude se to pořád rozpadat.
Z dalších věcí, co je potřeba dotáhnout, je sjednocení CMDPROC. Opět je to fork a bohužel mi s dalšími verzemi pro RTEMS, MX1 a m68k nesedí. Michal ho rozdělil do více souborů a i dost vylepšil. Bohužel ale některé úpravy nejsou zcela kompatibilní s naším použitím a podporou UARTů a dalších I/O.
Obecně je v syslessu zmatek v podpoře UARTů. Bohužel každý začal implementovat z nuly a hodně se to rozchází. Nejkompletnější je asi moje původní podpora pro m68k, obsahuje fronty, IRQ, HW (RTS/CTS) i SW (XON/XOFF) flow-control atd. V kooperaci s Michalem pak byla na základě ní a PiKRONské původní podpory H8S vytvořena H8S veze v RTIME syslessu. Ta je sice chudší o flow-control, ale má dobře vyřešenou volbu jednoho z více UARTů a integraci s deskami. Verze pro ARM v RTIME sysless vznikali zcela bez nějaké koordinace se mnou a pořádně je neznám. Sám mám připravený a používám základ pro MX1, co se týče ARMů.
Obecně by to chtělo sjednotit. Podpora by měla být udělaná tak, aby šla zkompilovat pomocí volby zcela bez IRQ nebo v režimu s frontami a IRQ. Optimálně tak, aby šlo v plné verzi mezi režimy IRQ/bez IRQ a bez IRQ i fronty přepínat. Hodí se to třeba při výpisu fatálních chyb, kdy již nejde předpokládat že se procesor nezresetuje dřív, než se zpráva vytiskne.
Sjednocení UARTů je potřeba i pro CMDPROC.
Další krok je sjednocení API pro CAN atd.
S pozdravem,
Pavel Píša e-mail: pisa@cmp.felk.cvut.cz www: http://cmp.felk.cvut.cz/~pisa university: http://dce.felk.cvut.cz/ company: http://www.pikron.com/
-- =================================================== Bc. Jiri Kubias Czech Technical University in Prague Faculty of Electrical Engineering dept. of Control Engineering Karlovo namesti 13/E, 121 35 Prague Czech Republic web page: http://dce.felk.cvut.cz e-mail: jiri.kubias@gmail.com mobile: 777 974167 =================================================== ---