IIija, I would love to just use Eclipse, and have the Config tool generate a compatible tree. Then use a standard debugger interface, like the PEMicro tools. The experience using Code Warrior with MQX is overall good. The thing I don't like about MQX is having to configure things with #define in include files. I really like that eCos takes the configuration out of the code tree. This makes it much easier to have multiple configurations, especially when using source code control.
I suppose I could just take the configuration results and use Code Warrior, but I loose some generality if my end users want to compile and debug on other targets. Do you have any suggestions on a generic compile and debugging tool chain that includes a JTAG debugger and has a low entry price? I would guess that eCos could be integrated into Eclipse, but the issue would be supporting debug on all the different targets. Mike On Dec 2, 2012, at 9:52 AM, Ilija Kocho <ili...@siva.com.mk> wrote: > Jones, > > On 02.12.2012 16:44, Michael Jones wrote: >> IIija, >> >> In my case, I already have an application in MQX, and it fits in a K60N512 >> with room to spare. There is a lot of value in applications that have >> minimum component count, and minimum cost. My goal is to port the >> application to eCos so that I de-constrain the target choice. > > FAOD, my comment is about debugging with RedBoot not eCos. For > standalone eCos application 128KiB RAM is plenty (dependent of > application of course). RedBoot provides some debugging facility but it > will occupy some memory for it's own use so less memory for application. > Therefore, provided that you have some kind of JTAG debugger you do not > need RedBoot, unless you need dynamic firmware loading. In that case > something like FLASH startup (mentioned in my previous mail) may be a > solution. > >> The eCos architecture is similar enough to MQX to make the port practical. >> For this application to work, I will have to add support for I2C, > > Actually there is already I2C driver for eCos, almost ready for check > in. http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001397 > I would ask Tomas, if he receives this mail, to tell us about the status > of the driver. > >> create a disk from part of the FLASH (MQX can do this through the BSP and >> Posix calls), use an SD card, use serial, and ethernet. > SD card works over SPI but there are 2 issues: > > 1. If you are using revision1 silicon you need to swap MISO and MOSI. > (Revision2 as well as K70 have additional PIN multiplexing that fixes this. > 2. There is a small bug in SPI driver that I discovered recently that > didn't show on our custom hardware but. I am preparing a fix. > >> The real constraints on the application are fast handling of interrupts and >> accurate timers triggering small amounts of time sensitive IO tasks. Memory >> is not such an issue. >> >> Once I get a hello world working that does not depend on external memory, >> I'll post a bug and my results, etc. >> >> Mike >> >> >> On Dec 2, 2012, at 3:12 AM, Ilija Kocho <ili...@siva.com.mk> wrote: >> >>> Hi Mike >>> >>> On 01.12.2012 22:07, Michael Jones wrote: >>>> BACKGROUND >>>> ---------------------- >>>> >>>> I am having a little bit of trouble trying to get my first hello world app >>>> on a K60 Tower Board. >>>> >>>> I have RedBoot running from ROM and I can ping the ethernet port, so >>>> presumably I will eventually get GDB to talk to it. >>>> >>>> I am having trouble building an initial app that uses the ROM monitor. >>>> Following the example in the eCos book, I went hunting for >>>> CYGSEM_HAL_USE_ROM_MONITOR, enabled it and then set startup to SRAM. This >>>> seems the obvious way to run and debug. >>>> >>>> PROBLEM >>>> -------------- >>>> >>>> I am getting a conflict I don't know how to resolve. I have set >>>> CYG_HAL_STARTUP_VAR = SRAM. This results in CYG_HAL_STARTUP = SRAM by >>>> calculation. >>>> >>>> But I get a conflict from CYGSEM_HAL_USE_ROM_MONITOR that wants >>>> CYG_HAL_STARTUP == RAM >>> SRAM and RAM startups are not the same. RAM startup is intended for >>> using under control of RedBoot and has some special properties: RAM, >>> unlike other startup types uses RedBoot's vectors, etc... >>> >>> SRAM startup is kind of "stand-alone" in a way it does not depend on >>> RedBoot (but depends on JTAG debugger) >>> >>>> QUESTIONS >>>> ----------------- >>>> >>>> 1) Can I ignore this conflict and get the monitor and app to work? >>> I'm afraid not because, SRAM startup collides with RedBoot. >>>> 2) Is there a better approach? >>> The right approach is to create RAM startup. It could live on variant >>> level and be available to all Kinetis platforms (though some may have >>> too little memory to utilize it). >>> The attached patches should produce proper variant-level RAM startup. >>> >>> I did not add it from beginning since I consider internal SRAM too >>> little for practical work, seems that other people have different view. >>> You are not the first to look for. >>> This being said, I am considering to add this startup to the main >>> repository. Would you open a Bug on Bugzilla? >>> >>>> 3) Has anyone succeeded to use RedBoot on the K60 and can you supply an >>>> example config project that works that I can look at? >>> You may want to try this: >>> http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001623 but beware, it >>> is experimental, and at present it may be broken as it's not synced with >>> recent Kinetis patches. >>> Take care not to lock your Kinetis flash - You have been warned :) >>> >>> I hope this helps and I would appreciate feedback. >>> >>> Regards >>> Ilija >>> <kinetis_var_ram-startup_cdl_121202.diff><kinetis_var_ram-startup_mlt_121202.diff>-- >>> >>> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos >>> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss >> > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
