ptitjes

As you can see there: http://www.midibox.org/dokuwiki/howto:dev:autotools-skeleton#getting_started 4 files added to the application itself (main.c and README) I chose the way it is done everywhere else! Every time you install a cross-compiling toolchain you get bin tools. But is it a problem ? It is transparent to the user... Good point! ;) I've seen this one while scrubing for in the wrapper... This one is a real problem and I've only thought a little about this. But maybe we can find a trick so that the wrapper find those pointers elsewhere! Standard linker scripts (adapted for MIOS) are provided by default for the host platform you compile libcmios for. They are transparently selected by the toolchain-wrapper. But you can still add a LDFLAGS += -s my-own-script.lkr in your Makefile.am file. Tests like AC_CHECK_HEADERS(...) used in the configure.in are programmed in the M4 macro language. I already use this for the MIOS-specific tests i included in mios-pic16-toolchain. There are plenty of standard tests available in Autoconf. And you can easily progam new tests to check for new things. So: Specific MIOS version: should rely on libcmios version Specific library element: AC_CHECK_HEADERS(...) There is an example of this in skeleton. There are lots of other AC_CHECK_ for libs, headers... see Autoconf documentation. cmios wrapper or SDCC version: I can add another specific test M4 macro in mios-pic16-toolchain to support this. That's no problem at all! What is interesting with Autoconf tests is that they automatically provide C preprocessor symbols (in generated config.h) so you can even have different way of doing things in your code depending on the availability of a library, header or anything you test in configure.in. I use this feature to have __pic18f4685__ or __mios__ defines in the skeleton. Example in my libcan/configure.in: AC_ARG_ENABLE([debug], [ --enable-debug (requires libdebug)], [ AC_CHECK_HEADERS([debug.h], [ AC_DEFINE([DEBUG], [], [Whether debug is enabled or not]) ], [ AC_MSG_FAILURE([Can't with debug support : libdebug's debug.h not available]) ]) ]) Explanation : If --enable-debug is set in configure then i test for the availability of debug.h. If debug.h is available then defines a preprocessor DEBUG define else fail the configure with a nice message. In the C code i have at the begining #ifdef DEBUG # ifndef HAVE_DEBUG_H # error "Can't have debug enabled without libdebug" # endif # include <debug.h> #endif and #ifdef DEBUG #endif sections around each of my debug calls... Easy and clean! Best regards, Didier.

Cool! Do no hesitate to ask me questions about the configure.in and Makefile.am files of the skeleton, as I still not have finished the documentation of its anatomy. You can also crosscheck the files from the skeleton and the ones from libcan, to better understand. Also here are the unique documentations i used to make that work : automake manual autoconf manual I'll add those links in the Wiki page too! Yeah! I do hope people will come and test the beast. :) I'm happy that you feel the same as me. I was completely stunned the first time i've seen the current skeleton, trying to understand what files were there for what, and why there were so many... Thanks to you for your patience. Cheers, Didier. PS: I won't be at home for one week to go and have Christmas festivities with my best friend. Do not know if i'll have an Internet access so...

My fault again... So i reworked that prefix things completely to make it more stable! Please read the "Making choices" section in the Wiki page. (http://www.midibox.org/dokuwiki/howto:dev:autotools-skeleton#making_choices) There I explain where installed things go depending on the prefix. Please uninstall everything, download it again, and restart the procedure! I've redone it completely at home (with prefix, without prefix... install everything/uninstall everything...) and it works very well. (Beware that version is still 1.9f-r1... as you are the only user for now and that there are certainly some other points to fix, i don't want to augment the versions too fast) Thank you very much for your help. Best regards, Didier.

You are the first beta-tester... (after me of course ;)) so this is quite normal that you get the bad things. But please do not dismiss! I need you! :) Exactly. BTW i uploaded a release correcting your previous problem and some minor other stuff. If you want to try to "sudo make uninstall" mios-pic16-toolchain and re "sudo make install" it to check if it now works correctly as on my computer.

There was a bug in the install-hook target of the Makefile of mios-pic16-toolchain... sorry but you are my first bug reporter :) Made a new release with a fix for this. See in the first post. So indeed your links are correct anyway. Could you provide me the content of config.log please ?

Starting some documentation : http://www.midibox.org/dokuwiki/howto:dev:autotools-skeleton Cheers, Didier.

Yes please show the internals!

