TK.

Concerning the usability evaluation: I would propose a two-step approach: first ask two or three programmers of User Projects to migrate their source code, thereafter ask common users (in the MIDIbox news section) to rebuild the applications (it isn't required to own the appr. hardware) Goal of the evaluation should be to find out, how much support people need to install and troubleshoot the toolchain, and how long it does take to get the setup ready for rebuilding an application. Please highlight in the announcements, that we are not searching for hackers who are already familar with Unix environments. As it was your idea to go for such an approach, you have to lead this evaluation pro-active. Best Regards, Thorsten.

The MIOS_LCD_PrintCString function of the updated MIOS wrapper is now able to handle strings located in code and RAM So, a special function is not required anymore. :) Best Regards, Thorsten.

There is a new skeleton release available in the http://www.ucapps.de/mios_download.html section . Changes: - enhancement of MIOS_LCD_PrintCString: now it can also print strings which are located in RAM The appr. function in mios_wrapper.asm and the declaration in cmios.h has been changed ("code" attribute removed) - updated latest MIOS header files - mkmk.pl enhancements (based on discussions with Ditier): source code can be located in subdirectories, and libraries can be created SDCC compatibility: I've tested my own applications with 2.7.0, and they are working fine. Therefore I recomment the usage of this SDCC release instead of 2.5.0 (reminder: 2.6.0 was too buggy) Migration: Since there are no bugfixes, a migration of your application is only required if you want to use the new features. However, due to consistency reasons it makes sense to release application updates with the new wrapper in future. Following steps are required: 1) copy the files of the tool directory into the tool directory of your application 2) copy the files of the mios_wrapper directory into the mios_wrapper directory of your application. Beware: unfortunately mios_tables.inc is still located there (could change in future) - don't overwrite this file, or make a backup and copy over your customized version 3) copy the new cmios.h into your application directory If you've added libsdcc.lib to your project, and want to use SDCC 2.7.0 in future, please update this library as well. A precompiled version is available at http://www.ucapps.de/mios/mios_libsdcc_v2_7_0.zip Creating a library Nice usecase for the new mkmk.pl feature is libsdcc, which has to be rebuilt for MIOS due to the changed FSR pointer mapping. Have a look into the README.txt and MAKEFILE.SPEC file of the library package mentioned above. Best Regards, Thorsten.

Hi Ciaran, before uploading the MIDIO128 configuration file, you have to install the MIDIO128 application - you will find the package at the MIOS upload page. It seems that this approach (installing MIOS -> MIDIO128 -> configuration) isn't so obvious, therefore I will add this info to the MIDIO128 introduction page soon Best Regards, Thorsten.

