• 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.

Development Languages

Status
Not open for further replies.

gaspode42

Member
Hi Everyone,

I have been using PIC's for a while now and doing all my development in asm. I would now like to use a 'higher level' language to do some development, but unsure what is best to use.

I have been looking at Basic, C or Pascal. I have used Basic on PC's before but never used the other two (although quite happy to learn). So my question really is are there any advantages to using C or Pascal or should I just stick to Basic?

The sort of projects I will be developing will be using I2C, USART, LCD, GLCD, SPI which seem to have libraries in all three languages so is there anything else that I should be considering?

Any advise would be much appreciated.

Rupert
 

dknguyen

Well-Known Member
Most Helpful Member
BASIC won't help you find a job nearly as much as C or pascal will (with C helping you more).

You don't need libraries to program any of those things. Just read the datasheet and figure out which bits you need to clear and configure and use the I2C, USART, and SPI. You have more complete control over the configuration too. I find those libraries make things confusing especially after you have read the datasheet carefully. It may help for something complicated like an LCD, but not for the things like the hardware periphreals of the MCU that are completely outlined in the datasheet and have more settings to them than you can write functions for.
 
Last edited:

ericgibbs

Well-Known Member
Most Helpful Member
hi,
Get the free download of Swordfish Basic for the 18F series, its well supported.
 

Pommie

Well-Known Member
Most Helpful Member
I'll put in a word for BoostC. The free version is limited to 2k instructions. This doesn't sound much but I currently have a project with LCD, Keypad, I2C clock, I2C EEPROM and OW temperature sensors. It all fits within the limit of the free version of BoostC.

And, if you outgrow it the full version is only $69.

I'll also give Swordfish Basic a big thumbs up. Again the free version is really generous before you have to buy the full version.

I also agree with DK, the libraries can cause confusion and I find it easier to write my own rather than try and figure out the vagaries of the supplies ones.

Mike.
 

arhi

Member
the point of libraries is easy movement trough families. You can make your USART work perfectly on 16F690 and then you change pic to 18F4550 .. then your USART routine does not work as you need to set up different registers to different values .. if you used library - it would work, then you switch to dspic33 .. again, it does not work because ... but .. if you used library - it would ..

the point of libraries is that they have "all versions" for "all occasions" (if they are properly written) .. so if you select PICxyz then initialisation will be done using XYZ.. and if yoiu .... not to mention simple things like calculating the bitrate, and then you change the osc :D :D ... you have to recalculate everything again ...

the whole point is to be able to "move from uC to uC" .. the point of high level language is to increase productivity, among other things by making code reusable. If you have to redesign the darn usart initialisation for every uC .. something is wrong with your compiler... - and yes, it is easier to write your own usart (or any other) library that will work for that one particular uC then to read and uderstand the provided library (by C18 for example) as those look / are complex for the sole purpose of covering "all the bases" ...

if you plan to use PIC18F or up - go with C18 / C30 microchip c compiler as they are standard for PIC .. if you wanna play with PIC16F and down - think twice what are you doing as those 16F's are not cheaper then those 18F's ...
 

Sceadwian

Banned
arhi, code libraries for micro controller lines are often not compatible with different chips, mainly because of differences in peripherals. Even with libraries when you change chip lines you'll have to port your libraries over as well.
 

arhi

Member
arhi, code libraries for micro controller lines are often not compatible with different chips, mainly because of differences in peripherals. Even with libraries when you change chip lines you'll have to port your libraries over as well.
I so do not agree that I don't have words for it :)

use C18 library for anything .. it will work on all capable 18F chips

take c30 now .. 80-90% of code for C18 (using C18 libraries) will work... now use C30 libraries, you can use the same code an all capable 24F, 30F and 33F pic's ...

of course if you use CAN library and your uC is not CAN capable library will fail but ... it will work, the lib from C30 on all 24, 30 and 33 pic's .. now if you do it "from the datasheed" then you have to write one for one part of 24's, one for second part of 24's ... another 4 or five for 30's and who knows how much for 33's ...

I was not insinuating that if you use usart library on C18 it will work on freescale or msp430 (ok usart will work, bad example, but something else .. CAN for example)

so .. "it will work"
 

Sceadwian

Banned
It will work, some of the time =)
 

Sceadwian

Banned
It's hard arhi, the problem isn't that there aren't standards out there, it's that there's too many of them =O
 

dknguyen

Well-Known Member
Most Helpful Member
The overabundance of standards is THE reason I am not a programmer today.
 
Last edited:
Status
Not open for further replies.

Latest threads

EE World Online Articles

Loading
Top