Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

8-bit vs-16 bit PICs...

Status
Not open for further replies.

smanches

New Member
After reading these forums for the past month, I've noticed there is never a mention of using the 16-bit PICs, only ever 8-bit versions. I was wondering why this is?

I've been using the 24H and 33F series almost exclusively. For my ACIM control the 33F MC series has a full H-bridge PWM controller with separate PFC PWM controller built in.

I could see using the smallest common denominator in a comercial product that is mass produced, but for hobby/one-off projects, I've always thought the bigger/better/faster controller would give more flexibility in the design process.
 
Most people asking PIC questions are blindly following manuals and other people's older designs which are using 16Fs, not even 18Fs.
 
Last edited:
It could just be that I'm a software engineer by trade, so I think in those terms. But also some of the features available are quite handy. Many people here making H-Bridge inverters, but not using dedicated h-bridge controllers.

I'm still depressed there is only one C++ compiler out there and I think it's $5000. And dont' start a C/C++ argument over this, please. I would really love function overloading. :)
 
There are several 8bit PICs that have an enhanced PWM module too. I've used a 24H in a project that used its funky 32/512x PLL as I needed some rather unusual frequencies.
 
It could just be that I'm a software engineer by trade, so I think in those terms. But also some of the features available are quite handy. Many people here making H-Bridge inverters, but not using dedicated h-bridge controllers.

I'm still depressed there is only one C++ compiler out there and I think it's $5000. And dont' start a C/C++ argument over this, please. I would really love function overloading. :)

*cough* ARM *cough* Oh wait, that's not 16 bit.
 
Last edited:
I've stuck with the 16-series as I know the assembly quite well. I'm too lazy read up on the few 18-series extra instructions :D But I understand that the 18 are meant to be coded in C, and things might change soon as I'm learning C for normal PCs right now at a C-course.

I like the fact that assembly is so near the device itself, it will do exactly what it is told to and I can take a paper and pen and figure out EXACTLY how long a routine will take to execute. And that makes it easier to bit-bang various communications schemes, which makes you a little less dependant on built-in peripherals.

Nigel had a good point which is valid for me, most of the time 16s are more than enough.

C looks nevertheless quite appealing to me. All math operations would be a lot easier.
 
Last edited:
*cough* ARM *cough* Oh wait, that's not 16 bit.

Technically Thumb mode would be 16bit.

Writing code for an ARM, I've gotten into a totally different mindset. Libraries I'm writing are much more full featured and I can write a library that encompasses a 'family' of chips I'm interfacing with rather than just a single chip or device and I don't care so much about the speed/codespace overhead. It also means I'm implementing a lot of error checking and validation that I would not have bothered with where code space was a premium.
 
It would be unusual for most people to prefer a computer language they did not know. Would you be suprised to find that my favorite spoken language is english ?

People have said C adds a layer of abstraction. It does but that is a very good thing.

I prefer to have to computer hide the details related to its instruction set. It allows me to think at the C level and generate code faster.

When I have to I can write inline ASM or look at the disassembler for details. It does not happen all that often.

I try to stay language neutral. My favorite tends to be the one I am using.

3v0
 
I'm old school from learning to code on 6502's (apples, commodores, atari's), so I think in "high-level assembly" but code in C/C++. If I need to optimize a routine, I usually just start with the compiler output and go from there, as it's going to be very close to what I need. I really don't like writing code if I don't know exactly how the hardware/OS is going to execute it.

I'll have to look into the AVRs. I've done some Gameboy programming, but never realized there were MCU versions of the ARM.

When do you think the MCU market is going to be corrupted by Java? :eek:
 
There are already "embedded systems" capaible of running most any language you like. But they can be expensive.

You can expect to see Java on an increasing number of embedded systems. How far down the chain it will travel will be limited by memory requirements. Sun already has an embedd java if you do not mind running a linux kernel or Windows XP-Embedded.**broken link removed** EDIT: It looks like there is no charge for this software.

Most of the code written on 8 and to some exstent 16 bit systems are simple compared a large OS or an accounting system. OO makes a lot of sense for complex applications but there are a lot of applications where OO is overkill, a burden.

On the low end I would look for extended more capable C compilers with features such as function overloading (smanches post). I would not look for, or want, inheritance on these small sytems.

The more capable 16 bit and 32 bit units are another matter. The first compiler I would look at is BoostC++. The memory limited version is free and the unlimited but non commerical use is only $100.

3v0
 
I'm old school from learning to code on 6502's (apples, commodores, atari's), so I think in "high-level assembly" but code in C/C++. If I need to optimize a routine, I usually just start with the compiler output and go from there, as it's going to be very close to what I need. I really don't like writing code if I don't know exactly how the hardware/OS is going to execute it.

I'll have to look into the AVRs. I've done some Gameboy programming, but never realized there were MCU versions of the ARM.

When do you think the MCU market is going to be corrupted by Java? :eek:
as a teen I programmed apples, commodores, TI 99/4s, 6800s and more.

there actually are java micros, the arm jazelles have java byte code built in and some are available from NXP and others. We currently have a project quoted that will use a TI ARM 9 video chip that has java code built in.

Dan
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top