ptitjes

Salut Boops! Euh le v3 de quoi ? de Midibox SID ? Sinon mais bien-sûr il n'y a pas de problèmes pour que tu te joignes à nous. C'est même avec plaisir! A++Didier.

Yeah I do agree :) But that is a pity there is no adjustable attack and release time in their typical design... Hehehe! I'm weak! :)

Sorry, but the two op-amps in the chip are available to transform the log RMS-level sensor signal in a compression level signal to feed to the internal VCA... IIRC you need one op-amp to compare to your compression threshold and one to adjust it according to your compression level. Just look at the typical application in the datasheet. However this makes a simple compression to build. This chip is so great! This is also on my todo list :) I would like to make a digitally-controlled compression. So if you go the That way please share your experience! Best regards, Didier.

Salut Jules! Et bien c'est avec plaisir! Chouette on est trois! :) Par contre, ce n'est pas ce samedi mais le suivant (le 1er Mars)! Wow!! Ben vu que on est trois je pense qu'on payera tous notre coup :) A++Didier.

Bon alors ben première réunion du PMUG Samedi 1er Mars - 14h au Jardin (52, r Bidassoa 75020 PARIS). Je sais on est que deux mais bon je le marque quand même au cas il y en aurait qui se réveillerais... A++Didier

Happy to know that because I'll do some shift and latch clock generation these next days... I will have to do a __asm nop __endasm define or write to latch registers directly so... Thanks for that useful information! Best regards, Didier.

I read that in the I/O pin section of the datasheet but not understood it at first. I'm not so used to read the simplified diagrams. That's ok now I think. Did not know the PIC had a pipelined architecture ! I hope sdcc takes care of this when he optimizes code... Oups! Yeah! I did not even think of it :) Well. I looked at the generated code for ternary (?:) and it used intermediate viariables and the generated code is not optimized then simple if then set else set... Best regards, Didier.

Salut à tous! Bon voilà l'idée... On s'est dit avec Bill (qui est parisien aussi) qu'il y avait sûrement d'autre parisien midiboxers/bidouilleurs et donc que ça serait sympa de se retrouver de manière régulière (quelque chose comme toutes les deux semaines) pour discutailler/boire des coups/échanger des idées, des conseils, des solutions/présenter l'avancement de nos projets respectifs... Bref on vous propose de monter un Midibox User Club sur Paris! Je vous propose qu'on se retrouve déjà une fois pour se discuter de l'idée de visu... autour d'une bonne bière, par exemple. Qui serait intéressé par se joindre à nous ?? Quel soir serait le plus facile pour se retrouver, dans quel bar ? Ou alors un autre lieu ? Pour ma part, je vous propose le Jardin (rue de la Bidassoa 20e) c'est sympa et convivial, et en plus pas vraiment cher!! Il y a de la place si certains veulent ramener deux trois bidouilles... Quant à la date je peux me libérer à peu près n'importe quand dans la semaine courante et à venir! Samedi après-midi peut-être ?? A++ Didier.

In fact this was : PORTA = (PORTA & 0xF0) | (oct & 0x0F); if (oct & 0x10) { PORTAbits.RA5 = 1; } else { PORTAbits.RA5 = 0; } PORTE = (PORTE & 0x1F) | ((oct & 0xE0) >> 5); which is the most efficient C code I found by looking to the generated asm...

This was only on that forum and I was able to post in all the others. I say "was" because yes! the buttons reappeared! I had only the "Mark Unread" button before. Anyway that's working again!

I think it is since Thorsten gave me access to the Programmers' lounge... :( Too bad, I got two good solutions...

Hi all! I just see that I can't post in the Design Concept anymore... I would like to give my advice to the cheap dout "bug contest" :) but I can't!! Best regards, Didier.

