12F675 | 16F628 | 16F84 | 16f877 | 16F877A | 16F88 | 18F458 | ADC | AVR | Bootloader | CAN | CCS | CRC | EAGLE | EEPROM | ICD | ICSP | IDE | JDM | LED | Macros | Microchip | MPLAB | PCB-CAD | PIC10F | Pic12f675 | PIC16F84 | PIC16F84A | PIC16F877 | PIC18 | PIC18F452 | PicBasic | PICC | PICSTART | PWM | RS-485 | RS232 | SMT | SPI | UART | USART | USB | Wireless | Wisp628 | Xilinx

A few people have expressed reservations about using C to program the
smaller PICs, especially when the program is pretty simple.

One thing that keeps coming up (and Microchip themselves say) is that PIC
assembly language is easy to learn, especially as there are "only 33
instructions to learn".

But I think there is a big difference between learning the PIC instructions,
and actually learning how to program in assembly language. Take this:

a = b * c

This is utterly trivial to write in C (indeed, I've just written it), but
multiplication is not trivial at all in assembly language. In particular,
in C I don't need to worry whether a, b and c are floating point or integer
values - it's written the same - whereas programming a floating point
multiplication in assembly language is very different from programming an
integer multiplication.

There are lots of other examples of how much easier C is than assembly. Not
least being the mega-kludge of bank-switched memory, which you can pretty
well forget about in C (simply because the compiler looks after it for you).

C lets you bash the bits much the same as assembly does: I'm not sure I buy
the argument that you "need" to use assembly to get the best from the chip.
Yes - you have the opportunity to optimise your assembly code, and with
sufficient expertise you will probably make a better job than the C
compiler. But I've seen assembly code that is LESS efficient (slower or
bigger) than that produced by the compiler - it all depends on the skill of
the programmer.

In most cases it isn't necessary to wring the last bit of performance out of
every clock cycle, so compiled code is usually perfectly OK.

But my main point is that assembly language programming is NOT easy to learn
- it's actually much harder than C programming. I don't think I really
understand why so many PIC programmers seem rather anti-C. My approach is
the opposite: I always program in C unless there's a compelling reason to
drop back into assembly language.

Any thoughts?

SteveT
------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

> I always program in C unless there's a compelling reason to
> drop back into assembly language.
>
> Any thoughts?

None, just agreement. That's word for word what I teach my students.

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu
------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

--- In p...@yahoogroups.com, "Staiger" wrote:
>
> ... I always program in C unless there's a compelling reason to
> drop back into assembly language.
>
> Any thoughts?

Just a question: What C compiler(s) do you use?

Best regards,
John
------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

--- In p...@yahoogroups.com, "Staiger" wrote:

> But my main point is that assembly language programming is NOT easy
to learn
> - it's actually much harder than C programming. I don't think I really
> understand why so many PIC programmers seem rather anti-C. My
approach is
> the opposite: I always program in C unless there's a compelling
reason to
> drop back into assembly language.
>
> Any thoughts?
>
> SteveT
>

I certainly agree about using C instead of ASM and the complexity of
learning to use ASM effectively.

Sometimes it is good to see the ASM code the C compiler emits just as
a learning exercise. Or look at other good ASM code. Some Microchip
app notes have excellent code. Others...not so much.

For things like multi-byte arithmetic or floating point, steal a
library and study the calling conventions. NOBODY should write a math
library. There are too many available, even from Microchip.

Another tool for simplifying ASM is the macro capability. Once you
know how to diddle a few bits for an application (set output to 0 to
turn on - kind of reverse thinking), write a macro with or without
parameters. Call it what is does: GreenLEDon or whatever.n.

But, given the availability of C for the PIC of choice (and it won't
be available for every variant), by all means, use it.

Richard

------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

--- In p...@yahoogroups.com, "jmsmith871" wrote:
>
> --- In p...@yahoogroups.com, "Staiger" wrote:
> >
> > ... I always program in C unless there's a compelling reason to
> > drop back into assembly language.
> >
> > Any thoughts?
>
> Just a question: What C compiler(s) do you use?
>
> Best regards,
> John
>

cc5x and PIC C Lite - both are demo versions with some kind of limitation.

Richard

------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Well, I can't really see why people, and especially beginners should be hell bent on using C and shying away from asm.
Actually I think beginners are better off starting with asm because it gives better understanding of what is actually
happening deep down in the bowls of the chip...

And these little PIC chips don't need C to get things done, and the smaller ones are probably best programmed in asm
anyhow.

Just build up a asm library of commonly used routines (macros) and you're half way to C, but still in asm.
E.g take this equation for a Infinite Impulse Response (IIR) filter:
AVG:F=(((256-k)*AVG:F)/256) + (k*NEW))/256
There are 16 and 24bit values/variables in there with fractional divisions and multiplications, and the beginner might think that this would be very difficult to do in
asm and that C would be more or less required for this type of thing..... WRONG!

See how easy this (and more) can be done in asm:

