Infos zu RoboPro / Yagarto C-Compiler / 4NetOS

[hamlet]

Liebe Fischertechnik-Freunde,
seit einer Woche bin ich RoboTX-Spielkind und habe mich durch die Dokumentation von RoboPro, der des C-Compilers und Doku der TXC-Lib gelesen.
RoboPro ist eine sehr schön intuitive Entwicklungsumgebung, in die man sich sehr schnell eingearbeitet hat. Dafür ein großes Lob an den/die Entwickler. Allerdings ist die Performance lokal ausgeführter Programme recht bescheiden:
-> Allein ein Durchlauf einer leeren Schleife benötigt 2ms.
-> Bis eine Liste mit 1000 Zufallszahlen, die mit der Bibliotheksfunktion RanUni erzeugt wurden, gefüllt ist, vergehen ganze 8.5 Sekunden.
Für viele Anwendungen ist das schlichtweg zu langsam: Sortieren und Durchsuchen von Listen, komlexere Regelaufgaben, neuronale Netze, ...
Ich vermute, dass RoboPro den gleichen 1ms-Zeitscheibenansatz verwendet, der auch in der C-Compiler-Dokumentaion beschrieben wird. Und um den Programmablauf konsistent zu halten, evaluiert RoboPro alle aktiven Datenojekte nur einmal pro Zeitscheibe und reicht deren Werte an die verbundenden Aktoren und Verzweigungen weiter. Dann laufen die Prozesse weiter, arbeiten Aktionen ab, modifizieren dabei die Datenobjekte, bis sie zu einem Aktor gelangen, dessen Verhalten vom Wert eines Datenobjekts abhängt. Dort halten die Prozesse an und warten auf einen stabilen Dateneingang in der nächsten Zeitscheibe. ... Naja, nur eine Vermutung.
*** Ist es evtl. möglich, für Prozesse, die in einem Objekt gekapselt sind und nur von objektinternen Variablen abhängen, die Evaluation der Daten und Abarbeitung der Aktionen mehrfach pro Zeitscheibe anzustoßen?
*** Gibt es weitergehende Dokumentation der Interna von RoboPro?
*** Gibt es Doku bzw. Beispiel/Test-Programme für den in der RoboPro Hilfe undokumentierten Level 5 "Objekte"?
*** Wird RoboPro in Zukunft noch erweitert? 32-bit integers, Einbindung von eigenem C-code, Listen von Objekten, BlueToothKommunikation, Zugriff auf Dateisysteme, ...

Die andere Möglichkeit lokale Programme zu erstellen ist der C-Compiler. Hier laufen lokale Applikationen weitaus schneller. Leider ist hierbei die Unterstützung des 4NetOS Beriebsystems bzw. der Fischer-Firmware recht dürftig. Aus der Doku: "Die einzige Beschränkung die dem Code in der Funktion „PrgTic“ obliegt, ist die, dass diese nicht zuviel Zeit in Anspruch nehmen sollte. Es wird eine Ausführungsdauer von bis zu einer halben Millisekunde (500 Mikrosekunden) empfohlen. Andernfalls steht nicht mehr genug CPU-Zeit für die restliche Firmware zur Verfügung und ein geregeltes Echtzeit-Multitasking ist nicht mehr möglich." Ausetzen von Tasks? Scheduler?
Ich habe im Netz leider kaum Informationen zu dem auf dem RoboTX Controller verwendeten 4NetOS gefunden.
*** Ist Dokumentation zu dem 4NetOS irgenwo erhältlich?
*** Unterstützt 4NetOS tasks bzw. verfügt es über einen scheduler?
*** Verfügt die Yargarto tool chain über eine standard c-lib?
*** Werden floating point Variablen unterstützt? Die Verwendung von Floats in einem modifizierten Demo-Programme wurde mit einem Linker-Error quittiert "arm-elf-ld: ERROR: ../../Bin/GNU/GNU_ARM/lib/gcc/arm-elf\libgcc.a(_arm_addsubsf3.o) uses hardware FP, whereas
StopGo.elf uses software FP"
*** Gibt es Zugriffsfunktionen für Dateisysteme, Bluetooth, I2C, serial, ...?

