Fischertechnik Library/Gnu C-Arm-C-Compiler

Alles rund um TX(T) und RoboPro, mit ft-Hard- und Software
Computing using original ft hard- and software
Forumsregeln
Bitte beachte die Forumsregeln!
Antworten
FTechGirl19
Beiträge: 3
Registriert: 04 Sep 2012, 16:48

Fischertechnik Library/Gnu C-Arm-C-Compiler

Beitrag von FTechGirl19 » 04 Sep 2012, 17:01

Hallo alle miteinander ;)

Ich habe einen Fischtertechnik Baukasten mit einem Robo TX Controller
hier und suche nun eine Möglichkeit diesen zu programmieren.

Ich habe von der Fischertechnikseite den Gnu C-Arm-C-Compiler
(Toolchain) heruntergeladen und habe auch schon ein bisschen was
programmiert (zB Schleife, LED, Motor, ... Linienverfolgung ...
Displayausgabe).
Soweit - so gut :D

Nun wollte ich einen Tasks oder Timer programmieren um eben zB alle
100ms einen Sensor auszulesen.
Da dies in den Beispielprogrammen nicht vorkommt und ich diesbezüglich
auch sonst (zB eine Dokumentation) nichts gefunden habe seid ihr meine
letzte Hoffnung!!! :(

Kennt sich jemand von euch damit aus und kann mir einen Link zu einer
Dokumentation oder zumindest einer Community nennen? -.-

Oder könnt ihr mir einen anderen Compiler/Library empfehlen, der/die
vielleicht besser ist.?! xD

glg
Sophie

Ad2
Beiträge: 306
Registriert: 31 Okt 2010, 22:20

Re: Fischertechnik Library/Gnu C-Arm-C-Compiler

Beitrag von Ad2 » 04 Sep 2012, 17:19

Hi,

If I remember correctly, there are some timer fields in the transfer area that are incremented every 10ms, 100ms etc. There is (hope this is still the case) a function UINT32 (*GetSystemTime) (enum TimerUnit unit) that returns the time since the TX was started. With 3 as the argument it will return milliseconds, so compare this value to a variable that you increase by 100 every time you exceed it.

good luck

hamlet
Beiträge: 332
Registriert: 12 Jan 2011, 21:41

Re: Fischertechnik Library/Gnu C-Arm-C-Compiler

Beitrag von hamlet » 04 Sep 2012, 18:13

Hallo Sophie,
... und die int PrgTic( TA * p_ta_array, int ta_count)-Funktion wird millisekündlich von der Firmware gerufen. Wenn Du also mit deinem Code in PrgTic unterhalb der erlaubten 500µs bleibst, kannst Du einen Timer einfach mit einer globalen oder statischen Variablen, die du bei jedem Durchlauf von PrgTic inkrementierst, realisieren. Das ist alles andere als schön, aber Tasks oder Timer bietet die Firmware nun mal nicht. Sauberer wäre Ad's Ansatz mit GetSystemTime , wobei der Aufruf über den Function-Pointer der Transfer-Area allein schon ca. 5µs benötigt. So war das zumindest bei älteren Firmware-Versionen.
cheers,
Helmut

FTechGirl19
Beiträge: 3
Registriert: 04 Sep 2012, 16:48

Re: Fischertechnik Library/Gnu C-Arm-C-Compiler

Beitrag von FTechGirl19 » 08 Sep 2012, 16:33

Erstmal dankeschön für die Antworten!! :)

Danke, diese Funktion ist sehr hilfreich! :)

gibt es wirklich gar keine Möglichkeit, tasks einzuprogrammieren? :(
Mit einer anderen Library vielleicht??

Welche Programmiersprache/Library ist denn eurer Ansicht nach die Beste, abgesehen von RoboPro?
Was verwendet ihr denn, zum Programmieren? :)

glg Sophie

FTechGirl19
Beiträge: 3
Registriert: 04 Sep 2012, 16:48

Re: Fischertechnik Library/Gnu C-Arm-C-Compiler

Beitrag von FTechGirl19 » 10 Sep 2012, 11:33

