On Device Programming: C vs Python

[Nic]

In the German forum we have a discussion about the future of OnDevice Programming.

Maybe your follow it by translating it, but it would be nice to give us your feedback, too.

TF suggests 2 opportunities, I try to summarize it, but If you have questions please ask TF:

 

1) On Device API in C: similar as Arduino API

Pros: Performance, near to hardware

Cons: Not very user friendly language, hard to code,

TF means they have to rewritten the firmware

Most users are hobbyist and would be more familiar with Phyton

 

2) On Device in Phyton: There exists at least an open source projects to deploy a light version of a Phyton Interpreter on chip

(http://code.google.com/p/python-on-a-chip/).

Pros: easy language, reuse of exsting bindings, developing on desktop, deploy same stuff on chip

Cons: disadvantages of interpreter, limit of source code size

 

Some users suggests to combine it with a new Brick with memory capacity.

 

Dont hesitate and give us your feedback !

[JavaLaurence]

Given that my first choice of on-chip language is probably out of the question (Java.. not J2ME, but full J2SE), I don't really care which language is used.

 

What I do care about is that

 

a) the existing bindings are not thrown away

 

b) one could transfer scripts/programs (call them what you want) to a stack VIA new APIs... so in my case, I would want to be able to send a program for on-device execution via the Java bindings.

 

c) the On Device API includes full TCP/IP capabilities so that resident programs can communicate back to controlling PC/Raspberry/whatever.

 

d) if Python is NOT chosen, then maybe it would be commercially valuable to try and copy as much Arduino stuff as possible (language, API). For TF to be able to use "Arduino-like" in their marketing effort would give them a commercial boost from the "other" guys.

 

Finally, I really think it's a shame this discussion is not held in English. It's about time TF realises that it needs to focus on the international community a lot more than on its German users... I've tried using Google Translate to try and follow some German threads, and it's a pretty hopeless exercise. I don't know of any other technology supplier/site which is so not-English.. it's a shame.

[Nic]

JavaLaurence, thanks for your feedback.

If you cannot follow or understand the translation of German Threads, dont hesitate to ask inside this thread in English or send a PM. I assume that in most cases they answer in English, too; otherwise other users will help.

[batti]

Hi JavaLaurence,

 

I'm not surprised by your language choice

 

Your point d) is interesting. We had the same discussion in our team. I think you can discuss it in two ways. Firstly the way you have done: "Create a compatibility". The other way is to make it more high level. In short: "Make something new, make it easier". We don't use C, we use a high level language like Python or Java.

 

The high level approach would use some kind of interpreter on the Bricks such that the performance will not be as high as when you use your own compiled C firmware.

 

We don't have formed an opinion so far.

[JavaLaurence]

TF's "making it easier" approach definitely hooked me. I had been looking at Arduino/Raspberry developments for ages, but because of my lack of electronics experience, I hesitated. Then I discovered your products.. ;-)

 

For the On Device way forward, a word of caution: if you invent a brand new programming model, you may end up the Cybiko way: great, ahead-of-its-time technology, but a commercial disaster (if you don't know what Cybiko is, cfr Wikipedia).

 

For custom approaches, there are a million possibilities (ever heard of the Rebol language?), but sadly enough, you need to ensure that your choice is commercially sound. Whatever the chosen path, it needs to attract more people to TinkerForge, not scare them away. I think that any custom or exotic language will scare people away. Also anything which only gives people a minimalistic library of executable code On Device, will not be very impressive. At the very least, ensure that there's lots of stuff to communicate to the outside world, not just to all the Tinkerforge "dimensions" (such as the I2C bus, the ADCs, the bricklet hardware).

 

HTH

[borg]

At the very least, ensure that there's lots of stuff to communicate to the outside world, not just to all the Tinkerforge "dimensions" (such as the I2C bus, the ADCs, the bricklet hardware).

 

If that is the goal, C is the only option. But i don't think that should be the goal. It is a pain to solder stuff to Bricks or Bricklets and why would we want to go the Arduino route? You said yourself that you didn't do anything with Arduino because of your lack in electronics experience .

[JavaLaurence]

I didn't explain myself well enough, because you misinterpreted what i wrote.

 

I'm assuming that the On Device API will give full access to all TinkerForge-specific features, such as the I2C bus, the ADCs of the Master Bricks etc.. but what I would love to see in addition to this, is full TCP/IP communications capabilities with the outside world (via Wifi Extension). That's got nothing to do with electronics.. it's just building in maximum (software) flexibility.

 

BTW, I bought a soldering gun, some solder, a book on electronics, and as soon as my resistors arrive, I'll be working on hooking up my CNY70 optosensors to my Digital IO-16 

[batti]

The primary goal of the On Device API should be that you have the possibility to write standalone programs with an API similar to the currently used High Level API. That means, you should be able to use methods like "setVelocity" etc. This way the development of applications should be similar easy but you are forced to use one specific programming language.

 

If this programming language will be C, of course there is the possibility to offer a (low level) Arduino like API which includes full hardware access. The usage of this low level API will not be as easy since you have to pay attention not to interfere with the On Device API functions.

[JavaLaurence]

I just did another desperate Google Translate of some of the German thread on above.. and it looks like you wanna go for a Linux Super Master idea.

 

Has anyone floated the idea to create a Raspberry Pi adaptor instead? Advantages: super cheap "Super Master" (the Pi), very standard.. all you would need is some physical adaptor that you can sell, and some custom library to "open up" the whole stack to the Raspberry code..

 

Just an idea.. I just feel that creating a custom 4x4 TF-clickable Linux board is reinventing the wheel a lot. It would make more commercial sense to leverage the huge following of the Pi...

 

My 0.02c

[borg]

No worries, we just splitted the On Device Programming thread, since it degraded to a discussion about a "Linux Brick" (that can handle real Java/Python with standard library etc).

 

I agree that a Super Master is no viable anymore when there are Linux boards for 35€ available.

[neomutant]

No worries, we just splitted the On Device Programming thread, since it degraded to a discussion about a "Linux Brick" (that can handle real Java/Python with standard library etc).

 

I agree that a Super Master is no viable anymore when there are Linux boards for 35€ available.

 

My Question is speed and delay ? If it works on linux board via USB the max speed is 1ms and that is not fast enough (exsample PWM reader for rc receiver, or DMX controll for controlling some light and strobe efects, or auto stabilisation systems ).

 

But, If it work on Super Master with high level language (and I assume that internal delay/speed between Bricks and bricket its lower/faster ) then more things are possibile for Tinkers.

 

[borg]

That depends on the speed of the board. If it has a really fast CPU this would probably be true, but it would also be very expensive .

[JavaLaurence]

Does the architecture use I²C High Speed mode? And what's the used bus clock speed? That should give people worrying about performance an idea of what a stack is capable of.. when On Device Programming becomes available.

 

BTW, What's the CPU clock speed of Masters? I don't think I've seen this mentioned anywhere in the docs.. just curious.

[borg]

Does the architecture use I²C High Speed mode?

Depending on the sensor we are using 100KHz or 400KHz (we generally use the max speed of the sensor).

 

And what's the used bus clock speed?

You mean for SPI? It is 8MHz.

 

BTW, What's the CPU clock speed of Masters?

64MHz