TK.

For programmers like us this is easy to handle after a short learning phase, especially because these are general concepts which are used by many projects today, so it isn't wasted effort to get familiar with such generic approaches. But IMHO, you still see the whole thing too much from the programmers perspective, and it seems that you expect from every MIOS user (even if he doesn't want to get into this topic, and only wants to change little things to customize the application) to spend some hours or days (maybe also with additional support from the forum) before beeing able to rebuild a .hex file, something which can be done today within a couple of minutes, and without the danger for incompatibility issues. I will give an hypothetical example: (1) Programmer A releases a quite useful library element (2) Programmer B uses this element in his application, his release package only contains his own source code. (3) Programmer A is doing changes in his library element, but Programmer B doesn't find them useful, as they slowdown his application, therefore stays at the old version. (4) Programmer A is doing even more changes. Parameter lists in functions are enhanced, so that the lib can even not be compiled anymore with the app of programmer B (5) after one year, a user has to recompile the application of programmer B. The compiler fails since he only owns the latest lib release (6) after some postings in the forum we find out, that he is using an incompatible release (programmer B wasn't aware of the funky autoconf checks, therefore the user wasn't warned about this) (7) programmer B doesn't respond to emails. With help from the community we find an older library version which could be compatible. Unfortunately the application is slowed down, realtime conditions are not met anymore (see 3.) (8) user is unhappy about his MIDIbox project, since it's so slow and buggy. Nobody can really help him, since only he and unreachable programmer B own exactly the hardware which is required to reconstruct issues. Something what is working quite well in the unix world meanwhile, cannot be 1:1 adapted to a project like MIDIbox. When somebody releases a complex application, he is the only one who can test it with his dedicated hardware for a long time, until other users build the same. Mostly he stays the only programmer who knows how to maintain the project. and he is the only guy who can qualify library changes with his hardware. Instead of beeing able to release a snapshot of all sources he was using during the programming period (like in he current approach), he releases only his own part. If he doesn't consider all the required compatibility checks due to lack of knowledge with the toolchain, and if the external parts he was using are not properly released, nobody will be able to reconstruct the .hex file after one or two years, especially when the programmer is not available anymore. Another issue for which I don't see a solution in your current implementation: how should a common user without programming knowledge recompile different MIDIbox projects which where created at different times (we are speaking about years), and which require different library or SDCC versions? Should he overwrite the /usr/local/mios files each time with older versions whenever he wants to create a new binary, or should he create parallel path structures? At least then we have reached exactly the state as today -> directories with many files... ;-) Sorry for the long posting before christmas (I will make a break as well) - just take it as inspiration for improvements. :) Best Regards, Thorsten.

Great that it is working now (because I had no other explanation for such issues) You can always overwrite an existing application, it isn't required to re-install MIOS The help files have been transfered into the Wiki, so that they are easier to maintain: http://www.midibox.org/dokuwiki/mios_studio and http://www.midibox.org/dokuwiki/using_mios_studio Best Regards, Thorsten.

I would propose to compare the number of files and complexity again once a realworld project has been setuped and tested ;-) Is it really required to create so many derivative specific links to the wrapper in the bin/ directory? Why not using a generic keyword for the PIC18F family like "pic16" instead of "pic18fxxxx"? What I'm missing is the possibility to change the stack sizes for main task and interrupts (as the wrapper is located in a prebuild library, it isn't possible to change it via define anymore). Solution: the stack pointers have to be defined via external constants How is it possible to adapt the linker file for application specific locations? How should this be handled for different derivatives? See also http://www.midibox.org/dokuwiki/using_pic18f4620#linker_script How is the version control managed? In long term it can happen, that users release an application which is only qualified for a specific MIOS version, or a specific library element, cmios wrapper or SDCC version. The last one is the most important, as the cmios wrapper implementation heavily depends on the way how SDCC passes parameters. Best Regards, Thorsten.

