[Scilab-Dev] code generation for microcontroller target

[Matías Silva Bustos]

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/20140811/85299674/attachment.htm>