Large compiled application size, is this normal?

Why would the floating point library be pulled in for the USART? All it does is transmit and receives bytes of data , no floating point calculations being caried out.

Scott

No I think there is purposeful casting of the maths related to the clock speed vs baud rate so it doesn't exceed scope. I would have done this with integer maths. All maths on the Cortex-M0 tends to be more library dependent given the core lacking key features. The incremental costs once you've got some base libraries pulled in is going to be more manageable.

The .MAP file should provide some understanding about where the bytes are getting eaten.

In the past I have always written my own code instead of printf etc. on other proecssors, as found it to be too much of a big overhead. For my applications, creating a few buffers for sending and recieving data within interupts is all I need (along with house keeping), and doesnt make much of a dent in program size.

Scott

First of all you're working with 32-bit code, in contrast to 8-bit code. The coded instructions will be bigger by definition.

That is not quite true.

The size of an instruction is defined by the number of instruction types to decode (like ADD, SUB, MOV, etc. in it's variants), and source and destination operand range. E.g. selecting one of 16 ARM core registers requires 4 bits of an instruction.

The same holds true for 8-bit processors. The Z80, for example, had 8 general purpose registers, requiring 3 bits for encoding.Only does that 8-bit core need more cycles to fetch a multi-byte instruction on the 8-bit data bus. That's why many old cores have a dedicated accumulator register - many operations implicitly use this accu, saving bits in instruction size and thus fetches. However, in the a greater context, you often need more instructions to achieve certain operations, loosing more than you gained before.