[Scilab-Dev] code generation for microcontroller target

[Matías Silva Bustos]

Hello!

I've made a repository in github: https://github.com/masilvabustos/xcos2uc

Regards.
Matías Silva Bustos.



2014-08-11 16:13 GMT-03:00 Matías Silva Bustos <masilvabustos at ieee.org>:

>
> Greetings,
>
> (answered inline)
>
> 2014-08-11 14:02 GMT-03:00 Markus Valtin <valtin at control.tu-berlin.de>:
>
> Am Mittwoch, 25. Juni 2014, 22:29:25 schrieb Matías Silva Bustos:
>> > Hello,
>> Hello,
>>
>> > I am about to begin the developement of a coder that takes a xcos
>> diagram
>> > and generates C code  suitable to be ran on a ARM Cortex M3 uC, a
>> STM32FXXX
>> > in particular.
>>
> That sounds interesting. I could recommend using the STM32F4XXX chips
>> because
>>  of the floating point unit. http://blog.stm32f4.eu/category/fpu/
>>
>
> In fact, a previous work related to this developement makes use of this
> series.
> IMHO the F3 series has better hardware for control applications.
> http://www.st.com/web/en/catalog/mmc/SC1169/SS1576
>
>
>> > Here my questions:
>> >
>> > a) Is the code generated by the xcos CodeGenerator suitable for this
>> > purpose without much code rewritting?
>> Imho it is not. You might find http://hart.sf.net interesting. This
>> toolbox
>> compiles a Scicos Diagram into a RTAI or Preempt Binary. It uses a
>> customized
>> do_compile_superblock.sci function which looks not really straight
>> forward.
>> To resulting code is also not easy to grasp but it works :-) and it might
>> give
>> you an idea.
>>
>
> Thanks for the link! :) The next step of the project Im working on is to
> develope (or copy if already done) a tool for hardware-in-the-loop
> simulation.  Oh, oh, I get the idea. Interesting.
>
>
>> > a_1) i.e. has the generated code too many library dependencies? I tryed
>> to
>> > compile the XXX_standalone.c  but it seems to require many scilab
>> > libraries, Am I right?.
>> Yeah but this is just for the recompiled Scilab blocks.
>> The real questing would be, what standard functions arm supports in there
>> cross-compiler tool chain. (I assume you want to use a free tool chain? I
>> also
>> not sure if you can use IAR or Keil from within scripts/makefiles.)
>>
>
>
> The question pointed to know how much work would be needed if I had to
> write the functions the generated code depends on.
> I know that there are some small libraries that implements more or less
> the POSIX interface.
> I'm using the gcc toolchain
> + the ST firmware for de Discovery kit (
> http://www.st.com/web/en/catalog/tools/PF257914) (I own a Value Line kit
> (STM32F100))
> + texane stlink (https://github.com/texane/stlink).
>
> I own a Value Line kit (STM32F100)
>
> I think it will be enough for now. Maybe the kit I own won't work real
> time, but I would be happy if it only worked.
>
>
>
>>
>> > b) Should I begin from scratch? I think I can reuse the xcos parser and
>> > some other code involving the diagram description.
>> > b_1) But from there, Is there other classes or functions I can use?
>>
>> You also need to consider the I/O side on the micro controller. How do you
>> receive or send data? This could be implemented as Scicos Block but this
>> requires knowledge about the micro controller used and the setup (like
>> clock
>> speed...).
>>
>
> For developing I will use the UART interface.
> Eventually the micro will read (write) the data from (to) the A/D (D/A) .
> An external hardware will interface between the micro and
> the PC (this will be the hard part, I think) for the hardware-in-the-loop
> simulation.
> The I/O is trivial. Analize a xcos diagram and automatically check
> implementability seems more complicated ;)
>
>
>> > c) Scilab is the preferred programming language? I have seen many
>> languages
>> > such as C, C++, Java, Modelica (i'm not sure what this is), FORTRAN.
>>
>> Depends on what you do. Each block has two functions, an interfacing
>> function
>> (Scilab) and a computational function (Scilab, C, C++, Fortran).
>>
>> The interfacing function is used by Xcos for the GUI,  some I/O size
>> things
>> and the parameter. This function is not important for you.
>>
>> The computational function on the other hand does all the real work during
>> simulation and this function must be ported to the micro controller.
>> I think you need all computational functions to be C/C++ functions
>> because I
>> don't think there is a Fortran compiler for ARM and there is definitely no
>> Scilab interpreter available.
>>
>
> Not all functions should be ported in my current project, just that ones
> which are involved in digital control and/or DSP.
>
>
>> Is there an open source repository?
>>
>
> It will be soon.
>
>
> Regards,
> Matías Silva Bustos.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20140825/3354f83f/attachment.htm>