Sorry Narwhal, I overlooked your post and didn't see that you did not pass the configure step. It seems that mios-pic16-toolchain did not install so well. Explanation: Your config.log says it does not find pic18f4685-microchip-mios-gcc: configure:2548: checking for pic18f4685-microchip-mios-gcc configure:2578: result: no configure:2588: checking for gcc configure:2604: found /usr/bin/gcc configure:2615: result: gcc configure:2853: checking for C compiler version configure:2860: gcc --version >&5 powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5370) Explanation continued: sdcc adds automatically its own include directory (containing amongst others pic18fregs.h), which standard gcc (here powerpc-apple-darwin8-gcc) hopefully does not. So could you please tell me what exact configure parameters you gave to mios-pic16-toolchain. What is the prefix you gave ? Did you put '/usr' or '/usr/local' ? And also what were the output ?? ~/Desktop/mios-c-skeleton/mios-pic16-toolchain/$ ./configure --target=pic18f4685-mios --prefix=/usr ~/Desktop/mios-c-skeleton/mios-pic16-toolchain/$ sudo make install I would like to understand where it installed the toolchain. Could you verify if ${prefix}/bin/pic18f4685-microchip-mios-gcc exists ? $ echo $PATH $ which pic18f4685-microchip-mios-gcc $ ls -l /usr/local/bin/pic18f4685-microchip-mios-gcc $ ls -l /usr/bin/pic18f4685-microchip-mios-gcc Thank you. Best regards, Didier.

Kurt, There is a DEBUG=0 at the beginning of the mios-pic16-tool-wrapper script. (It is located in /usr/bin or /usr/local/bin depending what prefix you put in the configure of mios-pic16-toolchain.) If you put DEBUG=1 instead you'll have the commands it really runs instead of gcc. Could you tell me what sdcc command it runs ? (Or maybe put all the output) I do process the -I___/sdcc/lib/pic16 option so it may come from that... Best regards, Didier.

I use quite exclusively Eclipse for all development tasks, and SciTE or nano for occasional quick editing.

A toolchain is the set of tools to go from source to executable (compile => assemble => librarian => linker) Comments are welcomed! Also could list the editor/IDE tool you use...

I don't say your approach is too conservative! You work on this project for now more than 5 years. Project span is really big and the use cases are numerous. I think you might have seen many many recurring user questions and problems. So you are certainly at the best seat to see what could be a new issue or difficulty for your users. As for the gpasm macro preprocessor, i'll look whether/how/if i can extend it... I must delve more into the MBSID code and also look further into the MIOS code to see what those macro looks like. Also maybe a pre-preprocessor is possible... I won't have to do that before January but i put that on my task list. Anyway I like the installation package idea! I'll document my approach on the Wiki during this week. Then we'll see if some users, including Windows-based, can test it! That feedback will make me figure out how to help and document with a transition scheme for those who wants to use it. Best regards, Didier.

According to http://gnuwin32.sourceforge.net/install.html : As for the PATH variable i think this has been corrected. And the interest of autotools is that it can generate makefile differently for the platform it runs on. There are also extensive discussion in the autotools' manuals about support of Win-specific filenames... so this should be tested by one that has Windows. If someone can test autotools on Windows, i likely want to make the autotools skeleton more portable. And again i think there is not too much work. Else, Cygwin is, IIRC, really easy to install. Something like a two click setup program. Generally, people that begins with programing on Windows never practiced cmd.exe before. So, really, we should immediately recommend them to install Cygwin. Learning DOS shell or learning POSIX shells is the same from a learning curve point of view, except that there are POSIX shells available for all platforms and no other plateform than Windows with a DOS shell. I completely agree that to reduce work, there should be the minimum of officially supported programming ways. But here is how I see it : MPASM is not a common case as it only runs under Windows. gputils and sdcc runs on all your supported platforms. So why not drop official support of MPASM and let people on their own if they want to experiment with using MPASM. By the way, it make a while now that I'm really wondering what Midibox's users are using as development platform... Would you mind if i make a poll on the forum ? Best regards, Didier.

I'm really not sure that you need Cygwin to run autotools on Windows: http://gnuwin32.sourceforge.net/packages/autotools.htm But i can't test that as I don't have any Windows at hand! And i surely never won't anymore... Anyway I don't know what dev. you can do without any decent make utility.

I see your point for the necessary user skill-level for such an approach... Configuring and compiling my linux kernel seems natural to me now but this has not always been the case. And maybe eliminating the need for a C wrapper completely but providing helper functions like PrintCString()! OK! I asked because i have so many other things on fire... However, i understand that you suggest that could be a decision for a redesign/rewrite for a V2 (surely also if it must support not only PIC but another processor family). So when the time will come, I volunteer to help you setting up the tool-chains and splitting MIOS! Heu... not sure to understand! Are you saying you will do it or are you saying that if you were me, you would split each and every function in it own file ?? (Wooow!! :o ::)) In fact, i can see this is the approach they have choosen for the sdcc libs... I'll have to make a script to automate this... else I'm too lazy!