Hi Didier, Yes, thats the drawback when complete source packages are released. On the other hand I can give users simple instructions how to update the MIOS wrapper. They only need to know, how to copy files from one into another directory. E.g., each MIOS release contains a migration/ directory with files which can be copied over the original files of a release package. By concept they are always downward compatible. In your approach, the user has to install a new MIOS library package. Thats similar, it has some other advantages, but also disadvantages (risk that some additional files or code libraries are released, which are not compatible with the application - bad if the user faces such issues again before the maintainer has tested a new library release with his hardware), but I think that we don't need to discuss this again - it would really be endless ;-) The next processor family used in MBHP is probably a 32bit microcontroller, either ARM or TriCore based. Regardless of which device is finally used, the code base has to be completely overworked. Re-use of existing files won't be possible - the trouble starts already with SDCC incompatibilities to gcc (e.g. structures, word alignments), assembly code, but also general conceptional topics. E.g., for a future OS I would like to include sophisticated interrupt handling, and multitasking capabilities (or I could be on a free OS like FREERTOS, or maybe Linux?). The programming style will be totally different (and hopefully easier) Accordingly it would be required to setup a new software platform - with a totally different structure. It wouldn't make much sense anymore to provide MIOS as a single kernel, also the bootloader wouldn't exist anymore (MIDI is too slow to transfer huge memory dumps). The whole firmware would be uploaded on a single run, probably via JTAG. The point is: for such a platform change I would prefer the usage of an existing toolchain, maybe even on an existing IDE for people, who want to spend some money for powerful debugging tools (and you really need such tools once you are starting to work with foreign sources). It could be structured totally different from yours. E.g., I evaluated HiTOP in the past, it generates Unix compatible Makefiles and uses Cygwin in background under Windows which will please you (as it means: the source code origanisation and build process is Unix compatible) But this just as an example - it could also look totally different in some years (once I'm doing the platform change...) depending on what is available at this time. If a powerful non-commercial toolchain is available until then, I would prefer such a solution instead of a (low-cost) commercial environment of course! So, you know the requirements: generating a simple DOS batch file - this is not possible with autoconf, but it's also obsolete as you can completely work with Unix tools once Cygwin has been installed. Your argument is, that it's easy for Windows people to install the additionally required tools. My argument is, that it will increase the complexity too much, including the installation of more files on the computer (can take a long time if somebody only has only a low-bandwith connection to internet (modem)), and learning how to use the bash shell instead of doubleclicking a .bat file But before discussing in circles again: some Windows guys - not only programmers, but especially "common users" - should try out your approach and report their experiences. Not really ;-) Nice gimmick, but nobody would try to build a dedicated PIC18F4685 application for PIC18F452 - and if he doing this, he will notice very quickly that some SFRs are not available during build time. The presence of headers doesn't need to be checked if all sources are part of a release package (and the maintainer ensured, that a rebuilt is possible), and preprocessor symbols can currently be easily included from the MAKEFILE.SPEC (-D...) Some C compiler features were unstable in the past (see bug tracking), it's dangerous to allow such a flexibility - you will notice this once you are debugging code anomalies like I did in the past. same can be defined in MAKEFILE.SPEC The release package which contains all sources is per concept ready for distribution (ok, "make clean" before zipping it makes sense) ...so far somebody writes documentation... Moving the platform into a direction which makes it only understandable for an elitary circle of Unix geeks? Maybe I see it too much black-white, I would like to hear the oppinions of other programmers and especially users - if they still follow this thread ;-) Best Regards, Thorsten. P.S.: I did the changes in the makefile generator this morning, and going to do some compatibility checks with SDCC 2.7.0, which I was planning for a long time... seems that the imperfections of 2.6.0 have been fixed! :)

Hi Didier, Nobody asked for library releases yet... Some of the modules could be put into a library, some others not since they are using constant definitions to customize the code. I don't like different approaches for different usecases. In addition, I would prefer that all source files which are required to rebuild an application are part of the release package. Therfore a good starting point would be a wiki page which collects all code modules, that are already available (there are a lot, but most of them are not so nicely documented like your CAN library). MIOS: was always downward compatible in the past, you can still run applications which have been programmed and compiled for earlier versions with the latest MIOS version Processor: within the PIC18F family, there are not so many processors which are qualified for MIOS due to available peripheral functions and packages. All of these processors are compatible to PIC18F452, only the available memory differs. Ok, there is one exception: the PIC18F4685 (and similar CAN derivatives) has a memory window between 0x60..0x7f which is not directly accesible. But if somebody wants to use a PIC18F452 application on a PIC18F4685, he only has to change a single line in the default linker script. This is a question of how good such a change is documented. Such a manual change would even be required in your approach, if a local linker file has been used in the project (e.g. for larger arrays) Or did I overlook something? Why haven't you just asked me for an extension in the makefile generator instead of setting up a new flow which will cause additional efforts at other sides? I will add this possibility to the next skeleton release. Here again: why haven't you just asked me to add such a feature? It doesn't take much time for me to add such a function, especially if I find it useful as well - it will be primitive, but I can ensure that it will work sufficient enough for Unix and DOS. Please also accept that I'm trying to keep things simple enough. There are flaws in your concept, and they can only be solved by adding even more complexity (tools and configuration options). Partly these are issues which went into my own decitions in the past, and which lead to the setup as it is. I fear that your proposals complicate the whole flow too much for a project, which is mainly intended for people who like to make music, and who mostly don't have the technical background like IT guys. I'm disappointed that your contributions will only be released for your own approach, but I guess that this shouldn't prevent others to try the same, time will show if it works successfull. What I take from this debate: - there is the need to define (sub)directories in the mkmk.pl script - it should be possible to generate a Makefile for a library - consider to provide the wrapper as a precompiled library (*) - there is still no page which collects all code module contributions (*) here I could profit from your work: did you already found a way to define the stack pointers outside the library? Concerning the two tables in mios_tables.inc: I noticed that you defined them in the main.c file - I would prefer following approach: put a mios_mproc_event_table.o and mios_enc_pin_table.o file into the library. These objects should contain the default table content. Then add "extern" references to these tables into cmios.h This opens following possibilities: the tables will be preloaded correctly with default entries, taken from the library, whenever there is no .o file with *the same name* in the local scope during linking. Accordingly, the programmer is able customize the tables within his project by copying the .asm file(s) from the library source directory into his own project, doing the required modifications and compiling them locally. Best Regards, Thorsten.

Some users of MBHP_USB and MBHP_USB_PIC interface have reported this issue in the past - it is related to the definition of the AC (Audio Control) interface. It seems, that this causes a problem with some Windows installations. I haven't started some more investigations, but just provide an alternative firmware without the AC definitions (see http://www.ucapps.de/tmp/mbhp_usb_pic_snapshot.zip, usbdsc.c) Note that my descriptors could be slightly different from the ones used in the MIDINator firmware (I haven't compared them) Yes, absolutely. Could you please try if my own PIC based implementation works better with your host? Note that it requires the USB bootloader, which is provided by Microchip (it simplifies the firmware upload). Therefore my firmware begins at 0x800. Beside of try&error: not really. :-/ Best Regards, Thorsten.

