TK.

I also burned a lot of PIC18F452 without this pull-down, but it seems that newer batches from the Microchip fab require it (there is nothing worst in logic design than floating input pins - maybe Microchip adjusted the process parameters and as a result the probability that this pin tends to logic-0 isn't so high anymore). However, you don't have to burn the firmware again, this pin is only important to select the correct programming mode on a "virgin" or erased flash. Once the configuration data has been uploaded, the LVP flag is disabled and you don't have to take care about it anymore. Best Regards, Thorsten.

Are you sure that this isn't a bug in the kx driver? You can test it in the following way: create a "physical" loopback with a MIDI cable (direct connection from MIDI Out to MIDI In), open the SysEx tool of MIDI-Ox, load the .syx file and start Send/Receive SysEx. If the number of received bytes doesn't match with the number of transmitted bytes, you've a problem... Best Regards, Thorsten.

Two additional links (helpful hardware modifications): External power supply: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=concepts;action=display;num=1061677417 Required pulldown resistor for PIC18F452 http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=concepts;action=display;num=1061750589

FYI: In the meantime two users who were not able to program a PIC18F452 before reported that this fix was the solution. They didn't need an external power supply. So please don't forget to add the resistor if you want to burn a PIC18F Best Regards, Thorsten.

I guess that the download fails due to a feedback loop: Best Regards, Thorsten.

Alright, this is something really different. IC-Prog searches for a device ID (like PIC18F452) in the .hex file, but MPASM doesn't write out this ID. You can disable this warning under Settings->Options->Notification: disable "ID word is missing in file" Best Regards, Thorsten.

This would be a job for somebody with programming skills who uses the same hardware. The implementation isn't so difficult. Best Regards, Thorsten.

you have my permission. Best Regards, Thorsten.

Hallo Wolfgang, zunaechst einmal eine schlechte Nachricht: C wird derzeit von MIOS nicht unterstuetzt, weil es noch keinen freien PIC18F compiler gibt (hoffen wir, dass sich jemand aus der gcc-Gemeinde dieses Thema annimmt). Einen Java compiler wird es mit Sicherheit nicht geben, weil der Resourcenverbrauch ungleich hoeher ist. Perl installieren, DOS-Shell oeffnen, in das Projekt-Verzeichnis gehen, "make" ausfuehren, das main.syx file via MIDI-Ox uploaden. Zu den Anforderungen fuer Deine Applikation: laesst sich alles problemlos realisieren Module: passt so Fragen: ja, die Leitungslaenge spielt bei den digitalen Eingaengen keine Rolle dito Das haengt davon ab, wie die Digits angesteuert werden. Leider gibt es hierzu noch kein Programmierbeispiel, aber lange kann es nicht mehr dauern, bis ich mich dazu aufraffe ;-) Auf der DOUT-Seite gibt es einen Schaltplan fuer das MTC-Display. Daraus sollte hervor gehen, wie die Digits anzuschliessen sind, und wieviele Pins benoetigt werden. Wichtig ist nur zu wissen, dass bis zu 4 DOUTX4 Module (-> 128 ausgaenge) hintereinander angeschlossen werden koennen Letztes Wochenende habe ich zufaellig ein Modul implementiert, das einer MIOS-Applikation einen zweiten MIDI I/O Port zur Verfuegung stellt. Der Datentransfer geschieht ueber das IIC Protokoll (hoert sich kompliziert an, ist aber relativ simpel zu bedienen). Das Modul arbeitet mit einem PIC16F874 und wird an CORE::J4 angeschlossen. Da der IIC Bus Multislave faehig ist, koennen sogar mehrere Module gleichzeitig betrieben werden. Ich werde das Modul mit der naechsten MIOS Version releasen. Gruss, Thorsten.

Hi Thomas, I will publish the source code of MIOS over an official channel (sourceforge.net) when I feel pleasant with the implementation... however, you don't need the source for debugging, and if any function or relation is unclear, please ask here so that I can documentate it. I'm planning to collect all the questions&answers for the programmers guide. Debugging - the simplest way: add a "org 0x00000" at the end of main.asm and call the function which should be simulated. Following example helps you to simulate a button event: org 0x00000 ;; (Input parameters: see documentation of the USER_DIN_NotifyToggle function) movlw 0x00 ;; 0 == button pressed movwf MIOS_PARAMETER2 movlw 7 ;; button #7 movwf MIOS_PARAMETER1 call USER_DIN_NotifyToggle EndlessLoop goto EndlessLoop END Since the Input/Output parameters of the hooks are clearly defined in the functions reference, it shouldn't be a problem to debug in this way. Framework for menu/cursor buttons: the most enhanced handler can be found in the SID application, the MIOS implementation of the old handler known from the PIC16F based firmware can be found here: http://www.ucapps.de/tmp/mb64seq_snapshot.zip Best Regards, Thorsten.

