Zigbee Pro - Arm Cortex M3

[ozpos]

Hi all but particularly Matz,

I have sent the email below to try and make some progress in this market sector. I would be grateful of any support that can be given.

Many thanks for your time.

John Leake

To: Mr. T. Tuttle (President and Chief Executive Officer of Silicon Labs)

Dear Mr. Tuttle,

This is a long shot so please bear with me.

I wrote my first assembler in hex for M6809 cpu and recorded the program on cassette tape using electronics I build from a Byte magazine schematic.

With a degree in Physics and Electronics I have been self employed for 35 years in the embedded systems market place selling my skills to multinational companies. I know how to write a time sliced OS in 2kB of memory.

I have recently come into contact with Zigbee and I am appalled by the primitive interface offered to developers in the form of AT modem commands (supposedly to insulate the developer from software development).

1) Please look at mruby. 2) Software should be open source, you are in the business of designing and licensing/manufacturing chips. 3) If you gave me free access to your tool chain and design documentation for the EM357 I could develop and hand over working mruby firmware that will be truly revolutionary. I would of course sign an NDA if it was required.

What do you think ?

Beast regards,

John Leake Embedded Systems

+44 191 237 2762 55, Collywell Bay Road. Seaton Sluice, Northumberland, NE26 4RG

[matz]

I am looking forward to see follow-up.

[bovi]

Did you got any response? I know some equipment from silabs but I'm far away from being an expert about their stuff. Which platform from them are you trying to target? The ones I know (cortex m3 based radio equipment) is targeting very low power and resources and so they also have very tiny amount of RAM (around 12kb to 30kb). Did you made any experiments with mruby to lower the memory footprint so far? If yes I'm EXTREMELY interested in your results!

Regards Daniel

[ozpos]

Hi Daniel,

No response yet.

I am currently using the EM357 (192kB FLASH, 12kB RAM).

My ultimate goal is to apply pressure to the whole Zigbee marketplace that seems to think modem AT commands make developers lives easy.
Perhaps this is because the designers are either Physicists, Mathematicians or RF engineers and generally not software engineers.

I have not experimented yet with mruby but I am confident that it can be pared back to a very small foot print, the size of which will be dictated by the feature set required by the target application. Many Zigbee embedded control systems simply respond to interrupts, manipulate A/D values with simple +-/* math and set local or remote outputs.

Thank you for your interest.

Best regards,

John Leake

On 22/05/13 11:56, Daniel Bovensiepen wrote:

Did you got any response? I know some equipment from silabs but I'm far away from being an expert about their stuff. Which platform from them are you trying to target? The ones I know (cortex m3 based radio equipment) is targeting very low power and resources and so they also have very tiny amount of RAM (around 12kb to 30kb). Did you made any experiments with mruby to lower the memory footprint so far? If yes I'm EXTREMELY interested in your results!

Regards Daniel

— Reply to this email directly or view it on GitHub https://github.com/mruby/mruby/issues/1262#issuecomment-18271144.

[bovi]

Hi John, I agree with you about the old school style of most embedded radio solutions (GSM modules is another one). About the RAM issue. I managed by myself to go below 96kb but not stable with really useful real world code. There is a project targeting NXT (http://www.csk.com/fukuoka/services/mruby/nxt01.html) which targets less than 64kb (with less than 40kb efficient available space) by doing dramatic changes to mruby but I don't have any detailed information about their changes. Nevertheless they described at least the results on their website in detail. Maybe that would be a starting point for your research.

[ozpos]

Hi Daniel, Thank you I will investigate. On 22/05/13 12:41, Daniel Bovensiepen wrote:

Hi John, I agree with you about the old school style of most embedded radio solutions (GSM modules is another one). About the RAM issue. I managed by myself to go below 96kb but not stable with really useful real world code. There is a project targeting NXT (http://www.csk.com/fukuoka/services/mruby/nxt01.html) which targets less than 64kb by doing dramatic changes to mruby but I don't have any detailed information about their changes. Nevertheless they described at least the results on their website in detail. Maybe that would be a starting point for your research.

— Reply to this email directly or view it on GitHub https://github.com/mruby/mruby/issues/1262#issuecomment-18272813.

[ozpos]

Hi All, There was no reply so I decided to embark on my own. I have purchased an Ember dev kit and 10 additional modules. The AT command set is dreadfully inflexible and cumbersome.

Silicon Labs have agreed to give me free access to the Ember Insight development tool chain but they will not give me an IAS3 jtag debug interface.

I have asked them if the Keil Ulink2 is compatable (I can get a clone for £28) but have not had a response yet.

Anyway, the reason for my email is to ask you if it is possible to compile an mruby script such that the resulting object file is stripped of all the unused parts of the language/libraries ?

Also is it possible to compile the target VM such that it too does not contain any unused code ?

Best regards,

Ozpos

[bovi]

Anyway, the reason for my email is to ask you if it is possible to compile an mruby script such that the resulting object file is stripped of all the unused parts of the language/libraries ?

We have a tool called mrbc which is available under the tools folder. This tool compiles Ruby code to bytecode which can be used inside of a C file. You still need to have the mruby lib.

Also is it possible to compile the target VM such that it too does not contain any unused code ?

You can start by removing all GEMs you don't need. You do that by modifying the build_config.rb file which should indicates the GEMs or GEMBoxes (collection of GEMs). Afterwards you could proceed and start to remove parts of the core. This is all handwork, there is no automatically way to drop all unused features.

[ozpos]

Hi All, So I forked mRuby and did a build with RubyMine. It all compiled without a hitch (I think).

Just to get my bearings, vm.o shows up as 117kB, would that be about right ?

If so then what size footprint would a Hello World app be ?

Best regards, Ozpos

[matz]

On my machine (Ubuntu 32bit), vm.o is 71K with debug info, and 39K stripped.

[ozpos]

Likewise Lubuntu 12.04 32-bit i686 Little Endian. I just ran build all straight off a clean fork. I wonder why it is so big ?

On 07/11/13 21:30, matz wrote:

On my machine (Ubuntu 32bit), vm.o is 71K with debug info, and 39K stripped.

— Reply to this email directly or view it on GitHub https://github.com/mruby/mruby/issues/1262#issuecomment-28008308.