Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #218463 > unrolled thread

Quelloffenes Microcontroller-Oekosystem?

Back to article view | Back to de.sci.electronics

Contents

  Quelloffenes Microcontroller-Oekosystem? <usenet@teply.info> - 2016-12-13 23:35 +0100
    Re: Quelloffenes Microcontroller-Oekosystem? "MaWin" <me@private.net> - 2016-12-13 23:58 +0100
      Re: Quelloffenes Microcontroller-Oekosystem? <floh@aluminium.mobile.teply.info> - 2016-12-14 06:38 +0100
        Re: Quelloffenes Microcontroller-Oekosystem? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-12-14 14:47 +0100
          Re: Quelloffenes Microcontroller-Oekosystem? "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2016-12-14 14:15 +0000
            Re: Quelloffenes Microcontroller-Oekosystem? Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> - 2016-12-14 15:30 +0000
              Re: Quelloffenes Microcontroller-Oekosystem? "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2016-12-14 16:10 +0000
                Re: Quelloffenes Microcontroller-Oekosystem? Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> - 2016-12-14 16:26 +0000
    Re: Quelloffenes Microcontroller-Oekosystem? Gerald Oppen <Gerald.Oppen@web.de> - 2016-12-14 00:05 +0100
      Re: Quelloffenes Microcontroller-Oekosystem? <usenet@teply.info> - 2016-12-14 06:48 +0100
        Re: Quelloffenes Microcontroller-Oekosystem? Volker Bartheld <news2016@bartheld.net> - 2016-12-14 13:27 +0100
          Re: Quelloffenes Microcontroller-Oekosystem? Edzard Egberts <news@edzeg.net> - 2016-12-14 13:53 +0100
            Re: Quelloffenes Microcontroller-Oekosystem? Florian Teply <usenet@teply.info> - 2016-12-14 21:14 +0100
              Re: Quelloffenes Microcontroller-Oekosystem? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-12-15 09:37 +0100
    Re: Quelloffenes Microcontroller-Oekosystem? Axel Schwenke <axel.schwenke@gmx.de> - 2016-12-14 01:11 +0100
      Re: Quelloffenes Microcontroller-Oekosystem? Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> - 2016-12-14 10:11 +0000
      Re: Quelloffenes Microcontroller-Oekosystem? Rafael Deliano <rafael_deliano@arcor.de> - 2016-12-14 18:16 +0100
        Re: Quelloffenes Microcontroller-Oekosystem? Michael Schwingen <news-1457978346@discworld.dascon.de> - 2016-12-14 22:31 +0000
    Re: Quelloffenes Microcontroller-Oekosystem? Edzard Egberts <news@edzeg.net> - 2016-12-14 13:19 +0100
      Re: Quelloffenes Microcontroller-Oekosystem? Matthias Weingart <mwnews@pentax.boerde.de> - 2016-12-16 08:07 +0000
        Re: Quelloffenes Microcontroller-Oekosystem? Edzard Egberts <news@edzeg.net> - 2016-12-16 09:29 +0100
          Re: Quelloffenes Microcontroller-Oekosystem? Matthias Weingart <mwnews@pentax.boerde.de> - 2016-12-16 09:27 +0000
            Re: Quelloffenes Microcontroller-Oekosystem? Matthias Weingart <mwnews@pentax.boerde.de> - 2016-12-16 09:34 +0000
              Re: Quelloffenes Microcontroller-Oekosystem? Edzard Egberts <news@edzeg.net> - 2016-12-16 11:06 +0100
            Re: Quelloffenes Microcontroller-Oekosystem? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-12-18 15:38 +0100
        Re: Quelloffenes Microcontroller-Oekosystem? Lutz Schulze <lschulze@netzwerkseite.de> - 2016-12-16 12:03 +0100
          Re: Quelloffenes Microcontroller-Oekosystem? Michael Bäuerle <michael.baeuerle@stz-e.de> - 2016-12-16 12:25 +0100
            Re: Quelloffenes Microcontroller-Oekosystem? Olaf Kaluza <olaf@criseis.ruhr.de> - 2016-12-16 13:54 +0100
              Re: Quelloffenes Microcontroller-Oekosystem? Michael Bäuerle <michael.baeuerle@stz-e.de> - 2016-12-16 15:27 +0100
                Re: Quelloffenes Microcontroller-Oekosystem? Olaf Kaluza <olaf@criseis.ruhr.de> - 2016-12-16 19:05 +0100
                  Re: Quelloffenes Microcontroller-Oekosystem? Michael Bäuerle <michael.baeuerle@stz-e.de> - 2016-12-19 10:12 +0100
                    Re: Quelloffenes Microcontroller-Oekosystem? Olaf Kaluza <olaf@criseis.ruhr.de> - 2016-12-19 12:18 +0100
                      Re: Quelloffenes Microcontroller-Oekosystem? Chris Jones <lugnut808@spam.yahoo.com> - 2016-12-19 23:27 +1100
                        Re: Quelloffenes Microcontroller-Oekosystem? Michael Bäuerle <michael.baeuerle@stz-e.de> - 2016-12-19 14:31 +0100
                      Re: Quelloffenes Microcontroller-Oekosystem? "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2016-12-19 12:38 +0000
                      Re: Quelloffenes Microcontroller-Oekosystem? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2016-12-23 21:47 +0100
                    Re: Quelloffenes Microcontroller-Oekosystem? Michael Schwingen <news-1457978346@discworld.dascon.de> - 2016-12-19 19:34 +0000
                    Re: Quelloffenes Microcontroller-Oekosystem? Florian Teply <usenet@teply.info> - 2016-12-19 20:14 +0100
              Re: Quelloffenes Microcontroller-Oekosystem? Marte Schwarz <marte.schwarz@gmx.de> - 2016-12-16 17:22 +0100
                Re: Quelloffenes Microcontroller-Oekosystem? Werner Holtfreter <Holtfreter@gmx.de> - 2016-12-16 18:15 +0100
              Re: Quelloffenes Microcontroller-Oekosystem? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-12-18 15:58 +0100
        Re: Quelloffenes Microcontroller-Oekosystem? Volker Bartheld <news2016@bartheld.net> - 2016-12-16 13:16 +0100
          Re: Quelloffenes Microcontroller-Oekosystem? Olaf Kaluza <olaf@criseis.ruhr.de> - 2016-12-16 14:14 +0100
            Re: Quelloffenes Microcontroller-Oekosystem? Volker Bartheld <news2016@bartheld.net> - 2016-12-16 15:31 +0100
              Re: Quelloffenes Microcontroller-Oekosystem? Olaf Kaluza <olaf@criseis.ruhr.de> - 2016-12-16 19:22 +0100
                Re: Quelloffenes Microcontroller-Oekosystem? Volker Bartheld <news2016@bartheld.net> - 2016-12-16 19:56 +0100
                  Re: Quelloffenes Microcontroller-Oekosystem? <floh@aluminium.mobile.teply.info> - 2016-12-17 15:17 +0100
                    Re: Quelloffenes Microcontroller-Oekosystem? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-12-18 16:11 +0100
                      Re: Quelloffenes Microcontroller-Oekosystem? Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> - 2016-12-18 15:25 +0000
                      Re: Quelloffenes Microcontroller-Oekosystem? Michael Schwingen <news-1457978346@discworld.dascon.de> - 2016-12-18 16:10 +0000
                        Re: Quelloffenes Microcontroller-Oekosystem? Olaf Kaluza <olaf@criseis.ruhr.de> - 2016-12-18 18:56 +0100
                          Re: Quelloffenes Microcontroller-Oekosystem? Michael Schwingen <news-1457978346@discworld.dascon.de> - 2016-12-18 20:13 +0000
                            Re: Quelloffenes Microcontroller-Oekosystem? Olaf Kaluza <olaf@criseis.ruhr.de> - 2016-12-18 22:06 +0100
                              Re: Quelloffenes Microcontroller-Oekosystem? Michael Schwingen <news-1457978346@discworld.dascon.de> - 2016-12-19 09:23 +0000
                                Re: Quelloffenes Microcontroller-Oekosystem? Olaf Kaluza <olaf@criseis.ruhr.de> - 2016-12-19 12:22 +0100
                          Re: Quelloffenes Microcontroller-Oekosystem? Matthias Weingart <mwnews@pentax.boerde.de> - 2016-12-19 10:32 +0000
                      Re: Quelloffenes Microcontroller-Oekosystem? Florian Teply <usenet@teply.info> - 2016-12-18 21:23 +0100
                        Re: Quelloffenes Microcontroller-Oekosystem? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2016-12-19 21:08 +0100
                Re: Quelloffenes Microcontroller-Oekosystem? "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2016-12-19 08:50 +0000
                  Re: Quelloffenes Microcontroller-Oekosystem? Axel Berger <Axel_Berger@B.Maus.De> - 2016-12-19 09:56 +0100
                    Re: Quelloffenes Microcontroller-Oekosystem? "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2016-12-19 11:14 +0000
        Re: Quelloffenes Microcontroller-Oekosystem? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-12-18 14:47 +0100
          Re: Quelloffenes Microcontroller-Oekosystem? Volker Bartheld <news2016@bartheld.net> - 2016-12-18 19:40 +0100
            Re: Quelloffenes Microcontroller-Oekosystem? Christian Zietz <newsgroup.1001@chz.xyz> - 2016-12-18 20:00 +0100
              Re: Quelloffenes Microcontroller-Oekosystem? Volker Bartheld <news2016@bartheld.net> - 2016-12-19 12:00 +0100
            Re: Quelloffenes Microcontroller-Oekosystem? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-12-19 12:06 +0100
          Re: Quelloffenes Microcontroller-Oekosystem? "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2016-12-19 08:59 +0000
            Re: Quelloffenes Microcontroller-Oekosystem? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-12-19 12:15 +0100
          Re: Quelloffenes Microcontroller-Oekosystem? Matthias Weingart <mwnews@pentax.boerde.de> - 2016-12-19 09:04 +0000
            Re: Quelloffenes Microcontroller-Oekosystem? Michael Schwingen <news-1457978346@discworld.dascon.de> - 2016-12-19 09:36 +0000
        Re: Quelloffenes Microcontroller-Oekosystem? Marcel Mueller <news.5.maazl@spamgourmet.org> - 2016-12-19 23:25 +0100
          Re: Quelloffenes Microcontroller-Oekosystem? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2016-12-26 22:51 +0100
    Re: Quelloffenes Microcontroller-Oekosystem? Marc Santhoff <m.santhoff@t-online.de> - 2016-12-14 18:38 +0100
      Re: Quelloffenes Microcontroller-Oekosystem? Dieter Wiedmann <dieter.wiedmann@t-online.de> - 2016-12-14 19:03 +0100
        Re: Quelloffenes Microcontroller-Oekosystem? Rafael Deliano <rafael_deliano@arcor.de> - 2016-12-14 19:52 +0100
          Re: Quelloffenes Microcontroller-Oekosystem? Dieter Wiedmann <dieter.wiedmann@t-online.de> - 2016-12-14 20:08 +0100
      Re: Quelloffenes Microcontroller-Oekosystem? Olaf Kaluza <olaf@criseis.ruhr.de> - 2016-12-14 20:06 +0100
        Re: Quelloffenes Microcontroller-Oekosystem? Marc Santhoff <m.santhoff@t-online.de> - 2016-12-14 23:03 +0100
          Re: Quelloffenes Microcontroller-Oekosystem? Olaf Kaluza <olaf@criseis.ruhr.de> - 2016-12-15 07:34 +0100
            Re: Quelloffenes Microcontroller-Oekosystem? <floh@aluminium.mobile.teply.info> - 2016-12-15 23:09 +0100
              Re: Quelloffenes Microcontroller-Oekosystem? Olaf Kaluza <olaf@criseis.ruhr.de> - 2016-12-16 09:07 +0100
        Re: Quelloffenes Microcontroller-Oekosystem? "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2016-12-15 09:25 +0000
      Re: Quelloffenes Microcontroller-Oekosystem? Florian Teply <usenet@teply.info> - 2016-12-14 23:12 +0100
        Re: Quelloffenes Microcontroller-Oekosystem? Lutz Schulze <lschulze@netzwerkseite.de> - 2016-12-15 07:12 +0100
          Re: Quelloffenes Microcontroller-Oekosystem? "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2016-12-15 09:40 +0000
            Re: Quelloffenes Microcontroller-Oekosystem? Edzard Egberts <news@edzeg.net> - 2016-12-15 11:13 +0100
              Re: Quelloffenes Microcontroller-Oekosystem? "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2016-12-15 12:21 +0000
        Re: Quelloffenes Microcontroller-Oekosystem? Marc Santhoff <m.santhoff@t-online.de> - 2016-12-15 14:54 +0100
          Re: Quelloffenes Microcontroller-Oekosystem? Florian Teply <usenet@teply.info> - 2016-12-15 22:08 +0100
        Re: Quelloffenes Microcontroller-Oekosystem? Michael Schwingen <news-1457978346@discworld.dascon.de> - 2016-12-15 23:07 +0000
          Re: Quelloffenes Microcontroller-Oekosystem? Florian Teply <usenet@teply.info> - 2016-12-16 15:01 +0100
            Re: Quelloffenes Microcontroller-Oekosystem? Michael Schwingen <news-1457978346@discworld.dascon.de> - 2016-12-16 20:27 +0000
    Re: Quelloffenes Microcontroller-Oekosystem? Matthias Weingart <mwnews@pentax.boerde.de> - 2016-12-16 07:47 +0000
      Re: Quelloffenes Microcontroller-Oekosystem? Florian Teply <usenet@teply.info> - 2016-12-16 15:49 +0100

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#218734

Axel Berger <Axel_Berger@b.maus.de> wrote:
>Peter Heitzer wrote:
>> Der Atari ST hatte 192 MiB ROM ...

>Kilo
Mea culpa.
Natürlich waren es KiB. Man ist solch "kleine" Speichergrössen mittlerweile nicht 
mehr gewohnt. Obwohl ich am WE für mein DSO einen 64 MB (wirklich Mega und
keine Giga) Speicherstick eingesetzt habe. Das war noch ein Stick mit
Schreibschutzschalter.

-- 
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de

[toc] | [prev] | [next] | [standalone]

#218660

Matthias Weingart schrieb:

> Dabei 
> ist das LED-Blinken ganz einfach: in der ohnehin vorhandenen Interruptroutine 
> des Systemtimers einfach ne Variable mitzählen lassen und wenn das 
> Blinkintervall voll ist, die LED toggeln. Der Controller ist weiterhin frei, 
> um andere Aufgaben zu übernehmen und das da ne LED noch irgendwo im 
> Hintergrund blinkt, kann völlig ausgeblendet werden.

Wobei die Abfrage im ISR den Ablauf immer verlangsamt, während eine 
Abfrage in loop() nur die überhaupt noch freie Zeit verringert. Man kann 
also durch Überlasten der ISR den ganzen Prozessor blockieren, beim 
Pollen in loop() hingegen geht nichts verloren, es wird höchstens etwas 
langsamer. Das ist gerade das Blinken einer LED oder auch das Entprellen 
eines Schalters ein ganz schlechtes Beispiel für die Verwendung von 
Interrupts.