Gibt es evtl. alternative Entwickungsumgebungen?

Falls irgendjemand etwas weiß, bin ich für jede Antwort dankbar.
Beste Grüße,
Helmut

[Sulu007]

Hallo Helmut,
erst einmal herzlich willkommen im Forum.
Klasse das du jetzt einen TXC hast und dich da so richtig reinhängst.
Bei aller Euphorie bedenke bitte aber es handelt sich hier um Spielzeug und nicht um einen Supercomuter mit Ein- und Ausgängen.
Für die meisten Anwendungen reichen die Geschwindigkeiten föllig aus.

Leider wirst du nicht viel Doku über Interna des Interfaces erhalten, da es kein OpenSource-Projekt ist und die Angst des Nachmachens zu wohl zu groß ist.

Weitere Infos zu anderen Sprachen kannst du hier finden.

[Ad2]

Hello Helmut,

I don't have that much experience with the TXC yet but it differs quite a lot from the RI (RoboInterface). On the RI a robopro program runs just like a user program written in Renesas C. The scheduling is part of the RoboPro (RP) program itself (co-operative multitasking). This makes sense because the RI firmware does not provide real-time OS services but only a hook into the 1ms timer-interrupt and access to the messaging mechanism. The TXC however has an OS but provides to the (Yagarto) user only a timertick which is indeed quite limited.I don't know if more services are provided to RP programs, this would be nice to know. The Yagarto environment is a general purpose compiler with which you can generate any program, you are only restricted by the OS and at the moment the OS says that we can only use the timertick. At some point in time we will find out more about the hardware and the OS and we may be able to bypass the OS and take complete control of the TX. This is particularly advantageous when we want to achieve things in areas where ft has been a bit lax (like camera, bluetooth and especially I2C). As you may know the datasheet of the controller (some atmel ARM9) is available, you could try whether you can access the registers of the I2C interface, important problem here is that the TXC firmware also has access to these registers and does not know (nor cares) about your program. There is someone on the forum who developed (parts of) 4NetOS, maybe this person can help us to get a foot between the door of this OS.

Ad

[vleeuwen]

4NetOS is a RTOS owned by Msc. There is no public information available.

See for more technical details about the hardware:
http://web.inter.nl.net/users/Ussel-Int ... index.html

[hamlet]