;************************* ANALOG AQUSITION AND FILTERING **********************
ADCACQ_ch0
;Heavy filtering is required to remove all traces of noise. This is acomplished
;by using a Infinite Impulse Response (IIR) filter. The effect is roughly equal
;to a 232 sample averaging filter. The basic equation for the IIR filter is
;AVG=(((256-k)*AVG) + (k*NEW))/256. However this filter has feedback, and the
;rounding effects from the division causes a gain offset and a hysteresis at the
;output for the larger filter factors (low k-values). This is largely eliminated
;by usinig one fractional byte (remainder) from the division. The equation then
;becomes: AVG:F=(((256-k)*AVG:F)/256) + (k*NEW))/256
;the AVG with the fractional byte is only used for feedback into the filter, the
;actual filter output is truncated to AVG.
;Input:16bit data from ADC and 8bit filter factor.
;Output:16bit filtered data in ANAVG.
;Cycles:1262
MOVFF BSR,BSRTMP
MOVFF ADCON0,WREG ;
ANDLW B'11000111'
IORLW B'00000000' ;Select ch0
MOVFF WREG,ADCON0 ;
MOVLW 0X80
ACQ0WAIT DECFSZ WREG ;Wait here while the holding capacitor charges
BRA ACQ0WAIT
BSF ADCON0,GO ;start new conversion
ADC0WAIT BTFSC ADCON0,GO ;ADC done?
BRA ADC0WAIT ;No!
MOVFF ADRESL,ADC+B0 ;Yes! copy ADRES to variable
MOVFF ADRESH,ADC+B1
MOVFF KVAL,WREG ;To avoid a 16bit subtraction we do a 255-k
SUBLW 0XFF ;and then add 1 to the result.
INCF WREG ;Wreg is now (256-k)
MOVFF WREG,BARGB0 ;Multiply...
CLRF BARGB1 ;(256-k)*
MOV24 CH0BUFF,AARGB0 ;ANAVG:F, 16bit AVG plus 8bit fractional
CALL MUL2416SU ;=((256-k)*AVG:F)
MOV32 AARGB1,TEMP0 ;after truncation: ((256-k)*AVG:F)/256 -> TEMP
MOV16 ADC,BARGB0 ;Multiply ADC*
MOVFF KVAL,AARGB2 ;k
CLRF AARGB3 ;
CLRF AARGB0
CALL FXM1616S ;=(k*ADC)
ADD32 AARGB0,TEMP0 ;=(((256-k)*AVG:F)/256) + (k*ADC)
MOV32 TEMP0,AARGB0 ;Divide...
CLRF BARGB0 ;
MOVLW 0X01 ;by 100h
MOVFF WREG,BARGB1
CLRF BARGB2
CLRF BARGB3
CALL DIV32_32 ;AVG:F=(((256-k)*AVG:F)/256) + (k*ADC))/256
MOV16 AARGB0,CH0BUFF+1 ;Move 16bit integer to ANAVG and
MOVFF REMB3,CH0BUFF ;extend to 24bits by moving remainder to ANAVG LSD.
MOV16 CH0BUFF+1,AN_ch0 ;Filtered 16bit output.
CALL SCALEHIGH ;Scale to fit
MOVFF BSRTMP,BSR
RETURN
;*****************************************************************
You'll see references to the math library which contains subs/functions and macros.
This is a quick and dirty routine I made many years ago for a PIC18. It is not super efficient but it works.

I would say learn asm first, then move to C if necessary.
Staiger wrote:

> A few people have expressed reservations about using C to program the
> smaller PICs, especially when the program is pretty simple.
>
> One thing that keeps coming up (and Microchip themselves say) is that PIC
> assembly language is easy to learn, especially as there are "only 33
> instructions to learn".
>
> But I think there is a big difference between learning the PIC instructions,
> and actually learning how to program in assembly language. Take this:
>
> a = b * c
>
> This is utterly trivial to write in C (indeed, I've just written it), but
> multiplication is not trivial at all in assembly language. In particular,
> in C I don't need to worry whether a, b and c are floating point or integer
> values - it's written the same - whereas programming a floating point
> multiplication in assembly language is very different from programming an
> integer multiplication.
>
> There are lots of other examples of how much easier C is than assembly. Not
> least being the mega-kludge of bank-switched memory, which you can pretty
> well forget about in C (simply because the compiler looks after it for you).
>
> C lets you bash the bits much the same as assembly does: I'm not sure I buy
> the argument that you "need" to use assembly to get the best from the chip.
> Yes - you have the opportunity to optimise your assembly code, and with
> sufficient expertise you will probably make a better job than the C
> compiler. But I've seen assembly code that is LESS efficient (slower or
> bigger) than that produced by the compiler - it all depends on the skill of
> the programmer.
>
> In most cases it isn't necessary to wring the last bit of performance out of
> every clock cycle, so compiled code is usually perfectly OK.
>
> But my main point is that assembly language programming is NOT easy to learn
> - it's actually much harder than C programming. I don't think I really
> understand why so many PIC programmers seem rather anti-C. My approach is
> the opposite: I always program in C unless there's a compelling reason to
> drop back into assembly language.
>
> Any thoughts?
>
> SteveT
>

--
*******************************************
VISIT MY HOME PAGE:

LAST UPDATED: 23/08/2003
*******************************************
Regards
Eirik Karlsen
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

--- In p...@yahoogroups.com, Eirik Karlsen wrote:
>
> Well, I can't really see why people, and especially beginners should
be hell bent on using C and shying away from asm.
> Actually I think beginners are better off starting with asm because
it gives better understanding of what is actually
> happening deep down in the bowls of the chip...
>
> And these little PIC chips don't need C to get things done, and the
smaller ones are probably best programmed in asm
> anyhow.
>
> Just build up a asm library of commonly used routines (macros) and
you're half way to C, but still in asm.
> E.g take this equation for a Infinite Impulse Response (IIR) filter:
> AVG:F=(((256-k)*AVG:F)/256) + (k*NEW))/256
> There are 16 and 24bit values/variables in there with fractional
divisions and multiplications, and the beginner might think that this
would be very difficult to do in
> asm and that C would be more or less required for this type of
thing..... WRONG!
>
> See how easy this (and more) can be done in asm:
>
> ;************************* ANALOG AQUSITION AND FILTERING
**********************
> ADCACQ_ch0
> ;Heavy filtering is required to remove all traces of noise. This is
acomplished
> ;by using a Infinite Impulse Response (IIR) filter. The effect is
roughly equal
> ;to a 232 sample averaging filter. The basic equation for the IIR
filter is
> ;AVG=(((256-k)*AVG) + (k*NEW))/256. However this filter has
feedback, and the
> ;rounding effects from the division causes a gain offset and a
hysteresis at the
> ;output for the larger filter factors (low k-values). This is
largely eliminated
> ;by usinig one fractional byte (remainder) from the division. The
equation then
> ;becomes: AVG:F=(((256-k)*AVG:F)/256) + (k*NEW))/256
> ;the AVG with the fractional byte is only used for feedback into the
filter, the
> ;actual filter output is truncated to AVG.
> ;Input:16bit data from ADC and 8bit filter factor.
> ;Output:16bit filtered data in ANAVG.
> ;Cycles:1262
> MOVFF BSR,BSRTMP
> MOVFF ADCON0,WREG ;
> ANDLW B'11000111'
> IORLW B'00000000' ;Select ch0
> MOVFF WREG,ADCON0 ;
> MOVLW 0X80
> ACQ0WAIT DECFSZ WREG ;Wait here while the holding capacitor charges
> BRA ACQ0WAIT
> BSF ADCON0,GO ;start new conversion
> ADC0WAIT BTFSC ADCON0,GO ;ADC done?
> BRA ADC0WAIT ;No!
> MOVFF ADRESL,ADC+B0 ;Yes! copy ADRES to variable
> MOVFF ADRESH,ADC+B1
> MOVFF KVAL,WREG ;To avoid a 16bit subtraction we do a 255-k
> SUBLW 0XFF ;and then add 1 to the result.
> INCF WREG ;Wreg is now (256-k)
> MOVFF WREG,BARGB0 ;Multiply...
> CLRF BARGB1 ;(256-k)*
> MOV24 CH0BUFF,AARGB0 ;ANAVG:F, 16bit AVG plus 8bit fractional
> CALL MUL2416SU ;=((256-k)*AVG:F)
> MOV32 AARGB1,TEMP0 ;after truncation: ((256-k)*AVG:F)/256 -> TEMP
> MOV16 ADC,BARGB0 ;Multiply ADC*
> MOVFF KVAL,AARGB2 ;k
> CLRF AARGB3 ;
> CLRF AARGB0
> CALL FXM1616S ;=(k*ADC)
> ADD32 AARGB0,TEMP0 ;=(((256-k)*AVG:F)/256) + (k*ADC)
> MOV32 TEMP0,AARGB0 ;Divide...
> CLRF BARGB0 ;
> MOVLW 0X01 ;by 100h
> MOVFF WREG,BARGB1
> CLRF BARGB2
> CLRF BARGB3
> CALL DIV32_32 ;AVG:F=(((256-k)*AVG:F)/256) + (k*ADC))/256
> MOV16 AARGB0,CH0BUFF+1 ;Move 16bit integer to ANAVG and
> MOVFF REMB3,CH0BUFF ;extend to 24bits by moving remainder to
ANAVG LSD.
> MOV16 CH0BUFF+1,AN_ch0 ;Filtered 16bit output.
> CALL SCALEHIGH ;Scale to fit
> MOVFF BSRTMP,BSR
> RETURN
> ;*****************************************************************
> You'll see references to the math library which contains
subs/functions and macros.
> This is a quick and dirty routine I made many years ago for a PIC18.
It is not super efficient but it works.
>
> I would say learn asm first, then move to C if necessary.

