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/ ---