Maybe another MIDI application allocates the MIDI In port and the interface is not multiclient capable. Ensure that no other MIDI program is running in parallel. Another possibility: the MIDI In port is not connected to the MIOS Studio Out Port - both connections (In/Out) are required for a bidirectional communication. Best Regards, Thorsten.

Hi Carl, I haven't tried the configuration via Sysexbox for a long time, it could be that there are incompatibility issues with newer MIDIO128 releases. I will check this soon. I propose the usage of MIDI-Ox instead. The delay between SysEx blocks has to be configured to ca. 750 mS Thats the expected message so long no MIDI event has been received. The LCD displays the last incoming MIDI event at the upper line, and the outgoing event at the lower line. E.g., when a C-3 Note event with max velocity over channel #1 is received, it should display " 1|Note C-3 127*" Assumed that MIOS and MIDIO128 are still working, and that the LCD displays the startup message, thereafter the MIDI monitor screen: could you please try to upload MIOS while the application is running? The "Wait for upload request" function should be disabled, so that MIOS Studio resets the core automatically and starts the transfer thereafter. Best Regards, Thorsten.

ain64_din128_dout128_v2_0 has to be changed manually. Within the Init() function, you have to add MIOS_MIDI_MergerSet(MIOS_MIDI_MERGER_MBLINK_EP); // endpoint or MIOS_MIDI_MergerSet(MIOS_MIDI_MERGER_MBLINK_FP); // forwarding point depending on the position in the chain. It makes sense to get use of the MIDIbox Link approach, it doesn't hurt and it prevents feedback loops Best Regards, Thorsten.

It's better to use different IDs, regardless if the MIDIboxes are chained or connected in parallel. This saves you from uploading the wrong firmware. E.g., one time (after a bootloader update) it happened that I uploaded the MBSID firmware into MBFM, as a result all BankStick were reformatted and all my new patches got lost. :-( The probability for such an handling error is lower, when you have to select the right device ID before uploading a firmware. Another point is, that MIOS reply strings won't be forwarded by a MIDIbox which is assigned to the same ID. So, you wouldn't be able to update a firmware without changing the MIDI cabling. Best Regards, Thorsten.

I think that this is more confusing for experts than for newbies - nobody complained about this yet. It was intended from my side to call even the Vcc inputs Vss just to avoid confusion. And as you can see: more than 8 years it was successful (everybody connected the 74HC165 Vcc input to +5V). Best Regards, Thorsten.

The ML303 community still exists, the forum is located here: http://19642.forendienst.de/index.php They also have an english section :) Best Regards, Thorsten.

Mit dem MIDI-Interface musst Du auch den COM Port nicht mehr verwenden - es ist sowieso die bessere Loesung. ;-) Grss, Thorsten.

I remember that somebody else reported such an issue with 7414 (without HC) some time ago, so I think that this could cause the problem. 74HC14 is more tolerant against CMOS drivers, and your PC board is probably stuffed with such ones. Best Regards, Thorsten.

No, you haven't explained it (see your posting history). I found it strange, because you introduced your controller with a single sentence, and one week later you offered it for selling. But as you've noticed, I gave you an ok anyhow (because based on your posting history I assumed that you are not one of those guys with commercial interests), so no need to feel offended! Best Regards, Thorsten.

I've added a comment to the schematic (you probably need to refresh the browser to see the change). Maybe you haven't noticed this yet, but I'm doing such improvements every time I read that a newbie miss-interpreted a circuit... no need to discuss if it makes sense or not, just write a short comment, thats enough. I won't change the naming to GND and Vcc due to consistency reasons. There are hundreds of schematics, and thousand of PCBs where this CMOS naming style has been used in the past, I don't really see an advantage to change this to another naming style, it only leads to confusion. Best Regards, Thorsten.

With 2-lead Duo LEDs, you will get the second colour Best Regards, Thorsten.

Fine! :) Best Regards, Thorsten.

