Greetings, (answered inline)
2014-08-11 14:02 GMT-03:00 Markus Valtin <val...@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.
_______________________________________________ dev mailing list dev@lists.scilab.org http://lists.scilab.org/mailman/listinfo/dev