Yeah!! Thank you Thorsten. In fact, I was in my previous code only handle on error (either OERR or FERR) for each RCIF. So, I handle both now reseting two times the usart and this works like a charm. Got DMX input!!!!! :) BTW, REFF is read-only. You also have to reset the usart (CREN=0; CREN=1) to get off of it. Thanks again Thorsten. You helped me so much also because I felt less alone ;) I'm sure you know what it is!! Best regards, Didier. Edit: Still not found why RX line is low at power-on but this makes my DMX receive led blink so this is ok for now but if you have an idea of what the problems come from...

Hi Thorsten! You're right! My C comment is wrong too... My goal was to say : C7 = RX input, C6 = TX output So! I double-check (should I say nth-check... :)) my breadboard and this is correct in respect to my schematic. Also, TX goes correctly to the RC6 pin and RX to the RC7 pin... I have re-read the USART datasheet more and this is more clear to me. In fact I was not sure about the high-level during idle. I also checked the informations I got about DMX and this is comfirmed. What I observe : - When nothing is connected, I have a +5V on the RX line, which is good. But the RCIF is constantly set to 1 anyway. - When a 12-channel lighting desk is connected, I have a good signal on the RX line, which studied at the osciloscope reveals : * a long low-level break followed by a 3 bits high (3*4µs), so this creates a frame error which identifies the start of a DMX paquet * 13 * the following sequence (1 start-code value = 0 and 12 channel values) * 9 bits low (8*4µs), so this is the start bit + 8 low bits of the value * 3 bits high (3*4µs), so this is the 9th bit of the value (which is always 1) + the stop bit + 1 bit idle So this signal is a correct DMX signal. Also, as low level is +0V and hight level is +5V, the SN75176 does seem to work well ! What I can't understand is why I have RCIF set when the RX pin is high... Best regards, Didier. Edit: When I power up my circuit, the RX line is low at first. Then I plug DMX, have signal on RX line. And when I unplug DMX, then RX line goes to high. I can't explain why it does not go to high at first!!

Hi Thorsten! What do you mean by "The SN75176 is powered by the Tx line" ? In fact I think I quite not understand what you explains. Could you please re-phrase it ? In fact, I don't transmit anything. DMX uses RS485 in a unidirectional manner. There is always only one transmitter, receivers are then daisy-chained on the RS485 bus and the bus is then terminated with a 120 resistor. This is why I do not enable the transmit part of the USART (TXSTAbits.TXEN = 0 and RCSTAbits.SPEN = 1) Also I do not use the pull-down anymore for RX. Sorry the schematic is old. I attached the latest version... I'm not sure yet if I will pull-up RX or let it as the SN75176 drives it as I explained in my previous post. I must admit I got inspired by the GPL work of Kelly Kohls. He provides schematic and asm source. But his work is based on a PIC16F876. He doesn't pull down RX. He pulls TX to high (10K), but I believe the PIC16F had their inputs at TLL-levels and CMOS levels as the PIC18F. Finally they use the same mechanism here. (schematic) They also use a PIC16F877, but with RX pull-down. Oh sorry!! I just re-read my previous post and see that I told all wrong. You must read RX everywhere i wrote TX in the last paragraphs... So let me re-phrase it : It appears that even when RX is low, i.e. no transmitter is connected to the bus (nothing plugged on the differential side of the SN75176), PIR1bits.RCIF is set. (Not convinced by my oscilloscope I even tried to directly set RX pin to ground with a 1K resistor...) I can see that RCIF is set because the led is a very little bit lit and putting the scope proves it too. I scratch my head on this for three days now!! You can't imagine how this even gives me nightmares :) This code is so simple that I can't see where I am wrong! Best regards, Didier.