Hi Phil, ISR means Interrupt service routine - a function which interrupts your mainprogram and therefore require some special care (see function description of USER_SR_Service_Finish) Btw.: more detailed informations about dedicated registers for mainprograms/ISR, and about shared registers: Following registers are dedicated for mainprograms, they will not be automatically saved before an interrupt call: TMP1...TMP5 and FSR0 Following registers are dedicated for interrupt service routines, they shouldn't be used by mainprograms: IRQ_TMP1...IRQ_TMP5 and FSR2 Following registers are stored automatically by the interrupt handler before a hook will be called, and they will be restored before the interrupt will be finished - therefore they can be used by the mainprogram and by ISRs without conflicts: FSR1, TBLPTRL, TBLPTRH, TABLAT, MIOS_PARAMETER1...MIOS_PARAMETER3 Best Regards, Thorsten.

He wrote about a software specific configuration problem (MIOS bootstrap loader). Best Regards, Thorsten.

to people who were not able to burn a PIC18F452 yet: Best Regards, Thorsten.

Das Betriebssystem fehlt noch: Gruss, Thorsten.

Great! :) Regarding the SID application: it's out of memory, you have to remove the CC strings under CS_MENU_CC_TABLE (file: cs_menu_cc_table.inc) in order to free 2k of memory Simplest solution: write "#if 0" below the label and "#endif" at the end of the file Best Regards, Thorsten.

Hi Nickca, thanks for the detailed report! I'm sure that it will help others to understand the relation between the device ID and the .syx file. You've to take care about it so long as no tool is available which changes the ID on-the-fly during the upload. Best Regards, Thorsten.

The RCLK pulse is high for ca. 200 nS some cycles before the CS# will be activated Which timebase are you using? Maybe it's too short so that your scope doesn't trigger on this pulse? Check it also without the SID module - if the pulse is available thereafter, you've a short on your SID module... Another point which should be checked: how long are the cables between the core and the SID module? Does it work when you shorten it? Best Regards, Thorsten.

This mod improves the MCLR# voltage, use it if the output voltage of your COM port is not high enough. The checks are still the same. The results are "improved". The derivative doesn't matter here. Just try it with an external supply if your JDM doesn't work (with a certain PIC or with any PIC) Best Regards, Thorsten.

Currently I'm trying to solve all open issues before I start with new projects (which naturally produce new issues ;-)) Best Regards, Thorsten.

Last week I got a PIC16F877A which wasn't programmable with my own JDM, although I burned a lot of ..A chips with this programmer before. I noticed that the voltage at MCLR# was lower than on a "common" PIC16F877A. It didn't help to vary the software settings of IC-Prog like IO-Delay or Interface type of IC-Prog, so I finally tried to increase vpp by using an external PSU - with success! Maybe (or hopefully) this is the solution for everybody who wasn't able to burn a PIC (especially the new ...A and the PIC18F types) yet: use either two 9V batteries or a PSU which delivers at least 15V. A regulator isn't required, the zener diodes limit the voltage don't forget the 220 Ohm resistor - it limits the current and protects the circuit plug the PIC directly into the JDM module socket when you burn it the first time, because an erased PIC requires the pull-down resistor at pin RB3 which disables the low-voltage programming mode. Good luck! Best Regards, Thorsten.

Yes, step C includes also step A and B Best Regards, Thorsten.

RES# is low? This means that the SID is still in reset state - the shift registers never have been updated, so possibly you've a problem with the RC (register clock) line Best Regards, Thorsten.

Alright - this is not the SID, this is digital noise from the MIDI In port - possibly the optocoupler is still ok, the error must be between optocoupler and PIC. Just follow these instructions: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=troubleshooting;action=display;num=1055726526;start=1#1 especially check the polarity of the 6N138, the 1N4148 diode and the MIDI cable Best Regards, Thorsten.

could you please record the clicking sound? I guess that it doesn't come from the SID, but from your MIDI port, and the reason could be that the optocoupler isn't connected correctly. But I need an audible impression to realize what is going on there. Best Regards, Thorsten.

yes, the core is running, so it's time to debug the SID module. Whats about the 1 MHz clock? You are using a direct connection to the core module, do you see the signal on the scope? Is the 12V supply ok? ca. 5-7V DC at the Audio Out and Audio In are normal, only the AC waveform is for interest. Select the AC function of your scope and use a resolution of 500 mV/div, this should give you better measuring results Best Regards, Thorsten.