Python programming...

Go To Last Post
19 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, I was wondering...do Atmel's AVR processors support the Python programming language? Coz I know this language is used in some advanced portions of programming, there should seriously be something like programming microcontrollers?? Apparently it's used for stuff like robotics...I've written an IRC bot with a friend of mine anyway...

BTW, I'm not sure exactly where this topic should go to, so I posted it here...I hope there's nothing wrong...it seemed the most relevant forum for this topic :D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Python is a scripting language mainly used in Linux (though there is a Windows version too). There's no way you could run something like that on an AVR. Python itself is huge but it also need the underlying OS to support it.

Cliff

(I'll leave this in AVR Forum as the question was about AVR programming after all - you weren't to know that it was not really applicable to a microcontroller)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Python on a Chip supports 8-Bit-AVRs.

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey...thanks for your reply. Ahuh, I did forget that Python was a scripting language...so apparently, C++ and Assembly are the most suitable then? It's cool...I like 'em both but I've tried C++ just a little...not fully...:D Thanks...

sternst: hey that's cool...thanks...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Python is a scripting language mainly used in Linux (though there is a Windows version too). There's no way you could run something like that on an AVR. Python itself is huge but it also need the underlying OS to support it.

I'm not sure that I would go as far to say that you can't run python on an AVR. Certainly a full blown implementation is unrealistic, but a subset is quite doable.

As an example. (not on an AVR, but on other 8 bit micros) Synapse wireless runs their SNAP stack on an 8 bit, and the programming environment exposed to users is python based. The stack, and python interpretor, take up approximately 40K o flash.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

glitch wrote:
I'm not sure that I would go as far to say that you can't run python on an AVR. Certainly a full blown implementation is unrealistic, but a subset is quite doable.

As an example. (not on an AVR, but on other 8 bit micros) Synapse wireless runs their SNAP stack on an 8 bit, and the programming environment exposed to users is python based. The stack, and python interpretor, take up approximately 40K o flash.

So, you mean it's quite possible to program with Python? Uh...are there any real advantages of using Python anyway? I really like it though...just that the indentation tends to be rather annoying at times...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

there is an option and personally i have no idea why you'd do it but it is possible to write all your code in python then use http://shed-skin.blogspot.com/ to convert the code to C++. Saying that the include files may not be written for python so that could lead to trouble, again though you can go between python and c/c++ (see http://docs.python.org/extending...).

The only advantages of python i can think of (having used both python and c++) is that its really quick to write. I think it is probably best to learn either c or c++ though as it is going to be the most supported language for micros, besides assembly that is.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bitcraze wrote:

So, you mean it's quite possible to program with Python? Uh...are there any real advantages of using Python anyway? I really like it though...just that the indentation tends to be rather annoying at times...

It is possible, if the scripting engine is available for the AVR (or you develop it yourself). But there is no real advantage, unless you need user scripting capability. If you are developing your own, fixed, application, you are better off programming in assembly, basic, c, or c++. (there are a few other options as well, but those 4 are the most common)

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sternst wrote:
Python on a Chip supports 8-Bit-AVRs.

