entity

Cool, I'll do that when I get them. Thanks everyone!

Debounce them? Are you referring to the MIOS method or is this something I have to do the switch? Please elaborate. Otherwise, I'll be ordering some switches soon :)

Hey guys, I haven't checked recently, but months ago I spent a while searching the forums for good foot switches for a midi foot controller (for a guitar rig). So far, I've found this http://www.smallbearelec.com/Detail.bok?no=672 to be the best quality/price. Has anyone tried these before, or does anyone have better suggestions? Also, has anyone dealt with this company? I am looking for something rugged that will fire without excessive force (I don't like slamming my foot down while playing guitar heh). Most "good" switches seem to cost $6+ (which sucks if you want to order 10 of them). I've also noticed companies like digitech tend to use tactile switches with plastic covers... but I've actually had those get "glitchy" in the past with repeated use, so I'd rather go with the more rugged, "harder to push", buttons. Finally, I want to mount the switches directly on the enclosure (a steel Hammond box) to simplify assembly. Anyways, thanks for reading and thanks ahead for any feedback :)

Thanks for the info stryd_one. You are a wealth of PIC info! Some of this is taking some thinking on my end... I thought I'd never have to learn ASM or worry about hardware. That's biting my butt now. haha When I get my PIC back I'll probably revisit this post a bunch.

This is an interesting thread since I come from the "high-level language on x86 or newer processor" world... AFAIK, the register keyword "suggests" that the compiler stores the variable in a register when possible. If this variable is a pointer, given a pointer in a register, the compiler will probably choose to optimize using indirect addressing over pointer math (that's what your findings suggest). I'm curious what happens if the "suggestion" is not always consistent in SDCC (ie... what if you use more register pointers across multiple banks then the number of available registers on the PIC? Ya it is knitpicking....) I'm a noob with PICs and such, so sorry if this sounds like a silly concern. Either way, I was running into this problem early and I think this is a clean solution in C. Do you still have to modify the linker script to combine the memory chunks?

This is probably way too late... In old C compilers (I can't talk much for SDDC), switch statements are converted to jump tables, which run much faster then if/else statements or function invocations. I'm not great at explaining things, but wikipedia should help. http://en.wikipedia.org/wiki/Jump_table (The example is actually for a PIC!) So to answer your question, use a switch statement. Calling a function is "better" style, but if you want efficiency, you'll need to "inline" the function body in the switch statement.

I'm working on an application in C that does something similar to what you are asking. Maybe I can help if this is still a valid project for you. For your project: With 99% certainty, you can get DIN1 to only send the "top" row CC values and DIN2 to only send the "bottom" row CC values. When you say "pots", do you really mean rotary encoders? It seems like you should be using rotary encoders if you want buttons to change the current value of a knob. For instance, if a knob is rotated 100% and your button tells it to send 0, you will not be able to raise the parameter anymore with a pot. It would be fine with a rotary encoder. Then again, I'm not a hardware guy, so hopefully I'm not giving bad advice.