Synapsys

You may want to consider the Microchip FAT16 file system. The code is freely available at the Microchip web site (see app note AN1045). I have used this code with both SD and MMC cards (on a PIC24H MCU) without problems. The full featured code for a PIC18F MCU takes around 55K of program memory and under 2K data memory. You could easily use a PIC18F2620 chip to implement the file system and interface it to MIOS via I2C. Hope this helps... Regards, Synapsys

Hi, When I first built the PIC Burner I had similar problems. I found that slowing down the timing parameters on P18 solved my probelms. Select the Options tab and then the Timing tab to set these values. I would try slowing down both the Interface and the PIC timing a lot and see if the problems stop. If yes, then increase each until the problems return and then back off a little. Hope this helps :) Regards, Synapsys

Of course, I agree with TK on this issue. The additional cost of adding the 16F88 is rather trivial compared to the advantages afforded by the 18F4620. Regards, Synapsys

I use the ICD2 module to do all my PIC programming. Since the 16F88 requires 13.1v for the programming voltage the PICkit2 may or may not work, I don't know. If you run into a road block because you can't program the 16F88 send me a PM and we'll work out a way to get one done for you. Regards, Synapsys P.S. Keep in mind that the 16F88 is an 18 pin chip when laying out your programmer board ;)

The IIC_MIDI module functionally resolves the EUSART bug. In fact, all you really need is the 'output only' version of the IIC_MIDI module to overcome the EUSART bug. You will, of course, also need to use MIOS V1.9 in order to support the IIC_MIDI module. The 18F4620 chip provides the advantage of more flash and more ram thus allowing for future additional features to be added to all MIDIbox applications. Having used the IIC_MIDI module for some weeks now with great success I would go with the 18F4620 for all new MIDIbox projects ;) Regards, Synapsys

Hi J, The silicon bug with the EUSART has not been corrected by Microsoft yet. The problem has been explained in threads here and on the Microchip forum. Back to back transfers are not possible since the TX port will transmit spurious bytes of all 0s. This makes it unacceptable for MIDI use. However, do not dispair :) With the advent of the new IIC_MIDI project the Microchip USB is once again a viable alternative to the Cypress chip. Hang in there for a little longer. Regards, Synapsys

Hi, There are a few differences between MPASM and GPASM but they are somewhat insignificant. The original difficulty with MIDIbox code (MIOS and applications) with respect to GPASM was the macros that TK wrote. He used a feature in some macros that is not available in GPASM (e.g. passing an instruction to a macro as a parameter). I certainly don't blame TK for this, as the feature is quite powerful. In and of itself, this is not a big problem since the macros can be expanded manually in the source code. This is a lot of work however and prone to errors. In the meantime, I believe that TK has modified the code to make it compatible with GPASM. (I am not certain about this so TK’s input is needed to be sure). As an exercise in absurdity ???, I wrote a Windows application last year that scanned every source module in MIOS and expanded all the macros into another set of source modules. Once I had done this I was able to build MIOS using GPASM. I don’t recommend this since you end up with a non-standard unsupported set of code. Like I said, an exercise in absurdity :P. Regards, Synapsys

Hi QBAS, Check out this link http://sdcc.sourceforge.net/ You can download the SDCC 'C' compiler and the gputils from this site. This compiler and utils provide support for the PIC chips. There are a couple of alternate methods for installing it on Linux depending on the flavor of Linux you have. The documentation with SDCC and gputils is fairly good. Although I don't use Linux that often, this is the same compiler that is used on Windows so building applications on Linux should be fairly easy. Hope this is what you are looking for :) Regards, Synapsys

I am not going to comment on the JDM other than to point out that there have been a great many posts here by people that have had trouble getting it to work with various PCs. I think you should consider the MBHP PIC Burner instead. I built one and it worked perfectly from the start. Nothing really weird here. Go to the uCApps site and check out the schematic for the core module. Connector J3 has jumpers that need to be removed to utilize the ICSP feature. This connector gives you access to the PGD,PGC and MCLR pins as I indicated in my prior reply. stryd_one said: I agree with this. The boot loader has code that prevents it from overwriting itself. They only way it could (normally) be overwritten is if you wrote code in an application that performs writes to program memory and uses addresses in the boot space. Up coming changes may even make this impossible by utilizing the boot protect configuration bits. I think it would be advisable to consider using the boot loader (or a derivative) in preference to ICSP. Not only is it more convenient, it is much faster. Regards, Synapsys

There is only one way to program a PIC (other than using something like the bootloader) and that is to use the PGD, PGC and MCLR pins. Whether you are doing the programming 'In-Circuit' or in a prgrammer the actual process of programming the chip is the same. If you look at the PIC Burner schematic on uCApps you will notice that only pins RB6,RB7 and MCLR are actually used to program the chip. If you wanted to do ICSP you could build the PIC burner and instead of having a socket have a short cable that connects to these pins on your board. Make sure that the PGD,PGC and MCLR pins do not have any other circuitry connected to them while programming is taking place. The other thing to be careful about is the pulldown resistors on RB5 (18F) and RB3 (16F). These are required to assure that the low voltage programming (LVP) mode is disabled. Alternatively, there is a configuration bit that disables LVP mode. This is how the ICD2 module works. So, ICSP is just as reliable as using an external programmer. Hope this helps. Regards, Synapsys

Hi, I took a look at both the dsPIC and the PIC24H chips and they are pretty much the same except, of course, the dsPIC has the DSP engine. Porting MIOS to either of these chips certainly looks doable. However, since these chips have a richer instruction set I would seriously consider a new design for the firmware that takes advantage of things such as 16 bit data memory, a true hardware supported software stack, 16 working registers etc. Take a look at the new Explorer 16 demo board on the Microchip website for the PIC24. One board comes with both a dsPIC and a PIC24 chip so that experiments could be done on both to determine which might be most appropriate for a particular application. And, considering that the board supports USB, RS232, LCD and more, it is relatively inexpensive, only $129 USD. Keep in mind that these chips come in surface mount packages only. This presents a challenge if you plan on building your own circuit boards. Regards, Synapsys

Hi Robin, The wparam modifier causes the first byte of the arguments to be passed to the function in the WREG. This makes for more effiecient processing. The use of prototypes is necessary so that the C preprocessor can determine the number of arguments a function requires. All modern C compilers will give at least a warning if a prototype is not present. Some C compilers will generate an error and force the inclusion of a prototype prior to calling a function. Hope this helps. Regards, Synapsys

I think this is a fair question for people trying to learn new things here. Electrical isolation does not require an opto-isolator at both ends, only one. The original MIDI specification had the goal of providing a standard interface at the lowest cost possible to inspire manufactures to implement MIDI on their devices. Isolation is achieved, in the case of MIDI, by having the input channel opto-isolated. The output channel does not need an opto-isolator because the input channel of the device it is connected to has the opto-isolator. BTW: Another question is why are opto-isolators used at all? There are two primary reasons, both having to do with grounding. If opto-isolation was not used (e.g. there is a direct electrical connection between devices) there is an inherent danger that the ground levels between the two devices are different. This could lead to damage to one or both devices. Secondly, ground loops could cause problems with noise being introduced onto the MIDI signal causing erratic behavior. I hope this helps :) Regards, Synapsys

Ok, against my better judgment I am going to add something to this thread. Yes, TK, I see the point. For example, Rah has no idea how much time (and therefore money) it is going to take to produce something as mundane as a product level Users Guide for the MIDIbox. Generally speaking, a non-technical person who might purchase a MIDIbox on ebay is going to expect to receive a clearly written functionally complete Users Guide with the equipment just like they would from a company such as Mackie. The word that such documentation does not exist will quickly spread via online forums and newsletters and will likely cause any substantial amount sales to cease. The perspective customers are going to expect some level of support. This is, of course, the main concern here. If Rah directs these customers to this forum to obtain support the customer will quickly determine that this forum is not intended to provide “operational†support for the MIDIbox but rather technical support for building and getting the box to run once it is built. Finally, I would like to give Rah some advice concerning liability when selling an electronic device to the public. Consider, for example, what would happen if a customer opens up the dual voltage SID power supply and injures (or kills) themselves due to exposure to mains voltage levels. Rah, or his so-called company, could very well be liable to the customer for damages. Better buy lots of insurance Rah. These are only a few thoughts on this subject. I am certain there are hundreds more. Having started my own business many years ago, I know how difficult and expensive it is to make it successful. I don't think we MIDIboxers have much to worry about here. Failure is almost a certainty. Regards, Synapsys

If you use the MIOS boot loader you can compile the application code and download it to the PIC via the MIDI port. This means you don't need a seperate programmer. This is why an in-circuit programmer is rarely mentioned. I use the Microchip ICD2 module to program and debug PIC code in-circuit. Since ICP uses two pins on port B a jumper setup like is on the core schematic is needed to allow programming and use of these pins for the LCD. To avoid having to use the jumper setup I run my LCD in 4-bit mode so port B bits 6 and 7 are free. Then I can use the ICD2 and the LCD at the same time. :D Regards, Synapsys

Hi Tyler, There are several other threads here about using PS/2 devices with MIDIbox (note that almost all laptop mousepads are PS/2). Try this for a start. http://www.midibox.org/forum/index.php?topic=3041.0 Duggle was working on a PS/2 interface for some time. I don't know it's current status but I know he did have a working prototype last year. Regards, Synapsys

