TK.

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.

Hi Pascal, ok, I guess that I've also found the reason for this problem: MIOS_GLCD_TMP1 is used by the IIC driver as temporary counter and it is also used by app_lcd.inc as temporary buffer. Means: the counter function overwrites the buffer. Shit happens - never use registers w/ different routines... :-/ Workaround: replace USER_LCD_PrintChar by following function: USER_LCD_PrintChar ;; temporary save character in MIOS_GLCD_TMP3 SET_BSR MIOS_GLCD_TMP3 movwf MIOS_GLCD_TMP3, BANKED IRQ_DISABLE ; interrupts have to be disabled during IIC transfer call MIOS_IIC_Start ; start IIC movlw USER_LCD_IIC_DEVICE_ADDRESS ; send device address call MIOS_IIC_ByteSend SET_BSR MIOS_GLCD_TMP3 movf MIOS_GLCD_TMP3, W, BANKED ; send character call MIOS_IIC_ByteSend call MIOS_IIC_Stop ; stop IIC IRQ_ENABLE ; enable interrupts return

Hi Phil, you've enough time to scan all switches in the USER_SR_Service_Finish hook - for comparison: this hook is also used by MIOS to handle with up to 64 rotary encoders, it takes 400 uS in worst case and loads the CPU by 40% (since the hook is called every milisecond) RC0-3 can be controlled by the ISR. They are also controlled by the AIN driver, but only when the multiplexers are enabled J14 is controlled by the SRIO driver, by setting bit "TRISD, 4" you can use it as input pin w/o conflicts. Best Regards, Thorsten.

No, the PIC18F isn't code compatible to the PIC16F... however, the bootloader provides all the functions which are necessary to test the MIDI IO: it sends a SysEx string after power-on (MIDI-Out test) and it reacts on incoming upload requests (MIDI-In test) Best Regards, Thorsten.

Hi Pascal, yes, I've a clue :) I've implemented an IIC slave with the PIC16F877 today (*) in order to test the master function and noticed that the clock stretching feature of the IIC bus is more important than expected - a temporary version is now available here: http://www.ucapps.de/tmp/mios_v1_3b2.syx.zip The clock stretching routine doesn't come with a timeout mechanism yet, this means: if the slave doesn't react or if you unplug an IIC device, MIOS could reboot after 2 seconds. This will be fixed in the final version. The final version will also allow to disable the clock stretching for fastest transfer to the BankStick. Important: w/ the clock stretching function you have to add a 1k pull-up resistor to the SCL line! (*) some words to the PIC16F slave: Richard suggested the support of IIC a while ago in order to allow a simple adaption of hardware extensions. I plan to publish the PIC16F based IIC/MIDI skeleton under GPL to give you the basics. The DMX extension could be realized in this way - the example already provides a buffered MIDI In/Out accessible via the IIC bus. In other words: the example can be used as MIDI IO extension for MIOS, more than 100 MIDI IO ports could be controlled from a single MIOS core ;-) Best Regards, Thorsten.

you could use the RxTx test: http://www.ucapps.de/howtodebug/test_rxtx.hex.zip it just forwards incoming events to the MIDI Out Best Regards, Thorsten.

No, with these inputs (sometimes working, sometimes not) it's impossible to give usefull tips into the right direction. First try to find the root cause why your hardware is so unstable - check the solderings, cables, etc... and use the verify function of IC-Prog to ensure that the firmware has been burned correctly into the PIC. Best Regards, Thorsten.

Yes, Logic occupies the port, but you could create an external "virtual" connection by using MIDI-Ox in combination with MIDI Yoke to duplicate the MIDI events. MIDI-Ox allows also to apply an additional filter so that only events generated by the GPC mode are forwarded to the MIDI Yoke port. Best Regards, Thorsten.

Just use the search function of this forum: Search for: vic20 Max Age since last post: 300 Search Best Regards, Thorsten.

Since the required upload procedure wasn't clear to some people, here a diagram which can be found at the Bootloader page now: Best Regards, Thorsten.

Does the tx test send other events than SysEx data? -> you've activated the SysEx filter in MIDI-Ox Did you check the pinning of the MIDI socket? -> exchanged cables Did you check the output signals with a LED? http://www.ucapps.de/howtodebug/midi_out_led.gif NOTE: this simple LED circuit helps to indicate the outgoing signal, but it consumes some power - you have to disconnect the LED before connecting the MIDI Out of your MIDIbox with the MIDI In of your PC! Best Regards, Thorsten.

The LC handling itself already has been implemented, the bars are visible on the screen. The firmware also allows to switch the LEDrings between "normal" and "metering" mode. The only feature which is missing is the possibility to use LEDrings and meters in parallel with a single core - and this will be implemented as soon as I've enhanced my own hardware (so that I can test the code). --- the same for external MTC digits. Best Regards, Thorsten.

Hallo, die ICs solltest Du lieber nicht direkt auf die Platine loeten - dafuer sind die IC-Sockel vorgesehen. Vorteil: so vermeidest Du eine Ueberhitzung des Bausteins und kannst ihn spaeter problemlos auswechseln, falls er mal kaputt gehen sollte (*), bzw. speziell PIC: um die Firmware zu aktualisieren. Das LCD wird ueber ein Flachbandkabel angeschlossen. Das Reichelt-LCD hat einen gruenen Hintergrund. Gruss, Thorsten. (*) die ICs die hier verwendet werden sind extrem robust und nahezu unkaputtbar, aber man weiss ja nie...

Hi Thomas, Unfortunately Microchip has changed the project file format, the old files are not compatible - you have to create a new project and add the main.asm file (nothing else) - thats all. Best Regards, Thorsten.

The configuration will be described after this feature has been implemented... ;-) Best Regards, Thorsten.

...just a question: did you upload MIOS itself? This has to be done once before uploading any application. Best Regards, Thorsten.

You don't need to bypass the bootloader, it's working. You are receiving 0F messages, this means that the checksums are correct and the code has been uploaded successfully. So the root cause for the failure must be related to any (currently unknown) MIOS problem or to a misconfigured hardware. Did you equip the whole core module - especially the required pull-up resistors? Best Regards, Thorsten.

I just got following input from a MIDIbox user. Before this change Reichelt billed 30 Euro and more for shipping to foreign countries... Best Regards, Thorsten.

It could take some days, however, I just have extended the mios_vectors.inc table by the already available IIC functions and I wrote a small example based on the Matrix Orbital specs (which are hopefully correct) First upload this interim MIOS release: http://www.ucapps.de/tmp/mios_v1_3b.syx.zip Thereafter the IIC example: http://www.ucapps.de/mios/custom_lcd_iic_v1.zip If it doesn't work with your display, you possibly have to change the control codes (or just the device address) in app_lcd.inc If this app is running (you should see a "Hello World" on the screen), you can add the driver to existing applications by copying "mios_vectors.inc" and "app_lcd.inc" into the appr. directory and by reassembling the code. You also have to add the MIOS_LCD_TypeSet function to the init code, alternatively you could burn the bootloader again with an adapted ID field. Btw.: The IIC functions could also be used to communicate with other PICs or peripheral chips - Remark: MIOS itself doesn't support the IIC slave functions since the appr. pins are allocated Best Regards, Thorsten.