Which is better to program in, in general, for Microchip's pics; C or Assembly? I am personally more fond of assembly but after trying a little using microchips "31 instructions" its a bit daunting. I really don't want to waste my time extending the instruction set just cause they want to hype it up with making it small as possible. Not sure why the stopped at 31... "Only 5 easy instructions to learn!!!".
Are there any drawbacks to using C(besides bloating?)?
While I don't mind using assembly I know that I will just end up making many macros to do what I want and it will basicaly end up as more of a HLL anyways so I probably should just go with C from the start. I'm mainly used to Masm syntax and semantics anyways and Microchip's synatic can be strange at times(and annoying when you only have one register to work with(I mean "W").
From glancing at some C code it seems much easier to do things like setting "File Registers" and such(I definately hate the INDR method for working with "pointers") but I should be able to accomplish that with a macro(assuming they have good macro functionality which I haven't checked out yet).
Although loathing C, I will shyly admit the (very) occasional use of a primitive language called 'Basic'. In general though, would say they're all much of a muchness and pretty marginal as to whether -any- of 'em can offer a decided benefit over assembler when used in Pics. Sure, it's nice to type a=sqrt(2*pi) and see some prewritten 32 bit maths routines pulled in. Or magic up a block of code for an I2C link from just a couple of lines of text, or even on command, load in a complete FAT32 setup. But we lose track of what the micro"controller" is there for in the first place. It's supposed to be a dirt cheap, fast, one stop shop, that can be programmed to handle all the messy real-world stuff, like ADCs, DACs, logic, transducers, etc, etc. Y'know ... stuff that the compiler writers have never even heard of and certainly haven't written any predigested routines to suit. Maybe some serious PIC work will come along, then despite all the compiler fluff on offer, you'll find that virtually all your hardware still needs tedious hand coding in assembler, added disadvantage then of having to also keep an eye out for what the compiler might be up to. It's a toss up as to benefit. But it's for sure, that without machine code familiarity, you'll be forever a cash cow for the compiler writers. john
Hell, no! REAL men program directly in machine code, and compile C++ on sight. By Gawd, when *I* started programming, all we HAD were 1s and 0s, and half the time they were late getting us the 1s....one long cold winter, when young Abe Lincoln, Tom Edison, Tom Swift and I were programming by firelight, we ran out of 0s and had to use the capital letter "O." Why, once, while on vacation in Bora Bora (from my job in the Department of Redundancy Department), I emulated a PDP-11 using pebbles collected from sea and placed into depressions in the sand to take the place of the registers...and then got burns on my hands from the friction, while trying to up the clock rate...
I tell ya....kids today...no idea how good they've got it....
- and damn near essential for anything moderately complex (like floating point math) or when you get above a few hundred lines of code for instance.
I use the HiTech C compiler, they have a free version available for several PICs. I've also heard the Microchip 18 series C compiler is now essentially free.
You'll no doubt get assembler freaks trying to tell you why C is crap and assembler is king, but the facts are that hgih level languages like C win hands down these days.
Yes, C adds a bit of overhead, but not much. In fact, poorly written assmbler can actually use more code and/or be slower than it's C equivalent. If you need every last byte in a micro then you probably should be using a bigger one anyway. (e.g what if you want to add features in the future)
If you want speed, almost all C compilers will support in-line assembler as well for those bits that need it.
Most real commercial work these days is done in C because it's much easier to maintain, review, and get someone else to debug later when the original programmer is not around any more.
Well it depends, C is more like a software management system than a computer lanuage. It compartmentalizes code, it's most important asset, manages data formats, allocates memory and comes with a library of "usefull" functions. For a program written by a team it's pretty much essential. There are some down sides however, first the traditional implementation doesnt work with the PICs below the 18 series, or 8051s, very well because of hardware issues. This has led to compiler writters useing a different approach which means that none of them comform fully to the ANSI standard, this may be unimportant for you however. The libraries contain alot of functionality you pobably will never use so if you use them your code size goes up, for a small program maybe quadruples so you cannot take advantage of the smaller devices. More code often means less speed which can mean you need faster clocks, more EMI, more power ect. Assembly is tedious, the upside of that is it forces you to PLAN your project properly in the first place unlike C programmers who "start codeing" from the outset, this act alone can reduce your program by at least 50% and your debug time by 80%, you should do it anyway regardless of which language you use. There are some that tell you C is easier to read than assemler, that isn't so, that is down to how you wrote it not the lanuage.
In the beginning, where you are, assembly is best. There are two reasons. First is that assembly gives you a low level view of the PIC architecture, which admittedly has its quirks. The second is that assembly is the trade language for the microcontroller. Not everyone does C, or BASIC, or JAL. However, there are tons and tons of code snippets in assembly. But they are difficult to use if you've never been exposed.
So at the very worst, you need a reading level understanding of PIC assembly.
How about a single instruction? Here's the outline for a Turing complete one instruction computer:
formatting link
formatting link
At the end of the day, instructions are available for convenience and abstraction.
I find a couple. First is that C doesn't have usable bit manipulation built in. It always has to be added on in some non standard way. Consider clearing bit 3 of Port A. In PIC assembly it's straightforward:
BCF PORTA,3
in standard C?
PORTA &= 0xF8;
Not really straitforward. Which nonstandard extension makes it easier? Well that depends on the C compiler you use. This is a feature I built into my NPCI language. In NPCI it would be:
PORTA:3 = 0
which is also straightforward.
Again you should have a reading level understanding of assembly. In general that means tackling at least one significant project in assembly.
There are lots of registers to work with. W just has to be one of them! ;-)
Great macro functionality. One other thing when you tackle PIC assembly. Take the time to learn how to use the linker. A short tutorial can be found here:
formatting link
At the end of the day, PIC assembly will be one of the tools you'll need in your toolbelt. So start with it. Once you get comfortable enough to use it, you can then start making decisions about other tools.
A program is easy to maintain if it's logical, has sensible data structures, and most importantly if it's thoroughly and correctly commented. Most C programmers comment little if any, apparently by tradition and training. My assembly programs are extensively commented
- roughly 4x as many characters of comment compared to code - and are easy to understand and maintain years later. And I always have a single batch file, GO.BAT, that completely rebuilds the entire project and makes a new rom file, and we archive all the tools.
I think the one-operation-per-line and resulting ease of commenting make assembly a lot easier to read than the monkeys-pounding-typewriters look of C. If you read my comments, you'll know exactly what's happening and why.
John
.SBTTL . XMAC : MACRO EXECUTION ENGINE
; THIS IS ENTERED WITH A0 AIMING AT A MACRO CODE FOLLOWED BY A ; PARAMETER LIST. THIS IS USUALLY IN VME SPACE, BUT CAN BE IN ROM ; WHEN THAT'S USEFUL. WE ALWAYS COPY THE COMMAND AND PARAMETERS ; INTO THE 'MAC' SPACE IN CPU RAM, TO ALLOW ROM INVOCATIONS AND ; TO SPEED UP MACRO EXECUTIONS, ESPECIALLY FOURIER FUNCTIONS. ; ; WE'LL TRY TO EXECUTE THE MACRO, AND WILL RETURN STATUS ; IN D7. B15 WILL BE UP IF WE DETECT AN ERROR.
XMAC: CLR.W AFLAG.W ; NUKE 'ADD WAVE' REQUEST
MOVE.W # 0FF00h, D7 ; ERROR CODE 255 WILL BE 'BAD MACRO'
MOVE.W (A0), D0 ; NAB CALLER'S COMMAND CODE ANDI.W # 255, D0 ; ISOLATE LOW BYTE CMPI.W # MAXIM, D0 ; CHECK AGAINST LIMIT BHI BADMAC ; POST ERROR IF OUT OF RANGE.
; NOW COPY THE ENTIRE COMMAND BLOCK...
MOVEA.W # MAC, A1 ; AIM AT DESTINATION IN CPU RAM MOVE.W # 110, D6 ; MAKE DBF COUNT FOR COMMAND+110 PARAMS
C has the big advantage that many canned routines already exist, but C is an ugly language written by programmers for programmers, the things that are easy to write in C for the PIC are the things that are easy to write in assembly, interfacing with I/O is where you spend most of your hours working with micro's and C hinders you here.
You had toes to grow toenails on to make clippings out of? Wow! Talk about having it soft!
--
Don Bruder - dakidd@sonic.net - If your "From:" address isn\'t on my whitelist,
or the subject of the message doesn\'t contain the exact text "PopperAndShadow"
somewhere, any message sent to this address will go in the garbage without my
ever knowing it arrived. Sorry... for more info
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.