Hello,
thank you very much for your responses! Well, I know, the TXC is a toy and I bought just for playing, but I also know that an ARM9 200Mhz CPU (AT91SAM9260) can do much better, than stepping with 500Hz through an empty for-loop.
A combination of the Yagarto tool chain and the HW-access provided by the firmware with real preemptive task scheduling would make the TXC just the perfect toy. In the current approach, you can't do very much useful in that 500µs slot of the PrgTic function without context switching. It is just enough to call the IsRunStillAllowed function ~100 times (btw with RoboPro this would take 200ms not 0.5ms). OK you can poll the IsRunStillAllowed function at certain check points and store your context manually before bail out and wait until you can continue in the next time slot. But that would result in really aweful code.
It seems that 4NetOS disappeared from market, when "Smart Network Devices" was taken over by MSC 3 years ago. A search for 4NetOS on the MSC page does not return any links. The development manager responsible for the RoboTX and 4NetOS development has been looking for new opportunities since last summer (google <- "robo tx" 4netos ). ... This does not sound very promising.
I am afraid, that for fiddeling arround with Boostrap SW and an alternative OS, my expertise in this area is not sufficient and if I would dare to try this, I would brick the TXC faster than I could say "!§$%&/".
I just found out that the Yatargo package includes a c-lib (newlib).
And I have read a bit in "Programming Embedded Systems in C and C++" (O'Reilly,1999). Therein a cute little but sufficient RTOS coded in C++ is described. Adding the assembler code for the context switch (tough), maybe it is possible to implement some RTOS features on top of the TXC timeslice approach. OK, due to the lack of an interrupt that calls the scheduler, the tasks would be still be responsible to poll the IsRunStillAllowed function and trigger the context switch by themselfs. And the time base of just 500µs is challenging. Just an idea, maybe not feasable.

cheers,
Helmut

[MisterWho]

In the old ft Forum the developer of 4NetOS wrote some lines about his work. (Has anyone a BackUp of the old forum or at least of the post?) As you already have discovered the development of 4NetOS has been stopped.
If I have got the post of the developer right in my mind, he said he would give us some further information?

Regards,
Joachim

[steffalk]

Hello everybody,

Just my 2 cents: The more I read about programming the TX directly here in the forum, the more I get the impression that native code programming inside the TX is practically unusable. Please correct me if I am wrong. There seems to exist simply no, or, if any, only rudimenatry documentation about the hardware, the operating system and any programming APIs.

On the other hand, the TX hardware seems to be really powerfull. It is under-utilized by RoboPro, which is understandable if we see RoboPro targeted to children mainly, with ease and robustness as priorities. The whole C compiler story seems to be really weird - again, please correct me if there is any worthy support of which I don't know.

I still wonder if it would be possible to port the Microsoft .net Micro Framework (µF) to the TX (http://www.microsoft.com/netmf). It is free, including source code and including the porting kit. The hardware is more than luxurious for the µF, and the benefit could be that at least Windows users could, at last, really use the hardware capabilities of the TX in a really productive development environment. That, combined with the rich feature set the µF offers (think of easy and robust multithreading, powerfull debugging, rich class libraries) seems a worthy goal to me. Also, as graphics are included, it could perhaps be possible to finally use some camera and do useful things with it. Now, as far as I can see, the vast majority of us can use just nothing inside the TX besides what RoboPro offers.

While the µF is not hard realtime-capable, it should still be fast enough to do many many interesting things with the TX. If someone would need hard realtime capabilities, these can be implemented in the native code layer, and communicated to the µF above. But it would have to be determined if such extensions are needed at all.

Nevertheless, I have no hardware experience and would very probably have no chance of porting the µF to the TX. The µF can sit ontop of an operating system, or directly upon the hardware (using no underlying OS at all). As far as I know, one would have to implement some KB of native C code (about 80 functions) to adapt the µF to the TX.

Is anybody here interested, and perhaps knowledable enough to tackle the porting effort? My original approach to the TX was simply skipping it until it really supports productive development or wait until a successor is there. In the state the TX is now, it simply doesn't offer compelling new use cases to me that I could not handle with my good old Robo Interface.

Best Regards,
Stefan

[vleeuwen]

Replacing the OS is not the main problem.
-) The BT stack
-) comminication with the PC
-) The stay compatible with RoboPro
-) etc.
It is not real a language problem. The problem is at a more abstract level.
More a library problem.

@MisterWho
4NetOS was bought a couple of years ago by Msc.
It is not public available and also the documnetation is not public available.
They are still using it or a derivative.

@Sulu007
You forgot MS Robotics Development Studio.
A very powerfull development environement for online use.
Not only programming in different levels of abstraction but also Visual simulation and interation with not fischertechnik actuators and sensors.

[niekerk]

Hello all,

I have 2 TX controllers, and while I do not regret the purchase, I'm not really enthusiastic either.
Most of the complaints I do have to agree with.

Most of my programs are in C, also for the Robo Interface. What I liked about the RI approach is
that the programming model for host and download mode were the same: with only a few #ifdefs
the same code could run in both modes. The new TX "inverted programming" mode makes this
very hard. Using a Finite State Machine (FSM) approach on both host and target could maybe solve this,
but it is too hard to write anything but the most simple programs this way for most of the people.

I thought about the dot net microframework too. I think it can work around the inverted model
problems. But I think the TX is falling short on I/O primitives. It really looks like they used all the
available power to make the device as restricted as possible. I really would welcome a micro framework
effort, and I would help as much as my time permits. But without the help of ft it will be difficult,
if possible at all.

