I agree with Rjenkins, a more clever written program can result in less programming space and maybe save you some money.

 

Hello nanovate,

"Here is an Atmel part that has >100k Flash, 16K SRAM and 4K EEPROM ......"

Yes but does it do C++. If not what is wrong with going with Mikroc and using a pic24?

Ross

 

Hello Rjenkins,

"Once you have installed the CCS Compiler (plus it's little MPLab interface program), you work purely within MPLab.

You have to tell it what 'toolset' you are using within the project setup (eg. CCS C compiler), but from then on you only use the facilities within MPLab - Build, Debug, Program, Trace / single step - all with the Microchip debug tools (ICD, PicKit etc) or just any supported generic programmer."

The way I understand it then, is you use CCS as the compiler and everything else we do it with MPLAB.... right?

Ross

 

Hello THE_RB,

"I don't want to sound mean, but maybe you need to re-think your code writing techniques. Working with microcontrollers you have to change some of the ways you do things."

No offense taken.

"May I ask just what is the application that you believe requires 100k code size??? "

Yes it is true that I use alot of strucutres... Perhaps a bad habit when using MCU's but I am used to it. But I am sure I can make my code a little more efficient, but the true issue here is the speed.

I am building a small controller with an LCD screen to control lights and motors. My current screen is 176 x 132 pixels and has 16 bit of color depth per pixel. As you may all know, somewhere in my code I have a for loop nested in another in order to go through all the pixles. And in every itteration I execute a fairly large amount of code. Therefore this is the reason that the PIC18F4685's 10 MIPS is sort of slow.

Here's the breakdown. Approximately 40K is used for drivers such as the color LCD display, close range infrared sensors/ motion sensors/ and special communications to a CPLD. The display driver can do four different types/sizes of fonts, 32 diffrent pictures and 100 or so icons of my choice. I can select any picture or icon and copy it in MS Paint and then I run it through a special c utility that I have created to convert the 24 bits/pixel RGB to 16 bits/pixel 565 color RGB format. Then, this file can simply be downloaded in an external flash so the MCU can fetch this data. One day I will need to create a VC++ PC application so this is done in a very user freindly way!

Approximately another 20K is used for a message loop Kernel which does a very similar messaging system as the Windows looping does. (Ex: with window procedures etc...) and approximately 30K is used to display 6 types of controls such as passcode keypads, menuing systems, dropdown listboxes, listboxes, progressive bar graphs and buttons which all have very specific functionalities and a unique look and feel. And that pretty well maxed out the PIC18F4685 part. I would of loved to continue my project, since I have two more controls to do and a little more code cleaning, but that will have to wait until I port my code to the PIC24 familly.

I don't seem to have any difficulty programming so many things in one MCU. I just create objects which do very specific things and just build on that for ever and ever as long as the objects are small and organized I don't seem to have any problems at all. I don't seem to get lost in my logic either. I must admit though, I put an immense amount of time to get everything organized like this. I even ran the controller for one month straight 24hours/24 and it never bombed. It used to take me 2 weeks to create a custom made control... for example a dropdown list box with custom functionality and features! Now I can create any control in a matter of hours.

On another note, I really like the electronics lecture videos that this site provides. I am looking a them and learning so much. I now try to do 1 video per evening. I really thank the individuals for doing this, I was always looking for an electronics refresher like this.

So in short, I am thinking of going with Mikroc! Any objections?

PS, thanks all for your replies... it is very appreciated.

Finest regards
Ross

 

Beware of some compile tricks like shift instead of multiply by powers of 2, a good compiler will often optimize better than the tricks. Deciding to use the right data type is a key decision that the compiler cannot optimize for you. Unsigned char rule on micros.

 

Sounds like a serious project! I can see why with that level of complexity you prefer to optimise your code for ease of coding and not for code size.

...
My current screen is 176 x 132 pixels and has 16 bit of color depth per pixel. As you may all know, somewhere in my code I have a for loop nested in another in order to go through all the pixles. And in every itteration I execute a fairly large amount of code. Therefore this is the reason that the PIC18F4685's 10 MIPS is sort of slow.
...

I hear you there. I was a 2D games graphic programmer in the early 90's when a screen was 640x480 and 1byte per pixel and PCs were SLOW... The first thing to look at is if you can optimise your "fairly large amount of code" for every pixel. That's a good area to convert to assembler, and/or recode the branching based on the most common options first to reduce time per pixel. Some graphics tricks we used back in the dark ages might help, like;
* don't update the whole screen, just the area you need
* align screen areas, and icons/fonts to byte boundaries (for XY addressing)
* write fast code to work with areas on byte boundaries, not individual pixels
* write even faster code for single colour block fills for redrawing single color areas of the screen like menu blocks and background areas etc

Some of that might help. Even at 10 MIPS your GLCD menu and bitmap drawing stuff should be lightning quick.

One of the things I like about MicroC compiler is you can keep the autogenerated .ASM file open in the IDE next to your .C file, so you can make changes to the C code and instantly see what the compiler is doing with it. Just with that bit of feedback you can probably change a few subtle things to make the compiler produce much smaller code, like some of the things it inlines you can manually setup as functions to reduce code size by a HUGE amount. Or make small changes to your math expressions that will calc on the spot rather than stacking a heap of variables then calling separate math routines which is both slow AND code hungry.

I've never used the PIC24 version of MikroC so I can't say much about it, but I do like their other C compilers and their hardware.

 

Hello THE_RB,

Yeah, your right, I see a couple of improvements I can do in my code which would make it go faster. But, I have lots more to do, and I absolutely need a bigger PIC.

That is great advice, I will keep it in mind!

Hope to hear from ye in another post! And now, I am off to watch another one of em electronics videos ...

Finest regards
Ross