As an addendum to my rant I suppose my argument would make more sense in this context. One of the best things about C is that you can use inline assembly or link in external assembler files. What I do when I really need to do something critical like an interrupt routine is write a optimized subroutine. Variables declared in C are visible to subroutines allowing for useful communication between C and ASM. So yes, writing *only* in C can and will pose limitations. Commercial compilers reduce those, but some hand-written assembly may do just the same or better. On Sun, Mar 2, 2014 at 3:16 PM, Jason White wrote: > > 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 th= e >> 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 move= d >> 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 t= ry >> again later. On debugging with optimization, single stepping the code, i= t >> just seems to jump all over the place. It's extremely difficult to figur= e >> 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 > > > > -- > Jason White --=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 .