We've just put a beta version of the website and compiler live; if you want to test it, just click on my profile and send me a message and i'll tell you how you can enable it.

FYI: major visible updates are:

• Improved compiler import
• Build details (i.e. RAM/FLASH usage)
• Publishing supports updating existing published programs

Thanks!
Simon

[Removed as I didn't read things correctly]

I'm very happy with this compiler. Works _so_ _MUCH_ better with Safari on a Mac. Being able to copy and paste is a real bonus!

thank you.

Morning beta testers!

There's quite a few of you now, so hopefully most new features have been tested out.

What are people's experiences?

Have many of you tried the new import wizard?

Does the versioned published program mechanism make sense?

Has your pet bug been squashed? If it has, great, if not, report it here!

Thanks,

Dan

Overall... a GREAT experience...

Copy/Paste in Safari seems to need to COPY twice, otherwise my paste is the previous copy... (I'm on a mac, 10.6.3).

Not really close to a published program as such yet, so haven't seen the versioning.

The new compiler works fine, the memory usage overview is great!

A few issues: 1. Cut doesn't work. 2. If I scroll up after an large undo part of the code will disappear (that happend also in the "old" version).

I'm on WinXP SP2 IE6.

Hi Dan

I was most interested in the memory usage. I would like to question why percentages for the RAM usage are given out of 32 KB when the 1768 has a total of 64 KB? Also, is there particular value in knowing the usage of flash split between code and libraries? I might need a lesson here in the M3, but the code doesn't run from flash does it?

Thanks
Daniel

Daniel Peter wrote:

I was most interested in the memory usage. I would like to question why percentages for the RAM usage are given out of 32 KB when the 1768 has a total of 64 KB? Also, is there particular value in knowing the usage of flash split between code and libraries? I might need a lesson here in the M3, but the code doesn't run from flash does it?

2. Yes, M3 does run code in flash. AFAIK making flash execution speed fast enough was one of the main goals of the Cortex-M designers.

Hi Simon and Dan (and Igor thanks for the explanation)

I've had a look at the lwip code which I know is an example of something that uses AHBSRAM1. It effectively provides a heap in that RAM area by defining a static array of u8_t which is then accessed by malloc like functions (refer lwipopts.h and mem.c). Because the array is defined statically, it should be possible for the compiler to know how much memory space is being reserved in that area for data. Hence my previous question about why the beta compiler was only reporting memory usage out of 32 KB. Is it not more desirable to have the compiler report on all the RAM usage whether main or AHB banks? Even if the main and AHB banks are displayed separately, it should still sum to 64 KB?

I'm also curious about the use of the flash memory which I believe is 512 KB. Is it possible to designate what code will be placed in there by the compiler? I've had a look at a few of my projects in the beta compiler and the flash is showing some usage but not quite sure why/how code and libraries are split between flash and RAM?

Thanks

Daniel

Hi Daniel,

All code always goes in FLASH; we just split out "libraries" to give you a high-level idea of where the code space was going. e.g. what is C or mbed libraries vs your own code.

As to the RAM display, it is intended to only show space allocated in the main RAM, as this is where general data lives including the stack and the heap; there is a bug in there at the moment which means it also includes any data allocated in these other special blocks you mention, but we'll fix that. The aim is to give you an indication of the main memory usage. I agree we could make it more comprehensive, but hopefully this is a start!

Simon

Hi Simon

I can understand why you might only want to include main RAM in the usage view, but can i suggest you label it as such so there is no confusion eg. by saying "Main RAM" rather than just "RAM" under the right hand bar graph. That way later you can add a couple more bars for AHBSRAM0 and AHBSRAM1 if required.

What also confuses me is the figures in the Component Sizes. Am I right in understanding that code goes into flash and data goes into RAM? If so, the grid view is a bit confusing because it implies code is going into both flash and RAM since all the figures are on one row of the grid labelled "Code". Do the figures represent the size of the code in flash, and the size of the data associated with that code in RAM?

Thanks
Daniel

Hi beta testers,

I have just put live the new versions of both the compiler and the general website. Full blog post with changelist to follow later today.

When the next version is ready for betatesting, I'll let you all know. For now though, you should turn off beta mode. Enabling it will now have no effect, in any case.

I'd like also to get any feedback on the actual beta testing process. Right now it's a bit 'manual' and I hope to make it more automated in the future. Also, the 'beta mode' switch could/should be a flag you set in your preferences which enables beta mode every time you log in.

Thanks for your help!

Dan