Hello all, I know this is not really related to MidiBoxes but I need some help and I know some of you have the knowledge I miss... It happens I'm trying to receive DMX512 through a SN75176 (differential transceiver) with PIC's integrated USART. I found a lot of schematics and asm sources on the Internet so I cooked myself a schematics and... got a lot of problems! Let me explain my problems and ask corresponding questions. (Schematics below...) It happens that the RX output of the SN75176 is electrically compatible to the VIH and VIL of the PIC. The SN75176 says VOH minimum is 2.7V but in pratice i measured 4.2V which is just above the 4V of PIC's minimum VIH. (I added a 1K pull-up just to test and it brings the VOH to 4.5V so maybe I'll that pull-up in the final design for safety). So I happily connected that to the PIC and implemented a simple (no interrupt) usart poll in my main loop. [...] code char at __CONFIG1H _conf0 = _OSC_HS_PLL_1H & _OSCS_OFF_1H; [...] #define DMX_OSC_FREQ 40000000 #define DMX_BAUD_RATE 250000 #define DMX_BAUD_RATE_SCALER (DMX_OSC_FREQ/(16*DMX_BAUD_RATE))-1 #define DATA_RECEIVE_LED PORTBbits.RB0 [...] PORTA = 0x00; PORTB = 0x00; PORTC = 0x40; // TX pin = 1 // 00000000 (A<7,6> outputs, A5 = Power drain output, A<4,0> outputs) TRISA = 0x00; // 00011110 (B<7,5> outputs, B<4,1> inputs, B0 output ) TRISB = 0x1E; // 10001110 (C7 = TX input, C6 = RX output, C<5,4> outputs, C<3,1> inputs, C0 output) TRISC = 0x8E; PORTBbits.RB0 = 1; // Turn led off [...] TXSTA = 0; RCSTA = 0; TXSTAbits.SYNC = 1; RCSTAbits.RX9 = 1; RCSTAbits.CREN = 1; TXSTAbits.BRGH = 1; PIR1bits.TXIF = 0; PIR1bits.RCIF = 0; PIE1bits.RCIE = 0; PIE1bits.TXIE = 0; SPBRG = DMX_BAUD_RATE_SCALER; // TXSTAbits.TXEN = 1; RCSTAbits.SPEN = 1; while (1) { if (PIR1bits.RCIF) { DATA_RECEIVE_LED = 0; // Turn led on dmx_rx_data = RCREG; DATA_RECEIVE_LED = 1; // Turn led off } } (Note: My quartz is a 10MHz and I use HS-PLL with 33pF caps as in MBHP.) It appears that even when TX is low, i.e. no device is connected to the bus, PIR1bits.RCIF is set. (Not convinced by my oscilloscope I even tried to directly set TX pin to ground with a 1K resistor...) I can see that because the led is a very little bit lit and putting the scope proves it too. I read from the PIC's datasheet that reading RCREG unsets RCIF. Also I tried to manually unset it and it changes nothing... Did I miss something ? Thanks for your help. Best regards, Didier. IMG_0068-reduit.JPG

Hi Simone, Surely Scite! This one is a really cool free software editor! http://www.scintilla.org/SciTE.html It has all the syntax highlighting you can imagine, and i think you can easily add some! And this one also runs on Windows... By the way, I can only tell people to vote against Micro$oft way to create what they call "standards"... Best regards, Didier.

Hi S1, I wanted you to set up that doc out! :) I don't have any Windows station at hand... so you might like to give it a try by yourself :)

Strangely i can't connect to irc.eu.gamesurge.net:6667 whereas i can connect to irc.freenode.net ... ???

Agreed. Of course. I'll make a call for that around the end of the month. Cool! And no there is no time-pressure at all :) I will work on my PCBs during January but will follow the forum everyday, available for any help. Also, I will complete the Wiki pages little by little... I could do an ebuild for Gentoo Linux. Also I never looked at the RPM and deb package formats. But I guess I could do that quite easily too. As for Windows, I don't know if there would not be a licensing issue if we want to provide Cygwin as part of a complete package... Anyone knows about this ? Best regards, Didier.

