From masilvabustos at ieee.org Mon Aug 11 17:56:49 2014 From: masilvabustos at ieee.org (=?UTF-8?Q?Mat=C3=ADas_Silva_Bustos?=) Date: Mon, 11 Aug 2014 12:56:49 -0300 Subject: [Scilab-Dev] code generation for microcontroller target In-Reply-To: <1403785952.2024.33.camel@paros> References: <1403785952.2024.33.camel@paros> Message-ID: Hello!. Sorry about the delay in answering. it was "final exam season" and winter break in between. I've just recently been updated about the project's final purpouse. It must generate code for real time execution on the microcontroller. In fact, the diagram to be "compiled" represents a discrete time control system. This is, not all functions must be implemented, they are limited to discrete time, quantization, sample/hold and some more. Other blocks, for example the integral block, are excluded from the code generation. This simplifies a lot. Answered inline. 2014-06-26 9:32 GMT-03:00 Cl?ment David < clement.david at scilab-enterprises.com>: [snip] > > 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. > > Great ! Do you plan to generate an application using a POSIX-like OS ? > if not, what's the minimal set of feature of your platform (eg. > bare-metal, contiki / Osek like, RTEMS, Embedded Linux, Full Linux) ? > It'll be bare-metal for now. Since it is a single process, I don't think a full OS will be necessary. (An ad-hoc OS?) At most a hardware abstraction layer. [snip] > > b) Should I begin from scratch? I think I can reuse the xcos parser > > and some other code involving the diagram description. > > In my view, to generate code that perform the same way as the simulator > you have to re-use the cpr structure (help scicos_cpr). The better way > to kick things off is to start from the current generator and start > refactor it (it's a nightmare) / implement some code generator templates > per simulation function. > Using well design code generator templates will allow you to both reduce > the actual generated code size and runtime requirements. > The limitation in the set of blocks that will actually be implemented makes this problem very "templatizable". I will soon push the code into a github repository. Regards. Mat?as Silva Bustos. -------------- next part -------------- An HTML attachment was scrubbed... URL: From valtin at control.tu-berlin.de Mon Aug 11 19:02:31 2014 From: valtin at control.tu-berlin.de (Markus Valtin) Date: Mon, 11 Aug 2014 19:02:31 +0200 Subject: [Scilab-Dev] code generation for microcontroller target In-Reply-To: References: Message-ID: <48547181.VUgbqSaSWu@valtin-rt-l1> 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/ > 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. > 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.) > 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...). > 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. Maybe you should create your own Scicos block to get more familiar with it. > d) What is the format of the zcos files? Which issues has the xcos (XML)? :( Size. zcos is a compressed format. > I'm electronic engineer student from Argentina. I was asked to do this > project by a professor and I accepted the challenge. > > Many thanks for considering my request. > Sincerely, > Mat?as Silva Bustos. Is there an open source repository? Sincerely M. Valtin -- Markus Valtin Technische Universit?t Berlin, FG Regelungssysteme (Control Systems Group) Room: EN 229 - Phone: +49-30-314-24893 - Fax: +49-30-314-21137 Post: TU Berlin - Sek. EN 11 - Einsteinufer 17 - D-10587 Berlin, Germany -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From masilvabustos at ieee.org Mon Aug 11 21:13:54 2014 From: masilvabustos at ieee.org (=?UTF-8?Q?Mat=C3=ADas_Silva_Bustos?=) Date: Mon, 11 Aug 2014 16:13:54 -0300 Subject: [Scilab-Dev] code generation for microcontroller target In-Reply-To: <48547181.VUgbqSaSWu@valtin-rt-l1> References: <48547181.VUgbqSaSWu@valtin-rt-l1> Message-ID: Greetings, (answered inline) 2014-08-11 14:02 GMT-03:00 Markus Valtin : > 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: From ierturk at ieee.org Wed Aug 20 04:07:03 2014 From: ierturk at ieee.org (ierturk) Date: Tue, 19 Aug 2014 19:07:03 -0700 (PDT) Subject: [Scilab-Dev] Enjoy Scilab and Python - Binding Scilab and Python - SciPyLab Message-ID: <1408500423111-4031070.post@n3.nabble.com> Scilab is a powerful computing platform for engineers and academicians. Python has many scientific tools. While I look for a tools for binding Python and Scilab for a project, I found one on ScilabForge. Sciscipy: A Scilab API for Python Unfortunately, it doesn't work with recent version of Scilab and Python under Windows. The original was coded as pure C extension. Whatever, I decided to simplify it for my purpose. At the moment, the simplified code is sufficient for my purpose. However, it will be developed. Initial version was uploaded onto BitBucket as Git repository. Installation and Usage are as follow, Clone git repository onto your computer from https://bitbucket.org/ierturk/scipylab.git Start a command window, then go to root of your local copy, and issue command below python setup.py buid_ext --inplace Open your favorite Python console then issue commands below >> from SciPyLab import Scilab >> sci=Scilab() >> sci. for example >> sci.sin(3.14/2) >> sci.plot([1, 2, 3]) The code tested under following condition Python 3.4 (Anaconda Python distribution from Continuum Analytics) Cython 0.20.2 Spyder 2.3.0 MSVC 2010 Express Scilab-5.5.0 Windows 7 x64 Numpy 1.8.2 SciPyLab -- View this message in context: http://mailinglists.scilab.org/Enjoy-Scilab-and-Python-Binding-Scilab-and-Python-SciPyLab-tp4031070.html Sent from the Scilab developers - Mailing Lists Archives mailing list archive at Nabble.com. From masilvabustos at ieee.org Mon Aug 25 19:21:53 2014 From: masilvabustos at ieee.org (=?UTF-8?Q?Mat=C3=ADas_Silva_Bustos?=) Date: Mon, 25 Aug 2014 14:21:53 -0300 Subject: [Scilab-Dev] code generation for microcontroller target In-Reply-To: References: <48547181.VUgbqSaSWu@valtin-rt-l1> Message-ID: 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 : > > Greetings, > > (answered inline) > > 2014-08-11 14:02 GMT-03:00 Markus Valtin : > > 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: From pierre-aime.agnel at scilab-enterprises.com Fri Aug 29 15:19:44 2014 From: pierre-aime.agnel at scilab-enterprises.com (=?UTF-8?B?UGllcnJlLUFpbcOpIEFnbmVs?=) Date: Fri, 29 Aug 2014 15:19:44 +0200 Subject: [Scilab-Dev] [SEP] Function for implicit plotting Message-ID: <54007DF0.1070901@scilab-enterprises.com> Hi, I created SEP #132 for implicit function plotting. The idea is to be able to plot F(x,y) = 0 directly instead of having to feval then contour the plot. A first experimentation from can be found here https://codereview.scilab.org/#/c/15130/ If you can give me your insight/comments on this to improve the feature. I'll add a implicitplot3d once I have confirmation from the author of contour3d that I can use the function. Thanks, -- Pierre-Aim? Agnel Development Team ----------------------------------------------------------- Scilab Enterprises 143bis rue Yves Le Coz - 78000 Versailles, France Phone: +33.1.80.77.04.68 http://www.scilab-enterprises.com -------------- next part -------------- A non-text attachment was scrubbed... Name: SEP_132_implicitplot.odt Type: application/vnd.oasis.opendocument.text Size: 64045 bytes Desc: not available URL: