Looking to learn to program using non proprietary language?

Status
Not open for further replies.

Nicksan

New Member
I have used the Basic stamp (Boe bot and a couple of my own bots I made) and its ok but I would like to learn to program in a non proprietary language like C++, java or plain basic.
What PICs should I look into for a beginner to do so?
Thanks.
 
You simply will not get the same quality compiler to that of "proprietary" software!

Swordfish's SE version has no restrictions compared to the full version other than a 200 variable limit
 
The only restriction is that if you develop your software around a particular product it can be difficult to switch to another product. It's a form of vendor lock-in and it's something that I try to avoid.
 
The Swordfish SE (demo) has a very generous limitation of 200 variables and does not expire. This is scads more than any BASIC Stamp and much much faster too. The old stamp was 16C57 based and we tell people not to use the 16F84!
On the positive stamp side it shows what you can do with a 20yr old PIC!
 
Hero999 said:
The only restriction is that if you develop your software around a particular product it can be difficult to switch to another product. It's a form of vendor lock-in and it's something that I try to avoid.

Thats exactly what I mean, I would like to use a Microcontroller that does not require its own special language, IE.. PBasic.
I dont know C++ or Java but have dabbled with them.
I was looking at the oopic website and that seems to be programmable in C or Java. Anyone use one of those?
 
Last edited:
Nicksan said:
Thats exactly what I mean, I would like to use a Microcontroller that does not require its own special language, IE.. PBasic.
I dont know C++ or Java but have dabbled with them.

Swordfish is like programming with Visual Basic, its a true modular type of programming. 16F PIC's architecture do not lend them selves to the same programming approach, hence why 18F PIC's are only supported by Swordfish.

Almost Any 18F PIC micro can be programmed with Swordfish, its simply a matter of changing the Device declaration. eg;
18F2620
Code:
[B]Device [/B]= 18F2620
[B]Clock [/B]= 20

[B]Dim [/B]LED [B]As [/B]PORTB.0

[B]While True
    DelaymS[/B](1000)
    [B]Toggle[/B](LED)
[B]Wend[/B]
18F452
Code:
[B]Device [/B]= 18F452
[B]Clock [/B]= 20

[B]Dim [/B]LED [B]As [/B]PORTB.0

[B]While True
    DelaymS[/B](1000)
    [B]Toggle[/B](LED)
[B]Wend[/B]

This is the same concept for all of the 18F PIC's supported by Swordfish

Supported Devices;
 

I don't think you'll find ANY language that isn't device specific, and if you did, it wouldn't be of much use. There are various versions of C available for PIC's, but all are very different from each other - if you are used to C, and planning using the 18F series PIC's, then the MicroChip C18 compiler is a free download, and is even used for most of the 18F application notes by MicroChip.
 
blueroomelectronics said:
The Swordfish SE (demo) has a very generous limitation of 200 variables and does not expire.
That's not my point.

It doesn't matter how marvelous the software is or how inexpensive it is. If you use a piece of proprietary software it means your project is tied to that piece of software. Also if you've written some libraries you might want to use on other projects then you'll either have to re-write them or use the same piece of software.

Vendor lock-in is something that people overlook all too often when they're choosing software. Before I select a piece of software, I always ask myself questions like: Can it load and save in other file formats? If I really decided that I wanted to use some other piece of software later on how easy would it be to switch?


That's a shame I thought that C varient seemed like a good choice because I was under the impression that there was a standard.
 
Is the issue really probriatary high level lanugaues Vs 'standards compliant' lanuagues, or rather the fact that all microcontrollers are I/O centric with many special hardware features that no standards compliant language would have access to?

Custom functions and statements are certainly required either added to the underlining language or included in custom libaries, so expecting to be able to recompile a non trivial source file from one software manufacture's compiler with another's compiler without modification is probably never going to happen?

Lefty
 
Like people are saying, there is nothing out there for what you are looking for. It simply doesn't exist. Though, you will not be able to switch uC's and just recompile code, a C compiler will be your best bet. I have taken alot of PIC and 8051 C code and adapted fairly easily to my own uC and compiler.

OOPIC is totally proprietary, don't even bother with it.
 
Hero999 said:
That's a shame I thought that C varient seemed like a good choice because I was under the impression that there was a standard.

