Maker Pro
Maker Pro

C or Assembly

  • Thread starter Abstract Dissonance
  • Start date
A

Abstract Dissonance

Jan 1, 1970
0
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).



Thanks,
Jon
 
S

Stef Mientki

Jan 1, 1970
0
Abstract said:
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).



Thanks,
Jon
take a look at JAL,
and beware there will be a new version within short time,
with many more great features.

Stef Mientki
 
J

John Fields

Jan 1, 1970
0
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).
 
S

Stef Mientki

Jan 1, 1970
0
then I'm probably be a woman,
but at least I get results (fast) !!
Stef
 
A

Abstract Dissonance

Jan 1, 1970
0
Are these the same men with no GF's/Wifes? ;)
 
A

Abstract Dissonance

Jan 1, 1970
0
Stef Mientki said:
take a look at JAL,
and beware there will be a new version within short time,
with many more great features.

Ok, I'll check it out. What would be nice is a masm like port!!! ;) Then I'd
be in heaven.
Stef Mientki

Thanks,
Jon
 
J

John Jardine.

Jan 1, 1970
0
Abstract Dissonance said:
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).



Thanks,
Jon
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
 
B

Bob Myers

Jan 1, 1970
0
John Fields said:
_Real_ men program in assembler! ;)

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....

Bob M.
 
D

David L. Jones

Jan 1, 1970
0
Abstract said:
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).



Thanks,
Jon

C is
- *much* easier and quicker to write
- easier to debug
- easier to port to another micro entirely
- 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.

Dave :)
 
Abstract said:
Which is better to program in, in general, for Microchip's pics; C or
Assembly?

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.
 
B

Byron A Jeff

Jan 1, 1970
0
Abstract Dissonance said:
Which is better to program in, in general, for Microchip's pics; C or
Assembly?

This is a question with a multistage answer.

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.

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!!!".

How about a single instruction? Here's the outline for a Turing complete
one instruction computer:

http://en.wikipedia.org/wiki/OISC
http://en.wikipedia.org/wiki/URISC

At the end of the day, instructions are available for convenience and
abstraction.
Are there any drawbacks to using C(besides bloating?)?

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.
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.

Again you should have a reading level understanding of assembly. In general
that means tackling at least one significant project in assembly.
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").

There are lots of registers to work with. W just has to be one of them! ;-)
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).

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:

http://www.engj.ulst.ac.uk/sidk/PIC/mplink_tut.pdf

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.

BAJ
 
B

Byron A Jeff

Jan 1, 1970
0
Abstract Dissonance said:
Which is better to program in, in general, for Microchip's pics; C or
Assembly?

One addendum:

While your original "get my programmer working" thread was appropriate
for this newsgroup, this question is better suited for comp.arch.embedded.

Also it may help if you join in the PICLIST. 2000+ pic enthusiasts can be
real helpful. You can get the skinny at www.piclist.com.

BAJ
 
J

John Larkin

Jan 1, 1970
0
C is
- *much* easier and quicker to write
- easier to debug
- easier to port to another micro entirely
- 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.


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

FILCH: MOVE.W (A0)+, (A1)+ ; COPY, WORDWISE.
DBF D6, FILCH

ASL.W # 1, D0 ; SCALE CMD * 2 FOR WORD LOOKUP
ADDI.W # DISMAL, D0 ; ADD IN TABLE START
MOVEA.W D0, A1 ; COPY TO AN ADDRESS REG

MOVEA.W (A1), A1 ; POP THE ROUTINE ADDRESS
JMP (A1) ; AND HOP TO IT.


; ALL COMMAND ERRORS JUMP HERE:

BADMAC: ORI.W # B15, D7 ; POST THE 'MACRO ERROR' CODE
CLR.B D7 ; AND NUKE 'COMMAND CODE' FIELD
RTS ; (BITS 8-14 HOLD ERROR CODES)

; AND SUCESSFUL MACROS EXIT HERE:

OKAY: CLR.W D7 ; HERE, INDICATE GOODNESS
RTS

.SBTTL . MACRO COMMAND DISPATCH TABLE

DISMAL: .WORD BADMAC ; 00 ILLEGAL COMMAND
.WORD FOURS ; 01 BUILD FOURIER SERIES
.WORD FOURA ; 02 ADD FOURIER
.WORD GEAR ; 03 BUILD GEAR

.WORD BADMAC ; 04
.WORD PULSE ; 05 BUILD PULSE TRAIN
.WORD PULSA ; 06 OVERLAY PULSE TRAIN
.WORD BADMAC ; 07 (BUILD NOISE)

.WORD BADMAC ; 08 (ADD NOISE)
.WORD CONST ; 09 LOAD CONSTANT
.WORD BADMAC ; 0A
.WORD BADMAC ; 0B (COPY WAVEFORM)

.WORD BADMAC ; 0C
.WORD FREAK ; 0D MEASURE FREQUENCY
.WORD BADMAC ; 0E
.WORD SWEEP ; 0F SWEEP

.WORD BADMAC ; 10
.WORD BADMAC ; 11
.WORD BADMAC ; 12
.WORD BADMAC ; 13

.WORD BADMAC ; 14
.WORD BADMAC ; 15
.WORD BADMAC ; 16
.WORD BADMAC ; 17

.WORD BADMAC ; 18
.WORD BADMAC ; 19
.WORD BADMAC ; 1A
.WORD BADMAC ; 1B

.WORD BADMAC ; 1C
.WORD BADMAC ; 1D
.WORD BADMAC ; 1E
.WORD BADMAC ; 1F

.WORD REINIT ; 20 REINITIALIZE
.WORD BADMAC ; 21 DEMO SETUP
.WORD TVME ; 22 TEST VME DPM
.WORD TWAVE ; 23 TEST WAVEFORM MEMORY

.WORD TWITCH ; 24 TEST WATCHDOG TIMER
.WORD HIBER ; 25 HIBERNATE
.WORD URAM ; 26 TEST CPU SRAM

MAXIM = 26h ; LAST LEGAL MACRO CODE
 
M

Michael A. Terrell

Jan 1, 1970
0
Bob said:
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....

Bob M.


You had pebbles?


--
Service to my country? Been there, Done that, and I've got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida
 
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.
 
P

petrus bitbyter

Jan 1, 1970
0
Abstract Dissonance said:
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).



Thanks,
Jon

I never wrote a C-program for a PIC without the need for inline assembly.

petrus bitbyter
 
D

Don Bruder

Jan 1, 1970
0
Bob Myers said:
Well, whenever the budget permitted it. Sometimes, we were
forced to use toenail clippings...

Bob M.

You had toes to grow toenails on to make clippings out of? Wow! Talk
about having it soft!
 
B

Bob Myers

Jan 1, 1970
0
Michael A. Terrell said:
You had pebbles?

Well, whenever the budget permitted it. Sometimes, we were
forced to use toenail clippings...

Bob M.
 
S

Sambo

Jan 1, 1970
0
Abstract said:
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).



Thanks,
Jon


If somebody warned me about the hardships of comparing two values, I might have at least considered a C compiler, other than that...

Cheers
 
Top