Somethig interesting to use http://www.picbasic.co.uk/forum/showthread.php?t=2418
Really handy to compare between 2 piece of code.
There's always a midpoint between a tight code and a 'bullet proof' code. Yes it's interesting to have some way to reduce code size but if it gives more potential bugs or headache... will you aprreciate your tight code even if it gaves you extra debug hours? I don't think so 
PBP is stable and mature, i don't like to play with his internal ressource to save few bytes only to save few cents by choosing a smaller PIC to do the job. well it's my opinion after doing that on a full 64K of code.... yeah it's working fine now.. no problem at all. I just hope to have a 28Pin device with much codespace one day... probably there's already one that i didn't see. I'd use a 18F2680. Code overlay could be an option at that time... i'd just challenge myself to fit everything in the same PIC.
about the speed... depending how critical your application is, using a higher crystal speed or use some assembler line could do the job as well.
each project is different so i don't think there's an universal way to do one thing.
Using built-in function for an application that don't need all the bells and ring and data handling include in the built-in function like ADCIN,SEROUT, HSEROUT,HSEROUT,HPWM and much other is often killer. Save code space by writing/reading directly to the internal register is the way to go. In many case, it will be done much faster too. Oh yeah much tricky... of course, but you have the full control of!
How to save code space, how to write a program is an endless story. In many case, i'll prefer the internal register way against built-in function... well for my own application. To teach to someone else, to do some test, the use of built-in function seems to be easier/faster to understand.
HTH
Last edited by mister_e; - 30th September 2005 at 17:47.
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
Bookmarks