I think you make the point perfectly for writing the code in C.
Although nicely documented, the code is totally obscure and takes
about 40 lines to do what can easily be done in a single C statement.
I know which one I would rather maintain.

This is exactly the reason that programmers, particularly for the 18F
variants, might just as well start with C.

The other advantage to C is that, well, C is C. Some days I work with
PIC, some days it's AVR. Then it's Blackfin and then it's ARM. But,
C is C. While the PIC ASM language may have ony a few instructions,
these other devices have a HUGE set of instructions. And they're all
different.

I like ASM. I really like macro ASM. But if C is available, I'd
rather just cut to the chase.

They (IBM, et al) used to say that a programmer could write about 100
debugged statements per day. Big statements or little statements, the
lines were the same. Hence the push for high level languages.

Richard

------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

> Well, I can't really see why people, and especially beginners should be
> hell bent on using C and shying away from asm.
> Actually I think beginners are better off starting with asm because it
> gives better understanding of what is actually
> happening deep down in the bowls of the chip...

Different people have different learning modes. Some prefer bottom-up
(start with assembler), some prefer top-down (start with Haskell). Some
prefer theory-first, some prefer learn-by-examples. Some prefer to
hear/read (that seems to be the same as far as your brain is concerned),
some prefer to see (<>read) or do (with their own hands). Some are happy
with an abstraction an don't want/need to know the details, some can't
grok anything without at least a hint of how it works.

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu
------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

My point is just that asm is not so terribly difficult as some (newbees) and hobbyists seem to think.
However in a professional or commercial environment where cost and development time is of
vital importance I wouldn't think of using asm... there you "have to" use C.
The reason is simply portability of the code and that C code is more or less independent of the chips
instruction set or even chip vendor. Also "everyone" can read your code when you're left the company.

But as a hobbyist I tend to stick with only one chip type for years. The last 4 years I've stuck to the PIC18
series and as a hobbyist I have no need or desire to use anything else... and asm works just fine for me.

One reason may be that I've never really used C, not since the '90s anyway, and my C skills are far
below asm.

rtstofer wrote:
> I think you make the point perfectly for writing the code in C.
> Although nicely documented, the code is totally obscure and takes
> about 40 lines to do what can easily be done in a single C statement.
> I know which one I would rather maintain.
>
> This is exactly the reason that programmers, particularly for the 18F
> variants, might just as well start with C.
>
> The other advantage to C is that, well, C is C. Some days I work with
> PIC, some days it's AVR. Then it's Blackfin and then it's ARM. But,
> C is C. While the PIC ASM language may have ony a few instructions,
> these other devices have a HUGE set of instructions. And they're all
> different.
>
> I like ASM. I really like macro ASM. But if C is available, I'd
> rather just cut to the chase.
>
> They (IBM, et al) used to say that a programmer could write about 100
> debugged statements per day. Big statements or little statements, the
> lines were the same. Hence the push for high level languages.
>
> Richard
--
*******************************************
VISIT MY HOME PAGE:

LAST UPDATED: 23/08/2003
*******************************************
Regards
Eirik Karlsen
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Eirik Karlsen wrote:
> My point is just that asm is not so terribly difficult as some (newbees)
> and hobbyists seem to think.

It is not so terribly difficult to understand a (small) instruction set,
but actually doing something with those instructions can be terribly
difficult, especially compared to doing the same thing in a HLL like C.

For one of my classes I use a 1-bit computer that has just 3
instructions: LOAD A (from a memory address), LOAD B (idem), and STORE A
nand B (to a memory address). (Yes I know, I could have used only 2
instructions). You can do everything with just these instructions, but
it is not easy. For a starter, try and 8 bit * 8 bit => 8 bit multiply.

Also note that for 12 and 14 bit cores the instruction set might be
simple, but there are things like code paging, memory banking, and the
use of indirection, that make actually using these few instructions a
real PITA. For 18F's this is much less of a problem.

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu
------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

My input into the assembler vs C issue is one based on professional
experience. By "professional", I mean paid work on larger projects
with time constraints, as opposed to hobbyist projects, and has
nothing to do with the program quality.

First, I've heard C referred to as high-level assembly programming.
Someone made the assertion that you should start with assembly to
"learn" how to use the PIC registers. C gives you the exact same
access assembly does, so if you don't know the PIC, C isn't going to
help and do it for you.

Bank-switching to access RAM is a loaded minefield. I've worked on
assembly programs of 10,000 lines. In making modifications, you
sometimes need to ad new RAM access to a block of code, and now need
to bank-switch from the original block to a new one. C will do this
automatically. And you also have to be VERY careful on returning from
subroutine calls in ASM. If you come back with a different bank
selected, the calling routine will not be able to access its desired
bank. There's nothing like stepping through the debugger and seeing
some variable not being updated in the watch window because you're in
the wrong bank.