DoDi

[toc] | [prev] | [next] | [standalone]

#218677

> Matthias Weingart schrieb:
>> Dabei ist das LED-Blinken ganz einfach: in der ohnehin vorhandenen
>> Interruptroutine des Systemtimers einfach ne Variable mitzählen lassen
>> und wenn das Blinkintervall voll ist, die LED toggeln.

On Sun, 18 Dec 2016 14:47:04 +0100, Hans-Peter Diettrich wrote:
> Wobei die Abfrage im ISR den Ablauf immer verlangsamt, während eine 
> Abfrage in loop() nur die überhaupt noch freie Zeit verringert.

Hmmmm. Die paar Taktzyklen für genau diesen Task (einen Port invertieren)?
Hielte ich für ein eher akademisches Problem.

> Man kann also durch Überlasten der ISR den ganzen Prozessor blockieren,

Natürlich, wenn man nicht verstanden hat, wofür so ein Interrupt eigentlich
gut ist.

Ich habe mir Leonardo Millanis leOS2
(http://www.leonardomiliani.com/en/?wpfb_dl=38)
zur Brust genommen und ein bißchen objektorientiert aufgehübscht
(vollständiger Quellcode auf Wunsch), da hat es dann die typischen
Funktionen

    enum taskStates_t { PAUSED=0b00000000, SCHEDULED=0b00000001, ONETIME=0b00000010, IS_ACTIVE_MASK=0b00000011, SCHEDULED_IMMEDIATESTART=0b00000101, IMMEDIATESTART=SCHEDULED_IMMEDIATESTART, IS_IMMEDIATE_MASK=0b00000100, INVALID=0b11111111 };
    typedef void (*CALLBACK)(void*);
    static void init(uint8_t granularity=WDTO_15MS, uint16_t resetTimeout = 0); // WDTO_15MS, WDTO_30MS, WDTO_60MS, WDTO_120MS, WDTO_250MS, WDTO_500MS, WDTO_1S, WDTO_2S
    static void exit();
    static bool addTask(CALLBACK, unsigned long taskInterval, uint8_t taskStatus=SCHEDULED, void* taskData=NULL);
    static bool removeTask(CALLBACK);
    static bool pauseTask(CALLBACK);
    static bool restartTask(CALLBACK);
    static uint8_t getTaskStatus(CALLBACK);
    static uint32_t convertMs(uint32_t);
    static void haltScheduler(void);
    static void restartScheduler(void);
    static void reset(void);

, der Scheduler sieht erwartungsgemäß so aus:

void leOS2::isr() {
  _ticksCounter++; // increment the ticks counter
  
    //check if the next timeout of the WDT an interrupt should be
    //called or a reset should be executed
    if (_wdtResetTimeout) {
        _WD_CONTROL_REG |= (1<<WDIE); // another interrupt, please...
        if (_taskIsRunning) { // check if a task is already running
            _maxTimeouts--;
            if (0==_maxTimeouts) _WD_CONTROL_REG &= ~(1<<WDIE); // max number of timeouts reached: clear WDIE bit but leave WDE set, so next time a chip reset is issued
            return;
        }
    }
    
  // THIS IS THE SCHEDULER!  
  for(uint8_t i=0; i<MAX_TASKS; ++i)
  {
    if(!tasks[i].taskPointer || PAUSED==tasks[i].taskStatus) continue; // slot is either empty or task paused
    
    //check if it's time to execute the task
    #ifdef SIXTYFOUR_MATH
    if (_ticksCounter > tasks[i].ETA) {
    #else
    if ((long)(_ticksCounter - tasks[i].ETA) >=0) { // this trick overruns the overflow of _ticksCounter
    #endif
      // prepare the counters to monitor if a task will freeze
      _maxTimeouts = _wdtResetTimeout;
      _taskIsRunning = true;
      tasks[i].taskPointer(tasks[i].taskData); // call the task
      _taskIsRunning = false; // reset the counters
      
      if (tasks[i].taskStatus == ONETIME) removeTask(tasks[i].taskPointer); // if it's a one-time task, then it has to be removed after running
      else tasks[i].ETA = _ticksCounter + tasks[i].userTasksInterval; // let's schedule next start
    }
  }
}

und der LED-Blinker ist ein Heimspiel:

#include "leOS2.h" //include the scheduler
leOS2 myOS; //create a new istance
const byte LED13 = 13;
byte LEDstatus = 0;

void setup() {
    myOS.init(WDTO_250MS);
    pinMode(LED13, OUTPUT);
    myOS.addTask(flashLed, myOS.convertMs(500));
}

void loop()
{
  for(int i=0; i<1000; ++i)
  {
    delay(10);
  }
  myOS.exit();
}

void flashLed(void*) {
    LEDstatus ^= 1;
    digitalWrite(LED13, LEDstatus);
}

Dabei trägt das eine XOR und der digitalWrite() wahrlich nicht besonders
auf, man muß halt genug Flash für die Klasse leOS2 übrig haben.

Meine Photoduino-Implementation (s. auch http://photoduino.com, das Projekt
ist mittlererweile leider genauso tot wie http://www.cameraaxe.com) bekam
irgendwann einen DIY-Screensaver, nachdem mir klar wurde, daß das
hintergrundbeleuchtete Display den größten Teil des Stromverbrauchs
ausmachte. Und nachdem ich den WDT nicht benötigte, bot sich genau dieser
Trick an:

void watchdog(bool enable)
{
  MCUSR = 0;            // ensure that the reset vectors are off
  wdt_disable();        // disable WD 
  SREG &= ~(1<<SREG_I); // disable all the interrupts    

  // Possible timeout values are: 15ms, 30ms, 60ms, 120ms, 250ms, 500ms, 1s, 2s (some devices also allow for 4s and 8s)
  // Symbolic constants are formed by the prefix
  // WDTO_, followed by the time: WDTO_15MS, WDTO_30MS, WDTO_60MS, WDTO_120MS, WDTO_250MS, WDTO_500MS, WDTO_1S, WDTO_2S, WDTO_4S, WDTO_8S
  byte wdcr=WDTO_1S;
  if(enable) wdcr |= _BV(WDIE);

  // Manual: "[...] To further ensure program security, alterations to the Watchdog set-up must follow timed sequences.
  // The sequence for clearing WDE and changing time-out configuration is as follows:
  // 1. In the same operation, write a logic one to the Watchdog change enable bit (WDCE) and WDE.
  //    A logic one must be written to WDE regardless of the previous value of the WDE bit.
  // 2. Within the next four clock cycles, write the WDE and Watchdog prescaler bits (WDP) as desired, but with the WDCE bit cleared.
  //    This must be done in one operation. [...]"
  _WD_CONTROL_REG = _BV(_WD_CHANGE_BIT) | _BV(WDE); // step 1
  _WD_CONTROL_REG = wdcr;                           // step 2

  SREG |= (1<<SREG_I); // re-enable interrupts
}

// ISR (Interrupt Service Routine) called by the timer's overflow:
// interrupt-driven routine to run the tasks - this ISR is not atomic
// so other ISRs can interrupt it
ISR(WDT_vect, ISR_NOBLOCK)
{
  ++ticksCounter; // increment the ticks counter
  
  if(!system_energySaving) return; // no energy saving (=automatic dimming of backlight)
  if(ticksCounter==system_energySaving) backlight_off(); // it's time to switch off the backlight
}

Der Kram ist einigermaßen selbsterklärend, vielleicht hilft er ja jemandem.
Ja, nein, sicher kann man das anders und/oder besser machen. Und auf den
Mond fliegen würde ich mit meinem Programm auch nicht.

Ciao,
Volker

-- 
@:  W E B 2 0 1 6 at B A R T H E L D dot N E T
3W: www.bartheld.net

[toc] | [prev] | [next] | [standalone]

#218683

Volker Bartheld schrieb:

> Ich habe mir Leonardo Millanis leOS2
> (http://www.leonardomiliani.com/en/?wpfb_dl=38)
> zur Brust genommen und ein bißchen objektorientiert aufgehübscht
> [...]
> Der Kram ist einigermaßen selbsterklärend, vielleicht hilft er ja jemandem.

Nett! Das sieht in der Tat sehr aufgeräumt aus. Wieviel Flash benötigt
denn das ganze so in etwa?

> Ja, nein, sicher kann man das anders und/oder besser machen. Und auf den
> Mond fliegen würde ich mit meinem Programm auch nicht.

Ach komm, die hatten doch auch Probleme mit dem Task-Scheduling:
<https://en.wikipedia.org/wiki/Apollo_11#Lunar_descent> ;-)

Christian
-- 
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

[toc] | [prev] | [next] | [standalone]

#218732

On Sun, 18 Dec 2016 20:00:17 +0100, Christian Zietz wrote:
> Volker Bartheld schrieb:
>> Ich habe mir Leonardo Millanis leOS2
>> (http://www.leonardomiliani.com/en/?wpfb_dl=38)
>> zur Brust genommen und ein bißchen objektorientiert aufgehübscht
> Nett! Das sieht in der Tat sehr aufgeräumt aus. Wieviel Flash benötigt
> denn das ganze so in etwa?

Leo schrieb, der zusätzliche Overhead für den objektorientierten Ansatz
wären etwa +10% im Vergleich zu seiner Fassung. Mehr Info habe ich leider
nicht parat, weil mir hier die Entwicklungsumgebung fehlt.

Ciao,
Volker

-- 
@:  W E B 2 0 1 6 at B A R T H E L D dot N E T
3W: www.bartheld.net

[toc] | [prev] | [next] | [standalone]

#218736

Volker Bartheld schrieb:
>> Matthias Weingart schrieb:
>>> Dabei ist das LED-Blinken ganz einfach: in der ohnehin vorhandenen
>>> Interruptroutine des Systemtimers einfach ne Variable mitzählen lassen
>>> und wenn das Blinkintervall voll ist, die LED toggeln.
> 
> On Sun, 18 Dec 2016 14:47:04 +0100, Hans-Peter Diettrich wrote:
>> Wobei die Abfrage im ISR den Ablauf immer verlangsamt, während eine 
>> Abfrage in loop() nur die überhaupt noch freie Zeit verringert.
> 
> Hmmmm. Die paar Taktzyklen für genau diesen Task (einen Port invertieren)?
> Hielte ich für ein eher akademisches Problem.

Eher ein didaktisches. Wieviele Fragen kamen dann von Anfängern, die ihr 
halbes Programm in ein ISR gepackt hatten :-(

DoDi

[toc] | [prev] | [next] | [standalone]

#218718

Hans-Peter Diettrich <DrDiettrich1@aol.com> wrote:
>Matthias Weingart schrieb:

>> Dabei 
>> ist das LED-Blinken ganz einfach: in der ohnehin vorhandenen Interruptroutine 
>> des Systemtimers einfach ne Variable mitzählen lassen und wenn das 
>> Blinkintervall voll ist, die LED toggeln. Der Controller ist weiterhin frei, 
>> um andere Aufgaben zu übernehmen und das da ne LED noch irgendwo im 
>> Hintergrund blinkt, kann völlig ausgeblendet werden.

>Wobei die Abfrage im ISR den Ablauf immer verlangsamt, während eine 
>Abfrage in loop() nur die überhaupt noch freie Zeit verringert. Man kann 
>also durch Überlasten der ISR den ganzen Prozessor blockieren, beim 
>Pollen in loop() hingegen geht nichts verloren, es wird höchstens etwas 
>langsamer. Das ist gerade das Blinken einer LED oder auch das Entprellen 
>eines Schalters ein ganz schlechtes Beispiel für die Verwendung von 
>Interrupts.
Bei manchen µC geht es auch ganz ohne ISR. Da programmiert man für den Timer
einfach Capture o.Ä. Register und wenn der Timer den Wert X erreicht, dann
toggled ein Portpin.

-- 
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de

[toc] | [prev] | [next] | [standalone]

#218737

Peter Heitzer schrieb:

> Bei manchen µC geht es auch ganz ohne ISR. Da programmiert man für den Timer
> einfach Capture o.Ä. Register und wenn der Timer den Wert X erreicht, dann
> toggled ein Portpin.

Das ist für mich einer der Unterschiede zwischen Mikro-Controller und 
-Computer. Ein Controller interagiert stärker mit der Außenwelt, über 
I/O Pins, während ein Computer mehr auf Rechenleistung (OS...) auf einem 
Chip ausgelegt ist.

Entsprechend sollte man sich vorher überlegen, ob man sich mit einem µC 
für Steuerungsaufgaben oder für Datenverarbeitung beschäftigen möchte, 
und danach einen passenden Controller und Entwicklungssystem für die 
nächsten Schritte auswählen.

DoDi

[toc] | [prev] | [next] | [standalone]

#218719

Hans-Peter Diettrich <DrDiettrich1@aol.com>:

> Matthias Weingart schrieb:
> 
>> Dabei 
>> ist das LED-Blinken ganz einfach: in der ohnehin vorhandenen
>> Interruptroutine des Systemtimers einfach ne Variable mitzählen lassen
>> und wenn das Blinkintervall voll ist, die LED toggeln. Der Controller
>> ist weiterhin frei, um andere Aufgaben zu übernehmen und das da ne LED
>> noch irgendwo im Hintergrund blinkt, kann völlig ausgeblendet werden.
> 
> Wobei die Abfrage im ISR den Ablauf immer verlangsamt, während eine 
> Abfrage in loop() nur die überhaupt noch freie Zeit verringert. Man kann
> also durch Überlasten der ISR den ganzen Prozessor blockieren, beim 
> Pollen in loop() hingegen geht nichts verloren, es wird höchstens etwas 
> langsamer. Das ist gerade das Blinken einer LED oder auch das Entprellen
> eines Schalters ein ganz schlechtes Beispiel für die Verwendung von 
> Interrupts.

Bin ich anderer Meinung. Wenn nur einzelne Bits zu toggeln sind (und das ist 
bei dem LED Beispiel nur ein Befehl, der Countdown und die Verzweigung dann 
noch zwei weitere), dann ist sowas sehr viel effizienter in einer ISR!
Problem ist bei Arduino aber die Kapselung (gute Idee zur Vereinfachung, 
schlechte Idee für die Code-Effizienz), z.B.:
digitalWrite(LED13, LEDstatus);
Bin jetzt kein Arduino-Experte (hab Arduino bei mir nicht installiert), aber 
das ist ja wohl ein Funktionsaufruf, Funktionsaufrufe aus ISR's sollte man 
bei den kleinen Controllern auf jeden Fall unterlassen. Besser wäre da ein 
Makro; und ein entsprechendes Makro digitalToggle(LED13) in die ISR 
eingebaut, wäre dann wirklich nur ein einziger Assemblerbefehl. Leider gibt C 
es nicht her, solche Makros, schön als auch effizient zu realisieren - wenn 
die Bits über mehrere Ports verteilt sind und man da nur einen einzigen 
"Befehl" haben möchte (z.B. LED0-7 sind auf Port A und LED8-15 auf Port B, 
dann kann man kein "#define digitalToggle(LED13)" programmieren, dass dann 
bei LED0-7 den Port A addressiert und bei den anderen den Port B), ohne das 
man da Code (if, also eine zusätzliche Verzweigung zur runtime) dazuschreiben 
muss. Aber das ist kein Arduinoproblem - sondern ein reines C-Problem....

M.
-- 

[toc] | [prev] | [next] | [standalone]

#218723

On 2016-12-19, Matthias Weingart <mwnews@pentax.boerde.de> wrote:
> "Befehl" haben möchte (z.B. LED0-7 sind auf Port A und LED8-15 auf Port B, 
> dann kann man kein "#define digitalToggle(LED13)" programmieren, dass dann 
> bei LED0-7 den Port A addressiert und bei den anderen den Port B), ohne das 
> man da Code (if, also eine zusätzliche Verzweigung zur runtime) dazuschreiben 
> muss. Aber das ist kein Arduinoproblem - sondern ein reines C-Problem....

Das geht durchaus: eine inline-Funktion wird, wenn sie mit konstanten
Argumenten aufgerufen wird, komplett wegoptimiert, so daß nur noch der eine
Portbefehl übrigbleibt - so gesehen auf Cortex-M3 mit eingeschalteter link
time optimization. Da fliegen die ganzen type checks, asserts etc. aus dem
ST-HAL dann 'raus (obwohl die checks zur compilezeit stattfinden!), und der
Portzugriff direkt aufs Register ist kein Stück schneller/kürzer.

Auf AVR habe ich das noch nicht hinbekommen - eigentlich sollte das mit den
aktuellsten Tools gehen.

Ohne LTO hast Du aber Recht. Wobei: evtl. bekommt man das mit Makros hin, so
dass die Ausdrücke zur Compilezeit schon als Konstante aufgelöst werden.

cu
Michael

[toc] | [prev] | [next] | [standalone]

#218791

On 16.12.16 09.07, Matthias Weingart wrote:
> Vorteil von Arduino ist sicherlich, dass es für einen Einsteiger recht gut
> geeignet ist, überhaupt erst mal einen uC kennezulernen. Ansonsten schränkt
> es sehr stark ein. Der Einsteiger lernt überhaupt nicht, wie leistungsfähig
> so ein Microcontroller eigentlich sein kann. Darum lehne ich für Einsteiger
> Arduino ab.
> Schönes Beispiel ist das Blinkenlassen einer LED. In der Hauptloop: Led an -
> sleep - led aus - sleep - loop. Schön. Damit ist der dann vollbeschäftigt.
[...]
> Vermutlich führt genau Arduino dann dazu, dass ein Einsteiger dann auf einen
> leistungsstarken Prozessor umsteigt, weil der Arduino-Cpntroller das ja nicht
> kann.

Was soll das bringen, wenn man nicht programmieren kann? Der wartet dann 
schneller in einer Schleife, oder was?

> Eigentlich müsste er nur die Entwicklungsumgebung wechseln....

Programmieren lernen eher.


Marcel

[toc] | [prev] | [next] | [standalone]

#219131

Marcel Mueller schrieb:
>
> Programmieren lernen eher.

Neiiiin. Ich wollte doch bloss eine LED blinken lassen.

(Irgendwie könnte man neuzeitliche Loriot-Sketches erfinden)

-- 
mfg Rolf Bombach

[toc] | [prev] | [next] | [standalone]

#218525

<usenet@teply.info> schrieb:

> Ich bin also auf der Suche nach a) einem Software-Toolset, das auch

gcc + Eclipse (o.ä., je nach Neigung) oder vi, ed und Makefiles.
Sourcecode ist Text.

> unter Linux auf nicht-x86 einsetzbar ist, und b) nach nem guenstigen
> Entwicklungssystem auf der Hardware-Seite. Was wuerdet Ihr empfehlen?

Irgendwas, das von gcc unterstützt wird, dir gefällt und die sonstigen
Anforderungen erfüllt.

Z.B.:

Cortex-Mx sind recht komplex für den Einstieg, aber verbreitet, von
ganz klein bis ziemlich fett zu bekommen.

Frühere ARM, ARM7(TDMI), ARM9(26) sind etwas überschaubarer, Abkündigung
ist aber zu befürchten (oder schon passiert?).

Atmel AVR sind handlich, verbreitet aber etwas "altmodisch", aussterben
werden die IMHO so schnell nicht, aber recht begrenzt in Sachen RAM
und Skalierbarkeit nach oben.

PIC hat teils hübsche Eingeschaften, ist aber irgendwie ein Überbleibsel
aus Zeiten kurz nach 6502, aber noch beliebt.

Alles sehr subjektiv natürlich...

Guck doch mal bei den üblichen Verdächtigen rum, welche Architekturen
in Sachen Verfügbarkeit zu Deiner Basteltätigkeit passen, dann finden
sich schon Kandidaten für die engere Auswahl.

HTH,
Marc

[toc] | [prev] | [next] | [standalone]

#218526

Am 14.12.2016 um 18:38 schrieb Marc Santhoff:

> PIC hat teils hübsche Eingeschaften, ist aber irgendwie ein Überbleibsel
> aus Zeiten kurz nach 6502, aber noch beliebt.

Die ursprünglichen PICs sind älter als der 6502.


Gruß Dieter

[toc] | [prev] | [next] | [standalone]

#218529

Am 14.12.2016 19:03, schrieb Dieter Wiedmann:
> Am 14.12.2016 um 18:38 schrieb Marc Santhoff:
>
>> PIC hat teils hübsche Eingeschaften, ist aber irgendwie ein Überbleibsel
>> aus Zeiten kurz nach 6502, aber noch beliebt.
>
> Die ursprünglichen PICs sind älter als der 6502.
>

Die haben den 6502 in 1975 einsortiert:

http://www.antiquetech.com/?page_id=28

1975 gabs von GI von den LP8000 in PMOS.
Einen 16 Bit CP1600 1976.
http://www.cpushack.com/2014/10/30/sgs-ates-m380-and-gi-lp8000-8-bits-for-europe/

Typisch findet man 1977 für den 1650:

http://www.antiquetech.com/?page_id=31

MfG JRD

[toc] | [prev] | [next] | [standalone]

#218530

Am 14.12.2016 um 19:52 schrieb Rafael Deliano:
> Am 14.12.2016 19:03, schrieb Dieter Wiedmann:
>> Am 14.12.2016 um 18:38 schrieb Marc Santhoff:
>>
>>> PIC hat teils hübsche Eingeschaften, ist aber irgendwie ein Überbleibsel
>>> aus Zeiten kurz nach 6502, aber noch beliebt.
>>
>> Die ursprünglichen PICs sind älter als der 6502.
>>
>
> Die haben den 6502 in 1975 einsortiert:
>
> http://www.antiquetech.com/?page_id=28
>
> 1975 gabs von GI von den LP8000 in PMOS.
> Einen 16 Bit CP1600 1976.
> http://www.cpushack.com/2014/10/30/sgs-ates-m380-and-gi-lp8000-8-bits-for-europe/
>
>
> Typisch findet man 1977 für den 1650:
>
> http://www.antiquetech.com/?page_id=31

Tatsache. 40 Jahre sind aber auch eine lange Zeit...



Gruß Dieter

[toc] | [prev] | [next] | [standalone]

#218531

Marc Santhoff <m.santhoff@t-online.de> wrote:


 >Irgendwas, das von gcc unterstützt wird, dir gefällt und die sonstigen
 >Anforderungen erfüllt.

Das reicht ihm aber nicht. Natuerlich kann man auf jeder beliebigen
Linuxhardware einen gcc uebersetzen und damit fuer so gut wie alles
entwickeln. Aber er muss seinen Code ja noch mindestens auf den
Microcontroller bringen, besser noch einen funktionierenden Debugger
haben. 
Reinflashen sollte mit jedem Controller gehen der einen Bootloader
fuer RS232 unterstuetzt. (das machen viele) 


Olaf

[toc] | [prev] | [next] | [standalone]

#218540

Olaf Kaluza <olaf@criseis.ruhr.de> schrieb:

> Marc Santhoff <m.santhoff@t-online.de> wrote:
> 
> 
>  >Irgendwas, das von gcc unterstützt wird, dir gefällt und die
>  >sonstigen Anforderungen erfüllt.
> 
> Das reicht ihm aber nicht. Natuerlich kann man auf jeder beliebigen
> Linuxhardware einen gcc uebersetzen und damit fuer so gut wie alles
> entwickeln. Aber er muss seinen Code ja noch mindestens auf den
> Microcontroller bringen, besser noch einen funktionierenden Debugger
> haben. 

... die sonstigen Anforderungen...

Und, was schlägst Du vor?

> Reinflashen sollte mit jedem Controller gehen der einen Bootloader
> fuer RS232 unterstuetzt. (das machen viele) 

Ja, ein Controller, in den sich nichts rein-flashen läßt, ist schon
irgendwie unpraktisch.

CNR,
Marc

[toc] | [prev] | [next] | [standalone]

#218553

Marc Santhoff <m.santhoff@t-online.de> wrote:


 >Und, was schlägst Du vor?

Ich kann nicht viel vorschlagen. Ich hab einen J-Link und da gibt es
soweit ich weiss nur Software fuer x86 Linux. Vor dem J-Link hab ich
mal SWD mit einem STM32 probiert. Das hat zwar irgendwie funktioniert,
war aber auch immer irgendwie wackelig.
M16C koennte ich noch empfehlen, aber die sind mittlerweile natuerlich
veraltet. Dann waeren da noch SH2, aber da bekommen die Bastler in
Deutschland immer gleich Angstpickel weil nicht ARM drauf steht.

Andererseits scheint der OP ja aus einem anderen Holz zu
bestehen. <BG> Hier gibt es den Source fuer Renesas H8/SH2:

http://strawberry-linux.com/h8/write.html

Hab ich bei mir laufen, funktioniert gut.

Dann gibt es natuerlich noch die grossen Renesas wie meinen
Lieblingsprozessor (SH7262). Der hat kein Flash sondern bootet aus
einem externen SPI-Flash. Da bekommt man seine Daten leicht rein.
Darauf hab ich ja meinen MP3-Player unter Linux entwickelt. Das Dingen
hat schon ordentlich Leistung unter der Haube. (1MB-Ram, DualportRAM,
SuperScalar, Cache, alles an Schnittstellen was es gibt, acht
Registersaetze fuer schnelle IRQs, usw)  

 >Ja, ein Controller, in den sich nichts rein-flashen läßt, ist schon
 >irgendwie unpraktisch.

Du brauchst halt eine dokumentierte Schnittstelle wenn du was eigenes
machen willst.

Olaf

[toc] | [prev] | [next] | [standalone]

#218577

Olaf Kaluza <olaf@criseis.ruhr.de> wrote:
> Marc Santhoff <m.santhoff@t-online.de> wrote:
> 
> 
>  >Und, was schlägst Du vor?
> 
> Ich kann nicht viel vorschlagen. Ich hab einen J-Link und da gibt es
> soweit ich weiss nur Software fuer x86 Linux. Vor dem J-Link hab ich
> mal SWD mit einem STM32 probiert. Das hat zwar irgendwie funktioniert,
> war aber auch immer irgendwie wackelig.
> M16C koennte ich noch empfehlen, aber die sind mittlerweile natuerlich
> veraltet. Dann waeren da noch SH2, aber da bekommen die Bastler in
> Deutschland immer gleich Angstpickel weil nicht ARM drauf steht.
> 
Hmm, SuperH. Hab ich vor langer Zeit auch schon mit geliebäugelt, weil
es den SH2 auch mit DSP-Funktionen gibt. Auch den anderen Krempel von 
Renesas (IIRC R8/M8/R16/M16/M32) hatte ich in Erwägung gezogen, aber 
auf den ersten Blick keine Entwicklungsboards gefunden. 
Und dann hatte ich halt freescale S12 auf dem Tisch liegen.

> Andererseits scheint der OP ja aus einem anderen Holz zu
> bestehen. <BG> Hier gibt es den Source fuer Renesas H8/SH2:
> 
> http://strawberry-linux.com/h8/write.html
> 
Äh, ich hab ja garkein Japanisch-Wörterbuch. Mal sehen, ob im Quelltext
was lesbareres zu finden ist...

> Hab ich bei mir laufen, funktioniert gut.
> 
> Dann gibt es natuerlich noch die grossen Renesas wie meinen
> Lieblingsprozessor (SH7262). Der hat kein Flash sondern bootet aus
> einem externen SPI-Flash. Da bekommt man seine Daten leicht rein.
> Darauf hab ich ja meinen MP3-Player unter Linux entwickelt. Das Dingen
> hat schon ordentlich Leistung unter der Haube. (1MB-Ram, DualportRAM,
> SuperScalar, Cache, alles an Schnittstellen was es gibt, acht
> Registersaetze fuer schnelle IRQs, usw)  
> 
Mal sehen, ob ich das jetzt richtig mitgemeisselt hab: Den Flash
beschreibst Du ebenfalls mit dem J-Link, und der Controller führt
vermutlich einfach den ersten Code aus den er findet, richtig?

Gruß,
Florian

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | de.sci.electronics

csiph-web