Yé! I understand that! I was thinking about that keeping the "simple solution" along to it however when i wrapped the mios wrapper in a library i lost the ability to use the perl script... However i still wish to reintegrate it in a latter time! In fact, this is one bonus of the library approach! http://gputils.sourceforge.net/reloc_howto.html says : (archive members are individual relocatable object files aka ".o") So, this means that the mios wrapper must be split in multiple asm files to make multiple objects. So that the linker extract only the ones needed by the application. So i think, there should be one core object file for the user callback vector definition, and one for each big features : DIN, DOUT,... But this scratches my head constantly that in fact that should be MIOS itself that should be cut in libraries. A core MIOS with just the bootloader (and MIDI-stuff used for the bootloader) and a series of libraries for each big features. I could help in splitting it if you would choose that for a latter major version of MIOS. If you want i can experiment on that so that we can see if it feasible of not! PS: Another bonus of the library approach is that i was forced to find a C macro way for defining the MIOS_ENC_TABLE and this is cool :)

Also support for pic18f4685 comes with sdcc-svn (has a package on Gentoo) and gputils-0.13.5!

Updated: 2007-12-20 New version 0.1.1 released. Documentation : http://www.midibox.org/dokuwiki/howto:dev:libcan Download : At the end of this post :) Merry Christmas! Happy coding! Cheers, Didier! TODOs : - Extract message table helper functions in a dedicated library - Add equivalent helper functions based on binary decision trees - Optimize code with inline asm code (i tried to be very close to what i would do in assembler so optimizations will be easily to achieved!) Changelog : 0.1.1 (2007-12-20) Fixed some type and incoherent names Made some documentation on the Wiki 0.1 (2007-12-14) Initial release libcan-0.1.1.zip libcan-0.1.1.zip

Updated : Starting some documentation : http://www.midibox.org/dokuwiki/howto:dev:autotools-skeleton New release: 1.9f-r1 Merry Christmas! Cheers, Didier. To Do : Cut libcmios in one object file per function Changelog : 1.9f-r1 (2007-12-21) Made mios-pic16-toolchain, libcmios and the skeleton itself to follow the same version scheme (MIOS version - release number) mios-pic16-toolchain Fixed installation of tool symbolic links Fixed management of installation prefix [*]libcmios: Removed now unused mios_tables.inc 1.9f [*]Initial release Hi all, Time maybe has come for me to publish a bit of my homework during the past months. In my quest to simplify the C skeleton, i wanted to achieved the following goals: 1) Not having identical files in different applications 2) Having a makefile system that is easily extensible (don't want to have to make rules for simple things and want to make simple rules for complex things), enables directory hierarchies, that encompass by default all my wanted targets (all, clean, install, dist, dist-check...) - Goal 1) required the mios wrapper itself to be put elsewhere than in the skeleton. Why not having a libcmios library ? Hopefully gplib can make shared libraries and gplink can grap object files from them and link them statically inside the application. Cool! - The mios-specific linker scripts also had to be put in a shared location. I decided to follow the usual rules of sharing for cross-compilation... having a directory that is specific for a host platform that contains headers and libraries. (${prefix}/host/) - The mios-specific asm fix script was a problem. But thinking about Goal 2) makes my try the autotools and I quickly understood how they were fullfiling Goal 2) completely. So I decided to make a wrapper script around sdcc, gpasm, gplib and gplink, that would take care of transparently fixing the asm, and that would use the GCC command line style: C compiler to compile for target processor-vendor-os is processor-vendor-os-gcc Asm compiler to compile for target processor-vendor-os is processor-vendor-os-as Librarian tool to make libraries for target processor-vendor-os is processor-vendor-os-ar Linker for target processor-vendor-os is processor-vendor-os-ld So here is the result. You can find an attachement in this post that contains libcmios-1.9f.tar.gz mios-pic16-toolchain-0.1.tar.gz mios-c-skeleton/ Possible targets/hosts are: pic18f452-microchip-mios, pic18f4520-microchip-mios, pic18f4620-microchip-mios, pic18f4685-microchip-mios Note that pic18f452-mios, pic18f4520-mios, pic18f4620-mios and pic18f4685-mios are automatically expanded. I will document this better in the Wiki in some days. Install the toolchain wrapper, libcmios and its linker scripts...: $ cd mios-pic16-toolchain $ ./configure --target=pic18f4685-mios --prefix=/usr $ sudo make install $ cd ../libcmios $ ./configure --host=pic18f4685-mios $ sudo make install As for the skeleton itself... Modify the configure.in, Makefile.am, src/Makefile.am and main.c... and then configure and make the application : $ autoreconf --install $ ./configure --host=pic18f4685-mios $ make mios-autotools-skeleton-1.9f-r1.zip mios-autotools-skeleton-1.9f-r1.zip