It's really about as standard as BASIC, even C for PC's isn't that portable!, and for micro-controllers a great deal of what you do is device specific. There's nothing to stop someone writing a compiler (either C or BASIC) that's completely portable across a range of micro-controllers - but because it would have to be written for the lowest common denominator it would be a pretty useless language.

Micro-controllers only use ONE language, and that's machine code, easily accessable directly as assembler - and personally I would suggest that's where anyone should start. PIC assembler is simple and fairly easy to learn, and it makes you understand the device you're using - C or BASIC try and hide the device from you, which means you don't really understand what you're doing, and why it doesn't work.
 
What Nigel said. To be an effective embedded programmer in any high level language you first need to understand the microcontroller you are programming. The most realistic way to do that is to learn to program it in assembler.

The machine code between processors is what the processor designers give you. There are many variants. The saving grace is that after you learn one or two the rest come rather easily.
 
What Nigel said. To be an effective embedded programmer in any high level language you first need to understand the microcontroller you are programming. The most realistic way to do that is to learn to program it in assembler.

I have to agree

Leant to program in asm to start with or at least do it as soon as you can it makes you code a whole lot better. At least then you will appreciate the time saved when you use a high level language
 
Hero999 said:
That's a shame I thought that C varient seemed like a good choice because I was under the impression that there was a standard.

There is a C standard, and the MCC18 compiler does adhere to it. You *can* write standard C with it, just as you can write operating systems code with C on other platforms.

The primary learning curve with the Microchip C is that like all microcontrollers it must access the unique resources of the PIC CPU and to do so there are some extensions (in a standards-allowed fashion) to the language.

This does *not* produce vendor lock-in to anything like the same extent as for proprietary languages. The code would only need *slight* changes to compile under any of the other C variants - something you could do with an awk, sed or Perl script (should you know any of these) or a good editor.

Microchip provide source for their library code, something I've found very useful for learning the PIC architecture, and producing zero vendor lock-in.

Also, using C on the 18F series, particularly the USB-enabled versions gives the fastest compile/test turn-around I've ever encountered in the embedded processor environment. It's the fastest way to learn PIC architecture, and be very productive very quickly.

Take a look at:

**broken link removed**

For the platform I'm using (it's based on the Microchip demo board etc.) I even have the programming and compilation tools working fine under Linux for the ultimate in no-vendor-lock-in

Paul
 
Maybe I am not explaining what I would like properly. I would like to program in C, C++, Java or even basic using any decent type of microcontroller, basically, I dont want to use a custom type of programming language like PBasic or Xbasic to program a MC.
Is the oopic a good MC, it looks simple and can program in what I would like.
 

You're explaining fine, you're just not listening to the replies - THERE IS NO SUCH LANGUAGE - by definition, to be of any use, a micro-controller language has to have many non-standard features to be of any use. As suggested, C is probably the closest, but you can't generally swap code from one device to another (or even one compiler to another) without making changes, which may be substantial.

But you can't even swap code between PC C compilers either, or between PC's and Linux - they all require changes as well.

Like I said before, such a generic language is possible, but it would be far too crippled to be of much use.

Is the oopic a good MC, it looks simple and can program in what I would like.

Oopic is a language, NOT a micro-controller, the device itself is just a PIC - it's probably as far away from what you're asking for as anything is!.
 

Nick... I thought my response showed you can program in C, a perfectly standard language. All you need do is know how to use the ANSI C language committee standards-approved extra features (e.g. #pragma) necessary to support the PIC 18F uC's... no way around that as all uC's are different and have features you really want to use so the compilers support them!

It's the same on x86 CPUs in PC's, as Nigel rightly points out, but often only visible in specialist programming such as operating systems code, games etc. You may not have encountered such software but it exists on PC's and uses gcc or Intel compiler extensions to gain access to them. Applications software is always much easier to port provided you are very careful, however even Java doesn't run the same on every platform!

That said, any C programmer could look at the code I've written for the PIC uC and understand what it was doing without really understanding the underlying uC architecture as I've buried that in macros etc. to make things more readable and more easily ported to another compiler or even perhaps another micro... though it would still involve work!

P.
 
Status
Not open for further replies.
Cookies are required to use this site. You must accept them to continue using the site. Learn more…