Regards,
Paul

[thkais]

Hello all,

I don't think that the speed-problems are caused by the RoboPro implementation only. Shurely, there is some overhead to guarantee some background, i.e. regular checks of the inputs, updating the outputs, etc.
It seems so, that the Controller spends a lot of time for the OS itself. As I analyzed the communication between two TX (master - slave) I was surprised, what was going on in the mind of the programmer. For an example, 4 Bytes(!) are used for the addressing of the slaves (summarized 8 Bytes - where one Byte will be enough). The whole communication is blown-up without any need, and I am very shure, that it can be shrinked to less than a half without any disadvantages (and then there will be no timing-problems with more than 4 slaves). I am afraid, that the whole concept of software on the TX follows this example, so much of the power of the controller is waisted. Another example: The respond-time of an slave for a request of the master is very different, and is approx. 0,5 ms. What the OS is doing in this time?
In an implementation of an interface I see not necessarily a need of a multi-tasking OS (especially when the User only can use one single task) but a lean OS, which consumes as less controller power as possible.
@steffalk: Show me the USB-connector for a camera on the TX - then you will able to use a camera on a µF with the TX. Otherwise you will only be able to use a PC and the TX in online-mode - and then there is no need of an µF-implementation on the TX.
In conclusion I see no chance that the µF will ever be implemented on the TX.

[Ad2]

Hello all,

I don't particularly like the closed TX environment either and would welcome any transition to an open system. The .net micro-framework is fine with me. I'm willing to help with porting, I have some experience with embedded programming but we need information about the hardware as well (how the peripherals (ports, bluetooth, display controller, memories) are connected to the microcontroller, maybe hobelbrecht can help again). Concerning a USB host interface we may be out of luck, it appears that the host and device ports use different pins (contrary to the mbed that I'm using for another project). When we also adapt ftmsclib we could maintain compatibility with robopro in online mode. Perhaps RPE could leak to us what API he uses for download mode.
Personally I think that getting started with this is the hardest part, once we start working we will learn more about the system and things will speed up.
@rei_vilo: The uF runs on the TXC and has nothing to do with windows. A change on the host side is a little beyond the scope of this project but when we involve the ftmsclib, an adaptation to linux should not be that hard. Furthermore there is some kind of .Net for other OS's too (I think it's called Mono).

Ad

[vleeuwen]

@ad2
>>I think it's called Mono (sponsord by NOVELL).
Mono is right. It implementing a big part of the ECMA standard for .NET.
I notice that some users a happy with Mono.
.

[steffalk]

Hello again,

the .net Micro Framework is related to the usual .net framework only as it is an interpreter for the same Intermediate Language (IL, the .net byte code), and that you use the same development environment (Visual Studio) and a subset of the same framework as on bigger irons. The µF implements its own ECMA-compatible common language runtime. As its implementation has nearly nothing to do with the normal .net framework, the existence of Mono for Linux would not help very much in using the µF with Linux, sorry.

Nevertheless, I guess that still the majority of users use or at least can use Windows. Even if the µF would probably not be useful for Linux/Mac users, it definitely would be for Windows users, and the advantages would be tremendous. The fact that not all users could benefit is sad, but imho no reason not to use the µF for the part of users that can use it. Anyway, other efforts targeting other operating systems would still be possible, wouldn't they?

If the µF or any other solution can ever be realized for the TX at all is a totally different story, though. As the available information is so limited, I do not have much hope that it will ever become a reality. But I wanted to give luck a chance by asking. Perhaps someone has better news on that than I. In the current state, I would simply skip the TX and stick to my RoboInt until a more capable successor gets available. There are enough models to build with the available material, after all.

Best Regards,
Stefan

[vleeuwen]

A lot of options and good ideas.

But is one of these options offering a good solution for the main problem: the BT Radio Call connection?
All other OS's will meet the same problem, the BT-stack.
And for that you will probaly we need Msc.