Hi, from http://www.ucapps.de/mios_bootstrap_newbies.html if multiple cores are connected to a single MIDI port in parallel or in a chain, each core should get it's unique device ID, so that the upload tool can address the code to the right receiver. The device ID is part of the ID header, which can only be modified during the flash programming of the bootstrap loader, or with the change_id application. The device ID selected in the upload window must match with the device ID of the core which should response to the transfer. This means in other words: after the MIOS device ID has been modified by the change_id application, the ID in the MIOS Studio Upload Window has to be changed as well, so that it matches with the new ID value. So long only one MIDIbox is connected to the MIDI port, it's save to use device ID 00. A project where different device IDs are required is the MIDIbox SID (the master gets the ID 00, the slaves the IDs 01, 02 and 03) Especially MIDIbox SID users will notice the problem, that the MIDI Outs of the slaves are not connected to the PC (only the MIDI Out of the master core). Accordingly, the upload tool of MIOS studio won't continue after the first code block has been transfered, since it doesn't get a response. There are two adequate solutions to overcome this: the Newbie method: plug the slave PIC into the master core socket and program it in the same way like you did for the master PIC. Only differences: you have to pick another .hex file, and you need to change the device ID. This has the advantage, that you can also ensure that the software is installed properly with the master core/SID as a "reference". Best Regards, Thorsten.

Hallo Constantin, die Baudrate wird im sogenannten "ID Header" festgelegt, der zusammen mit dem Bootloader in das Flash programmiert wird. Ohne Programmiergeraet gibt es nur die "change_id" Applikation als Alternative, doch diese muesstest Du zusammen mit MIOS ueber ein normales MIDI Interface aufladen. Hast Du eins in Reichweite? Gruss, Thorsten.

Did you also try to upload MIOS via 1st level bootloader, just to check that a corrupted installation isn't the issue? You can do this the following way: power-off the core, enable smart mode, load the latest MIOS .hex file into MIOS Studio (mios_v1_9f_pic18f4685.hex), and press the upload button. Now power the core: MIOS Studio should start with the upload after the upload request has been received. Best Regards, Thorsten.

Hi Lars, unfortunately these LEDs are not the right ones, because they either lit yellow or green depending on the polarity (so, you cannot mix the colours). In order to get use of the two colours, each LED has to be connected between two output pins, and some changes in the firmware are required as well (at different places - I cannot list them without testing it by myself). In general, duo-colour LEDs with 3 leads are only supported in matrix configuration as shown in the schematic Best Regards, Thorsten.

It's also normal that the PIC18F452 version of MBSID V1.7303 behaves strangely, because the PIC18F4685 is not completely compatible. Could you please create a SRAM dump from address 0x000, range 0x80 and address 0x500, range 0x100 and copy&paste it here? This give me the required informations about the LCD state. The SRAM can be read with the debug tool of MIOS Studio like shown here: Best Regards, Thorsten.

It's ok from my side so long this is a one-term business, although I find it strange as well. Best Regards, Thorsten.