- Use the pic18f4685.h provided with sdcc (or better pic18fregs.h if you can make portable code) - Don't forget to fix the asm generated by sdcc with the provided perl script - Link with the following modified pic18f4685.lkr linker script ... and all should compile and work well! pic18f4685.lkr : // linker script for a MIOS project // Thorsten Klose (tk@midibox.org), 2004-07-10 LIBPATH . CODEPAGE NAME=vectors START=0x2C00 END=0x2FFF PROTECTED CODEPAGE NAME=page START=0x3000 END=0x17FFF CODEPAGE NAME=idlocs START=0x200000 END=0x200007 PROTECTED CODEPAGE NAME=config START=0x300000 END=0x30000D PROTECTED CODEPAGE NAME=devid START=0x3FFFFE END=0x3FFFFF PROTECTED CODEPAGE NAME=eedata START=0xF00000 END=0xF003FF PROTECTED DATABANK NAME=miosvars START=0x000 END=0x00F ACCESSBANK NAME=accessram START=0x010 END=0x05F DATABANK NAME=gpr0 START=0x060 END=0x0FF DATABANK NAME=gpr1 START=0x100 END=0x1FF DATABANK NAME=gpr2 START=0x200 END=0x2FF DATABANK NAME=stack START=0x300 END=0x37F PROTECTED DATABANK NAME=miosram_u START=0x380 END=0x5FF PROTECTED DATABANK NAME=gpr3 START=0x600 END=0x6FF DATABANK NAME=gpr4 START=0x700 END=0x7FF DATABANK NAME=gpr5 START=0x800 END=0x8FF DATABANK NAME=gpr6 START=0x900 END=0x9FF DATABANK NAME=gpr7 START=0xA00 END=0xAFF DATABANK NAME=gpr8 START=0xB00 END=0xBFF DATABANK NAME=gpr9 START=0xC00 END=0xCFF DATABANK NAME=sfr13 START=0xD00 END=0xDFF PROTECTED DATABANK NAME=sfr14 START=0xE00 END=0xEFF PROTECTED DATABANK NAME=sfr15 START=0xF00 END=0xF5F PROTECTED ACCESSBANK NAME=accesssfr START=0xF60 END=0xFFF PROTECTED SECTION NAME=CONFIG ROM=config

Ok! Great thanks as i missed that one... I now have a better view of the touchsensor story. I had the same feeling! I planned to experiment on this, however i wanted to have a first understanding of it and maybe some people already knew if it was a show-stopper.

Sorry. Maybe i did not correctly formulate my question! I do not want to make a matrix of touch-sensors! I want to use touch sensors *alongside* the led/button matrix. So as the sm_example_v2 code is disabling the touchsensors, i am wondering if this is possible... Does touchsensors uses service_prepare and service_finish to enable/disable J14 or in another way ? And how is that preventing from using touchsensors alongside a led/button matrix ? Didier.

Hello, When i look in main.asm of the sm_example_v2 in the MIOS Download page, i can see that the touchsensors feature of MIOS are disabled. As i can test that yet, i would like to know if and how the touchsensor feature may interact with a led/button matrix as programmed in the example ? (I would need both...) Thanks for your help. Didier.

Bon c'est ok. Mon pôte a un PIC01 et je vais le chercher dans la semaine. D'après lui il permet de programmer les 16F aussi. Mais comme j'arrive pas à en trouver la page sur Internet je ne sais pas combien de pins ont ses différents sockets... Il habite dans le 20ème donc si tu as le soft pour programmer et si tu veux que je passe dans la foulée chez toi... je te PM mon numéro de téléphone... J'ai pas encore regardé ce qui existe comme soft pour Linux donc je ne pourais pas te le programmer moi-même pour l'instant. A+didier

Salut Bill! J'ai un pôte qui a ça il me semble! Je l'appelle demain et je te tiens au courant! Tu es où à Paris ? a++didier