Das es das für Lego gibt, weiß ich. Mein letztes Projekt war mit Lego in RobotC, wo ich eben Tasks verwendet habe.
Das ist auch der Grund, warum ich auch beim Fischertechnikroboter gerne Tasks verwendet hätte..

was verwendest du beim programmieren mit Fischertechnik???

Ad2
Beiträge: 306
Registriert: 31 Okt 2010, 22:20

Re: Fischertechnik Library/Gnu C-Arm-C-Compiler

Beitrag von Ad2 » 10 Sep 2012, 17:37

@Ford

That's a bit harsh. Both the RoboInt and the TX are good interfaces. RoboPro is a good piece of software too. Only problems: it is very closed and it appears to hinge on a single developper, butit is intended mostly for beginners. The support for PC programming is reasonably OK although I'm not a fan of the transferarea paradigm, I would prefer a normal API with functions (the TX has this but still on top of the transferarea).
Also the timing could be more transparent in the sense that the sampling in the interface and the communication and signalling on the PC side are synchronous (and at 10ms intervals).
The offline programming is more complicated but in order to do that you need to be a bit an expert anyway (embedded programming is not for just anybody). The main problem is the firmware and more specifically that fact that it is not open. If I want to use a certain peripheral in the interface I probably can't because the firmware is also using it and there is no documentation how this can be disabled. There is also no documentation on which ports connect to what or even on the definition of the camera connector. This lack of documentation makes it extremely difficult to make your own software modules for instance to connect a camera, do something nice with bluetooth or improve the RS485 communication. Even if the firmware would not be laid open it would be nice to have sufficient documentation to be able to develop a user community firmware which can be used as an alternative to the official firmware. Although I'm not sure the ft community is big enough to achieve this.
So: hardware good, software reasonable, documentation very poor.

vleeuwen
Beiträge: 1609
Registriert: 31 Okt 2010, 22:23
Wohnort: Enschede (NL)
Kontaktdaten:

Re: Fischertechnik Library/Gnu C-Arm-C-Compiler

Beitrag von vleeuwen » 10 Sep 2012, 21:54

I agree with Ad2.

thkais
Beiträge: 384
Registriert: 31 Okt 2010, 21:45

Re: Fischertechnik Library/Gnu C-Arm-C-Compiler

Beitrag von thkais » 11 Sep 2012, 07:33

Moin,

... und diese Antwort ist nicht ganz richtig.
Richtig würde sie lauten: Das gibt es nicht für den TX-Controller.
Für das Robo-Interface ist eine Script-Sprache für autonomen Betrieb mit Multitasking existent.
(Nebenbei: Rekursive Funktionsaufrufe sind hier möglich)

Man kann aber auch mit der Toolchain des Gnu-Arm Compilers Multitasking programmieren - man muss sich eben mit dem Konzept des kooperativen Multitasking vertraut machen. Also kann man nicht generell behaupten, es ginge garnicht. Und nur, weil man ein Konzept nicht versteht, muss man es nicht verteufeln.
Gruß
Thomas

Ad2
Beiträge: 306
Registriert: 31 Okt 2010, 22:20

Re: Fischertechnik Library/Gnu C-Arm-C-Compiler

Beitrag von Ad2 » 11 Sep 2012, 10:23

I think it's not the GCC that prohibits this, GCC supports multithreading. It is the firmware (the Arduino like programming model) that gets in the way. The firmware requires you to give up the time slice after 500us. With multiple threads running concurrently this is difficult to accomplish (maybe impossible and certainly not elegant). Futhermore preemptive multitasking usually requires a timer but all the hardware is under control of the firmware. It is probably not that easy to just 'take over' the machine from the firmware.

thkais
Beiträge: 384
Registriert: 31 Okt 2010, 21:45

Re: Fischertechnik Library/Gnu C-Arm-C-Compiler

Beitrag von thkais » 11 Sep 2012, 11:37

Moin,

darf ich mich selbst zitieren?
".... man muss sich eben mit dem Konzept des kooperativen Multitasking vertraut machen."

Kooperatives Multitasking ist Multitasking. Nur eben ein anderes Konzept.

edit:
Wie das Programm aussehen würde? Wie jedes andere mit kooperativem Multitasking... Speziell für den GNU-ARM C-Compiler kann ich es nicht sagen, weil ich diesen Compiler noch nicht angerührt habe.
Zuletzt geändert von thkais am 11 Sep 2012, 11:41, insgesamt 1-mal geändert.
Gruß
Thomas

