Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

MikroC any one Like it?

Which C do you use

  • C18

    Votes: 0 0.0%
  • H-tech

    Votes: 0 0.0%
  • boostC

    Votes: 0 0.0%
  • CCS

    Votes: 0 0.0%
  • gcc

    Votes: 0 0.0%
  • Crossworks

    Votes: 0 0.0%
  • Code Red

    Votes: 0 0.0%
  • Keil

    Votes: 0 0.0%

  • Total voters
    1
Status
Not open for further replies.
It would only let me set for 4 for some reason, Anyway LPCXpresso CodeRed is easy as pie to use

The only problem i have had is one of my LPC-LINK was a dud. I cut the board and used the new one I have and all joy LOL
 
Last edited:
I got two for free I first one the link was a dud I spent two week being told it was me I told them it was not loading the firmware came home and i had a new one
at the door There great can't beat the power of a 32 bit arm. I like CodeRed but still looking for some thing more like the ide I use with the pic's
 
what's differences each C ?
 

Attachments

  • C..GIF
    C..GIF
    10.3 KB · Views: 231
what's differences each C ?

Not a great deal... Most are ANSCI compliant. The trick comes when the addon libraries and the memory access is used... Some compilers are easier to use than others... Where data is placed where constants are stored and pointing to said locations... Once you learn these few annoyances you tend to stick with what you know... I used to use C16/7 for pic14 devices now microchip dropped them and you now have Hitec that took their role.
 
Last edited:
Want to emphasis what AtomSoft said about #defines.

One can write code to be portable between compilers, or port existing code to a new compiler with a #defines. It take a bit more work for the ISR and fuses.

My NAOS multi tasking demo is an example of that. It can be compiler with C18 BoostC and has been ported to Hi Tech and the 12F.
 
Had Microchips C18 stuck with the convention of constants in upper case and variables in lower case then porting would have been much easier. It makes sense to me that PORTA is the address of the port and porta is the value stored at location PORTA. What do others think?

Mike.
 
Had Microchips C18 stuck with the convention of constants in upper case and variables in lower case then porting would have been much easier. It makes sense to me that PORTA is the address of the port and porta is the value stored at location PORTA. What do others think?

Mike.
I think it should be made a crime, punishable by death, to have the same name (distinguishable only by case) used for two different purposes.

This is just begging for confusion and bug-ridden code.

What is wrong with, say, a constant called PORTA_ADDRESS and a variable PORTA_value? Look how clear the distinction is - in any case. Not that you normally need either....

The definition of PORTA, usually contained in a .h file, seems to be written cleverly enough to translate our use of "PORTA" into the correct compiler-dependant C definition that gives the effect that we want.
 
Last edited:
Mike I think it would be a good idea too it's a hell of a lot easier to see what your pointing to.


Hex I think you looking at what Mike is saying wrong He talking about
constants in upper case and variables in lower case
 
I think it should be made a crime, punishable by death, to have the same name (distinguishable only by case) used for two different purposes.

This is just begging for confusion and bug-ridden code.

What is wrong with, say, a constant called PORTA_ADDRESS and a variable PORTA_value? Look how clear the distinction is - in any case. Not that you normally need either....

The definition of PORTA, usually contained in a .h file, seems to be written cleverly enough to translate our use of "PORTA" into the correct compiler-dependant C definition that gives the effect that we want.

You seem to be confused about the word "convention".

Mike.
 
Mike I think it would be a good idea too it's a hell of a lot easier to see what your pointing to.


Hex I think you looking at what Mike is saying wrong He talking about
As far as I know, Microchip does tend to use Upper Case for constants, and lower case (EDIT or mixed case) for variables. Perhaps you could give an example where they do not?

In my opinion, use of "porta" (lower case) for anything is confusing, and to be avoided.
I would not think of "PORTA" as either a constant or a variable. It is the name of a register.
There is no register called "porta" in any of my PICs. There is a register called "PORTA" in many PICs, so what is the meaning of "porta".

But maybe I am not understanding? ....or as you suggest, looking at it wrong.
 
Last edited:
I would agree with hexreader on this one, using u/c and l/c labels to differentiate between addresses and data is a bad idea.
 
You seem to be confused about the word "convention".

Mike.
I have no problem with the convention of using uppercase for constants, which I believe is a C convention, not just a Micrchip one. I also think it is an excellent idea.

I admit that maybe I missed that this was the main point, and that maybe I should not have got fixated on the use of "porta" for a variable name. If so, I apologise for misunderstanding.

Robin.
 
Last edited:
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top