Paging for longs calls and jumps also falls under the previous
category. And if your code overflows a page boundary, well, you're out
of luck and have to do some reshuffling, not to mention possibly going
back and changing ALL the page selections when going to certain addresses.

One issue that would be difficult to do in ASM is implementing local
variables. In C, these would be allocated automatically for any
variables defined within a function, then would be freed up after the
function returns. This gives the program extra RAM space, and might
make a big difference if the RAM space is tight. You can try to do
this with ASM, but now you're talking about setting up a heap space,
defining variable names within that heap, making sure that routines
called sequentially don't use the same space within the heap,
and...NOO!!! Don't even TRY this when C will do this for you!

Efficiency has also been mentioned for ASM. Unless you're transferring
gobs of data through an Ethernet connection, there should not be a
real issue on this. If your project is bottlenecked because C is only
half as fast as ASM, either rewrite a specific function only in ASM
(you can mix the two), or better yet, use a faster chip! Moving from
an 18F to a 24F will provide drastic increases in throughput, since
the native register size is now 16 bits instead of 8, no banking or
paging is required, etc. In the software world, it is usually cheaper
to throw some more hardware at the problem than it is to triple the
development time. Unless you plan on selling 100,000 widgets a month
or so.

I used to work at Motorola, and the embedded design engineers there
had a software modeling program they used which actually wrote most of
the embedded code used for automotive modules (door, seat, light
units). It allowed them to "reposition" program code diagrammatically
instead of touching the source code directly. "Simple" changes that
could take days to modify and retest took an hour or two.

------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Well of course there are lots of thoughts about this! The old classic
language wars. It really depends on you, your skill level, your chosen
areas of work, and your willingness to learn new things.

The PIC is a bit of an oddity in the microcontroller realm because of
its strange structure and small page sizes. And although it has several
eternal compilers available I would suggest that most users stick with
the Microchip supplied stuff, so many of the darwbacks I see to the use
of compilers on other micros probably don't apply to the PIC. these are
mostly related to the fact that C was never intended for small
microcontrolers and real time operations, therefore its bit handling is
arcane to say the least, and also the C 'STANDARD is incredibly loose
whe it comes to many microcontroller type operations. Thus compiler
vendors are free to implement many things as they wish. So learning a
new compiler is often much harder than moving from one instruction set
to another.

te argument about librariies, math routines etc only holds for those
making a fresh start. Most of us with long experience should have plenty
of highly optimised maths libaries at our disposal. Certainly whe i
started with PICs years ago as distributed controllers for robotic wafer
handlers I found the Microchip app notes fantatstic, and along with
those and my existing library of optimised maths from the Intel 8xxx
microcontrollers It was a task of an hour or so to tweak the microchip
libraries. The same was done with graphics drivers, and all the other
useful stuff.

The biggest point though is that you can write rubbish in any language.
I've seen C programmes with 2000 lines of code for a single function,
that forced a reset every time it needed to exit, because the programmer
didin't understand how to get C running a task scheuler from main using
interrupts. Then I've seen a 1400 line assembler program that after
starting and receiving is first interrupt, read the interrup flag byte
to the accumulator, shifted it then called sub routines sequenctially as
each bit was tested. The problem was he didin't preserve ACC first, so
on return from the first cll ACC was now whatever the call had set it
too, and the res of the calls were trash. This resulted in the system
hanging, so the inventive little sole had added a n I/O to monitor an
external packet Modem LED, becuase when his system eventually ate itself
that LED became set as the modem jammed on, and it reset his micro.

So, I prefer assembler, and am willing to bet that I can design, build
and program a new design faster than anyone can do the same in C,
because it isn't just about the language to me, but the whole package. C
may divorce you from the hardware, but I cnsider knowledge of the
hardware to be the greatest tool an embedded systems designer can have.
Too often have seen the mutant results wen a 'hardware guy' produces
his bit, without any software expertise to guide him, and the n the
'software guy' cmes along without adequete harware knowledge and
proceeds to produce as best he can.

I know my views aren't popular, but most new engineers have been
brainwashed by their uni lecturers who have convinced them that there
are 'good' and 'bad' things in languages and programming, this is
bullshit. There are bad programmers but that is all. Les face it at te
end of the day it is easier to teach C for the lecturer, and probably
easier to teach to a wider array of students, since it does take a mocre
dsciplined approach, and academia is no longer about the pursuit of
excellence, but the pursuit of bums on seats.

Al

Staiger wrote:

>A few people have expressed reservations about using C to program the
>smaller PICs, especially when the program is pretty simple.
>
>One thing that keeps coming up (and Microchip themselves say) is that PIC
>assembly language is easy to learn, especially as there are "only 33
>instructions to learn".
>
>But I think there is a big difference between learning the PIC instructions,
>and actually learning how to program in assembly language. Take this:
>
>a = b * c
>
>This is utterly trivial to write in C (indeed, I've just written it), but
>multiplication is not trivial at all in assembly language. In particular,
>in C I don't need to worry whether a, b and c are floating point or integer
>values - it's written the same - whereas programming a floating point
>multiplication in assembly language is very different from programming an
>integer multiplication.
>
>There are lots of other examples of how much easier C is than assembly. Not
>least being the mega-kludge of bank-switched memory, which you can pretty
>well forget about in C (simply because the compiler looks after it for you).
>
>C lets you bash the bits much the same as assembly does: I'm not sure I buy
>the argument that you "need" to use assembly to get the best from the chip.
>Yes - you have the opportunity to optimise your assembly code, and with
>sufficient expertise you will probably make a better job than the C
>compiler. But I've seen assembly code that is LESS efficient (slower or
>bigger) than that produced by the compiler - it all depends on the skill of
>the programmer.
>
>In most cases it isn't necessary to wring the last bit of performance out of
>every clock cycle, so compiled code is usually perfectly OK.
>
>But my main point is that assembly language programming is NOT easy to learn
>- it's actually much harder than C programming. I don't think I really
>understand why so many PIC programmers seem rather anti-C. My approach is
>the opposite: I always program in C unless there's a compelling reason to
>drop back into assembly language.
>
>Any thoughts?
>
>SteveT
>------------------------------------
>
>to unsubscribe, go to http://www.yahoogroups.com and follow the instructions

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

IBM were obviously overpaying part timers, or were operating under the
military industrial complex phenomenon of the $15000 silver hammer.