Ad2
Beiträge: 306
Registriert: 31 Okt 2010, 22:20

Re: Fischertechnik Library/Gnu C-Arm-C-Compiler

Beitrag von Ad2 » 11 Sep 2012, 12:05

The compiler is more or less the same. NXT uses a kernel (lejos-osek) that does not yet exists for ft-tx. The tx has its own OS (apparently preemptive multitasking), if we would just get the API to access the kernel functions we would be in business. That we don't have the API is not a technical problem (unless you consider hacking it) but a commercial problem (please do ask ft why they don't give to us).

thkais
Beiträge: 384
Registriert: 31 Okt 2010, 21:45

Re: Fischertechnik Library/Gnu C-Arm-C-Compiler

Beitrag von thkais » 11 Sep 2012, 19:13

Moin,

nun, lieber Ford, dann möchte ich Deinen Geist erleuchten ;)
Wenn man genau hinsieht, sieht man - kaum einen Unterschied.... wobei ich zugeben muss, dass das Beispiel für kooperatives Multitasking bestens geeignet ist.
Die Display/Motor Funktionsaufrufe habe ich der besseren Vergleichbarkeit einfach übernommen.
Einzig eine vom OS bereitgestellte Funktion, die mir unabhängig Timer zählen kann, brauche ich. Mehr nicht.
Zeit zum Umschreiben: Keine 5 Minuten - ungetestet und keine Garantie auf Vollständigkeit, weil ich keinen GNU-ARM installiert habe.
So, und nun habe ich Wichtigeres zu tun.

@FTEchGirl19: Sollest du noch Fragen zur Realisierung von Algorithmen mit kooperativem Multitasking haben, helfe ich gerne.

Code: Alles auswählen



   volatile int MotorTimer;
   volatile int DisplayTimer;  

   void SysTick (void) 		// Systemtimer, wird per Interrupt im 1ms-Raster ausgeführt - so eine Funktion wird AFAIK vom OS bereitgestellt
   {
     if (DisplayTimer > 0)
     {
       DisplayTimer --;
     }
     if (MotorTimer > 0)
     {
       MotorTimer --;
     }
   }

   void DisplayValues(void)
   {
      if (DisplayTimer == 0)
      {
        TextOut(0,56, "Enc.A:", CLEOL); NumOut(42,56, MotorRotationCount(OUT_A));
        TextOut(0,48, "Enc.B:", CLEOL); NumOut(42,48, MotorRotationCount(OUT_B));
        TextOut(0,40, "Enc.C:", CLEOL); NumOut(42,40, MotorRotationCount(OUT_C));
	DisplayTimer = 10;
      }
    }


   void MotorControl(void) 
   {
      int speed;

      if (MotorTimer == 0)
      {
        speed=Random(201) - 100; // ergibt eine Zufallszahl für die Motorleistung  zwischen -100 und +100
        OnFwd(OUT_A,speed);

        speed=Random(201) - 100;
        OnFwd(OUT_B,speed);

        speed=Random(201) - 100;
        OnFwd(OUT_C,speed);
       
        MotorTimer = 200+ (Random(2800) ; // ergibt eine Zufallszahl für die Aktionsdauer von 200 - 3000 ms
      }
    }


   int main (void)
   {
      while(1)
      {
        DisplayValues();
        MotorControl();
      }

   }
Gruß
Thomas

thkais
Beiträge: 384
Registriert: 31 Okt 2010, 21:45

Re: Fischertechnik Library/Gnu C-Arm-C-Compiler

Beitrag von thkais » 12 Sep 2012, 19:33

Moin,
ich sehe - natürlich - alles anders ;)
Richtig ist: Kooperatives Multitasking verlangt einen Hauch mehr Planung und Hirnschmalz des Programmierers. Aber nicht allzuviel, man programmiert - wie im obigen Beispiel zu sehen - einfach anders. Alles eine Frage der Gewohnheiten / Erfahrungen.
Falsch ist allerdings, dass kooperatives Multitasking nicht echtzeitfähig wäre (Seit wann ist z.B. Windows - das präemptives Multitasking verwendet - echtzeitfähig?)
Man muss lediglich darauf achten, dass ein Task eine bestimmte Maximalzeit nicht überschreitet - oder dass bei einem zeitintensiven Task (z.B. irgendwelche komplizierten Berechnungen) immer wieder mal eine "Pause" eingelegt wird. Sogar bei rekursiven Berechnungsalgorithmen kann man über geeignete Maßnahmen (einem einfachen Funktionsaufruf....) sicherstellen, dass zeitkritische Dinge rechtzeitig erledigt werden. Komplexe Algorithmen lassen sich über eine State-Machine in Häppchen zerlegen.
Im Gegenteil sehe ich beim kooperativen Multitasking den Vorteil, dass Tasks, die gerade nichts zu tun haben, sich schnellstmöglich selbst beenden zugunsten von Tasks, die mehr Rechenzeit benötigen. Beim präemptiven Multitasking bekommt der Task seine Zeit zugeteilt - ob er nun wirklich etwas tut oder nur eine Warteschleife abarbeitet.
Wenn man es genauer betrachtet, ähnelt das der Interrupt-Programmierung. Interrupt-Routinen müssen ebenfalls kurz / schnell sein, um den normalen Programmablauf nicht unnötig zu stören. Ebenso müssen kooperative Tasks ausgeführt werden.
Ich möchte hier nicht einen Glaubenskrieg entfachen / weiterführen und keine Grundsatzdiskussion führen, aber aus täglicher Erfahrung weiß ich, was möglich ist - und was nicht. Und es gibt nichts, das ich nicht auch - mit vertretbarem Aufwand - mit kooperativem Multitasking lösen könnte. Sind wir mal ehrlich - wir planen hier keine Mondlandung, wir lassen Roboter über den Boden fahren - da ist die Komplexität endlich.
Den einzigen Nachteil, den ich gelten lassen möchte: Man muss sich um das Timing selber kümmern und eben wissen, was der Code tut.

Damit das nun nicht ganz OT wird verabschiede ich mich aus diesem Thread und überlasse Ford das letzte Wort ;)
Gruß
Thomas

vleeuwen
Beiträge: 1609
Registriert: 31 Okt 2010, 22:23
Wohnort: Enschede (NL)
Kontaktdaten:

Re: Fischertechnik Library/Gnu C-Arm-C-Compiler

Beitrag von vleeuwen » 12 Sep 2012, 23:29


Ad2
Beiträge: 306
Registriert: 31 Okt 2010, 22:20

Re: Fischertechnik Library/Gnu C-Arm-C-Compiler

Beitrag von Ad2 » 13 Sep 2012, 11:23

@Ford

Are you trying to solve a problem within the present constraints of the TX or are you just trying to make a point?

I know that when we had more documentation we could port the NXT software, but we haven't so we have to cope without. This makes our life more difficult than it could be but not impossible. Please ask ft for the documentation and if you get it I will help to port the NXT software to the TX. If not we will just have to work with what we've got.
BTW.: Preemptive multitasking introduces synchronisation issues that cannot occur in cooperative multitasking, so you gain some and you lose some. The solution of thkais is not a true multitasking solution in the sense that there is no stack/register switch. The RoboPro compiler (at least on the RoboInt) uses true cooperative multitasking. It is also real-time because the RoboPro compiler guarantees that in every loop there is a call to the yield() function (the actual task switch). So there is never busy waiting unless all tasks block, in which case the yield() function keeps cycling until a task becomes ready to continue. This is not that different from preemptive multitasking where the cpu is allocated to the next task when the current task gets blocked (same as cooperative), or at the end of a timeslice (preemption). When there are no tasks ready to run the cpu will be busy waiting or do something esoteric as counting idle time, until a tasks becomes ready.
But: True task switching is really difficult to implement because you have to be aware of register usage etc. So a solution a la thkais is much easier and fits the init-loop programming model of the TX programming package. If a 'task' cannot continue you preserve the state and move on to the next 'task'. At the next iteration, depending on the state, you check whether you can continue. It demands programming discipline and for each 'task' you need to explicitely maintain a state but it avoids implementing complete context switches.

Antworten