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 <masilvabus...@ieee.org>: > > 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