The main advantage that C is perceived to have is that simple
instructions perform the equivalent of multiple complex low level
instructions, and that it's portable. Much of its strength comes through
its libraries. Much of its weaknesses also come trough it linraries.
They often try to be architecture immune, and thus end up being
hopelessly generic. Portability is a myth. try porting code written for
IAR for example t code written for Crossworks, or any oterh compiler. It
doesn't work. Anyway I don't think I've ever been asked to move an exact
design from, say an Intel 8051 to a PIC16C54, and I've been doing this
since 1970 professionally, and since 1962 as a hobby. What invariably
happens is that somebody wants to upgade, or update their design in the
process, so the new chip has new peripherals, different ways to handle
them, new memory structires, different architecture etc etc, that
suggests a redesign is the order of the day.

Any good assembler programmer has more libraries than most C compilers,
optimised over time to suit a wide variety of different application
needs. Te general assumption always appears to be that assembler
programmers are like cavemen, or goldfish. everything they do has to be
re-invented all the time. This may be true for some masochists out
there, but not for the real engineers.

I don't come to a new design and think to mysefl how can I create a
graphics suite for this system. I cut and paste each tiny module I need.
So i don't need a complete drawing package, but if i need to have a line
draw and area fill routine, for example I can either use amacro (I
don't like macros either!) or I can simply do (PSEUDOCODE BASED ON AN
msp430 ACTUALLY):-

MOVE #LINESET,R4
CALL MULTILINE
MOVE CURSOR X,Y
CALL AREA_FILL

i REGULARLY WRITE AND DEBUG 1000+ LINES of code in a day. The difference
is that I am debugging what I wrote, not the creation of some body elses
compiler that may use arcane compression techniques that confuse the
actual method. I'd rather debug my faults than have to deal with
compiler bugs AND my own. This is how I get a micro with 8 I/O pins, 2K
of code space and 128 bytes of RAM running a an RF transceiver (CC1100)
communications with a bar code scanner, controlling a video/still camera
module, and running local bottle recogntion based on bottle labels (when
the bar code is not recognised), and then sending this over the internet
via a wirless PC hook up. That used a bubch of library processes, tat
i'av developed for years. the only new thing was control of the Cc1100.
It used 1600 instructions filled 2k of code space, plus 200 bytes of
config memory, so was a few thouand lines. Now this is nothing special,
but it hopefully illustrates that the li9ngustic advantages of C ARE
REAL ONLY WHEN COMPARED AGAINST DISORGANISED OR LAZY ASSERMBLER
PROGRAMMERS. Whoops!

Actually my favourite programming language is almost certainly the
algebraic form used by ADI in their ADSP21xx family. Since I think in
the logical fashion used, it skips all the steps of trying to understand
that logic in terms of C (which ain't too crash hot at bitwise logic anyway)

Until windows became dominant I even used to program the PC in asm. C
was something I considered a mildy better form of BASIC that was
convenient fr throwing together a quick and dirty analysis of an idea,
nothing more.
Cheers

Al

rtstofer wrote:

>--- In p...@yahoogroups.com, Eirik Karlsen wrote:
>
>
>>Well, I can't really see why people, and especially beginners should
>>
>>
>be hell bent on using C and shying away from asm.
>
>
>>Actually I think beginners are better off starting with asm because
>>
>>
>it gives better understanding of what is actually
>
>
>>happening deep down in the bowls of the chip...
>>
>>And these little PIC chips don't need C to get things done, and the
>>
>>
>smaller ones are probably best programmed in asm
>
>
>>anyhow.
>>
>>Just build up a asm library of commonly used routines (macros) and
>>
>>
>you're half way to C, but still in asm.
>
>
>>E.g take this equation for a Infinite Impulse Response (IIR) filter:
>>AVG:F=(((256-k)*AVG:F)/256) + (k*NEW))/256
>>There are 16 and 24bit values/variables in there with fractional
>>
>>
>divisions and multiplications, and the beginner might think that this
>would be very difficult to do in
>
>
>>asm and that C would be more or less required for this type of
>>
>>
>thing..... WRONG!
>
>
>>See how easy this (and more) can be done in asm:
>>
>>;************************* ANALOG AQUSITION AND FILTERING
>>
>>
>**********************
>
>
>>ADCACQ_ch0
>>;Heavy filtering is required to remove all traces of noise. This is
>>
>>
>acomplished
>
>
>>;by using a Infinite Impulse Response (IIR) filter. The effect is
>>
>>
>roughly equal
>
>
>>;to a 232 sample averaging filter. The basic equation for the IIR
>>
>>
>filter is
>
>
>>;AVG=(((256-k)*AVG) + (k*NEW))/256. However this filter has
>>
>>
>feedback, and the
>
>
>>;rounding effects from the division causes a gain offset and a
>>
>>
>hysteresis at the
>
>
>>;output for the larger filter factors (low k-values). This is
>>
>>
>largely eliminated
>
>
>>;by usinig one fractional byte (remainder) from the division. The
>>
>>
>equation then
>
>
>>;becomes: AVG:F=(((256-k)*AVG:F)/256) + (k*NEW))/256
>>;the AVG with the fractional byte is only used for feedback into the
>>
>>
>filter, the
>
>
>>;actual filter output is truncated to AVG.
>>;Input:16bit data from ADC and 8bit filter factor.
>>;Output:16bit filtered data in ANAVG.
>>;Cycles:1262
>> MOVFF BSR,BSRTMP
>> MOVFF ADCON0,WREG ;
>> ANDLW B'11000111'
>> IORLW B'00000000' ;Select ch0
>> MOVFF WREG,ADCON0 ;
>> MOVLW 0X80
>>ACQ0WAIT DECFSZ WREG ;Wait here while the holding capacitor charges
>> BRA ACQ0WAIT
>> BSF ADCON0,GO ;start new conversion
>>ADC0WAIT BTFSC ADCON0,GO ;ADC done?
>> BRA ADC0WAIT ;No!
>> MOVFF ADRESL,ADC+B0 ;Yes! copy ADRES to variable
>> MOVFF ADRESH,ADC+B1
>> MOVFF KVAL,WREG ;To avoid a 16bit subtraction we do a 255-k
>> SUBLW 0XFF ;and then add 1 to the result.
>> INCF WREG ;Wreg is now (256-k)
>> MOVFF WREG,BARGB0 ;Multiply...
>> CLRF BARGB1 ;(256-k)*
>> MOV24 CH0BUFF,AARGB0 ;ANAVG:F, 16bit AVG plus 8bit fractional
>> CALL MUL2416SU ;=((256-k)*AVG:F)
>> MOV32 AARGB1,TEMP0 ;after truncation: ((256-k)*AVG:F)/256 -> TEMP
>> MOV16 ADC,BARGB0 ;Multiply ADC*
>> MOVFF KVAL,AARGB2 ;k
>> CLRF AARGB3 ;
>> CLRF AARGB0
>> CALL FXM1616S ;=(k*ADC)
>> ADD32 AARGB0,TEMP0 ;=(((256-k)*AVG:F)/256) + (k*ADC)
>> MOV32 TEMP0,AARGB0 ;Divide...
>> CLRF BARGB0 ;
>> MOVLW 0X01 ;by 100h
>> MOVFF WREG,BARGB1
>> CLRF BARGB2
>> CLRF BARGB3
>> CALL DIV32_32 ;AVG:F=(((256-k)*AVG:F)/256) + (k*ADC))/256
>> MOV16 AARGB0,CH0BUFF+1 ;Move 16bit integer to ANAVG and
>> MOVFF REMB3,CH0BUFF ;extend to 24bits by moving remainder to
>>
>>
>ANAVG LSD.
>
>
>> MOV16 CH0BUFF+1,AN_ch0 ;Filtered 16bit output.
>> CALL SCALEHIGH ;Scale to fit
>> MOVFF BSRTMP,BSR
>> RETURN
>>;*****************************************************************
>>You'll see references to the math library which contains
>>
>>
>subs/functions and macros.
>
>
>>This is a quick and dirty routine I made many years ago for a PIC18.
>>
>>
>It is not super efficient but it works.
>
>
>>I would say learn asm first, then move to C if necessary.
>>
>>I think you make the point perfectly for writing the code in C.
>Although nicely documented, the code is totally obscure and takes
>about 40 lines to do what can easily be done in a single C statement.
> I know which one I would rather maintain.
>
>This is exactly the reason that programmers, particularly for the 18F
>variants, might just as well start with C.
>
>The other advantage to C is that, well, C is C. Some days I work with
>PIC, some days it's AVR. Then it's Blackfin and then it's ARM. But,
>C is C. While the PIC ASM language may have ony a few instructions,
>these other devices have a HUGE set of instructions. And they're all
>different.
>
>I like ASM. I really like macro ASM. But if C is available, I'd
>rather just cut to the chase.
>
>They (IBM, et al) used to say that a programmer could write about 100
>debugged statements per day. Big statements or little statements, the
>lines were the same. Hence the push for high level languages.
>
>Richard
>
>------------------------------------
>
>to unsubscribe, go to http://www.yahoogroups.com and follow the instructionsYahoo! Groups Links
>
>
>



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Not every 'professional' job means large code, in fact the majority of
micros are deployed in very simple applications. Most white goods jobs,
for example are severely price constrained in the hardware. Who cares if
you pay a guy to improve the code and it takes a month longer when you
are going to sell 2-3million a year of these things. Software should
happen once, the hardware costs lasts for ever.

