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