TK.

yes Best Regards, Thorsten.

because I had some spare Sub-Ds and no other use for them anymore ;-) Best Regards, Thorsten.

I've added a new .hex file to the http://www.ucapps.de/howto_debug_midi.html page which provides a simple software implemented loopback test. Could you please try this out? Best Regards, Thorsten.

Hoert sich eher nach relaxten Bedingungen an, ein Motorfader erreicht normalerweise nach wenigen 100 Millisekunden die Endposition - wenn ich mich richtig erinnere, dauert es bei meinem Fadern so ca. 0.2 sekunden. Bei den Potis dauert es wohl 5 mal so lange ;-) Ich habe vor einiger Zeit mal die Billig-Alps-Motorpots getestet, die es bei Pollin fuer 3 EUR gibt, die benoetigten ca. 3-5 Sekunden (auch hier weiss ich den genauen Wert nicht mehr) Gruss, Thorsten.

Hi Robin, in order to find out if this is a electrical, or a software problem, I would suggest an extension in the program which checks if two F0 are successivly sent. The best place for such a routine is the "USER_MIDI_NotifyTx" hook, which will be called by MIOS before a MIDI byte is sent out. Note that this is an interrupt routine, therefore you have to take some special things into account (see the explanations below). However, just try the following (search for the label in main.asm and replace it by:) ;; -------------------------------------------------------------------------- ;; This function is called by MIOS before the transfer of a MIDI byte. ;; It can be used to monitor the Tx activity or to do any other actions ;; (e.g. to switch a pin for multiplexed MIDI Outs) before the byte will ;; be sent. ;; Note that this is an interrupt service routine! Use FSR2 instead of FSR0 ;; and IRQ_TMPx instead of TMPx -- and make the routine as fast as possible! ;; Input: ;; o transmitted byte in WREG ;; -------------------------------------------------------------------------- USER_MIDI_NotifyTx ;; save received byte in IRQ_TMP1 movwf IRQ_TMP1 ;; don't continue if byte is != 0xf0 movlw 0xf0 IFNEQ IRQ_TMP1, ACCESS, rgoto USER_MIDI_NotifyTx_End ;; don't continue if last byte was not 0xf0 movf LAST_RECEIVED_BYTE, W IFNEQ IRQ_TMP1, ACCESS, rgoto USER_MIDI_NotifyTx_End ;; error regognized, set a debug pin (RD4 - CORE::J14) bsf LATD, 4 USER_MIDI_NotifyTx_End ;; save byte for next call of this routine and exit movff IRQ_TMP1, LAST_RECEIVED_BYTE return [/code] This will set pin RD4 to +5V if an error has been regognized. If this pin is always zero, even when your monitor shows two F0, then a cross-check is required (e.g. check for 0x00 instead of 0xf0) If this pin goes to +5V, then you know that there is really an electrical problem (or a problem with your PC MIDI interface...) Note that "LAST_RECEIVED_BYTE" has to be located to a free address in app_defines.inc, it should be below 0x80 Best Regards, Thorsten.

Update: the MBHP_USB_PIC development is currently "stalled" due to a possible EUSART issue that I found during the development, and which is not part of the errata (yet?). I've created a coding example which passes on the PIC18F452 (with the old UART) and which fails on the PIC18F4550 (with the new extented UART), and I've sent it to Microchip in the hope to get a statement and especially a software workaround. We will see. If a workaround is not possible (it happens sporadically when MIDI data is sent and received at the same time, random zeroes will be inserted into the outgoing stream), then it could mean that a lot of additional circuirity is required (e.g. an external UART peripheral), or that we just have to wait for the next silicon release. Best Regards, Thorsten.

Cannot believe that this bug does already exist in MPLAB :-/ Hint: don't assign the missing encoders to pin 0, but move the ENC_EOT to the last valid encoder entry instead. just to avoid any unexplainable side effects Best Regards, Thorsten.

Hi Sasa, ID 0x00 is ok in your case. I guess that you've found the different number (0x12) in the bootloader docs - this is only an example to point out where the device ID is located, just to give an orientation, and not a hint that this is a requirement to get anything working. as mentioned above the ID is not relevant, it's even better when you set it to 0x00 again so that you don't need to change the device ID of MIOS and the application. But it's strange that you read back ID 00 - I just tried this with IC-Prog and the JDM, I can read back the correct ID. Could you please clarify if you are still using a different programmer (not the JDM) and that you are still receiving different MIDI events (like Pitch Wheel) instead of the upload request message? In this case I would say that IC Prog has a bug and can neither write nor read back the ID field properly with your programmer. In this case I could also create a .hex which solves the problem If this is not the case anymore, if you are not receiving any MIDI event anymore, then I could tell you more debugging hints. But you have to hurry up with your answers, because I will have some holidays soon Best Regards, Thorsten.