Interesting, but given that the Windows installation of Python is 13MB I wonder exactly how cut down a 350KB distribution is? (interestingly it's built with avr-gcc)

It's a bit like saying you could run Java on an AVR. Sure you could but the implementation would ditch virtually all the library support that an average Java program likely relies upon.

Even if it's available I see no advantage in using .Python in favour of C, C++ or Asm. You'll find a lot of other folks (and code examples) using those languages. If you can find anyone using Python on an AVR you should have them stuffed!

(apart from anyone else I doubt anyone's made SFR definitions for the AVR range in Python as they have done for C and Asm so that's a headache even before you get started - the example just shows support for PORTA and nothing more)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff you need to separate the language from the library. (and it's not 350Kb it's 40Kb) You can support the language without all of the library. We see this happening in virtually all programming languages when they are ported for small micros, including C. While a good portion of the library might be there, there are many parts that are not, simply due to the fact that there is no space or resources, or that there is no underlying OS to support them.

Having said that I do agree that there is not much point in using Python on an AVR except in an academic exercise, an exercise in curiosity, or if you need user scriptability for your app.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

glitch,

The 350KB was simply the figure stated here:

http://code.google.com/p/python-...

But the point remains - this is not Python, it's a cut-down subset of Python. It'd be a bit like a C compiler with while() but no for(). Sure you can create for() using while() but the point is you shouldn't have to and no existing code examples are going to have been written with such a limitation.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The 40K came from the same site:
http://code.google.com/p/python-...

Quote:

Features of the PyMite VM:

* Requires roughly 40 KB program memory and initializes in under 3 KB of RAM

You quited the size of the archive, which contains tools, source, examples, and documentation. that would be like saying one could never use C on an AVR, simply by looking at the size of the GCC install!

And your comparison of crippling the language is not fair, as you're talking about removing core parts of the language, and not the library. Using your example: for & while are not in the library, they are part of the language definition. [sticking with c] removing things like printf, which is from the library, is what we're talking about. (or at least I am) And removals like that from the "standard libraries" is quite common. [a real AVR/C example would be the standard time.h functions, and file i/o functions]

Having said that, in this case the language itself does not appear to be fully implemented (yet), though it does appear that the more critical parts are. Perhaps it should be referred to as being "python-like" instead of python in this case [ePy perhaps?].

As for examples, I don't care about them, as one should be able to understand that they are working in a limited environment, and be able to work around it, as long as the differences/limitations are well documented. I'm a strong advocate for learning, understanding, and applying; as opposed to memorizing and regurgitating (which is really no better than copying & pasting).

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One (small) advantage is that the program code can come from an external media. Nearly unlimited code size, executing different programs by exchanging the media, ...

Quote:
But the point remains - this is not Python, it's a cut-down subset of Python.
AFAIK gcc is not fully C99 compliant, so you are not programming in C, but only in a cut-down subset of C? ;-)
Quote:
no existing code examples are going to have been written with such a limitation.
Perhaps most of the examples don't use the missing parts. It really depends on what is actually missing.

But just to make it clear:
Of course I do not recommend using python on AVRs in general. But if someone ask for it, and I know it exists, why not telling him?

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you want some very small scripting language, you could try Adam Dunkel's uBasic :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

You quited the size of the archive, which contains tools, source, examples, and documentation. that would be like saying one could never use C on an AVR, simply by looking at the size of the GCC install!

Glitch, without flogging a dead horse: I think it's often an indication of tool complexity to look at the size of the entire distribution. Here we see that a 350K distro builds 40K of code. The 13MB distro builds a 2.2MB binary tool (well, OK, that's the size of the binary on one of my Ubuntu machines but I guess the Windows binary is similar). Given that 2.2MB is more than 50 times the size there's got to be SOMETHING more to it surely? The manual mentions the exclusion of 'class' and 'try' amongst other things - two of the core features of an OO language surely and just as "core" as while() or for() in C surely?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But we currently have the same problem with C++, some core features are not yet implemented. Python, is not purely an OO language, it is also a procedural (imperative) language, as well as a functional one.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
The manual mentions the exclusion of 'class' and 'try' amongst other things
Quote:
2009/04/28 (r356) New feature: Classes with multiple inheritance

Looks like the documentation is somewhat outdated. ;-)

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hey..cool thanks for all your replies guys...not to mention the really interesting argument :D...I'm a Linux advanced user see? and I'm messing around with python..not that much but am learning abit here and there...I made this bot with a friend of mine (who actually did the base :D) and got really interested and with that learned that there's more to it than meets the eye...well I got not one answer but many to my questions..thanks once again :D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now that's a different AVR application.

274,207,281-1 The largest known Mersenne Prime

Measure twice, cry, go back to the hardware store