octal wrote:I'll not discuss the C++ overhead as with actual optimizing compilers and by limiting ourselves to one level of inheritence, this becomes really negligible. Also if the compiler is written in a way to handle inheritance "statically", the overhead will almost become almost null.
Agreed. Embedded should embrace C++ since it is there for a (good) reason!
octal wrote:
Programming XMOS devices is more like dealing with event handling and behaviour description than handling entities (objects).
Nothing can forbid you from seeing SPI as an object (object means class implementation and instances when needed).
But for me, when I see an XMOS doing SPI, I see it the opposite way, I see it more as PORTS objects having a certain behaviour (the protocol), handling events and answering them than an SPI port (in old hardware devices on other mcu) doing communications.
What I mean is that the main entity is the PORT doing something and behaving in a certain way. The SPI, I2C, ... protocols here will become simple behaviours, not main actors!
XMOS enforces that in the fact that this "behaviour" can be changed on the fly since everything is software configurable (at certain limits).
From my point of view this perhaps describes our point of view best:
I am looking at the XMOS as a system - and therefore wanting to implement a certain behaviour in it (the program). That you have ports with protocols on them is an easy way for me to flexibly use all the ports available.
Your description seems to me representing an FPGA like structure, that you have a chip with some pins and that is responds in a certain way if you dirve signals to the pins.
Did I get you right?
octal wrote:
Don't forgot also that, in that, with XMOS dev tools you have an extremely valuable tool, the timing analyzer. I think that this kind of tool becomes impossible to develop if it had to analyze your code through hierarchies (dynamic and virtual methods will make it mad).
Never got that really working for me with XC - so still so much to learn for me ;)
octal wrote:
I think that what is really needed to make code "cleaner" and more structured is namespaces and some privacy management!
Having namespaces will already change a lot of things.
As a personal tought, I know that C (and its derivatives) is THE FACTO standard in embedded world, so this makes things difficult to change. But I think that we need a clean programming language, with members cleanly private/public, and with some kind of encapsulation without loosing the "linearity" of algorithms in the XC way (to keep timing analyzing tools affective and less complex to develop).
(Don't kick me of :mrgreen: ), but I think that for such tasks, the best language that need to be ported to XMOS platform is something like Oberon7 or Modula2/3 !!!
It solves the pb of encapsulation (via modules and exported/private methods) without imposing inheritance and object orientation.
OK not enough experence with Oberon7 and Modula.
But how do you handle contracts then? E.g. you can have a contract of a 1 channel analogue digital converter and by implementing the contract you can swap the converter without changing much of your code.
The ADC contract woul then allow you t read a value and would give you information about timing and precision. Or is this again a too system-like point of view?