In this case the smallets cheapest design matters. 1cent in hardware
saved is huge. One of the tightest designs I ever did replaced a Philips
ASIC used in washing machine motor contol (actually a set of several,
each with one or two different parameters, like supply voltage, spin
speeds etc) with a single device that ultimately cost 90c less than the
philips part, yet managed everything it did in a single, configurable
device, and added a few features.

More recently by the use of asembler over C I was able to move a job
from a micro with 4k of code space to one with just 1k of code space,
yet fixed a few bugs and improved performance on the way, in doing so i
got the manufacturing cost per unit down from just under $9 to $4.60.
Only marginally over half the original. based on sales of 500,000 units
a year I figure $2.3b saved is pretty enormous for the client, yet the
task took just over a week to do, compared to the original development
(in an 8k part of nearly 3 years followed by almost a year with a highly
recommended third party developer to get it down to 3.7k.

recently I looked at the PIC32 with a view to entering the design
competition, but frankly I couldn't think of anything that truly needed
that amount of power, that I wanted to do, that I couldn't do on a
smaller more efficient part, and to me the 'lets just throw a bigger
micro at it' solution is part of what is wrong with programming now.
It's why we have to suffer wth bloated inefficient costly systems.

On the other scale of things I've worked on massive projects, including
automotive. Some early FOD ECU's were moto based, and Ive seen the
aftermath of the development methods. 5 years in development and trials
and then it goes to the filed and is so buggy it has to be withdrawn,
but to save face the old ECU is shipped in the new ECU box so people
think they have the latest and greatest. My favourite ECU design ever
was done on a PIC12C74 (the final version fit in a 12C72, but the PROM
version was the 4k. Why do this? Actually because I am a big fan of
small micros, and someone on the net was shouting about how useless 8
pinners they were, what sort of 'serious; application could you use one
for (define serious? any application that sells and makes money is serious!)

This did everything a normal ECU did, :-

vac sensor
'TPS
Air temp
Engine temp
OXY sensor
2 banks of injector drivers
single ignition coil
RPM/CPS sensor
real time adaptive learn
and even included a spare pin (if both RPM and CPS weren't used) for
motro control such as AC shut down under load.
It drives my sons VWbug, a friends V8, and powered a couple of
microlights too.

My biggest project was probably for an embedded 8xx86/88 based design in
the late 80's running to a couple of meg in total. That was used to
measure the thickness and analyse each of several layers of deposited
film on a wafer

I don't use asm beause I don't know C, indeed I've written real time
voice and audio codec in C that ran on a PC, back as far as 1991, adn
speech recog in the mid 90's. There is nothing you can do in a high
level language that wasn't done first in asm, and can't be done in asm
if desirable, but there are many things that can be done in asm that
high levels languages prevent you from doing.

Not everybody can get their head around asm, but if you can it soon
becomes as easy as anything else that you practice.

Al

jvoytovich wrote:

>My input into the assembler vs C issue is one based on professional
>experience. By "professional", I mean paid work on larger projects
>with time constraints, as opposed to hobbyist projects, and has
>nothing to do with the program quality.
>
>First, I've heard C referred to as high-level assembly programming.
>Someone made the assertion that you should start with assembly to
>"learn" how to use the PIC registers. C gives you the exact same
>access assembly does, so if you don't know the PIC, C isn't going to
>help and do it for you.
>
>Bank-switching to access RAM is a loaded minefield. I've worked on
>assembly programs of 10,000 lines. In making modifications, you
>sometimes need to ad new RAM access to a block of code, and now need
>to bank-switch from the original block to a new one. C will do this
>automatically. And you also have to be VERY careful on returning from
>subroutine calls in ASM. If you come back with a different bank
>selected, the calling routine will not be able to access its desired
>bank. There's nothing like stepping through the debugger and seeing
>some variable not being updated in the watch window because you're in
>the wrong bank.
>
>Paging for longs calls and jumps also falls under the previous
>category. And if your code overflows a page boundary, well, you're out
>of luck and have to do some reshuffling, not to mention possibly going
>back and changing ALL the page selections when going to certain addresses.
>
>One issue that would be difficult to do in ASM is implementing local
>variables. In C, these would be allocated automatically for any
>variables defined within a function, then would be freed up after the
>function returns. This gives the program extra RAM space, and might
>make a big difference if the RAM space is tight. You can try to do
>this with ASM, but now you're talking about setting up a heap space,
>defining variable names within that heap, making sure that routines
>called sequentially don't use the same space within the heap,
>and...NOO!!! Don't even TRY this when C will do this for you!
>
>Efficiency has also been mentioned for ASM. Unless you're transferring
>gobs of data through an Ethernet connection, there should not be a
>real issue on this. If your project is bottlenecked because C is only
>half as fast as ASM, either rewrite a specific function only in ASM
>(you can mix the two), or better yet, use a faster chip! Moving from
>an 18F to a 24F will provide drastic increases in throughput, since
>the native register size is now 16 bits instead of 8, no banking or
>paging is required, etc. In the software world, it is usually cheaper
>to throw some more hardware at the problem than it is to triple the
>development time. Unless you plan on selling 100,000 widgets a month
>or so.
>
>I used to work at Motorola, and the embedded design engineers there
>had a software modeling program they used which actually wrote most of
>the embedded code used for automotive modules (door, seat, light
>units). It allowed them to "reposition" program code diagrammatically
>instead of touching the source code directly. "Simple" changes that
>could take days to modify and retest took an hour or two.
>
>------------------------------------
>
>to unsubscribe, go to http://www.yahoogroups.com and follow the instructions

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

> More recently by the use of asembler over C I was able to move a job
> from a micro with 4k of code space to one with just 1k of code space,
> yet fixed a few bugs and improved performance on the way, in doing so i
> got the manufacturing cost per unit down from just under $9 to $4.60.

Wow, that was an expensive chip. Most PICs don't trop that far in price
when switching from 4k code to 1k.

> Only marginally over half the original. based on sales of 500,000 units
> a year I figure $2.3b saved is pretty enormous for the client, yet the
> task took just over a week to do, compared to the original development
> (in an 8k part of nearly 3 years followed by almost a year with a highly
> recommended third party developer to get it down to 3.7k.

I certainly don't say that assembler has no place. But one should do an
(approximate) calculation like you do. If your client sold 1k units/y
your code size reduction would have been a waste. (but the bugfixes
could still make it worthwile).

> Not everybody can get their head around asm, but if you can it soon
> becomes as easy as anything else that you practice.

I recon that I did and still do, but for me it certain is not as easy as
anything else. Maybe you never got your head around proper HLL use?

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu
------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

--- In p...@yahoogroups.com, "Staiger" wrote:
>
> A few people have expressed reservations about using C to program the
> smaller PICs, especially when the program is pretty simple.
>
> One thing that keeps coming up (and Microchip themselves say) is
that PIC
> assembly language is easy to learn, especially as there are "only 33
> instructions to learn".
>
> But I think there is a big difference between learning the PIC
instructions,
> and actually learning how to program in assembly language. Take this:
>
> a = b * c
>
> This is utterly trivial to write in C (indeed, I've just written
it), but
> multiplication is not trivial at all in assembly language. In
particular,
> in C I don't need to worry whether a, b and c are floating point or
integer
> values - it's written the same - whereas programming a floating point
> multiplication in assembly language is very different from
programming an
> integer multiplication.

Actually this really does depend on the assembler you are using. The
XCASM assembler has the '.let' directive that converts a 'C' type
expression to optimised inline assembler. It understands the
difference between (signed / unsigned) bytes, ints, longs and floats.
It also generates correct code for array and pointer indirection and
function calls.

>
> There are lots of other examples of how much easier C is than
assembly. Not4
> least being the mega-kludge of bank-switched memory, which you can
pretty
> well forget about in C (simply because the compiler looks after it
for you).

The XCASM assembler also include a RAM page and CODE bank manager that
analyses the executable and inserts paging and banking instructions
where necessary.

>
> C lets you bash the bits much the same as assembly does: I'm not
sure I buy
> the argument that you "need" to use assembly to get the best from
the chip.
> Yes - you have the opportunity to optimise your assembly code, and with
> sufficient expertise you will probably make a better job than the C
> compiler. But I've seen assembly code that is LESS efficient (slower or
> bigger) than that produced by the compiler - it all depends on the
skill of
> the programmer.
>
> In most cases it isn't necessary to wring the last bit of
performance out of
> every clock cycle, so compiled code is usually perfectly OK.
>
> But my main point is that assembly language programming is NOT easy
to learn
> - it's actually much harder than C programming. I don't think I really
> understand why so many PIC programmers seem rather anti-C. My
approach is
> the opposite: I always program in C unless there's a compelling
reason to
> drop back into assembly language.
>
> Any thoughts?
>

Actually a really good compiler can generate exceptionally optimised
code such that you don't need to drop down to assembler at all.

Regards
Sergio Masci
------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

In a previous posting...

>>Software should happen once, the hardware costs lasts for ever.<<

YIKES! I want to work at THAT company!!!

Unless your design is for a very vanilla product (such as a previously
mentioned washing machine controller), software will almost always
need to be updated. Another product mentioned was an engine controller
unit (ECU). I've worked in a plant that built these, and I know the
software was always being tweaked between model years for one reason
or another. Writing maintainable code is more critical than small
code, in this case. Also, since the units have a fairly long life span
(maybe 8 - 10 years), it is almost certain that people other than the
original programmer will be doing the changes at some time. Since
software is the most expensive product on earth, writing
easy-to-maintain code saves money on this end.

Latent bugs can absolutely kill both a product line, customer
contracts and bottom line. Putting out 5,000 units a week only to have
to recall them 3 months into production will cost a company a fortune.
And since it's not as simple as providing customer updates via the
internet, customers will have to have their equipment updated at a
service center. In a car, this could also lead to safety and
environmental issues - and more money.

>>...but there are many things that can be done in asm that high
levels languages prevent you from doing.<<

I haven't run into anything like that. Would someone care to leave
some examples, please?

When I started working in electronics about 20 years ago, I saw the
engineers I worked with hacking out code that eventually worked, but
it did not seem to be the most efficient way to do it. I went back and
got a computer science degree so I would really understand the
software. Writing an algorithm is only half the work; designing the
data structures to go in the program is the other half. ASM doesn't
allow you to easily create these structures.

A previous posting mentioned that the member could write and debug
1000 lines of ASM a day. This might be possible for pre-defined,
single function routines, but does this include the analysis and
design phases, along with any documentation? I also play with C
compiler listing outputs to se what kind of code they generate, and
one line of C code can generate a whole page (for a math function), or
more, of ASM code, so that 1000 lines may break down into just a few
pages of C.

Here's an idea - can we list some programming projects for the
newbies, and show implementations in both C and ASM? And usage of
macros would be encouraged. I worked on an ASM program a few years ago
and put in macros to make the code more readable. My boss looked at it
for a few moments, then said slowly "This isn't ASM, is it?". After I
revised it, the code did look more like BASIC than ASM. Showing
techniques like this would be useful.

What do you all think?

------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

--- In p...@yahoogroups.com, "jvoytovich" wrote:
>
> In a previous posting...
>
> >>Software should happen once, the hardware costs lasts for ever.<<

Not true! When I worked for the manufacturer of the "World's Fastest
Computers", the standing line was that it cost as much to produce a
copy of the OS for each machine as it cost to build the hardware.
Each machine!

Software development and maintenance costs are unbelievable.

> A previous posting mentioned that the member could write and debug
> 1000 lines of ASM a day.

I think I said 100 lines per day. Now, I realize that a small program
of, say, 10,000 lines might not take anywhere near 100 man-days. But,
a large project of 10,000,000 lines could easily take 100,000
man-days. Defining the project, breaking it up into chunks, writing
code, integrating chunks, debugging, quality control, documentation,
customer testing... Unending meetings... All of this goes into
writing code.

> Here's an idea - can we list some programming projects for the
> newbies, and show implementations in both C and ASM? And usage of
> macros would be encouraged. I worked on an ASM program a few years ago
> and put in macros to make the code more readable. My boss looked at it
> for a few moments, then said slowly "This isn't ASM, is it?". After I
> revised it, the code did look more like BASIC than ASM. Showing
> techniques like this would be useful.
>
> What do you all think?

I like the idea but only in the context of MPLAB and any other free or
demo compiler. Creating samples for compilers that no hobbyist can
afford is best left to the manufacturers.

>From my workings with MPASM, it's macro capability is more than
adequate for creating higher level constructs and complex data structures.

In fact, I would like to keep the ASM portion strictly limited to
MPASM since it is universally available, well documented and factory
supported.

Richard

------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

----- Original Message -----
From: "jvoytovich"
To:
Sent: Sunday, September 21, 2008 12:43 PM
Subject: [piclist] Re: Assembler vs C
> software. Writing an algorithm is only half the work; designing the
> data structures to go in the program is the other half. ASM doesn't
> allow you to easily create these structures.

SAY WHAT? Have you ever actually written any significant app in assembler?

Now, I will say that I doubt that an assembler programmer is likely to write
well thought out data structures unless he has some background in a high
level language, or preferably multiple high level languages, but the
flexibility of assembler means that you can write structures that are
difficult to express in some languages. I would argue that quite the
opposite is true. You are less constrained in your choice of data
structures in assembler. Of course, just as someone writing, say, COBOL
might have a hard time visualizing how the processor will ultimately deal
with his code, so too, a HLL-only programmer would likely have a hard time
visualizing how to express some complex data structure in assembler.

> A previous posting mentioned that the member could write and debug
> 1000 lines of ASM a day. This might be possible for pre-defined,

One of the problems with comparing languages is that the bulk of the
published productivity data is around general purpose applications.
Programmer productivity is affected far more by the application domain that
it is by the language. A programmer writing a general purpose business app
will be 3-5 times more productive in C than in assembler. However, that
same C programmer will be 10 to 20 times more productive than a C programmer
writing a data warehouse application.

Unfortunately, there has never been an agreed upon method for sizing
embedded apps so we don't have good metrics on emedded apps, let alone
published data on programmer productivity across multiple languages in the
embedded space.

> single function routines, but does this include the analysis and
> design phases, along with any documentation? I also play with C

Of course, MOST of the effort is in analysis and design, so for comparing
languages the only relevant part is coding. The rest of the SDLC just
swamps the coding part. (In my view of the world, documentation is part of
analysis and design, and it is pretty silly to start coding before the
documentation is done. Programmers from level 1 shops will obviously view
that differently).

> Here's an idea - can we list some programming projects for the
> newbies, and show implementations in both C and ASM? And usage of
> macros would be encouraged. I worked on an ASM program a few years ago
> and put in macros to make the code more readable. My boss looked at it
> for a few moments, then said slowly "This isn't ASM, is it?". After I
> revised it, the code did look more like BASIC than ASM. Showing
> techniques like this would be useful.

Macros are very useful, not only in assembler but also in C. Within some
application spaces, C macros can be a huge advantage, too. But one big
difference; with assembler macros you still see what you are doing.

As I mentioned before, I've looked at the output of many PIC16 C compilers,
and each have something they do horribly. One effect of this is that you
can go along happily using a C compiler and all of a sudden the program size
explodes to many times what is was, not a problem on a PC with 4 gigs of
RAM, but a big problem if you are targeting a 12F with 1K. If all you know
is C, you are at a total loss to explain what happened.

Recently I've been pawing through the code in the October Esquire magazine.
The code was obviously produced by a compiler, and if an assembler
programmer wanted to not have to worry about banking, this code is an
excellent example. Simply select the bank before EVERY memory or register
access. No actual assembler programmer would do this as that single
sub-optimization increases the code size by about a third. (I have no idea
what compiler they used, all I've seen is what I could read from the chip).
I've seen other compliers do even more obnoxious things, usually in an
effort to comply with the ANSI standard.

An experienced programmer can understand, maybe even intuitively, what the
compiler is going to do. For him, a compiler can be a big productivity
benefit. For a less experienced programmer, though, it is a minefield.

As I mentioned earlier, these comments are specifically around the smaller
PICs where program space, and especially RAM, are very limited. On the 16
bit parts, C compiler don't have to jump through quite so many hoops, and as
a result, rarely, if ever, produces pathological code. On the flip side,
the 16 bit instruction set isn't nearly as easy to learn as on the 8 bit
parts, and the applications are likely to be quite a bit more complex. On
these parts, the balance clearly shifts in favor of C.

72/73 de WB8RCR http://www.qsl.net/wb8rcr
didileydadidah QRP-L #1446 Code Warriors #35

------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )