<div dir="ltr">Good idea, I did it.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 3, 2014 at 10:32 PM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Please send a note to rtems-users, some may be interested to hear this<br>
addition. -Gedare<br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, Nov 3, 2014 at 4:28 PM, Ben Gras <<a href="mailto:beng@shrike-systems.com">beng@shrike-systems.com</a>> wrote:<br>
> Indeed. I did right away verify I can build & run & test everything for the<br>
> beaglebones and the bbxm from mainline. So that seems to have gone fine.<br>
><br>
> The supporting tools and RSB stuff I am in contact with Chris about.<br>
><br>
><br>
> On Mon, Nov 3, 2014 at 10:23 PM, Joel Sherrill <<a href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a>><br>
> wrote:<br>
>><br>
>><br>
>> On 11/3/2014 3:06 PM, Ben Gras wrote:<br>
>><br>
>> All,<br>
>><br>
>><br>
>> Joel merged these and I updated my blog post to reflect the mainline repo.<br>
>> Thanks Joel!<br>
>><br>
>> Thank you Ben for the nice submission!!!<br>
>><br>
>> Now to make sure it is reproducible from here and we have merged<br>
>> all the bits into the tools, etc.<br>
>><br>
>> On Mon, Nov 3, 2014 at 8:40 PM, Ben Gras <<a href="mailto:beng@shrike-systems.com">beng@shrike-systems.com</a>> wrote:<br>
>>><br>
>>> All,<br>
>>><br>
>>> I have new patches with some last-minute smoothings added; removed<br>
>>> obsolete beagle.cfg, TODO, and separated the more generic ARM headers into a<br>
>>> separate commit. The new 3 commits are attached (and in my RTEMS github<br>
>>> repo).<br>
>>><br>
>>> Gedare, there is also a diff w.r.t. the previous submission attached as<br>
>>> requested.<br>
>>><br>
>>><br>
>>><br>
>>> On Mon, Nov 3, 2014 at 3:01 PM, Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br>
>>>><br>
>>>> Hi,<br>
>>>><br>
>>>> I don't have time to review, but am OK in principle with committing<br>
>>>> this code as it is tested, with the caveat that my previous comments<br>
>>>> be addressed post-merge.<br>
>>>><br>
>>>> If you have a diff / commits on top of what you sent before, I'd be<br>
>>>> glad to give those a quick look.<br>
>>>><br>
>>>> Thanks for your contribution!<br>
>>>> Gedare<br>
>>>><br>
>>>> On Mon, Nov 3, 2014 at 7:20 AM, Ben Gras <<a href="mailto:beng@shrike-systems.com">beng@shrike-systems.com</a>><br>
>>>> wrote:<br>
>>>> > All,<br>
>>>> ><br>
>>>> > Ok, as promised, I rebased and re-tested and have found & included a<br>
>>>> > portable way of making the SD card image (included in sdcard.sh), to<br>
>>>> > be<br>
>>>> > merged with RSB (i.e. some of the tools sdcard.sh relies on are<br>
>>>> > missing in<br>
>>>> > mainline RSB). Some of Gedare's initial feedback is processed thanks<br>
>>>> > to<br>
>>>> > Brandon Matthews. It's tested to run on the original beaglebone,<br>
>>>> > beaglebone<br>
>>>> > black and qemu linaro. (The assumption is it'll run on the bbxm<br>
>>>> > hardware as<br>
>>>> > well as it was before rebasing.)<br>
>>>> ><br>
>>>> > The result is split into 2 patches to show what was Claas's initial<br>
>>>> > work.<br>
>>>> > This makes them a bit unreadable for the final result from the patches<br>
>>>> > unfortunately.<br>
>>>> ><br>
>>>> > As before, see<br>
>>>> ><br>
>>>> > <a href="http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html" target="_blank">http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html</a><br>
>>>> > on how to build all the tools, RTEMS executables, sdcard images, and<br>
>>>> > run the<br>
>>>> > test set from linaro qemu.<br>
>>>> ><br>
>>>> ><br>
>>>> ><br>
>>>> > On Sat, Aug 30, 2014 at 5:50 PM, Ben Gras <<a href="mailto:beng@shrike-systems.com">beng@shrike-systems.com</a>><br>
>>>> > wrote:<br>
>>>> >><br>
>>>> >> All,<br>
>>>> >><br>
>>>> >> OK, that seems like a fruitful way to proceed to me.<br>
>>>> >><br>
>>>> >> Then I will do some minor cleanups, rebase, do all the tests again,<br>
>>>> >> and<br>
>>>> >> re-submit. There's just one problem I know of that I want to fix<br>
>>>> >> before the<br>
>>>> >> first commit happens, and that is that the FAT fs made by mtools<br>
>>>> >> doesn't<br>
>>>> >> boot on the HW it seems. (It does on the emulator.) A last-minute<br>
>>>> >> change -<br>
>>>> >> switching to mtools instead of dosfstools to use to make the SD card<br>
>>>> >> image<br>
>>>> >> because the latter is so linux-only.<br>
>>>> >><br>
>>>> >> Stay tuned.<br>
>>>> >><br>
>>>> >><br>
>>>> >><br>
>>>> >><br>
>>>> >> On Wed, Aug 20, 2014 at 4:20 PM, Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>><br>
>>>> >> wrote:<br>
>>>> >>><br>
>>>> >>> Ben, As far as getting this merged, all of my comments can be done<br>
>>>> >>> as<br>
>>>> >>> a follow-on commit. -Gedare<br>
>>>> >>><br>
>>>> >>> On Thu, Jul 24, 2014 at 4:28 PM, Ben Gras <<a href="mailto:beng@shrike-systems.com">beng@shrike-systems.com</a>><br>
>>>> >>> wrote:<br>
>>>> >>> > Thanks for the fast & detailed review. Let me get back to it/you.<br>
>>>> >>> ><br>
>>>> >>> > In the meantime, any other feedback? From anyone I mean.<br>
>>>> >>> ><br>
>>>> >>> ><br>
>>>> >>> ><br>
>>>> >>> > On Thu, Jul 24, 2014 at 4:45 PM, Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>><br>
>>>> >>> > wrote:<br>
>>>> >>> >><br>
>>>> >>> >> Hi Ben,<br>
>>>> >>> >> Great work. I have a few comments. I skipped the i2c.h and i2c.c<br>
>>>> >>> >> files. Most of my comments are about style and a few requests to<br>
>>>> >>> >> refactor some of the larger files. The refactoring can be added<br>
>>>> >>> >> to<br>
>>>> >>> >> your TODO if you like. Please fix the style issues if it is not a<br>
>>>> >>> >> burden.<br>
>>>> >>> >><br>
>>>> >>> >> +++ b/c/src/lib/libbsp/arm/beagle/README<br>
>>>> >>> >> +$ ../claas-rtems/configure --target=arm-rtems4.11<br>
>>>> >>> >> --enable-rtemsbsp="beaglebonewhite beagleboardxm"<br>
>>>> >>> >> Replace claas-rtems with rtems. If RSB support is available, make<br>
>>>> >>> >> a<br>
>>>> >>> >> note about it.<br>
>>>> >>> >><br>
>>>> >>> >> +++ b/c/src/lib/libbsp/arm/beagle/TODO<br>
>>>> >>> >> [...]<br>
>>>> >>> >> open:<br>
>>>> >>> >> + . how to handle the interrupt?<br>
>>>> >>> >><br>
>>>> >>> >> What does this mean?<br>
>>>> >>> >><br>
>>>> >>> >> +++ b/c/src/lib/libbsp/arm/beagle/clock.c<br>
>>>> >>> >> Why is the entire file ifdef'd on ARM_MULTILIB_ARCH_V4?<br>
>>>> >>> >><br>
>>>> >>> >> It might be sensible to put the struct definitions in a .h file<br>
>>>> >>> >> if<br>
>>>> >>> >> these omap registers might be re-usable.<br>
>>>> >>> >><br>
>>>> >>> >> +static struct omap_timer_registers regs_v2 = {<br>
>>>> >>> >> This might be better to put behind an #if IS_AM335X since it is<br>
>>>> >>> >> not<br>
>>>> >>> >> used otherwise?<br>
>>>> >>> >><br>
>>>> >>> >> +<br>
>>>> >>> >> +<br>
>>>> >>> >> +<br>
>>>> >>> >> Avoid more than one blank line in a row.<br>
>>>> >>> >><br>
>>>> >>> >> +static int done = 0;<br>
>>>> >>> >> It would be nice if you got rid of this, but otherwise give it a<br>
>>>> >>> >> more<br>
>>>> >>> >> useful name like "mmio_init_done"<br>
>>>> >>> >><br>
>>>> >>> >> +static void beagle_clock_handler_install(rtems_interrupt_handler<br>
>>>> >>> >> isr)<br>
>>>> >>> >> + if (sc != RTEMS_SUCCESSFUL) {<br>
>>>> >>> >> + rtems_fatal_error_occurred(0xdeadbeef);<br>
>>>> >>> >> I think there is some capabilities in ARM for bsp fatal error<br>
>>>> >>> >> codes<br>
>>>> >>> >> now. They should be preferred to be used to help debug these<br>
>>>> >>> >> fatal<br>
>>>> >>> >> conditions.<br>
>>>> >>> >><br>
>>>> >>> >> +static inline uint32_t<br>
>>>> >>> >> beagle_clock_nanoseconds_since_last_tick(void)<br>
>>>> >>> >> + return (read_frc() - (uint64_t) last_tick_nanoseconds) *<br>
>>>> >>> >> 1000000000<br>
>>>> >>> >> / FRCLOCK_HZ;<br>
>>>> >>> >> This line is > 80 characters, please break it or shrink it.<br>
>>>> >>> >><br>
>>>> >>> >> +++ b/c/src/lib/libbsp/arm/beagle/console/console-config.c<br>
>>>> >>> >> +#define CONSOLE_UART_LSR (*(volatile unsigned int<br>
>>>> >>> >> *)(BSP_CONSOLE_UART_BASE+0x14))<br>
>>>> >>> >> Line > 80 characters, even with the spacing modified.<br>
>>>> >>> >><br>
>>>> >>> >> +static void beagle_console_init(void)<br>
>>>> >>> >><br>
>>>> >>> >> + while ((CONSOLE_SYSS & 1) == 0)<br>
>>>> >>> >> + ;<br>
>>>> >>> >> Is this a fatal loop or is it waiting for hardware to clear<br>
>>>> >>> >> something?<br>
>>>> >>> >><br>
>>>> >>> >> + if ((CONSOLE_LSR & (CONSOLE_LSR_THRE | CONSOLE_LSR_TEMT)) ==<br>
>>>> >>> >> CONSOLE_LSR_THRE) {<br>
>>>> >>> >> Again > 80 characters. Is the test logically equivalent to: if (<br>
>>>> >>> >> (CONSOLE_LSR & CONSOLE_LSR_THRE) == CONSOLE_LSR_THRE)<br>
>>>> >>> >><br>
>>>> >>> >> + while ((CONSOLE_LSR & CONSOLE_LSR_TEMT) == 0)<br>
>>>> >>> >> + ;<br>
>>>> >>> >> Is this a fatal loop or is it waiting for hardware?<br>
>>>> >>> >><br>
>>>> >>> >> +++ b/c/src/lib/libbsp/arm/beagle/include/bsp.h<br>
>>>> >>> >> This bsp.h is really long. Probably it should be refactored into<br>
>>>> >>> >> other<br>
>>>> >>> >> headers, including non-public ones.<br>
>>>> >>> >><br>
>>>> >>> >> +static inline void dsb(void)<br>
>>>> >>> >> +{<br>
>>>> >>> >> + asm volatile("dsb" : : : "memory");<br>
>>>> >>> >> Fix the indentation.<br>
>>>> >>> >><br>
>>>> >>> >> +static inline void flush_data_cache(void)<br>
>>>> >>> >> Perhaps this should be using _CPU_cache_flush_entire_data()?<br>
>>>> >>> >> Perhaps<br>
>>>> >>> >> there is a difference in that the cache manager code flushes and<br>
>>>> >>> >> "cleans" the cache...<br>
>>>> >>> >><br>
>>>> >>> >> +<br>
>>>> >>> >> +<br>
>>>> >>> >> +<br>
>>>> >>> >> +<br>
>>>> >>> >> Excess newlines. Done a few places in this file.<br>
>>>> >>> >><br>
>>>> >>> >> The comments following the defines for various AM33X_INT_ values<br>
>>>> >>> >> go<br>
>>>> >>> >> off the end of the 80 column character width. Same for some other<br>
>>>> >>> >> comments following defines for OMAP3_TIMER, AM33X_DMTIMER1, and<br>
>>>> >>> >> AM335X_TIMER_. And further below for the CM_ WKUP and<br>
>>>> >>> >> CM_PER_TIMER7<br>
>>>> >>> >> defines, and CLKSEL_TIMER1MS_CLK_SEL_SEL5.<br>
>>>> >>> >><br>
>>>> >>> >> +#define OMAP3_TCLR_AR (1 << 1) /* Autoreload or one-shot<br>
>>>> >>> >> mode<br>
>>>> >>> >> */<br>
>>>> >>> >> +#define OMAP3_TCLR_PRE (1 << 5) /* Prescaler on */<br>
>>>> >>> >> +#define OMAP3_TCLR_PTV 2<br>
>>>> >>> >> This PTV is odd compared to the other defines here. Is it 2 ==<br>
>>>> >>> >> (1<<1),<br>
>>>> >>> >> or is there a typo here?<br>
>>>> >>> >><br>
>>>> >>> >> Tabs are used in the OMAP3_CM_ defines, it should be space<br>
>>>> >>> >> characters.<br>
>>>> >>> >> Also tabs are used in the read/write actlr, ttbcr, dacr, rrbr0<br>
>>>> >>> >> functions and the refresh_tlb function.<br>
>>>> >>> >><br>
>>>> >>> >> +/* i2c stuff */<br>
>>>> >>> >> +typedef struct {<br>
>>>> >>> >> ...<br>
>>>> >>> >> +} beagle_i2c;<br>
>>>> >>> >> Shouldn't this go in beagle/include/i2c.h?<br>
>>>> >>> >><br>
>>>> >>> >> All of this mmu handling code should be refactored. Where<br>
>>>> >>> >> possible, it<br>
>>>> >>> >> should use the existing code in arm-cp15.h<br>
>>>> >>> >><br>
>>>> >>> >> +++ b/c/src/lib/libbsp/arm/beagle/include/i2c.h<br>
>>>> >>> >> This header defines static, non-inline functions. This doesn't<br>
>>>> >>> >> make<br>
>>>> >>> >> sense.<br>
>>>> >>> >><br>
>>>> >>> >> +++ b/c/src/lib/libbsp/arm/beagle/irq.c<br>
>>>> >>> >> +static int irqs_enabled[BSP_INTERRUPT_VECTOR_MAX+1];<br>
>>>> >>> >> This is an array of 512 bytes. You could use a bit vector<br>
>>>> >>> >> comprising 4<br>
>>>> >>> >> unsigned ints for the same purpose.<br>
>>>> >>> >><br>
>>>> >>> >> +volatile static int level = 0;<br>
>>>> >>> >> Unused variable?<br>
>>>> >>> >><br>
>>>> >>> >> +static uint32_t get_mir_reg(int vector, uint32_t *mask)<br>
>>>> >>> >> + if(vector < 0) while(1) ;<br>
>>>> >>> >> Make this a fatal error?<br>
>>>> >>> >><br>
>>>> >>> >> + if(vector < 32) return OMAP3_INTCPS_MIR0;<br>
>>>> >>> >> + if(vector < 32) return OMAP3_INTCPS_MIR0;<br>
>>>> >>> >> duplicate code.<br>
>>>> >>> >><br>
>>>> >>> >> + while(1) ;<br>
>>>> >>> >> Make this a fatal error?<br>
>>>> >>> >><br>
>>>> >>> >> +rtems_status_code bsp_interrupt_facility_initialize(void)<br>
>>>> >>> >> + mmio_write(omap_intr.base + OMAP3_INTCPS_SYSCONFIG,<br>
>>>> >>> >> OMAP3_SYSCONFIG_AUTOIDLE);<br>
>>>> >>> >> Line length > 80.<br>
>>>> >>> >><br>
>>>> >>> >> +++ b/c/src/lib/libbsp/arm/beagle/startup/bspstartmmu.c<br>
>>>> >>> >><br>
>>>> >>> >> +//static uint32_t pagetable[ARM_SECTIONS] __attribute__((aligned<br>
>>>> >>> >> (1024*16)));<br>
>>>> >>> >> commented-out.. delete it?<br>
>>>> >>> >><br>
>>>> >>> >> +BSP_START_TEXT_SECTION void beagle_setup_mmu_and_cache(void)<br>
>>>> >>> >> __attribute__ ((weak));<br>
>>>> >>> >> More than 80 characters.<br>
>>>> >>> >><br>
>>>> >>> >> diff --git a/c/src/lib/libbsp/bfin/acinclude.m4<br>
>>>> >>> >> b/c/src/lib/libbsp/bfin/acinclude.m4<br>
>>>> >>> >> index ab6082e..828fd89 100644<br>
>>>> >>> >> --- a/c/src/lib/libbsp/bfin/acinclude.m4<br>
>>>> >>> >> +++ b/c/src/lib/libbsp/bfin/acinclude.m4<br>
>>>> >>> >> diff --git a/c/src/lib/libbsp/powerpc/acinclude.m4<br>
>>>> >>> >> b/c/src/lib/libbsp/powerpc/acinclude.m4<br>
>>>> >>> >> index 6442399..e46fa2b 100644<br>
>>>> >>> >> --- a/c/src/lib/libbsp/powerpc/acinclude.m4<br>
>>>> >>> >> +++ b/c/src/lib/libbsp/powerpc/acinclude.m4<br>
>>>> >>> >> Don't include these changes. Check your tool versions, and if the<br>
>>>> >>> >> correct version of tools does this, provide a separate patch for<br>
>>>> >>> >> generated files.<br>
>>>> >>> >><br>
>>>> >>> >> -Gedare<br>
>>>> >>> >><br>
>>>> >>> >> On Wed, Jul 23, 2014 at 9:00 PM, Ben Gras<br>
>>>> >>> >> <<a href="mailto:beng@shrike-systems.com">beng@shrike-systems.com</a>><br>
>>>> >>> >> wrote:<br>
>>>> >>> >> > All,<br>
>>>> >>> >> ><br>
>>>> >>> >> > Full details on how to reproduce all the work from source<br>
>>>> >>> >> > repositories<br>
>>>> >>> >> > to<br>
>>>> >>> >> > scripts & utilities to write a complete sd card booting RTEMS<br>
>>>> >>> >> > and<br>
>>>> >>> >> > test<br>
>>>> >>> >> > the<br>
>>>> >>> >> > whole thing:<br>
>>>> >>> >> ><br>
>>>> >>> >> ><br>
>>>> >>> >> ><br>
>>>> >>> >> ><br>
>>>> >>> >> > <a href="http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html" target="_blank">http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html</a><br>
>>>> >>> >> ><br>
>>>> >>> >> > I am submitting the attached patch for review for merging. If<br>
>>>> >>> >> > accepted<br>
>>>> >>> >> > for<br>
>>>> >>> >> > merging, please use the top two commits on<br>
>>>> >>> >> ><br>
>>>> >>> >> > <a href="https://github.com/bengras/rtems/tree/beaglebone-wip" target="_blank">https://github.com/bengras/rtems/tree/beaglebone-wip</a><br>
>>>> >>> >> ><br>
>>>> >>> >> > which have the same net effect but preserve Claas' work because<br>
>>>> >>> >> > of<br>
>>>> >>> >> > the<br>
>>>> >>> >> > earlier commit. The squashed version attached is for more<br>
>>>> >>> >> > convenient<br>
>>>> >>> >> > review.<br>
>>>> >>> >> ><br>
>>>> >>> >> > I was ironing out more wrinkles but given recent interest it<br>
>>>> >>> >> > seems<br>
>>>> >>> >> > smarter<br>
>>>> >>> >> > to merge sooner and keep polishing from mainline. Nevertheless<br>
>>>> >>> >> > I<br>
>>>> >>> >> > have<br>
>>>> >>> >> > put a<br>
>>>> >>> >> > lot of work into getting it into good shape already.<br>
>>>> >>> >> ><br>
>>>> >>> >> > I have rebased everything on the very latest master and<br>
>>>> >>> >> > verified<br>
>>>> >>> >> ><br>
>>>> >>> >> > That building all the tools and utilities from scratch work,<br>
>>>> >>> >> > using<br>
>>>> >>> >> > the<br>
>>>> >>> >> > RTEMS<br>
>>>> >>> >> > Source Builder repository (Ubuntu + FreeBSD).<br>
>>>> >>> >> > That building the beaglebone and bbxm BSPs and linking them<br>
>>>> >>> >> > with all<br>
>>>> >>> >> > the<br>
>>>> >>> >> > testsuite programs works (Ubuntu + FreeBSD).<br>
>>>> >>> >> > That the beaglexm-emulating linaro qemu executes all of those<br>
>>>> >>> >> > tests<br>
>>>> >>> >> > properly, invoked using a single command line with the scripts<br>
>>>> >>> >> > in<br>
>>>> >>> >> > the<br>
>>>> >>> >> > RTEMS<br>
>>>> >>> >> > tools repository, even though not all pass currently (Ubuntu +<br>
>>>> >>> >> > FreeBSD).<br>
>>>> >>> >> > That loading & running over JTAG works, both interactively with<br>
>>>> >>> >> > gdb<br>
>>>> >>> >> > and<br>
>>>> >>> >> > in a<br>
>>>> >>> >> > batch using gdb and the test runner.<br>
>>>> >>> >> > That running RTEMS executables using u-boot on the beaglebones<br>
>>>> >>> >> > from<br>
>>>> >>> >> > sd<br>
>>>> >>> >> > card<br>
>>>> >>> >> > work; both with and without MMU enabled at RTEMS start time.<br>
>>>> >>> >> > That Claas' earlier commit builds.<br>
>>>> >>> >> ><br>
>>>> >>> >> > Thanks so far to Chris and Brandon for help, support,<br>
>>>> >>> >> > instructions<br>
>>>> >>> >> > and<br>
>>>> >>> >> > advice in various forms :)<br>
>>>> >>> >> ><br>
>>>> >>> >> > Test results on qemu:<br>
>>>> >>> >> > Passed: 497 Failed: 3 Timeouts: 1 Invalid: 0<br>
>>>> >>> >> ><br>
>>>> >>> >> > The test results on bbxm over jtag (older):<br>
>>>> >>> >> > Passed: 475 Failed: 7 Timeouts: 10 Invalid: 0<br>
>>>> >>> >> ><br>
>>>> >>> >> > I want to iron out more wrinkles and build support (ethernet)<br>
>>>> >>> >> > but<br>
>>>> >>> >> > giving<br>
>>>> >>> >> > the<br>
>>>> >>> >> > bsp more exposure and having it in mainline so i don't have to<br>
>>>> >>> >> > keep<br>
>>>> >>> >> > rebasing<br>
>>>> >>> >> > & testing would be nice at this point.<br>
>>>> >>> >> ><br>
>>>> >>> >> ><br>
>>>> >>> >> ><br>
>>>> >>> >> ><br>
>>>> >>> >> > _______________________________________________<br>
>>>> >>> >> > devel mailing list<br>
>>>> >>> >> > <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
>>>> >>> >> > <a href="http://lists.rtems.org/mailman/listinfo/devel" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>>>> >>> ><br>
>>>> >>> ><br>
>>>> >><br>
>>>> >><br>
>>>> ><br>
>>><br>
>>><br>
>><br>
>><br>
>> --<br>
>> Joel Sherrill, Ph.D. Director of Research & Development<br>
>> joel.sherrill@OARcorp.com On-Line Applications Research<br>
>> Ask me about RTEMS: a free RTOS Huntsville AL 35805<br>
>> Support Available <a href="tel:%28256%29%20722-9985" value="+12567229985">(256) 722-9985</a><br>
><br>
><br>
</div></div></blockquote></div><br></div>