> This is one reason why I've considered moving up to the PIC24F chips.
> I know a lot of people that like them, and they seem like an ideal
> next step, especially since they are a bit more suited to C. But then
> I am learning embedded C _and_ a new family at the same time.

I moved to the 24H as soon as it became available. I then moved to the
PIC32 as soon as it became available. I did just do one project using the
PIC24H because it has more ADC inputs than were available on the PIC24H.
The price differences between the chips is small enough that I generally
go for the fastest biggest chip I can. On some larger volume low cost
products, I move back to the PIC18, generally the QFN 64MHz parts.

Unless you're doing bootloading, you generally don't need to worry about
the instruction set of the chip. I've done bootloaders for the PIC18,
PIC24H, and PIC32, so I've had to deal with writing to flash, boot
sections of flash, and the C initialization code for the bootloader. On
the PIC18, I did the bootloader in assembly. On others, it's been in C
along with some assembly to set up for C execution (setting up stack
pointer and other registers that C requires be initialized). The startup
code generated by the compiler is used to initialize stuff for the
application. Since this changes as the application changes, this is moved
into the application area of flash.

Also when dealing with bootloaders, you have to mess with the linker
script to place code into the proper sections of flash. I find linker
scripts extremely cryptic. I've managed to modify them to do what I want,
but every time I go back to look at it, I have to relearn everything.

Summarizing, if you're looking at moving away from PIC18, how about
PIC32MX? I have to start looking at PIC32MZ.


>
>> I also recommend MPLABX in favor of MPLAB8. I would never go back
>> even though there still are some problems, especially when debugging
>> but I can manage well enough with an ICD3. Always debug with no
>> optimization though.

I tried migrating one project to MPLABX and gave up after a week. I'll try
again later. On debugging with optimization, single stepping the code, it
just seems to jump all over the place. It's extremely difficult to figure
out what's going on. So, I debug with optimization disabled.

On optimization, I find that if I enable full optimization, stuff stops
working. That includes stuff like the TCP/IP stack. So, I just back off
optimization until it works.

Harold

--=20
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!
Not sent from an iPhone.
--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.