kpete

And your " u8 led_startstop = 14; " must be outside of any function. If it was inside a function then it can only be found and used by that function.

This is one of the problems with using a serial interface to the Dout boards that don't have a power ON reset circuit or pin to hold the shift registers off. Most latching IC;s will power up in a random state and this is what you see before the Midibox starts scanning the Dio chain. For lights its usually not a problem but if you are driving electromagnets it can be problematic and something to consider in your design. Bringing up the power in stages with 2 power supplies works fine too. Pete

Why not just buy the right board. They are cheep enough.

jjonas is right but doesn't give you enough information. It's been a long time that I have done this, but looking at the code this is what I see. In the mios_v1_9h.zip file are directories for each supported PIC. As you select your path, you will come to a "BURNER" directory. This is the one that must be programmed first. The hex file is something like "bootloader_v1_2b_pic18f4620.hex". It should contain all the CONFIG parameters needed to set the oscillator options in the PIC. After that you can then program the MIOS hex file for v1.9h which is in the "MIDI" directory and called something like "mios8_v1_9h_pic18f4620.hex". Note: programming this way gives and ID value of " #define PICID_DEVICE_ID 0x00 " If I am wrong, someone please respond. Pete

I don't know why your are so concerned about this 32us shift. I don't know why this is happening but 32us is 1 bit of the 30 bit (3 byte) Midi message which would take almost 1ms (0.96ms) for the entire message. A human can't tell the difference between 15ms from the time the key is pressed and the sound is generated. How do you expect a 32us delay to be a problem? What happens when you start using Midi over USB? The data might come faster as a buffered group but there is still a delay from the time the application starts sending it and the receiving device even sees it. It sounds like you are not using any of the Midibox software for your testing. Midibox uses a multi task operating system and I would think that if you tested it in this way it would not meet your expectations either. Respectfully Pete.

From the first post I was wondering if you were using one of those synths that would send a Midi All Notes Off message for the last note rather than just a note off message. Your last post answered that question eptheca.

Having pin 10 connected to +5v should not be a problem but removing it won't hurt either. This is normally connected to a +V and is used to snub the voltage spiks that occur when the outputs of the ULN2803 are connected to relays. Since the outputs are connected to LED's, it is not needed.

Looking at the SP0256 spec you sent, this is a 5v device just like the PIC core. The LRQ output can drive 2 LS-TTL loads with a ZERO voltage of 0.5v and a ONE voltage at 2.5 volts. The PIC running on a 5 volt power supply can input a ZERO for anything less than 0.8v and a ONE for anything over 2.0 volts. So you can directly connect any of the SP0256 outputs to the PIC inputs without any issues. No resistor necessary. When you are debugging your code I would remove the SP0256 from the socket and make sure that your software has configured the TRIS registers correctly. You don't want to drive one of the SP0256 outputs with outputs from the PIC. You might blow up your SP0256 output pin if your PIC is configured wrong.

You have identified a big problem. You can clip out the current arrays and replace them with individual resistors if you want. You do need the bussed units.

It's a Hobbico Wire Cutter. You can get it a Amazon for about $14 USD. Ebay also has them along with some Hobby stores. They are great for stranded wire larger that 26 AWG gauge wire but will nick the wires if solid copper. I have had some problems with wires breaking over time at the strip point when used on small gauge telephone wires. This was on an Organ with over 3000 soldered wires.

When power is applied to the PIC processor that has a boot loader in it, a SYSEX message is sent out the Midi Out port. It is f0 00 00 7e 40 01 f7 when the device ID is 0. If you have a simple LED, go ahead and stick the leads into the Midi Out connector on your core. When the unit is first powered up you should see the LED blink for a short period when this short message is sent out. If you don't see it flash the first time, then reverse the leads on the LED and cycle the power again going to the core. No flash indicates something is wrong. Either missing resistors, bad PIC or pick not programmed with MIOS or no +5v. You might even try looking at pin 1 of the PIC. It should have a resistor pullup on it. If it is missing it can cause the PIC to not run. If you have a display on your CORE it will show a message saying READY.

Your software would have to run using the MIOS code that also includes the boot loader software, functions for Din & Dout and LCD functions. The Midi code that decodes the Midi commands is also part of this MIOS code. There is a skeleton code example that can be modified by you and compiled for your application needs. It is located at http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Ftemplates%2Fasm_skeleton%2F Your code would have to work around all the code and variables used by MIOS. This skeleton code does this for you. I've used it for my Midi projects.

Thanks for the update. And I understand the confusion with the port numbers.

So what Solved the final problem. Don't be shy. We all make dumb mistakes.

One question I have is why do you have no power on the Vdd pin and a voltage on the reference pin? Vdd should never be lower than the reference pin. Maybe this is why the part failed in the first place. Pete