On 31/05/2011 19:53, IV3YNB op. Matteo wrote:
> Is it difficult to learn C ?
It's not difficult to start writing basic programs, and to become reasonably competent.
However, (and I think this applies to most languages and subjects in general) it is difficult to become an "expert".
There are certainly easier languages, with C you have a lot of power at your disposal but it won't "save" you from yourself if you code badly. There are a lot of "hidden" traps for the unwary newcomer.
On a uC though it's a little different as you don't have a wealth of "easier" languages like VB, C#, Java, etc, so the choice is kind of made for you if you want a higher level (than assembly) and portable language.
Porting your code from one family of chips to another can be as simple as changing a header file.
With a lot more memory available and faster, cheaper chips (e.g. 32-bit, 32K for a couple of dollars) squeezing every last bit of space out of a chip in assembler is no longer as important for many applications. Assembly will always have it's place of course, but often C is just fine, and for critical routines you can use inline assembler.
If you can learn to be good at both then you have the best of both worlds.
There are other higher level options too, like JAL.
> Why is it so used worldwide?
Difficult question with lots of answers available. People will probably have widely varying views on this one.
I wouldn't worry about it too much, and just dive in and learn it - if you want to have a very useful tool at your disposal for embedded development, C is certainly that. It's not going away anytime soon.
There are countless books and sites with examples, so that makes life a lot easier than learning some obscure language - this alone would make me choose C over a "better" but uncommon language.
Em 31/5/2011 15:53, IV3YNB op. Matteo escreveu:
> Dear all in the list,
> thank you for your useful information, sure I learned I have lot to learn
> more... :-)
> Anyway, this afternoon I found some examples in the web using better search tips
> in Google...
> I'll take a look at them, I'llstudy some more on the "sacred books" and then
> I'll try some code.
> Only one question more: I do not know anything about C, sorry for that, but I
> only know assy and some mikrobasik.
> Is it difficult to learn C ?
I don't think so. YMMV.
> Why is it so used worldwide?
Because of its portability. That is: write once and reuse many (with
I share lots of my C between PICs, AVRs, ARMs, etc.
> Thank you once again, see you on the list.
Oli Glaser wrote:
> People will probably have widely varying views on this one.
heh - exactly.
C on the smaller microcontrollers can be a real bear unless you are
already familiar with the part and the compiler. If you are already an
expert on the chip it can be a real time saver. But if you don't already
understand the chip, then it can be a real black hole unless you stick to
On the other hand, some of the newer, bigger, faster parts take C quite
well. Still, a microcontroller is not a mainframe, so programming it in C
isn't like programming C on a PC. There is still a lot of grody detail to
learn, but with parts like the 16 bit PICs, it isn't nearly the minefield
it is with the 8 bit parts.
If you haven't already invested a bunch of time into the 16Fs (as a lot of
hams have and the IV3YNB makes me suspect you might be one of them), I
would suggest you get the biggest 24F or 30F you can get in a package you
are comfortable with and have at it. (Many of the cooler parts only come
in hobbyist-hostile packages.) Even the most expensive of those PICs are
under about ten euro, and with a ton of memory and pins you won't be
trying to squeeze things in. The 30Fs have the advantage of being 5 volt,
so depending on the DDS you choose they may be worth it even if you don't
need the DSP. There are some differences in available features between
the 24 and 30 families, but the basic programming is identical.
Once you have a working prototype, if you then decide you want multiples,
it is pretty easy to move to another, cheaper part in the same family. But if its just for you, then why not burn a couple of extra euro to save
yourself some frustration.,
If you don't mind spending a few euro I would suggest getting the Explorer
16 and a few of Microchip's protoboards to hold your circuitry. That way
all the micro support is taken care of (not that there's a lot) and you
can focus on your own circuitry until you get more comfortable. Plus,
Microchip has some example code you can play with to get the hang of it. Kind of pricey but a nice way to get off the ground.
Of course, there is the reverse approach. There is plenty of DDS code
around for the 16F family ... check out AA0ZZ's work for example. Most is
for the AD98xx or si570, so if you are wanting to use a different DDS it
may or may not be helpful. The 16F's are dirt cheap, and have been a ham
favorite forever. But almost all the work there has been in assembler. I
don't personally see that as a problem (for obvious reasons). But if you
are just getting in now maybe it is better to dive into the newer, more
Just my 2 cents worth. In my opinion, high level compilers for PIC's
aren't what they're cracked up to be.
I program almost exclusively in assembler. Most people don't program
this way. They use an HLL. That's fine. I have used 'C' for PIC's several times because a
customer requested or required the source
to be in 'C'. But, even in HLL's, if you look through the resulting
code, probably a third to a half of
the code is in the same basic form as assembler. Things like register
initialization, interrupt setup, etc. looks a lot to me like assembler. So, in my opinion, why waste my
time with 'C' when assembler is just
as good. Some people make the argument that HLL's are faster to code. If you already know the language,
maybe. But to me, HLL's just add cost and complexity that isn't
Now before anyone says how wrong I am, let me say that this is my
opinion and experience talking.
If you disagree, that's okay. I won't think less of anyone that uses
and likes HLL's. I'm just saying they're not for me. Anyone reading this post can choose to consider
this information as helpful, or as pure rubbish. Whichever you choose. I'm just presenting it for
consideration as another voice of the
PICLIST to someone contemplating the use of an HLL for PIC's..
On 31/05/2011 20:24, Isaac Marino Bavaresco wrote:
>> Only one question more: I do not know anything about C, sorry for that, but I
>> > only know assy and some mikrobasik.
>> > Is it difficult to learn C ?
> I don't think so. YMMV.
But very hard to write perfect programs with
Takes much longer to learn the Libraries
>> > Why is it so used worldwide?
Because most of UNIX, Linux, OS/2, Windows etc is written in it. Sheer momentum.
> Because of its portability. That is: write once and reuse many (with
> minimal modifications).
Because it's little more than a machine independent macro assembler. Makes it very portable.
If writing accurate clear to read and easily maintainable programs is more important than portability look at other languages.
I prefer C for Linux and ARM.
C# for Windows GUI applications
C++ or Modula-2 for Device drivers, OS
JAL for PIC 10/12/16/18F
C is probably best for other Microchip CPUs which are only really PICs in part name..
Em 31/5/2011 18:54, Michael Watterson escreveu:
> On 31/05/2011 20:24, Isaac Marino Bavaresco wrote:
>>> Only one question more: I do not know anything about C, sorry for that, but I
>>>> only know assy and some mikrobasik.
>>>> Is it difficult to learn C ?
>> I don't think so. YMMV.
> But very hard to write perfect programs with
As somebody pointed out, learning to program and learning a language are
different things. A bad programmer is a bad programmer in any language
> Takes much longer to learn the Libraries
This problem i common to every language.
>>>> Why is it so used worldwide?
> Because most of UNIX, Linux, OS/2, Windows etc is written in it. Sheer
One more good reason...
>> Because of its portability. That is: write once and reuse many (with
>> minimal modifications).
> Because it's little more than a machine independent macro assembler.
> Makes it very portable.
Well, it seems a good reason for the assembly programmers migrate to C :)
> If writing accurate clear to read and easily maintainable programs is
> more important than portability look at other languages.
I think this is a point that is more related to programming style than
to the language itself, although some languages really don't help.
> I prefer C for Linux and ARM.
> C# for Windows GUI applications
> C++ or Modula-2 for Device drivers, OS
> JAL for PIC 10/12/16/18F
I use GCC in C or C++ mode where available, and for desktop GUI
applications I use wxWidgets so I need to write code only once and
compile for Windows, Linux and Macintosh (although I never used a Mac in
> C is probably best for other Microchip CPUs which are only really PICs
> in part name..
Don't underestimate the C compilers for small PICs, Hi-Tech PICC is very
good. It's a long time since I last used pure assembly in a PIC application..
I like Hi-Tech PICC for PIC16F and MPLAB C18 for PIC18, and they are
For dsPIC, PIC24 and PIC32 there is GCC, which is a great thing because
it is easier to port GCC code across platforms, including desktop systems.
On 31/05/2011 23:40, Isaac Marino Bavaresco wrote:
> For dsPIC, PIC24 and PIC32 there is GCC, which is a great thing because
> it is easier to port GCC code across platforms, including desktop systems..
I'd use gcc for those
I'd not use Assembler for anything. I'm not focused enough or using one cpu enough
Em 31/5/2011 20:38, Michael Watterson escreveu:
> On 31/05/2011 23:40, Isaac Marino Bavaresco wrote:
>> For dsPIC, PIC24 and PIC32 there is GCC, which is a great thing because
>> it is easier to port GCC code across platforms, including desktop systems.
> I'd use gcc for those
> I'd not use Assembler for anything. I'm not focused enough or using one
> cpu enough.
Well, it seems that you agree with me, or did I understand it wrong and
you are disagreeing?
I must admit that learning something new, exactly from the very beginnign, for me is almost everytime a matter of time.
To learn new things well, one must have enough time to read, study, write, practice and obviously one must have an idea to put in software (luckily i got many...). And somebody to judge, could be good... to know if the code is alright.
Because C can be either a low-level language or a high-level language, as the moment requires.
> why waste my time with 'C' when assembler is just as good.
Well, the current example wants
M = (f0 * 2^32)/fc
Where f0 and fc are 32 bit numbers (some constant, some not.) That's not particularly a line that I'd like to translate into assembler. (I suppose it depends on how much access you have to a good set of libraries...) (And then C will easily go low-level and let you separate the bytes efficiently (one way or another), supporting my first statement.)
On 01/06/2011 00:58, Isaac Marino Bavaresco wrote:
> Well, it seems that you agree with me, or did I understand it wrong and
> you are disagreeing?
I agree in a limited sense.
C rather than Assembler.
I'm not impressed with C on 10F/12F/16F/18F etc. (I've tried 3 compilers and I'm experienced with C)
I can see why Olin uses Assembler.
I'm happy to use JAL on 10F/12F/16F/18F,
I'd use C for dsPIC, PIC24 and PIC32, though I'd likely use Blackfin and ARMs rather than those with C.
I've done PIC 16F, Z80, 8085, x86, 8051, 6502, 78HC11, SC/MP assembler. No ambition to do any more assembler ever.
I've used C, Forth, Pascal and Modula-2 on Z80. The Modula-2 compiler wins there and I've even reused code on x86 32 bit windows M2, with VB6 GUI calling the DLL made in M2. Never did Win16. Used Modula-2, C and C++ for DOS and then VB5, C++ and Modula-2 on Win32, later adding C#, Java and VB6.
On Linux & Windows I've used C, C++, C#, Java. Device Drivers on Linux tend to end up being in C. Embedded applications hosted on OpenWRT Linux as testgear in C++. Small cross platform GUI stuff on Java. On Windows only larger GUI projects I'm weaning myself off VB6 to C#, No point to vb.net I've looked at Ada and Oberon in the past. I learnt C++ a year before C which may have been unusual in late 1980s
JAL2 is very suited to 10F/12/16/18F but is not suited for PIC32, ARM etc even if the compiler was ported. There would need to be V3 superset of the language.
*Special JAL features*
Fantastic Chip include support
at allows union like feature declare an array and then AT it at a longword
strings as arrays without a pointer to byte
no pointers (yes this is a positive feature for this size cpu and realtime reliable apps)
Easy to understand libraries without 1976 legacy madness of some C libraries
get and put keywords on procedures and functions to make device drivers look like arrays or variables.
no need for ; on each statement
C like variable declarations
BASIC like IF, LOOP, CASE constructs
Dead code elimination. No worries including large library and using one little function
special support for accurate SW delays
Very very efficient optimising compiler creating "p-code" which is compiled to PIC Assembler
Libraries optimised for embedded applications and devices commonly connected to PIC rather than mostly originally for Mini-Computer UNIX as is case with C.
On 01/06/2011 08:00, William "Chops" Westfield wrote:
>> > why waste my time with 'C' when assembler is just as good.
> Well, the current example wants
> M = (f0 * 232)/fc
> Where f0 and fc are 32 bit numbers (some constant, some not.) That's
> not particularly a line that I'd like to translate into assembler. (I
> suppose it depends on how much access you have to a good set of
> libraries...) (And then C will easily go low-level and let you
> separate the bytes efficiently (one way or another), supporting my
> first statement.)
Olin probably has such an assembler library and can write the entire DDS app inc "GUI" with keypad, rotary encoder and graphic panel in a coffee break. The rest of us would be better using C or JAL on 16F
232/fc is presumably a constant.
f0 is the part that changes.
fc is 50,000,000
fo is likely less than 150,000,000
232 = 4,294,967,296
You don't want to convert to floating or lose any resolution.
Pre-calculating a constant
4,294,967,296/50,000,000 = 85.89934592, approx 86 as integer, loses too much
so it does need 64 bit int maths if you do (f0 * 232)/fc properly. This is possible in C or JAL
However if fo max is 150MHz then that is 1/28.63311530667 of 232
Or if fo = 30MHz max 1/ 143.16557653333333333333333333333
There isn't a way to scale to 32bit maths unless the frequency step is integer multiple of scaling..
Minikits in Australia have a PIC kit with DDS chip premounted for this kind of application. It's not very complicated.
I've written a similar application in JAL that outputs in packed BCD via serial to a radio rather than a DDS.