There are two possibilities: 1) either forwarding 6 independent transposed/sequenced/arpeggiated key values to CV outputs 2) or forwarding 6 independent oscillator frequencies to CV outputs Option 1 would already be useful for most cases (especially for TB303-like hardware, as glide is generated by an analog circuit and controlled from a digital pin) Option 2 would give you a lot of additional possibilities, as it would include the portamento/glide/glissando effect, Pitchbender, Finetune/Detune and the modulation matrix output. You can turn your analog synth immediately into a modulation monster! ;-) Drawbacks of Option 1: none Drawbacks of Option 2: the appr. SID oscillator needs to be disabled, as the SID frequency register doesn't work linear. However, you can still control your SIDs from a second, third or fourth core, or from a second MIDIbox Digital gate options: a) gate/glide and accent of OSC1 Left and Right channel (makes 6 digital outputs) b) the 6 gates of the 6 oscillators Option a) would be perfect for TB303-like hardware, these are the control signals which are going into the analog domain. But you could "only" control two synth modules per core Option b) would give you exactly the same features as with 6 SID oscillators (however, the SID itself would be silent... or it shouldn't be stuffed at all) Means: fat Lead patches with multiple modulation possibilities, punchy drum synth, two basslines with additional modulation possibilities, and a multi engine for polyphonic sounds (or 6 independent voices) with dynamic or static voice allocation. Hm, would be interesting how a Minimoog sounds when it is controlled from a wavetable or fast C64-like arpeggiator ;-) These are the changes I could include into the firmware very easily. In fact for Option 1) I only need to copy the key value to the AOUT register, and for Option 2) I only need to select a linear frequency mapping and copy the oscillator value to the AOUT register The flags for option a) and b) already exist as well, and only need to be copied into the AOUT_GATE register All options would still allow to forward the SID filter value to CV outputs in addition. By doing so, the external synth filter (or any other CV source) would be part of the mighty modulation matrix Thats all what is possible without much effort, only question: should it be a soft- or hardoption. Means: is it ok for you to build a new .hex file and upload it to the core in order to configure the CV routing, or is it really required to control this from a menu page during runtime (which increases the effort at my side dramatically, and makes it less flexible) Best Regards, Thorsten.

Ok, I checked the GNUWIN32 status and found out, that it is very similar as some time ago - you still need Cygwin (at least bash) to use the tools like "configure", and you need to install a lot of additional packages in order to get the toolchain running. So, I think that two or three independent windows users should evaluate your approach, if it is easy enough to understand, especially when a certain tool doesn't work immediately. I won't give much more comments anymore to ensure that nobody is influenced by my own oppinion (which might be too conservative?). The result should be a clear picture, if people who have used MPASM (see http://www.ucapps.de/howto_tools_mpasm.html) for assembly based firmwares, or the current SDCC setup http://www.ucapps.de/mios_c.html) in the past, will be able to rebuild the source code of an application if it is completely handled by autotools with similar 1-2-3 instructions (install this, install that, push the button). Note that most users who have to (re-)build an application are not programmers, they maybe only want to configure their MIDIbox and create a new .hex file with hardware specific settings. Therefore it would be important that after a basic windows setup has been found out, some additional users without programming knowledge try to rebuilt a .hex by themself based on instructions. Note: if the concept works, then an "all-incusive installation package" could be created. Best Regards, Thorsten.

Ok, I will check it this evening and give you feedback. I haven't expected that the development still continues, I did the evaluations ca. 2 years ago, and only found unix ports with flaws... Problem is, that most of my own assembly programs can only be assembled with MPASM due to the more powerful macro pre-processor. Some time ago I wanted to switch all my programs to a GPASM friendly format without these macros (could be automated easily) but I felt handicaped while programming without my beloved IFSET and IFCLR macros. And there are more complex macros, e.g. in the MBSID firmware, which cannot be replaced on an automated way, and where the code looks really ugly if you try to transform them into multiple lines... A solution would be to extend the GPASM macro processor, but after I looked into the source code I noticed that this won't be an easy task (at least for me) However, the SDCC wrapper on the other hand cannot be used with MPASM. All C based, and some of my newer small applications (like the MBHP_IIC_* and MBHP_USB_PIC firmwares) are completely GPASM compatible. For people who are not writing so much in assembler, or who are not used to work with complex macros, don't have any disadvantages here though... You can start a poll, but I think the result is clear: there will only be one person who prefers to work with MPASM, and thats me ;-) Best Regards, Thorsten.

This approach won't work. The PIC17 is a very different chip, it especially has only an OTP (one-time programmable) memory instead of flash. Therefore it will be dangerous to program it with a cheap PIC burner, if this has never been tested before. With bad luck you will quickly loose two or three PICs and a lot of money. In addition, the MIOS bootloader is located at a special memory range which is probably overlapped by the firmware. And it would require a special adaption for the PIC17 derivative... Unfortunately my PICstart kit (which can burn PIC17 chips) doesn't work on my PC anymore due to a missing COM port, otherwise I would be able to help you Best Regards, Thorsten.