Yes, the output is currently very zippering, and yes, the SHX8 will help :) The reason why there is no progress yet is not, that I'm having problems where I have no idea how to solve them, it's just because of the missing time to get more experiences, to improve the circuit and to write a documentation Best Regards, Thorsten.

Hi, is there anybody (beside of me) who got the burner working with all PICs? ;-) The :04 entry defines an address extension. This information is not part of the memory image, and therefore cannot be read back from the PIC - ignore this The :0E... entry contains the PIC configuration. So, it seems that the code has been programmed correctly, only the configuration sector is wrong. The same line of the read-back .hex should help to find out what is wrong If you've luck, the PIC will already boot properly. Best Regards, Thorsten.

Hi Luzifer, it seems that the device ID is 0x70, however, there is an easy way to fix this. Just load the mios_v1_7.hex into Serge's SysEx loader, set the ID to 0x70 and upload the file Thereafter upload the change_id application, it will overwrite the ID field with zeroes Best Regards, Thorsten.

yes... Best Regards, Thorsten.

Hi Robin, there is new hope: during my USB experiments I noticed a similar effect The reason was the "Low Level Input Buffer" setting of MIDI-Ox (View->SysEx, SysEx->Configure), which was not large enough for long data bulks. Try 32768, this should work better Best Regards, Thorsten.

Hi Davo, you've listed single channel DACs, the MAX525 provides 4 channels at once, this makes the chip so special. The Low-Cost AOUT module is just a design idea and will be provided "as is", everbody is free to use different DACs. The reason why I want to use resistors instead of ICs is to avoid the endless discussions about the "best DAC", which you will possibly get today from your favourite distributor, but which vanishes from the list tomorrow... Best Regards, Thorsten.

Hi Then, I'm using the P18 programming software with a selfbuilt programmer, more infos can be found here: http://www.ucapps.de/mbhp_burner.html Microchip provides a free USB bootloader which works very fast & stable, I will post some details about the "installation" on the http://www.ucapps.de/mbhp_usb_pic.html page soon :) Best Regards, Thorsten.

Hallo, zu den Rotary-Pots kann ich nichts sagen, im Datenblatt kann ich nirgendwo das Wort "sauschnell" entdecken ;-) V-Fader: wie ich bereits erwaehnte, benoetigt man hier ein voellig anderes Ansteuerungskonzept - ich kann jedoch keins aus dem Hut zaubern, hier sind Motor-Experten mit jahrelanger Erfahrung gefragt. Gruss, Thorsten.

Hallo Roger, nein, das alleine hilft beim Coreless Motor nicht weiter, man muss die PWM Spannung ueber ein internes Peripheral erzeugen, um die Aufloesung zu erhoehen. Das Ansteuerungskonzept ist anders Gruss, Thorsten.

Sasa, My answer to your initial question: > How can I know do I burned MIOS and application in a PIC you could merge the .hex files with a text editor, but it wouldn't really help - because it won't fix the root cause, the MIDI Out still wouldn't send proper MIDI messages. However, from my experience the standard question "which tests are working" mostly leads to the inputs for which I'm searching - so, here a possible reason: you wrote that you've used a new programmer. Could it be that the programming software doesn't allow you to modify the device ID? Could it be that the device ID is ffffffff, so that the to-COM option is enabled (-> wrong baudrate). This would make sense, because you've noticed that some, but not the correct, MIDI data is sent. The solution for this programming software problem can be found here: http://69.56.171.55/~midibox/forum/index.php?topic=982.0 Best Regards, Thorsten.

Here some nice pictures of the MBSEQ V2 made by Albert:

Hi Sasa, there isn't a complete hex available, and it wouldn't really help you if the MIDI port is not working. Did you follow all steps of the MIDI troubleshooting guide? -> http://www.ucapps.de/howto_debug_midi.html Which tests are working, which not? Best Regards, Thorsten.

Hi Twin-X, seems that no measuring is done, from the general account information page: "Bandwidth usage (current month) 0.00 Megabytes" The web stats are also empty Best Regards, Thorsten.

Hallo, bisher wurden hauptsaechlich die auf der mbhp_mf Seite aufgefuehrten Panasonic und Alps Typen betrieben, fuer alle anderen Typen kann ich nichts garantieren (vielleicht sollte ich das auf der Seite nochmal verdeutlichen). Gruss, Thorsten.

Hi Robin, no, this is not what I saying. I assumed that sending a single F0 was your intention. Forget this about FE (don't feel confused ;-) It must be an error somewhere in your program, thats all what I can say Best Regards, Thorsten.

It's built, but requires some improvements Best Regards, Thorsten.

http://www.tweakheadz.com/vintage_sequencers.html http://tamw.atari-users.net/s16.htm http://tamw.atari-users.net/quad.htm http://tamw.atari-users.net/timidi.htm Best Regards, Thorsten.