I don't see what everyone gets so caught up on optimization. The real reason to move to C is not for efficiency, its for ease of development and portability. Hobbyists (and often engineers too) don't need to to worry about squeezing every last bit out of a chip that only costs $0.90 to start with. The time spent often outweighs the marginal costs of increased flash usage. C works just fine on the 8 bit PICs, the only time optimization becomes an issue is when you start doing operations that the processor can't do natively. Relative offset addressing, floating point math, division, dynamic memory, and other advanced features enabled by C should be used with caution. However that does not mean that either C or the processor are inherently bad. The compiler only does what you tell it, if stick to basic basic operations like you would do in assembly (writing to registers, loops, 8 bit integer math) there shouldn't be an issue at all. On Sun, Mar 2, 2014 at 2:37 PM, Harold Hallikainen wrote: > >> 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 tr= y > 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 > > -- > FCC Rules Updated Daily at http://www.hallikainen.com - Advertising > opportunities available! > Not sent from an iPhone. > -- > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist --=20 Jason White --=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 .