thats correct. yes, no problem. The two gates of the AOUT module are only useful if somebody has built this module into a breakout box (so that the module can be plugged to different MIDIboxes) - and if he doesn't need more than 2 gates. AOUT_LC and AOUT_NG users have to use the 8 gate pins at J5 anyhow. Best Regards, Thorsten.

Hi, the loopback test is a special firmware which cannot be uploaded via MIDI, it replaces the bootloader and therefore is only useful for somebody who owns a PIC burner. However, although the bootloader refuses to upload this firmware... the messages are looking good! The block between 0x3000..0x30ff (the only one outside bootloader range) has been uploaded successfully. This means, that the bidirectional connection is working. Before uploading MIDIO128, you have to upload MIOS v1.9f (can be found in the mios_v1_9f_update package within the pic18f452/midi directory) Best Regards, Thorsten.

After MPLAB has been installed, you will find the "MPASMWIN" application in the installation tree which allows you to build a .hex file without using the IDE. So, just edit the files of the midibox release package with your favourite text editor (don't rename the files), and assemble the code like described here: http://www.ucapps.de/howto_tools_mpasm.html. For MIDIbox64 it means: assemble main.asm - it's always this toplevel file, it includes all the .inc files. Thereafter upload the new main.hex file with MIOS Studio. The .ini file (probably you mean the one of the mk_syx package) is part of the bank configuration. It can be changed and converted to a .syx, thereafter uploaded to the MIDIbox64 during runtime. However, this is part of the "configuration layer" - the firmware has to run for beeing able to receive this configuration data. Best Regards, Thorsten. P.S.: ah yes - happy new year! :)

Hi Didier, I don't take this as offence, and hope that you don't take it personally when I'm saying, that I still have the impression that you are trying to apply methods evolved in computer world to the embedded world, regardless of the facts that PIC microcontrollers have very limited resources which don't allow to use all those nice programming techniques like soft-configuration, sophisticated APIs, complete modularity, etc... Of course, in small embedded applications your suggested approach will work in it's whole beauty, but once resources should be shared between complex applications created by different people, it won't work anymore, or you will loose so much performance that general programming rules have to be violated again and again (and exceptions make it even more worse). I want to highlight: I'm speaking about projects for 8bit controllers. It's almost the same for 16bit controllers, it has changed for 32bit controllers due to enhanced instruction sets which support C and C++ programming, and the huge amount of memory. I for myself use a totally different programming style on 32bit controllers, which goes into the direction you are suggesting here. Based on my experiences you cannot reach the same performance on 8/16bit controllers with a full modular approach (where sources are completely statically released in libraries) In addition, your approach can only work when program sources are released in a version management system. @Work I'm using Clearcase to share sources with other team members, in open source projects CVS is prefered. Such a system is at least required to make changes smooth, e.g. giving somebody the possibility to incorporate library changes made by other people, and to label/tag a working version. It also gives the possibility for users, to get a released version view with "known working" modules which have been tested by the maintainer (what I called "qualified" release before) I think that it isn't required to give a comment on all your statements. Many of them are true and I know them from other parties as well, I even apply them by myself in other projects. Some others are realstic for MIOS projects, they just don't exist because nobody have implemented them yet. Some others are over-engineered, or just go into the wrong direction, which you will probably notice two or three years later once you made your own experiences with 8bit programming, and especially with the people who are programming! I will give you three examples and I would like to know how you would handle them: 1) http://www.ucapps.de/mios/midibox_lc_v2_0_alpha1.zip: how would you implement the "hard-options" in main.h in a configuration layer without consuming more memory than available on a PIC18F452? Note that the same source code is used to create a .hex for MIDIbox LC and MIDIbox SEQ - two totally different hardware variants, therefore so many #define statements are used. 2) http://www.ucapps.de/mios/midibox64e_v2_2.zip: similar question: how would you handle all the options in setup_*.asm for all the different variations without loosing too much memory? And how much programming effort do you estimate for an additional configuration layer (and tools which handle the configuration) compared by using simple #define statements? Who should maintain the configuration tool? How should the configuration layer be structured, so that it's flexible enough for future expansions? Where should configuration data be stored? In RAM, internal Flash or external EEPROM? (Sidenote: we already had this situation in PIC16F projects - a single firmware and a configuration tool called "vmidibox64" - using #define's was the next step, learned from the limitations and additional efforts of this approach) 3) http://www.ucapps.de/mios/midi_router_v1_1.zip: how would the configuration layer for router.c look like without loosing flexibility. And how would you make a library element of iic_midi.asm without static pin assignments PORT_RI_N_SLAVE_* (again: without loosing too much performance) Best Regards, Thorsten.

...but I think that a workaround is possible. Some SID players don't send the "start" command, which would clear the lower line. I could also clear the line whenever the "LCD" command is sent, under the assumption that this is only done once per song Best Regards, Thorsten.

Hi Karl, yes correct, it's a parameter of the generic MIDI_EVNT_Send routine, which is located in midi_evnt.inc (see the comments there) the configuration data is part of a SysEx stream, and within such a stream it isn't allowed to use values >= 0x80. Therefore I proposed 0x01 (or any other value which you don't use in your configuration). Alternatively you could use meta events - thats a proper solution, but it requires better programming skills. Best Regards, Thorsten.

It's probably a bug in your SID file player Best Regards, Thorsten.

Ha!!! :) FAQMARKER (damit ich den Artikel einfacher wiederfinde) Gruss, Thorsten.

Hi Karl, here is a quick&dirty solution: just overwrite the velocity with the 7bit value of the analog input whenever a MIDI event is sent. In order to differ between "foot controlled", and "hardcoded" velocity, you could use an unused value (like 0x01) to differ between the two modes. Events are sent from the MIDIO_MIDI_SendDINEvent function in midio_midi.inc, it has to be changed the following way: ;; -------------------------------------------------------------------------- ;; This function sends a DIN event ;; Input: number of DIN in MIDIO_CURRENT_DIN ;; -------------------------------------------------------------------------- MIDIO_MIDI_SendDINEvent rcall MIDIO_MIDI_PrepareDINEvent ;; check for velcocity == 1 movf MIDI_EVNT_VALUE, W xorlw 0x01 bnz MIDIO_MIDI_SendDINEvent_NoPot MIDIO_MIDI_SendDINEvent_Pot ;; get current 7bit value of first pot movlw 0 call MIOS_AIN_Pin7bitGet ;; and copy it into MIDI_EVNT_VALUE movwf MIDI_EVNT_VALUE MIDIO_MIDI_SendDINEvent_NoPot ;; if meta event: branch to meta handler, else to MIDI sender movf MIDI_EVNT0, W andlw 0xf0 xorlw 0xf0 skpnz goto MIDIO_META_Handler_DIN goto MIDI_EVNT_Send [/code] Now you only need to enable the AIN handler in USER_Init (-> main.asm) Just add following code below the USER_Init label: [code] USER_Init ;; initialize the AIN driver movlw 1 ; pot call MIOS_AIN_NumberSet call MIOS_AIN_UnMuxed movlw 7 ; +/- 7 is recommented for 7bit values call MIOS_AIN_DeadbandSet Best Regards, Thorsten.

This topic has been moved to MIDIbox of the Week. [iurl]http://www.midibox.org/forum/index.php?topic=10426.0[/iurl]

Great result! :) Best Regards, Thorsten.

I've added the code, it's available in RC15 Unfortunately I had no possibility to check all the new functions with analog synths yet (vacation time...), however the waveforms are looking good on the scope. Channel assignments for K2A and/or O2A + the gates have to be done in setup_*.asm, please read the comments In addition, the appr. function has to be activated in the ENS->EXT menu to get it working If you find the configuration too complicated, just let me know about your usecase. Example Configuration: two analog synth modules should act as two basslines. They don't offer a special glide input, therefore the O2A function is used for a digital glide/slide/portamento function. In addition to the frequency, Filter CutOff, Resonance and Pulsewidth should be modulated from MBSID Recommented Configuration: [tt] #define DEFAULT_J5_FUNCTION 3 #define ENABLE_AOUT <number of your AOUT module: AOUT=1, AOUT_LC=2, AOUT_NG=3> #define DEFAULT_F2A_CUTOFF_L_AOUT 1 #define DEFAULT_F2A_RESONANCE_L_AOUT 2 #define DEFAULT_F2A_CUTOFF_R_AOUT 3 #define DEFAULT_F2A_RESONANCE_R_AOUT 4 #define DEFAULT_P2A_OSC1_L_AOUT 5 #define DEFAULT_P2A_OSC1_R_AOUT 6 #define DEFAULT_O2A_OSC1_L_AOUT 7 #define DEFAULT_O2A_OSC1_R_AOUT 8 #define DEFAULT_GATE_OSC1_L_OUT 1 #define DEFAULT_GATE_OSC1_R_OUT 2 [/tt] Ensure that all other assignments are decactivated (= 0) After the firmware has been uploaded, go into the ENS->EXT menu, and activate F2A, P2A and O2A Adapt the Min/Max range of the filters in ENS->FIL Thereafter store the ensemble Best Regards, Thorsten.

RC15 is now available, from the ChangeLog: o improved FIP function (linear interpolation of filter cutoff) - it is working now the same way as implemented in MIDIbox CV o F2A and V2A flags moved to new storage position in ensemble - old ensemble setups (where F2A and/or V2A was set) have to be adapted! o added new AOUT forwarding functions: - P2A (Pulsewidth-to-AOUT) - K2A (Key-to-AOUT) - O2A (Oscillator Frequency-to-AOUT) Channel assignments have to be adapted in setup_*.asm - all channels are disabled by default o added functions to forward the 6 gates/slide/accent signals to the digital outputs at J5. Assignments have to be configured in the setup_*.asm file. Note that DEFAULT_J5_FUNCTION has to be set to 3 in order to enable the digital output function of CORE:J5 [/code] Best Regards, Thorsten.

This seems to be an error in the PCB silkscreening, the labels which can be found in the original schematics are still valid, and it doesn't make sense to change them. Best Regards, Thorsten.

Why should I repeat something what I did 20 years ago? -> http://utenti.lycos.it/ice00/HVMEC/CONTROL/Tracker/Soundwriter/v2.0/index.html However, PCM playback has ultra-low priority - just for the case that I feel boring ;-) Best Regards, Thorsten.

Good input! I suggested this MIDI interface multiple times in the past, good to know that it works reliable :) Best Regards, Thorsten.

(contacted via email) Best Regards, Thorsten.

Just remove the "#if/#endif" below the USER_ENC_NotifyChange label in main.asm, remove it in mios_tables.inc as well and adapt the encoder entry Best Regards, Thorsten.