W-ARM IDE

Hello everybody. :smiley:

I am an electronics and software enthusiast.

I have created a freeware open source distribution to develop and program ARM controllers of the SAM7 series of Atmel.

It is called W-ARM.

It consists of an ide project manager(W-ARM), an editor (Programmers notepad 2) GCC distribution 4.4.2 and utils for the arm from yagharto gcc distribution 20091223. And SAMBA 2.10.

I am planning support for the SAM3S series as well and for cortex M3 controllers of other manufacturers.

At the moment the program is still beta but it works. I have on sourceforge a readme with the limitations.

I wrote the program for my own use but i thought more people would like to use it. For home and hobby stuff it is ideal.

If you want to use W-ARM for professional use i advice not too because it is still beta and i do not provide support as the commercial IDe providers. Because i use it myself i am always improving it and every improvement i will document and present. When the IDE V1.0 is finished and stable, i will also put the sources for the project manager on sourceforge. What W-ARM does is setup the right options for you and it generates the makefile and linkerfile for you.

From within the PN2 editor you are able to access everything. W-ARM is still beta but in the near future W-ARM will also feature an bootloader and then you can program it with the W-ARM IDE. For now this does not work and is only visual.

I have more information on this link with pictures.

http://forums.anandtech.com/showthread.php?t=2084007

I have the W-ARM ide on sourceforge.

http://sourceforge.net/projects/warmdevkit/files/

I have also some schematics and books but i am still improving these because i am still learning as well.

I will put more and more schematics on sourceforge as well with code examples.

W-ARM is at the moment V0.90 and still beta. But i will update it soon (end of october)to Version 0.91.

##################################################################

Change log :

version 0.91

  • Added more instructions and directives to the assembler scheme and to the c scheme of PN2.

  • Removed a bug from the SAM7S linker generator where the .text sections in the fastcode section where duplicated into the

general .text section. Creating a bigger memory footprint then is necessary.

  • Added linker code to the linkergenerator to support interrupt handlers executed from ram.

  • Rewritten the low_level_init.c source file. Rewritten the startup.s file. Added the isr_asm.s file.

This means that there is an incompatibility with older code. Use your own sources with the new templates. And after

compilation it should work again. You do this by creating a new project, copy template files and then add your own source files

and header files to the src and the inc directories respectively. After that, invoke W-ARM program manager, add the correct settings

and create configuration files. After that you can compile again and all should work.

  • Uses the C99 convention for type defines. To create more readable code. Types as uint32_t must be used now instead of word or dword.

This because a word on the ARM architecture is natively 32 bit while on other architectures this can be 16 bit. Because

many users use different architectures, this creates confusion and i do not like to spread confusion.

  • Support for interrupts is here. 9 simultaneous interrupts are supported by default but can be expanded up to 32.

The pheripheral Interrupts run from ram as does the fetal os interrupts( No OS yet, but the ground work is here).

  • Added default values to stacksizes.

  • Removed usesless thumb option from instruction set options menu.

  • My PrintString version in semi_stdio.c now supports the ascii codes : \r, \t, \n, \ .

  • Templates files updated : semi_stdio = V2.0 , low_level_init.c = V2.0 , startup.s = V2.0 .

More information i have on the sourceforge site.

Thanks for the work!

Eager to see if this goes to NXP ARM7 and Cortex, maybe Energy Micro and STM.

Though I have long used Atmel AVRs, NXP has been the key for my work for ARM.

Which ones of the NXP LPC controllers would you like supported ?

I cannot support all of them but the most popular should be possible.

I have no experience with the LPC controller but if there are some sort of template files (basic startup, main, interrupts and lowlevelinit to get started with) existing i can include those as well.

Template files are not really necessary, but it would be fun if a new project is started and there are default header and sources files present to get started fast.

I have no problem including the nxp. I think i have to modify the linker generator and the makefile generator for the LPC a bit too but if i have information about the memory mapping of the nxp and the limitations it should be not that difficult. Might take me a few weeks worst case though to implement everything. But if the NXP is really that similar, then i probably do not have to modify the makefile generator and only the linker file generator for the specific memory addresses.

Once i have finished the bootloader to use with the programming feature( I have cooked up an extensive list of features that will come in handy while still being small) i think a version can be adapted fast to work on the nxp as well.

If not to much, it should be easily implemented.

Copying the sam7s settings for NXP is very easy since i wrote the W-ARM program manager in a modular way.

Extending it is to an extent easy to do. Adding nxp controllers when provided with enough information, i can do for you yes. :smiley:

forward looking, itā€™s the LPC17xx I suppose.

To date, most of my work has been with the LPC2106, some 2103 and 2129 (no use of CAN bus)

Can you provide me with specs of those controllers to help me out ?

Adding the NXP processors to the menu is trivial and is easily done.

The makefile generator i do not need to rewrite.

I have to make some adjustments to the linkerfile generator. But in order to do that, i require the following :

For each processor :

ROM start, ROM size.

RAM start, RAM size.

I believe there is a limitation how much ram is remapped yes ?

Because of the width data bus to flash or something ?

Because i have to modify the linkerfile in such a way that all interrupt service routines end up in the proper ram.

If there is no need for interrupt code to be relocated to ram at boot time, i will be done quicklyā€¦

Because i think template files is a handy feature, i need some basic startup files. Enough to be able to compile without errors and to make some ledā€™s flash for exampleā€¦ Something basic to start from. I have done the same for the SAM7S series. Although i am planning to put a template file for the SAM7S with support for interrupts and hardware. Basic stuff like I2C, UART,SPI. All well documented to modify to ones needs. :smiley:

I would have to add some instructions in the manual how to add the NXP version of samba to the PN2 editor.

Then both SAM7S and LCP2 series will be supported fully. :smiley:

I assume the LPC7 series are cortex M3 models ?

That will take some time because i do not have a sam3s4b yet.

The NXP website has specs on the LPC21xx.

With ARM7 or Cortex, the issue isnā€™t the core, itā€™s having an IDE that has all the .h for the various on-chip I/O peripherals. This, of course, varies widely by vendor. I think NXP has the largest market share, then STM, and Atmel is probably down the list.

Well, i have the header files as well in the template directories. When a new project is started, the W-ARM program manager can copy the template files if you wish to do so. It also copies header files.

Atmel has extensive header files. You can directly program everything when using the header file of the SAM7S. I know this from experience.

With NXP, i know that NXP does a very good job at describing their products. As such i am sure there will be a header file for the LPC series as well.

When i have some time, i will study the datasheets of the LPC. Cannot be that hard.

I was hoping the LPC memory organization would be common knowledge on the ARM section of the forum.

The SAM7S is as it seems widely used as well. I have not seen stm arm7tdmiā€™s thoughā€¦

But to be honest, iwhen i bought the chip, i selected it because of itā€™s large RAM memory and dma controller.

I wanted to build experience with dma controllers.

There are extensive software examples for the NXP parts at their website.

http://ics.nxp.com/support/documents/mi ā€¦ e=software

Most are oriented towards Keil tools, but you can get an evaluation copy of those.

Translating to gcc tools is not too big of a deal, but just for all parts would be time consuming.

I understand. I think i can take the examples of WINARM. That is a collection of tools also for a windows based gcc compiler / ide for the arm. I will look into it. Basically supporting all processors would not be that easy indeed, a lot of time for processors i myself might not ever use. I would have to make a selection for the most popular once. But if people want to help out with gcc compatible headerfiles, it would be a lot easier for me.

Just to give you some background, for either you or others.

There is already Eclipse out there that integrates all the tools. My opinion is that while it does everything you need, its also pretty complex.

Yagarto seems to be the most actively supported GCC version.

Coridium developed a Tcl based IDE for ourselves and our products. We would have some interest in placing that in the public domain.

William_Gaatjes:
I understand. I think i can take the examples of WINARM. That is a collection of tools also for a windows based gcc compiler / ide for the arm. I will look into it. Basically supporting all processors would not be that easy indeed, a lot of time for processors i myself might not ever use. I would have to make a selection for the most popular once. But if people want to help out with gcc compatible headerfiles, it would be a lot easier for me.

Yep. It makes sense to pick the top 2 or 3. With all due respect to Atmel, in the world of ARM, perhaps Atmel doesn't have a commanding market share as compared to NXP and STM. I may be wrong.

viskr:
Just to give you some background, for either you or others.

There is already Eclipse out there that integrates all the tools. My opinion is that while it does everything you need, its also pretty complex.

Yagarto seems to be the most actively supported GCC version.

Coridium developed a Tcl based IDE for ourselves and our products. We would have some interest in placing that in the public domain.

I have tried eclipse. But i found it a little to much and to large for a basic editor. I tried it but i did not like it. I liked WINARM more but winarm had no program manager that presents you with an gui tool to select processors, gcc options, stack sizes, configuration backups. It has a program that generates makefile files but it just misses those key features to make it more intuitive. That is when i decided to create an program manager. Your products are interesting. Do not worry, i have no intention in taking your market. I will not provide any support other then explanation about the how to use the IDE and the c functions i provide which are enough for me but may be limiting for others. I use visual c++ 2008 express for writing the program manager.

stevech:

William_Gaatjes:
I understand. I think i can take the examples of WINARM. That is a collection of tools also for a windows based gcc compiler / ide for the arm. I will look into it. Basically supporting all processors would not be that easy indeed, a lot of time for processors i myself might not ever use. I would have to make a selection for the most popular once. But if people want to help out with gcc compatible headerfiles, it would be a lot easier for me.

Yep. It makes sense to pick the top 2 or 3. With all due respect to Atmel, in the world of ARM, perhaps Atmel doesn't have a commanding market share as compared to NXP and STM. I may be wrong.

I am sure you are right. I may be wrong but i think Atmel biggest customer was nokia. NXP is huge and everything they develop, they develop for their own future products but can afcourse also be used by others. Open up any LG product, and you will find NXP products in it. May even have a lg stamp on it. But is developed by NXP. STM was originally SGS Thomson electronics. A French, Italian company. I think their market is similar as the NXP market.

William_Gaatjes wrote:

Do not worry, i have no intention in taking your market

As our IDE is free to download, its not market that Iā€™m worrying about. But also there is not a lot of incentive for us to support CPUs that we donā€™t use in the manufacture of our PCBs. But if we did open it up, it provides us with a potentially better product too.

MakeItC is a relatively simple equivalent of automake, that will build hex files and allow you to use whatever text editor you want. Due to the later, its not as well integrated as some tools. But as tools go, we use it all the time, so it pretty much does the things we need it to do.

Things weā€™d like to see added, would include C++ support, though we would probably not use it. Integration of a JTAG tool, though the wiggler class is probably too flakey to support. Cross platform support is also of interest.

Iā€™m just thinking that re-inventing the wheel is not always useful. Our motivation with MakeItC, was that Eclipse was overkill, and frankly it was a way for us to learn about a cross platform language like Tcl.

I tried Eclipse a year ago. Maybe itā€™s better now. But then, it was, IMO, a perfect thing for the person who is more interested in trying to get the IDE/tools to work than the objective.

stevech:
I tried Eclipse a year ago. Maybe itā€™s better now. But then, it was, IMO, a perfect thing for the person who is more interested in trying to get the IDE/tools to work than the objective.

I had that same feeling about eclipse. To bloated for what i wanted and still want and it took me a while to get it to work and after that i just did not like it. I prefer ā€œlean and meanā€ instead of a ā€œ1 solution for everythingā€ product.

viskr:
Things weā€™d like to see added, would include C++ support, though we would probably not use it. Integration of a JTAG tool, though the wiggler class is probably too flakey to support. Cross platform support is also of interest.

Iā€™m just thinking that re-inventing the wheel is not always useful. Our motivation with MakeItC, was that Eclipse was overkill, and frankly it was a way for us to learn about a cross platform language like Tcl.

Well, i wrote the program for myself but i thought it would be useful to others too. At the time i also want to build more experience with windows programming, as such for me this was the perfect opportunity to do so. I also wanted to dig deep in what the c compiler actually does because i am always interested in the assembler language of different architectures. When i have a thorough understanding of the inner workings of c language and compiler i can extract maximum performance of the given architecture which for me is the ARM. That is why and how behind the program manager. That and when i filled my head with algorithms, i do not want to think about trivial things as configuration setups. :smiley:

For me, i had experience with the c language already, just not enough. That was the primary reason for me.

C++ i never found interesting for embedded controllers.

A JTAG tool is in my wish list. But at the moment i first want to do the basis properly.

stevech:
forward looking, itā€™s the LPC17xx I suppose.

To date, most of my work has been with the LPC2106, some 2103 and 2129 (no use of CAN bus)

Hello Steve,

I have added the following MCUā€™s from NXP : LPC2104, LPC2105, LPC2106.

I am at the moment busy modifying the linkerscript generator code to support the LPC 2104,2105 and 2106.

I will not be able to test it fully, i will have a look if olimex has some example code with flashing leds available to test it on. Then i can also use the startup.s and lowlevel init code from that example file as template files.

I hope to have it ready by the end of october. I have not had much time to continue my own ARM programming last few weeks. I did build an example accelerometer test pcb with an ADXL325. I now also have all the parts for my own NOKIA 6610 LCD pcb. I hope to start building my lcd project this weekend.

I now have the time and spirit again to continue where i left of. :slight_smile:

When i have the program ready , i will rename it to v0.91b and put it on sourceforge to test if you likeā€¦

should I try it with a 2106 or 2129?

Did I miss seeing, or does it have options for the PLL constants?

Hello,

I have not posted it yet because i am still working on it. I do not have at the moment any template files where the core and the clock generator is setup.

A program to generate pll values i do not posses. I myself go for the highest available clock input for the SAM7S and scale it down when i have to because of power saving features. Which at the moment is not yet the case.

I will limit the selection to LPC2104, 2105 and 2106. But that is just trivial.

It just generates for now a makefile and partial linkerfile. I am still working on the linkerfile because i want to program it in a modular way and do not want to break my existing code.

I will put it on as soon as possible but the date will probably be around 31 oktober but if i finish my desired feature set earlier, i will post it earlier with afcourse a notification.

If i remember correctly, a flash download program from nxp can be used to program these processors yes ?

Then maybe i should modify the editor to support this program as well.

EDIT : forgot to mention, that i need to look into how to support fastcode from ram for the LPC210x series.

the LPC21xx and others have an a serial port bootloader installed by NXP. Nice.

I think they do the same for the new Cortex chips too. Freeware called FlashMagic is used with the bootloader.

I use this for field updates and use JTAG (J-Link) for development.

A GUI and aid for setting up the PLL would be really helpful. That was and is a really hard to understand part. I go for max speed and rely on sleep cycles for power conservation.