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

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

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?