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