http://www.poptronics.com/interactive/FreeProjects/PIC_LICK-1/PicLick-1-P1.html
and let's see what new inventions come during 2004
Maneco
nice link
thanx
tone
If I were to give one piece of advice to someone wanting to get into PIC programming it would be this; learn C. Just basic C stuff. Nothing heavy duty. While it may seem like a long way to go about it will save you alot more ____ in the end.
Andrew
i'm 2 old 2 learn another language.
Still trying 2 learn spanish.....sheesh!
Can't get the hang of C, any flavor.
Though i like Hi-C, but prefer OJ.
i'll stick to QuickBasic.
Compiled, it makes exe's just like the big stuff.
An exe doesn't care how U got there.
For PICs, I'm using BasicPro PIC compiler($99).
Haven't looked at the "canned" PIC routines on your LINK.
Looking/learning for input triggering routines.
Just haven't sat down and figured it out....
2 many projects,...... 2 little time....
AFN
tone
PIC stuff is probably pretty close, but exe's actually do depend on how you got there. Visual Basic programs will be much more clunky (and usually larger) than a well-written C program. I took a compilers class last quarter and wrote a compiler for a made-up language called "COOL," and believe me, you do not want to write programs using my compiler! :D There's even differences between compilers for the same language; Intel's can create faster code than CodeWarrior or Microsoft's, or vice versa.
Sorry, off-topic :)
I'd actually suggest learning some assembly for PIC programming if you can, but failing that C is definitely a good choice. I have not tried the PicBASIC stuff, so I can't say how good the compiler is, though on a microcontroller there's a good chance the code it produces stands up fairly well against handwritten asm or c.
It also depends on how far you want to get into Pic development, and knowing if you'll ever need programming skills in the future... for example, if you want to get into programming for personal computers, learning C or BASIC makes a lot more sense than learning an assembly variant that only runs on a PIC-16x.
I am one month away from having used PICs for 10 years now, and I've done PIC projects for companies like Apple Computer and IDEO, as well as a custom phone line switching system in Madison Square Garden that was all PIC based and networked using Apple's Localtalk electrical interface and Appletalk protocols. I have also done limited production PIC devices for Boeing, the National Super-Collider (now a defunct project), Disney, Kal-Kan, and many others.
I would avoid C !!!!
There is no point to using C in a resource limited microcontroller. There are MANY reasons to not use C there.
I can't think of a single reason to use C on a PIC other than not having to learn the amazingly easy PIC assembly language and that is not a valid reason as far as I am concerned.
C wastes RAM, C wastes ROM, and C wastes processor cycles.
When you have a full blown computer, C is a help to some people and it does make programs portable, but you can NEVER match the efficiency of assembly. Period. In embedded systems, C can make debugging a pure nightmare too. Been there..... Done that....
PICs are very cool chips. They are very easy to learn and use. The funny thing about them is that they were originally the I/O co-processor for a General Instruments CPU that is now long dead. (PIC=Peripherial Interface Controller)
These days, I much prefer the Atmel AVR series to the PIC, but the PIC will always have a place in my heart. I also love the Ubicom SX28 which is like a supercharged PIC16C57 on setroids. The PIC16F84 makes it very easy to get started and little boards like Maneco posted about make it even easier.
For anybody starting in embedded programming, remember the golden rule of embedded systems..... An embedded system that is a little bit unreliable is like a woman that is a little bit pregnant. It's a very binary situation.
There's my morning rant. ;)
Take care,
-Peter
In a similar thread, I am working on a method for controlling effects using midi, and will be using a PIC16, or PIC18 for this purpose. I've got the methode mapped out in theory and its now time to begin building the device. I'd like to sell it in rack enclosures. I'd put something like a Tube screamer, a wah, and volume control in a 1U rack with switching and midi control. I want the exact effects to be flexable so people can use what they wish. I can't use the Midibox interface though because it is an open project, and can't be sold. Although, I will post the code, and the schematics for building my design also.
My first milestones will be to get the pic to recieve midi time code, and blink two led's like a metronome. I am having problems finding information on how midi data is transmited. Does anyone know of a resource that covers programming for sending and recieving midi? Thanks.
William
hi,
maybe you still have this link..
http://www.audiomulch.com/midipic/
for the midi metronome:
http://www.maxmidi.com/diy/metro/
this one works,i`ve built a couple for testing the midi clock output in my machines ,that's not done with a pic,but with a serila cmos shift register...
...manecoloopers are "look ma,no microcontroller..."maybe in the future i start working with a pic for providing tap tempo functions and sound bank storing...
hope this helps
Maneco
I would like to respond to Peter's comments about C Vs. Assembler.
There is a myth running about that assembler code is ALWAYS better the C or other compilers. Its not. There are regular tests made by the C compiler companies and Microchip that show that alot of the time they are equal and sometimes C code beats hand code. The compiler companies spend alot of time writting algorithms and tricks that are way beyond the complexity of the vast majority of assembler coders and they are made availible to the average C coder.
There is alot more information to teach a beginner C then there is for assembler.
With C I don't have to screw with remembering stack counts, addresses, registers, etc. That stuff is taken care of by the complier.
I can port my code to other processors with minimum hassle. I can also reuse alot of my code in other projects.
There a loads of libraries availible. If I need a RS232, USB, SPI, serial interface I just get the library. If I need A/D, D/A stuff I get a library. With assembler I have to write alot of that by hand.
Debugging is a breeze. First you write your C code and test it out on your computer. Then you convert the code to run on an emulator. Then you throw it into a processor for testing. Along the way you can interface the code to MPLAB. You can even do real-time debugging.
I don't see any major objection to using C. We are not talking about running a C binary on the processor here. The compiler makes assembler files just like what you write by hand only its cleaner. If you have some fetish to write some parts in assembler then any good compiler will allow you to mix assembler code with C.
You could learn assembler but I consider that just one step from punch cards and I have a life so I don't bother with it. I think its important to learn a little bit so you can understand whats going on but after that move to more civilzed programming.
That being said I think PICs are cool little things and they can do alot of things for people playing with effects. Its not the ultimate device though.
This is just my opinion.
Andrew
Re: Languages
Languages don't matter. If you have thought your program logic out well, you don't even need to have previously learned the programming language you type in the final code in. I have learned so many languages that I don't remember any one specific language. I remember the data structures, access methods, and control logic. Every possible language has to have constructs for handling those. You write the program design in pseudocode or whatever makes it easy to write down the logic. The rest is all just getting the commas, semicolons, and other punctuation right. I've never seen a language that could make you think right.
I guess, put another way, if the language matters, the application is too critical to discuss here.
Time for a computer joke:
=======================================
How to Determine Which Programming Language You're Using
The proliferation of modern programming languages which seem to have stolen countless features from each other sometimes makes it difficult to remember which language you're using. This guide is offered as a public service to help programmers in such dilemmas.
C: You shoot yourself in the foot.
C++: You accidentally create a dozen instances of yourself and shoot them all in the foot. Providing emergency medical care is impossible since you can't tell which are bitwise copies and which are just pointing at others and saying, "that's me, over there."
Ada: If you are dumb enough to actually use this language, the United States Department of Defense will kidnap you, stand you up in front of a firing squad, and tell the soldiers, "Shoot at his feet."
Algol: You shoot yourself in the foot with a musket. The musket is esthetically fascinating, and the wound baffles the adolescent medic in the emergency room.
APL: You hear a gunshot, and there's a hole in your foot, but you don't remember enough linear algebra to understand what happened.
Assembly: You crash the OS and overwrite the root disk. The system administrator arrives and shoots you in the foot. After a moment of contemplation, the administrator shoots himself in the foot and then hops around the room rabidly shooting at everyone in sight.
BASIC: Shoot self in foot with water pistol. On big systems, continue until entire lower body is waterlogged.
COBOL: USEing a COLT45 HANDGUN, AIM gun at LEG.FOOT, THEN place ARM.HAND.FINGER on HANDGUN.TRIGGER, and SQUEEZE. THEN return HANDGUN to HOLSTER. Check whether shoelace needs to be retied.
DBase: You squeeze the trigger, but the bullet moves so slowly that by the time your foot feels the pain you've forgotten why you shot yourself anyway.
DBase IV V 1.0: You pull the trigger, but it turns out that the gun was a poorly designed grenade and the whole building blows up.
Forth: yourself foot shoot.
FORTRAN: You shoot yourself in each toe, iteratively, until you run out of toes, then you read in the next foot and repeat. If you run out of bullets, you continue anyway because you have no exception processing ability
Modula/2: After realizing that you can't actually accomplish anything in the language, you shoot yourself in the head.
sh, csh, etc.: You can't remember the syntax for anything, so you spend five hours reading man pages before giving up. You then shoot the computer and switch to C.
Smalltalk: You spend so much time playing with the graphics and windowing system that your boss shoots you in the foot, takes away your workstation, and makes you develop in COBOL on a character terminal.
PL/I: You consume all available system resources, including all the offline bullets. The Data Processing & Payroll Department doubles its size, triples its budget, acquires four new mainframes, and drops the original one on your foot.
Prolog: You attempt to shoot yourself in the foot, but the bullet, failing to find its mark, backtracks to the gun which then explodes in your face.
SNOBOL: You grab your foot with your hand, then rewrite your hand to be a bullet. The act of shooting the original foot then changes your hand/bullet into yet another foot (a left foot).
lisp: You shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds...
scheme: You shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds ...but none of the other appendages are aware of this happening.
English: You put your foot in your mouth, then bite it off.
CLIPPER: You grab a bullet, get ready to insert it in the gun so that you can shoot yourself in the foot, and discover that the gun that the bullet fits has not yet been built, but should be arriving in the mail REAL SOON NOW .
SQL: You cut your foot off, send it out to a service bureau and when it returns, it has a hole in it, but will no longer fit the attachment at the end of your leg.
AHAHAHAHAAAAAA
*falls off chair*
perl: your foot seems to be represented by ^(\@%#\!\)(&%#\)\*!\!!)(&*\///\/\\/!@^#!@I\/U\//\/\\\y!@*!)(!!\..[]]{!@#!}{!#!$
It takes you so long to figure out what it means that you die of old age trying to understand it. Meanwhile someone much better than you releases your foot as LGPL and your wife buys a copy from microsoft
Slightly OT but..... I was surprised to see that no one gave this link while discussing pics and effects. http://www.ucapps.de/
Much of the work has already been done. I'm thinking of building my own floorboard with a separate relay switcher....mmmmm, 128 loops..drool. :D
OK, now you guys have my attention. Seeing as I am an expert in C - uh take that with a BIG grain of salt - please tell me what I can do with a PIC and C or the assembler?
How would it apply to my pedals?
I used to program in FORTH using the Meta Language for Adaptive Synthesis and Control i.e. MASC but that was a long time ago.
Aron
QuoteOK, now you guys have my attention. Seeing as I am an expert in C - uh take that with a BIG grain of salt - please tell me what I can do with a PIC and C or the assembler?
ummm... that's what the ASMOP series was all about. Give it a read.
What you can do with PICs and (insert favorite language, or lack thereof):
- any switching scheme you can think of and write down rigorously, like a mega-looper floor bypass setup.
- remoting switching stuff or anything else you can think of as digital by using the built in serial capabilities and a long wire, or radio link, or optical broadcast, ala TV remote controls
- read one or more pots directly into the uC as a digital value
- output a semi-analog voltage by pulse width modulation
- output any digital function or combination of digital outputs you can think of as a result of any digital inputs or pot reading you can do
- do A-D conversion and D-A conversion (speed limits this to be less than audio bandwidth, or I'd already have done a digital delay up to a megasecond)
- Generate arbitrary waveforms from an interior table look up. Things like sines, squares, triangles, hyper-tris, etc. are trivial. Do this at a speed that is controlled by one of those pots you can read. Can you say "Digital LFO"?
- Directly control analog circuits by PWM modulation of resistors and caps, as in clocked-capacitor filters
- communicate anything musical via MIDI
... I'm getting tired of typing...
Go read ASMOP.
The fundamental limitation is how many I/O pins you have and how fast the clock speed of the unit you have is. Beyond that, you can do largely anything you can write down a clear logical description for.
Quote from: R.G.Languages don't matter.
R.G., I could not disagree more with that statement when it comes to getting the most out of a chip.
For "simple" projects or manipulations in an environment where you have high amounts of excess resources this can be very true, but I have written a LOT of code that didn't fall into that category.
I have squeezed the "impossible" out a chip on several occasions. In reality these things have been very difficult in assembly, but would have been totally impossible using a "high level language" simply because of the inefficiency introduced by the compiler.
When it comes down to it, the processor knows only one language.... assembly. Anything you do to distance yourself from that assembly will consume something in one way or another.
I have never seen compiler output that could even approach touching the efficiency of a native assembly program when it comes to doing "real work" in a constrained environment. Note that I'm not talking about writing a browser here, I'm talking about embedded control systems using non-bloated PC architectures.
An example for effects use?....
MILAN: The Musical Instrument Local Area Network
This is a project from several years back that made use of a
software version of the Zilog 85C30 Serial Communications Controller to network effects and control variables. Picture every advantage computer networks provide when it comes to distributing info and think about what that could mean for effects controls. The ability to share a control value between devices including the ability to manipulate those values via additional math can be very powerful. Say you had a MILAN controller pedal (like a volume pedal with network output). You could use that value to control level, mixing, filter parameters, modulation parameters, and more all at the same time with each control relationship tweaked in a specific way. Functionality is defined by.... as R.G. puts it.... a simple matter of programming.
The options are almost endless when you combine a PIC with high resolution A/D and D/A(s). Basic effects switching is powerful, but it's only the very beginning.
Take a look at the "RNC" from http://www.fmraudio.com/ While I'm not a compressor head, I do love compressors and the RNC does an amazing job at it by using a digital control algorithm running on a tiny Motorola 6805 to vary a control voltage going to a THAT VCA. The chain is all analog, but the control is nothing short of amazing.
It isn't a PIC, but as a high speed enhanced clone of a PIC, the Ubicom SX series is fast enough to do things that were once the exclusive domain of ASICs. The "big brother" of the SX series, the IP series, is fast enough to do things like Ethernet using mostly software to replace dedicated transistors.
It's a wide world out there.
Oh Andrew... punch cards??? Come on... :roll:
BTW: My first experience with "mainframe computing" was sorting my 2nd grade spelling words on an IBM puchcard sorter. I code in assembly for a whole mess of CPUs and I do have a life. ASSEMBLY IS VERY EASY! DIY!
Anybody who says compiler output is cleaner than decent hand assembly has never looked. I have seen endless amounts of compiled code that was nightmarish, to be kind. I wrote some disk copy protection code in the 80s and used C for some of it
JUST to make it a nightmare to trace. Gee... why do something in two assembly instructions when a compiler can do the same in 12 and waste two registers in the process? Notice how the amount of C coding on a particular processor is directly proportional to the number of registers it has. LOL!
Take care,
-Peter
Real DIYers do it in Analog *AND* machine code.
LOL!!!!!
Make that Real OLD DIYers...!.
LOL!!!!!
Weee don't need no stinkin' languages!
Power 2 the Machines!
Gentlemen, start your Fuzz boxes!
Hee Haw!!!
thirty four instructions
and U want a complier?????
javascript:emoticon('8)')
javascript:emoticon('8)')
I pretty much agree with Peter, though with much, much less experience to back it up with PICs.
If you know what you're doing, writing things in as low-level a language as possible is better, especially for devices with very limited resources such as a PIC microcontroller.
As I mentioned, my (slight) suggestion to learn C rather than assembly was in part due to the fact that it may seem easier to people who have had at least some programming experience (in a language such as BASIC/Pascal/etc), and it will arguably help you more than assembly if you need to program for something else than a PIC. There's enough you can do with PIC C, but I would never personally choose C over ASM for a PIC. I've heard that some people have a little bit of trouble with the way asm "reads," but it's very logical.
The only cases I've personally seen where the compiler can do a better job than handwritten assembly involves choosing which variables to keep in the cache vs out in slower RAM, and even this advantage can be taken away if the programmer is smart enough to make that decision for himself/herself. I'm not sure how well optimized compilers such as Intel's fare, but that's a moot point on the PIC :)
I knew that my snide comment would raise these issues, and pretty much along these lines. Let me expand.
There is a whole range of problems to solve by programming. Some are trivial, some so complex that thousands of programmers work on them for years.
The issue is - what problem are you trying to solve, and what are you willing to pay to solve it?
It is quite true that humans, being fundamentally pattern matching intelligences, can find and exploit patterns in very, very complicated situations, and the more they know about the situation, the better they can do it. In the instance we're discussing, a person who carries the whole machine architecture around in their head and has solved many, many similar problems before can often find and exploit a pattern that will wring almost the last bit of performance out of a limited resource like a pin, instruction, and resource limited chip like a PIC.
However, there is a cost. That cost is that first, you have to have a person with that knowledge and experience in their head. That can easily take years to get, especially if you have to grow the knowledge base inside your own personal head. Then there's the issue of how much of that person's time and the additional cost of support equipment you're willing to spend. That can be substantial, as those of you who have done this kind of thing will know.
And I did insert the caveat:
QuoteI guess, put another way, if the language matters, the application is too critical to discuss here.
This is a DIY forum. PICs are sufficiently capable that very few apps that I can conceive for effects are going to come near the edge where the cost of programming in time and dollars starts increasing exponentially. And if they do, it's far more cost effective to get a bigger horse (a faster, more capable PIC or other controller) than it is to squeeze the last drop out of the one you started with.
This is most assuredly NOT true for commercial programming where you'll make or lose millions on the boundary of saving $1.00 on a cheaper chip.
But it is true here, where I'd happily spend another $20 on a bigger chip if I could get the programming done in a day instead of a year.
And for people who don't spend all their time wringing the last drop out of a controller, it's counterproductive to learn even thirty four assembly instructions if the instructions are confusing (some of the PIC's are) and then you have to spend more time debugging. It's far more efficient in terms of the human cost to use the language that is either closest to the way the person writes down the program logic or to use the language that the person is already proficient with, or to use the language that you have easiest at hand.
I'm well aware of the efficiency of assembler in certain cases. I'm also aware that in my last programming job, I had a team of twenty experienced C and assembler programmers that would first program a driver in C then try to read and tweak the object where they could to get more gains. We had exactly two occasions where a driver got faster from hand tweaking. Of course, we had a custom-built compiler, too.
So I think that, perhaps not in all cases, but certainly in the majority of cases of programming in general, and in controller programming for DIY effects in particular, the language does not matter. Use the one you have - or the one you have patience enough to master. Professional programming wizards may prefer to program right down to the bare metal. Beginners, part timers, and people who just want it to work ought to start with what they have, or what they understand best.
I first learned assembly programming on the IBM 1620, which was a relic when I first touched it. The 1620 was informally named the "CADET", which was an acronym for Can't Add, Don't Even Try, in honor of the fact that it had NO arithmetic hardware. It did arithmetic by table lookup, as humans do. I've done a lot of assembly since then; 360, 8080, 6800, 6502, x86, pMachine, some machines no one else would recognize. In all cases, I'd have given a lot to have a language available.
Assembly language is like single malt scotch - it's not for everyone, but true believers think there's nothing else 8-)