Without the BT Radio Call, the TX-C is not so bad.

The main problem is that all other development is waiting until the BT-problem has been resolved.
Not only the technical part but also the development of the documentation and didactical material.
With the FtTxService for the intergration of the TX-C into MS-RDS I made a lot of progress.
The refresh rate is much better than the adviced 40-50 msec for a PC BT based interface connection.
(50 msec is the Bluetooth a rough rul of the thumb poll frequency for Lego
source ProMSRDS pag 163 ISBN:978-0-470-14107-6)

A second problem is the connection with RoboPro.
After the integration of the FtLib into the RoboPro .exe, RoboPro became a close system in the online mode too.
Before it was possible to hook up the FtLib.Dll with a dummy.
The TA and API definition was the interface specification.
In terms of MS-RDS the alternate contract specification.

[Ad2]

Alternatively we could use something like Netduino and build our own shield with motordrivers and inputs. It will not have the nice form factor of the tx and we still have to hack some of the communication but it will be open source, forward instead of reverse engineering and possibly cheaper.

[vleeuwen]

Hi Ad,
Creating our own interface is nice for a small group of specialist but I am not sure if this will also be helpfull for the main target group of fischertechnik.
Personal I am working with Microchip stuff and I am happy with that too.

I am still hoping that the TX-C creaters will succeed in creating some entries that makes it possible for the group of specialist to add their own functionality to the TX-C controller. Like I describe this some months ago.

[Ad2]

I know all that and the robopro programmers should stick to what ft provides. It's just that the hardware has so much more potential. The C environment offered so far does not unleash it. An adaptation will always be for a small group of users only. That does not mean it is not worth the trouble. But porting the uF is one thing, having to hack the existing system is another.

[steffalk]

Hello again,

if we are talking about designing new hardware already, there is another thought: There are so many board manufacturers out there supporting the µF (see http://www.microsoft.com/netmf/hardware/ for examples). They would "only" have to be made fischertechnik-compatible. That is, add power supply, add drivers for motors etc. Could someone with hardware experience suggest what board to use, what components would be needed besides the board itself, and how to glue all that together?

As a benefit, long-term supporters as, for example, GFI, had their boards always updated from µF 1.0 up to the current 4.x. That combined with the relatively easy portability of application source code between boards would offer a solution which can be used and kept current for long times without the need to totally change the development environment.

Best Regards,
Stefan

[Ad2]

Hmmm, I looked at one of them, with a similar processor, it is commercial so you have to pay for the port which I already don't like. It is based on the standard AT91SAM9261-EK Evaluation Kit from Atmel which cost around a whopping 1000 Euro (depending on where you buy it). I was hoping for cheaper solutions like Netduino (31 Euro) or Elektor Sceptre (100 Euro), both based on ARM7.

[Ad2]

Hi rei-vilo,

Arduino is a nice concept (although it is not quite C), it is based on the ATMega168 (or 328) and this not nearly as powerful as the M16C in the RoboInterface, let alone the ARM9 in the TXC. I use the ATMega (not Arduino) for specific interfaces like the TX-bridge and an RI-I/O extension. With the ATMega you quickly hit its limits, e.g. for communication with the TXC over RS485 you need almost half of its processing power. The Netduino does better because it is ARM based (32 bit i.o. 8) higher clockspeed, more RAM, more ROM. Still the Netduino has no external RAM or ROM and hence is no match for the TXC. On the other hand it is fully open source and implements the .Net uF. So from a software point of view it is a great solution, from a hardware point of view however it is not so good because it does not interface to ft at all. So a shield must be developed that implements for instance motordrivers, universal inputs, bluetooth or RS485. I2C is already there but here we have to wait for ft. At the moment I'm experimenting with 'mbed' mbed.org which is an arduino like approach with easy to use libraries and an online IDE. It is based on an ARM7 and has the shape of a small processor board that you plug into a baseboard (Arduino is a baseboard in which you plug extension shields). There is an attempt going to port the uF but I have no experience with that (yet).

Ad