Hi, The 18F4520 uses the Microchip EUSART rather than the standard USART found in the 18F452. All 18F family chips that use the EUSART have a silicon bug that prevents back-to-back interrupt driven transfers on the serial port. This makes them unusable for MIDI applications such as MIOS. I have not tested the 18F4520 but have no reason to believe that Microchip has resolved this problem since they have not published anything to the contrary. So, I say stay away from the 18F4520 and stick to the 18F452 which I am sure will be available for many years to come. Regards, Synapsys

For anyone interested here is a link to a page where the data sheet for this BBD can be found. http://www.synthdiy.com/view/filecat.asp Schematics using the 3207 and 3102: http://experimentalistsanonymous.com/diy/Schematics/Chorus/Ibanez%20CS5.gif http://experimentalistsanonymous.com/diy/Schematics/Chorus/Ibanez%20PC10.pdf http://experimentalistsanonymous.com/diy/Schematics/Chorus/Ibanez%20SC10.pdf Regards, Synapsys

Hi, Another thing you should watch here is the label 50KA. If the pots are relatively new the A could mean audio taper. If the pots are old the A could mean linear. The best thing to do is place the slider in the middle of its travel and measure the resistance between the tap and each end with a meter. The value will be relatively equal if the pot is linear taper but will be noticably different if its audio taper. Hope this is useful... Regards, Synapsys

Hi I saw your reply moebius and thought I would correct the pin numbers you gave. The DIN/DOUT chips are 16 pin chips and the bypass caps go between pin 8 (ground) and 16 (+5v). You are correct when you say that leaving out the bypass caps will (probably) have no affect on the operation of the DIN/DOUT modules. However, putting them in does lend itself to a cleaner power bus and reduces the risk of affecting other more sensitive areas of circuitry such as the analog inputs from faders. Regards, Synapsys

Hi, Here is a link to the Digikey catalog page that contains a tool called a nibbler. http://dkc3.digikey.com/PDF/T053/1440.pdf If you are working with relatively thin panels (up to about the thickness of a PCB) this tool works quite well. I have used it to make many rectangular holes in aluminum panels as well as shape some PCBs. To use the tool you need to drill a hole (usually in the center of the rectangle) large enough for the nibbler bit to fit through. Then you simply insert the bit, grab a piece of the material and squeeze the handle to nibble away at the material. Since the bit is square, the result is a square cut. Regards, Synapsys

Hi Drappel, When you apply full-wave rectification to an ac signal the dc output level is actually higher than the ac level. The general formula is that the dc output in volts will be 1.414 times the input. Thus you can expect to have about 12*1.414 or 16.97 volts dc feeding the regulators. In actual practice this voltage will be somewhat lower due to the diode drops, you mentioned, as well as other losses in the transformer. A good rule of thumb is that the ac voltage of the transformer secondary should be about 0.8 times the expected unregulated dc output from the bridge. Hope this helps... Regards, Synapsys

The code that Thorsten gave you WILL pulse the A0 pin just as you would expect. How do you have PORTA configured? When the 16F877 powers up PORTA is set for analog input by default. Unless you specically program the port to be digital you will have problems. Regards, Synapsys

Hi, I believe that you would have better success if you ran the wires for the buttons/encoders to the remote location rather than the connections between the core and the DIN module. MIOS scans the DIN shift registers at a relatively high frequencey (ca. 75 usec for all 128 inputs). As the length of the wires between the core and the DIN module increases so does the capacitance. The increasing capacitance degrades the signals and at some point the signals will no longer be reliable. I agree with pay_c about lowering the value of the pullup resistors. The are two benefits to this. One, lower resistance improves the signals as capacitance rises (i.e. improves the rise time due to a lower RC time constant). Second, lower resistance values help reduce interference from external electrical noise. The 74HC595 shift register chips can sink 25 ma which means you could lower the resistance down to about 200 ohms without endangering the chips. Shielded cable would also be advisable with the shield connected to ground at the DIN module end of things. As is always the case, however, the best thing to do is just try it :) Regards, Synapsys

Hi, One thing to keep in mind here is that in the MIOS software the PIC watchdog timer is active. If the timer is allowed to expire the system will reboot. This will happen if any routine goes into a loop that takes longer than the watchdog timer timeout. This was done by design to allow the bootlstrap loader to become activated if such a condition occurs thus giving the opportunity to upload a fixed (maybe older) version of the application. Unless the bootstrap loader has become corrupted, you should be able to upload a fresh version of MIOS immediately after a reboot (within 2 seconds). Once the fresh copy of MIOS is uploaded the application is no longer linked so the reboot should stop. At this point you can decide to upload an older (working) version of your applicaition to be sure that it still works. Then look at the changes you made to find the problem. BTW, it is this type of problem that points out how valuable an in-circuit debugger is. I struggled with some difficult to find bugs in my code and finally purchased the ICD2 debugger from Microchip. It is significantly easier to find bugs now and I believe that if you are doing extensive software work on the PIC the debugger is well worth the cost. Hope this helps, Synapsys