Re TK, That would be great if you could take some time to write in greater detail a wiki page with the different directions you are exploring, and your actual state of mind for your future architecture. Do not know any of those... I currently concentrate my background research around FPGAs. People! People! Please could you help by testing ?? :) Maybe could you contact directly people that you know could compose a nice sample of users with different methods ?? I do prefer a nice explanation message at configure time than an ugly and obscure C compiler message that would only add some more support requests... What do you call a release package ?? Are you saying that library headers should be copied in every application. If yes you are coming back to the same problems as it is actually... You have to understand that those preprocessor symbols are defined or not whether a header file is present. This is way far more powerful. And library headers are shared amongst all applications. But it is possible, that some software need them. Having a check for those is better than testing for a particular sdcc version. And again you'll have a pretty explanation error message at configure time. I do prefer command-line configuration than having to edit a file from the distribution. Also, one has to know what preprocessor symbol it has to define to have different build features. You only have to do "./configure --help=short" to have a clear and documented view of what build features a particular package has. Yeah, renaming the directory with correct version number, making a clean, and then zipping... "make dist" is way far simple for anybody. Oh! What a dishonesty... :) We are all, you included, complaining about the lack of documentation on some topics and in general that documentation is fuzzily organized on the Wiki. Providing a way to have corresponding documentation along to the code is a good way make things more organized. So you should support that if you want more documentation. I don't think that this is so unix-oriented. Also, i still hope some people with a long background of your project could try the proposed a skeleton and give feedback. Yeah i told you that in one of the first posts in this thread. However, warn that (i don't have the commit mailing-list threads at hands) for support of the 4685 you need svn version of sdcc and latest version of gputils. Best regards, Didier.

Hi TK, I can only agree with this!! This first thing I can point out is the led/button matrix thiing that really would need to be in a library. (this is already on my todo list as I need that in two of my applications) But there are lots of other code spread into many of the applications that could be factored out for the benefit of everyone... +1 for the wiki page. Sorry, I was talking for the new stuff in new MIOS versions. When there is a new thing available in MIOS, i don't want to have to replicate the new wrapper code everywhere to benefit of this new thing. A simple such example that I have been in the place to watch is the addition of the DETENDED3 constant. Sorry, again, i was not that clear. I was meaning complete new processor family. But here I was really anticipating. Please just forget that if you find thinking about this is too soon. As for the linker scripts, if you need a project-specific script you have only on line to add in the Makefile.am. But please remember that memory windows larger than what is addressable by the PIC is greatly discourage by both the PIC and also sdcc documentations. Also, in my approach, if you do not need a project-specific linker script, a processor-specific linker script is already selected transparently without any user intervention at all. Because, as I've read many times on the forum, you already have lots of topics to work on, and that you are the sole one that can work on these. I do prefer that you work on all those things that will bring us additional advantages to use MBHP. Understand my point of view : I am a newbie in electronics. In more than six months now, I started reading The Art of Electronics. I also read quite all, I think, the documents I could find on the Wiki and ucapps.de, delved into the code of quite all the applications (not started reading th SID one yet though). I am, day by day, understanding more and more of your work. I now have a quite clear understanding of all the MBHP architecture, and the interactions between hardware and software. However, I still miss some features and this is why I consider the box I'm building will only be a prototype. So when I can do some things (like software, which is what I'm really good ine for now), I do it to let you work on other things I could not do for you. However, those really fit my needs. Please see below... And also, I don't understand why you want to reinvent the wheel. There exists software that do what your makefile generator does and more. So why don't use it. I'm tired of people rewriting things already existing, because they can't reach the consensus that brought those things to exist. (Please don't take this as an offense, as you have reasons that we are discussing in the past posts) But you forget all the other features I really need : (you can take that as a feature request... if you really want to code that again) - Checks for the host platform if the application/library can be build for it (eg. my libcan can only be build for 4685) - Checks for presence of some headers for the building platform and automatic preprocessor symbols to have code variants - Checks for presence of specific C compiler features - Possibility to have features enabled/disabled at configure time and automatic preprocessor symbols to have the corresponding code variants (eg. my libcan can be build with or without debug support, and i will add more features in the future like disabling of inline assembler code optimized variants, ...) - Automatic distribution releases building (dist, dist-zip, ...) that really ease the making of a source distribution archive - Automatic installation of documentation/licenses in a standard location and other data along with the install of a library All of these comes by default with AutoTools and the toolchain I released. And the ones you pointed out : - Checks for libraries' and MIOS versions - ... Also, how will you manage the location of the libraries' headers to build applications that use them ? Will you have to configure each and every application with the location of the headers of each of the libraries it uses ? This can be done in an automated way which is what 'make install' are for. Also if you rewrite some code for a 'make install' in your makefile generator, you will have a standard path where to put libraries and their headers, coming back to problem of which platform those libraries are for people that build applications for different PIC micro-controllers. Please, make the sum of all those things we just enumerated above and estimate the amount of dev/test/... you still have to do to reach the quality of the AutoTools. Also, please consider that using standard tools is a way to make the MIDIbox project more professional and accessible to people already involved in other open-source projects. I have to test what you suggest here. If it works that is a good thing. Edit: I'm currently designing my PCBs, so I can't work on this now. I think I have a month of work to get some correct PCB layouts (I have 16 PCBs to layout... !!$##** :)) However, the toolchain/skeleton provide quite all of what I need now, so, after the PCB layouts are ready, I will then polish it while completing/finishing my libraries/applications. Hoping that all these issues will see their resolution in 2008 ;) Best regards, Didier.

Hi BugFight! I know what embedded systems are. And who speaks about OOP here ? Modularity is not OOP. So please read the posts completely before trolling... TK: The suggestion about a second upload for configuration was just a flying idea. Not thought about this too much but I think I'll explore that in the following months... I know 8bit micro-controllers does not enable full-modularity and state of the art programming. However when you have already C functions that are already defined in a header and independent of any other part of a program please tell me what prevents you to put that in a separate library... I won't go back to the actual skeleton for the following reasons : - I have many applications and prefer to update one library (libcmios) than many applications when MIOS will be updated or new processor will be available. - Adding a sub-folder for sources took 4 hours of work with its proprietary makefile generator where i had one day of work to get the autotools toolchain/skeleton to work and now i need 15 seconds to add a sub-source folder. - Making libraries is impossible if you don't want to have a one day rework of the proprietary makefile generator where the autotools toolchain/skeleton provides that as is... I don't want to fight with the MBHP community but help it go forward. So please accept my point of view. I think we should stop that discussion as this goes nowhere. I was trying to push some things i think are good for the MBHP. Anyway, i will continue to release/maintain the toolchain/skeleton and my libraries, if someone wants to use that! I still hope you'll change your mind and maybe, one day, try the stuff I released to really see how it works and how simple it is! Best regards, Didier.

Hi TK, hi all! First i hope you had a good Christmas and i wish you all an Happy New Year, health and happiness... hardware and coding success too :) TK, please don't take offense at what i write in this post. I read you many times hoping that i understand it wrong. However, i don't find your argument about versionning and modularity relevant. Let me explain why... (Hope you will read that long post patiently... sorry!) It seems to me that you use the versionning of modules as an argument against modularity itself. The whole programming industry (yes all! and not only open-source and *nix communities) made programming evolve to an art of feature-separation and good modularity. I don't want to use that fact as an argument, I just want to remind you that such a discussion already occurred all over the place many years ago. There are lots of reasons why this direction has been taken and maybe we should learn from those reasons... (the first surely being maintainability) In fact, a better modularity makes less version changes as, obviously, orthogonal features evolve independently in different modules. Thus, single changes in independent modules are easier to handle than multiple changes in a single software brick. As for the interdependence and compatibility between modules and applications. A simple, yet efficient, way of doing things exists : a standard versionning scheme. One exists that has proven its benefits : major.minor.release Major version change implying API compatibility change (and obviously binary) and/or addition/removal of sets of new features Minor version change implying binary compatibility change only and/or addition of little new features Release number change implying bug fixes only Deprecation, along to this versionning scheme, can be used to make things evolve between version without forcing module users to update their applications at every module change. Also, modules for orthogonal feature sets makes users able to take benefit of new features and bug fixes more quickly. For instance, if one has a good led/button matrix code and make a library for it, then another don't have to replicate/copy that code in its own application. When the matrix code evolves, then all users can take profit of those changes without updating their code, by just updating the library (provided that this is just a minor version change or that the old API is only deprecated) and recompile their application. Using the standard version scheme, knowing that the library is still compatible is only a matter of comparing the version numbers. When one releases an application, he writes in the documentation a requirement section where he tells what modules and versions he has used (or announce it on the forum post). Again, knowing that a new library version is still compatible is only a matter of comparing the version numbers. When a new major version is set up (with new features), old versions of a library should be provided for download. Also the last old major version could be maintained temporarily (what is called branching) with bug fixes, in order to ease transition and not force users to update immediately. Making a feature evolve in a big and fuzzy application is quite complicated because it is harder to know how changing a thing in one place won't interact with something in another place. Making a feature evolve in one library is thought based on API evolution. You know what you can do and what you cannot do in order to no break compatibility. You know what a particular change will imply for users. And you know that you can change the internals of the library without breaking API compatibility. Also, having defined and cleanly separated APIs for different feature set is very very convenient for programming users. It is easier for them to have a big picture of the whole architecture and/or of their own application! One can better identify the interaction between software and hardware without delving into the code. Finally, having different modules for different feature set enables users to choose appropriately what features they need and update their versions independently. They don't bloat their head with informations or features not useful to them. I understand this may be a little harder to achieve for module providers but this is not the job of the non-programming users! The fact that a non-programming user should be able to adapt an application to its own hardware is an orthogonal problem. I agree this should be simple to execute. But this should not make complex thing hard to do when they could also be simple. So let resolve this use case by making it simpler even. IMHO, non-programming user should not have to recompile an application to adapt it to their hardware (provided the feature field is the same). POINT. I can give you a possible track to explore to solve this in a clean/easy way. It seems to me that configuration tables should be provided in a second upload. There is no need for a C or even asm compiler to generate those tables... a script and appropriate tooling integration (MIOS Studio...) could do the thing. Then one could provide binaries for its application (in addition to the sources if he wants to release them). Again, let give me an example similar to yours to demonstrate how this can be evil to manipulate an application with the current approach : (1) Programmer A writes an application based on the actual MIOS C wrapper. (2) Programmer B likes parts of what this application does and replicates the application code to integrate those parts to its own application. (3) Programmer B also makes changes to that code in order it fits the way its application works. (4) Meanwhile, Programmer A fixes many bugs in his application and maybe is doing even more changes. (Like you said : parameter lists in functions are enhanced...) (5) Programmer B tries to back-port bug fixes in its own application, but the code is not anymore compatible. When he copies/pastes the code, he even introduces new bugs (and maybe compile errors) (6) Programmer B explains on the forum how his application doesn't work since he back-ported the code of A, but programmer A can't identify where the problems comes from as the code of B is now very different. (7) Programmer B is unhappy about his MIDIbox project since it can't even work anymore... That example is not so hypothetical and I'm sure I could find many forum posts where that kind of problems already occurred. We can finally conclude from that experience that back-porting sucks so that modules is the way to go. Best regards, Didier.

Maybe try: autoreconf --install before configure and make. Also, I upgraded the documentation which now contains lots of informations (I say this in case you would not have seen this page) http://www.midibox.org/dokuwiki/howto:dev:autotools-skeleton I can't help you too much now as I go for one week in one hour. Merry Christmas! Cheers, Didier.