how to code microprocessors and microcontrollers in python or do I need to learn assembly

There's a good poll and comments on programming languages here: What programming language should EE's learn first?

Some of the comments address assembly language.  I generally recommend ANSI C for programming embedded systems.  Assembly language is useful to learn at some point since some bugs can only be understood at the assembly language level.  I'm not a Python programmer, but I get the impression that you need a fairly large processor to run it well.

If your really coding for the micro controller then typically you would be using C or assembly, with arduino  and the like most people use a simplified and abstracted coding language called wiring, this is c structure and syntax but you are hidden from talking direct to the hardware which is good for beginners and portability but not always good for performance

Raspberry PI and the like run Linux so and under that you can run interpretive languages like Python or php or compiled languages like c or assembly, there a many more choices

As stated php and other interpretive languages don't often let you directly at the hardware with the benefit of portability between systems but this is often at the cost of performance

Performance is not always important, it depends on the application you are writing

Sent from my iPhone

If you wan to program a 8-bit or 16-bit microcontroller, it is essential to learn assembly language, It mainly because assembly is faster(Than C) and easier to debug.

Knowing python is good because you can use it to interface with serial.

Here is a tool that might work.

https://code.google.com/p/python-on-a-chip/

If you only want to use 32bit mcu like the ARM Cortex based then you need not learn assembly.

Sorry  for the late reply

I'm sorry to be contrary S142857 but your statement "If you wan to program a 8-bit or 16-bit microcontroller, it is essential to learn assembly language, It mainly because assembly is faster(Than C) and easier to debug." just isn't correct.

The TI MSP430 is a 16 bit controller which is almost always programmed in C and the Atmel AVR 8 bit processor was designed to be programmed in C.

The usually recommended practice is to write all your code in C and then, if required, optimise those small sections of it that are running too slowly. Optimization may include using assembler but more often requires algorithmic improvement. There are occasions when assembler can be written to go faster than even a good compiler can manage but most of the time it just doesn't matter.

There are a few very small 8 processor where there is no C compiler available and it may be necessary to code them in assembler but unless production volumes are large it will be cheaper to use a more powerful processor and code it in C.

Debugging in C is much simpler than in assembler with the tools typically available for each.

I don't use 8 bit AVRs any more but when I did a few years ago all the code was written in C.

It is useful to understand the assembly language of the processor you are using because every now and again you will suspect the compiler of misbehaving (and one time in 100 it will be mis-behaving) and then it's good to look at the code it made.

MK

Michael Kellett wrote:

 

Debugging in C is much simpler than in assembler with the tools typically available for each.

Absolutely.  I'll take a printf over single-stepping with a binary console any day.

It is useful to understand the assembly language of the processor you are using because every now and again you will suspect the compiler of misbehaving (and one time in 100 it will be mis-behaving) and then it's good to look at the code it made.

Sometimes the compiler behaves correctly, but you think it's doing the wrong thing because of something you forgot or didn't know about.  My favorite example of this is when we ported 100K lines of C from 68000 to PowerPC.  The original code was not careful about shared variables used by interrupt service routines.  One thing it did was to increment and decrement buffer size variables.  Well, it turns out on the 68000 you could increment a memory variable in a single, uninterruptable instruction.  However, PowerPC is a RISC machine required three instructions: load, increment register, and store.  If an interrupt occurred in the middle of this sequence, the interrupt service routine might decrement that same variable using its old value instead of its new value, and suddenly data would appear in or disappear from a buffer for no apparent reason, with low probability of occurrence.  Looking at the ASM made it clear that the compiler was doing this new behavior (which is entirely correct for a PowerPC) and gave a clue what the problem was.

What chance would you have of figuring out this problem without ASM?

I completely agree with John,

Michael I think you misunderstood

Assembly is always faster than c,  even in avr

Binary is even faster

It is because even in a language like there is a lot of code that is not necessary for the program to function(libraries) ,

In a computer with 16GB ram and 3.6ghz processor it is not a problem but when used with a mcu with 8kb ram and 16mhz processor it has effects on speed of execution.

@s142857, there's a not bad Wiki article about assembler which will help you to understand why assembler and binary run at the same speed.

Assembly language - Wikipedia, the free encyclopedia

Assembler (in real life) isn't always faster than C because it takes too long to write it well. In the days when there was no choice most programmers used libraries of code which meant that they were using  a standard bit of code for most jobs rather than opitimising exactly for each tiny task - which is pretty much what compilers do except they don't get bored and make silly mistakes so easily.

C compilers and linkers generally do a good job of not including code which isn't used  - a lot of my C code is running on processors with less than 8k of RAM. Speed and code size are not always directly related - for example it may be faster on some processors to unroll a loop and repeat the same code many times  - leaving chunks of unused code in a programme is bad practice but it doesn't necessarily make it slower.

MK

Binary faster than Assembly, is kind of like saying French is faster than English (Maybe a bad analogy )

Assembly is simply mnemonic representation of Binary to make it easier to remember the codes, even the data sheets list the code sets using the friendly mnemonic along with the HEX / Binary

It is the general use of Libraries in any language that can slow things down due to being typically written in an way to maximize use for many applications rather than one.

Assembly in of itself is no slower than the direct binary coding. except to actually write the code where the assembly can be way faster.

Peter

Thank you all for your help guys, I truly do appreciate your comments which

help enable me to reaching my dreams of becoming an entrepreneur which

can develop his own electronic products