Explaining STM32F4 to a lay person is frustrating

[skillet]

Posted on February 15, 2013 at 04:56

I am currently migrating from F1 to F4. Am getting very frustrated. After many reviews of my presentation on F4, I get feedback that : to a lay person, the current project deliverables does not warrant 12 weeks of work. Right now, I have managed to configure digital I/O (push switch in and LED out), and serial communication via UART.

However, the expectation is that after 12 weeks of work I should at least be working with DSP to dynamically balance a robot.

The current robot software is built on layers upon layers of software.

Either 1) I explain the technicalities regarding What is actually involved to justify what is taking so long - which the assessor is not interested in, doesn't understand or 2) Simplify it just a little so that the assessor has a concrete idea, but the impression is that I take so long just to complete a 'simple' task.

The teaching kits in my school are mostly 8051, but migrating from F1 to F4 is much much more complicated. So I get remarks like ''Why would changing the chip take so long?'' ''Configuring switches and LEDs should be quite simple'' and so on.

How would I explain the amount of effort I put into it without being too technical? Need to convince the project assessors that while externally it might not look impressive, it actually takes a lot of work

#migration #porting

[Tesla DeLorean]

Posted on February 15, 2013 at 12:42

I guess I'd be pretty disappointed too. May be you're just new to embedded, micro controllers, and ARM in general? That all this stuff is new, and you're just on a steep learning curve, might be a bit more plausible? May be its a generational thing, I'd hazard there are a couple people on the forum, like myself, who were probably coding in basic/assembler/machine-code in their early teens, and got degrees in the field 7-8 years later. So may be ''I grew up on Java, and it f'd up my brain, and the way I understand computers'', might be a convincing argument for me.

I've regularly ported back and forth between F1/F2/F4 designs, different architectures and tool chains. I also use things like merge tools, and source code analysis / static analysis tools.If it took me a week, it would be because I spent 39 hours reading the manuals back-to-back.

[jpeacock2399]

Posted on February 15, 2013 at 15:49

Welcome to the real world.  Embedded programming is as much about economics as writing code.  If you can't make a business case to management on changing processors then you need to look at all the factors involved in the project, not just the technical ones.  Time to market is a critical factor in any commercial project.  If the time limit is 12 weeks you might ask yourself if it's wise to make large scale changes in the software.

One of the most valuable of all programming classes I had at school was Economics 101.  Supply and demand, cost of production, multiplers, all are just as important as DO loops and variable scope.

  Jack Peacock

[emalund]

Posted on February 15, 2013 at 15:59

This started me thinking and I decided to look up ''estimated time'' in a couple of places

From ''The mangers encyclopedia'':

estimated time: something wildly excessive

From ''The engineers encyclopedia'':

estimated time: something never long enough