Go Down

Topic: Arduino Operating System (Read 11973 times) previous topic - next topic

GoForSmoke

#75
Mar 22, 2019, 10:23 pm Last Edit: Mar 22, 2019, 11:51 pm by GoForSmoke
- Your code without library
-- takes 2394 bytes (7%) of flash, it is 230 bytes more than my code with library
-- takes 238 bytes (11%) of RAM, it is 87 bytes more
Your code does no Serial unlike Robin's that does a lot of explaining.

I took Serial out of mine.
Sketch uses 992 bytes (3%) of program storage space. Maximum is 32256 bytes.
Global variables use 57 bytes (2%) of dynamic memory, leaving 1991 bytes for local variables. Maximum is 2048 bytes.

2394 - 230 - 992 = 1172. Your code with library is over 2x as large as mine at 2164..
238 - 87 - 57 = 94. Your code with library uses over 3x the RAM mine does at 151.

And I predict that your code runs slower too, like I wrote early in the thread.

So is there any chance where you can show how my task code is error prone, referring to the actual code and not something else?
1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

GoForSmoke

I can understand the attraction of figuring out how to write a simple OS for an Arduino but I find it hard to see any practical value as it just (IMHO) uses up CPU cycles and RAM that could be better used for the project itself.

...R
When you have no OS you have to write your own bugs.

Program = Code + Data.
1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

Robin2

#77
Mar 22, 2019, 11:17 pm Last Edit: Mar 22, 2019, 11:30 pm by Robin2
I like Forth, it liberated me in 83.
I also liked Forth back in '83

Maybe it would be more accurate to say I thought it was cute.

Forth is a bit like write-only memory. (like my brain ?).


...R
Two or three hours spent thinking and reading documentation solves most programming problems.

GoForSmoke

#78
Mar 22, 2019, 11:42 pm Last Edit: Mar 22, 2019, 11:54 pm by GoForSmoke
I also liked Forth back in '83

Maybe it would be more accurate to say I thought it was cute.

Forth is a bit like write-only memory. (like my brain ?).


...R
Oh no. I got a copy of Starting Forth and learned OOP and extending the compiler. Forth is capable of extending itself. Only when I got C++ did I have a compiler that can do the same things. It just takes a LOT more typing, but the money was in writing C++.

I spent real time working and playing in Forth.
1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

akouz

And if I leave Serial and the loop counter out of it, like some other sketches....

Sketch uses 992 bytes (3%) of program storage space. Maximum is 32256 bytes.
Global variables use 57 bytes (2%) of dynamic memory, leaving 1991 bytes for local variables. Maximum is 2048 bytes.

Please do not claim that your code is easy to understand. Event 6v6gt code  in #54 is more transparent.


akouz

#80
Mar 23, 2019, 12:37 am Last Edit: Mar 23, 2019, 01:09 am by akouz
So is there any chance where you can show how my task code is error prone, referring to the actual code and not something else?

Your code is obscure. It is hard to follow its logic.  While today the code might be clear for yourself, it will not be so clear few month later when you look at it again, unless you have exceptional memory. And it is not clear for anyone else, especially for newbies.

Obscure code is prone to errors, it is hard to debug. It might be a reason why you presented it with a delay. It took me about 5 minutes to write and debug my initial code. And "debug" was fixing typos and tuning timing. "Fading challenge" in #62 took me few minutes too. Higher level of abstraction gives great flexibility.

akouz

I suspect I did not spend as long developing my little program as you did developing your library.

It is exactly the point. Do not reinvent the wheel, do not waste time on writing code doing the same job. Use library. 

lastchancename

#82
Mar 23, 2019, 01:14 am Last Edit: Mar 23, 2019, 02:34 am by lastchancename
Coos challenge: fade up and fade down the LED on pin 13.

VIDEO: 8MHz PIC a few years ago - but can do
Software PWM on a chain of TPIC595s
This shows 24 channels (8x RGB) out of 72 channels actually running (24x RGB LEDs)

Experienced responders have a nose for laziness, (they were beginners once)... Sure, there are trolls, chest-beaters, and pretenders - but the help you'll get here is about as good as it gets - if you try to help youself!.

GolamMostafa

#83
Mar 23, 2019, 01:16 am Last Edit: Mar 23, 2019, 01:16 am by GolamMostafa
AVR core has 32 General Purpose 8-bit registers. Every one of them can be an accumulator, an address register, an index, but the instructions that operate on the registers are in flash.
There are restrictions. For example:
1. In the multiplication process, only R0 and R1 registers work as accumulator.
2. In the load immediate process, only the upper 16 registers (R16-R31) are the receiving/accumulating registers.
3. ...

GoForSmoke

Your code is obscure. It is hard to follow its logic.  While today the code might be clear for yourself, it will not be so clear few month later when you look at it again, unless you have exceptional memory. And it is not clear for anyone else, especially for newbies.

Obscure code is prone to errors, it is hard to debug. It might be a reason why you presented it with a delay. It took me about 5 minutes to write and debug my initial code. And "debug" was fixing typos and tuning timing.
I didn't comment it to death yet but as far as obscure, that is your opinion.

Making useful full explanations of logic and why in English takes a lot longer than writing the logic once you're good at logic, I didn't put in the time to write a freaking book for your challenge and this is all you can pick at?

The code itself is actually simple once you understand the approach. People on this forum do learn it, just not everybody... let them run your work-around that will be as obscure to them as you feign the few lines I wrote to be to you.

I hope you don't feel that it took me long to go from blinking status led to what I first posted after I looked through your post. I did have a bit of real life in between, hope you don't mind.

I find that the way I code leads to less code and less errors and in your case way less overhead. But then if that bit of code was hard for your experienced self then just what do you need help with understanding? We can break it down. There's the uneven blink status led and the sos led. Which gives you trouble?

Show me actual errors and spare the hand waving as I don't buy your truism.  I'll even help you look.
1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

akouz

#85
Mar 23, 2019, 05:20 am Last Edit: Mar 23, 2019, 06:05 am by akouz
Show me actual errors and spare the hand waving as I don't buy your truism.  I'll even help you look.

You code does not operate properly, is not it an error?  After reset it makes 2 long flashes, then 3 short flashes, then 6 long, 3 short, 6 long, etc. It does not look like SOS for me.  In a very spectacular way it proves that your code is prone to errors, perfectly in line to what I said before :)


GoForSmoke

Just loaded the last version I posted (the 992 byte compile) and I am right now watching led 13 give 3 quick blinks followed by 3 long blinks followed by 3 quick blinks, a long wait and repeat.

When I switch the sos pin to 2 and the uneven status blink on pin 13 and I get the status blink.
Please don't insult me with speculation that if I run both leds at once the timing of either changes. It won't at all.

I don't know what you loaded to your board or what you do but ---

Anyone on the forum with an Uno can see this for themselves. Here's the file to make an easy grab.

Code: [Select]
word  nowMs; // 16 bit millis is good to time 65.535 seconds

byte ledState, ledPin = 2; // use byte for small values, int cost 2 bytes
word startBlink, waitBlink[] = { 900, 100 };

void Blinker() 
{
  if ( nowMs - startBlink >= waitBlink[ ledState ] )
  {
    startBlink += waitBlink[ ledState ]; // next blink starts when it should, even if this one ended late.
    ledState = !ledState; // ! is logical NOT: 0 becomes 1, not 0 becomes 0. 0 is false.
    digitalWrite( ledPin, ledState ); // the led changes to the new state.
  }
}

// sos led vars
byte sosIdx, sosPin = 13;
const byte sosDo = 18;
word  sosStart;  // the sosTimes array could be putin PROGMEM and save 36 bytes of RAM
word  sosTimes[] = { 200, 250, 200, 250, 200, 500, 800, 250, 800, 250, 800, 500, 200, 250, 200, 250, 200, 2500 };

void SOS()
{
  if ( nowMs - sosStart >= sosTimes[ sosIdx ] ) // difference in time by subtracting start from end
  {
    sosStart += sosTimes[ sosIdx ]; // next blink starts when it should, even if this is late.
    digitalWrite( sosPin, sosIdx & 1 ); // the led changes to the new state.
    if ( ++sosIdx == sosDo )  sosIdx = 0;
  }
}

void setup()
{
  pinMode( ledPin, OUTPUT );
  pinMode( sosPin, OUTPUT );
}

void loop() // runs over and over
{
  nowMs = word( millis());
  Blinker();
  SOS();
}[/quote]

1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

neiklot


akouz

#88
Mar 23, 2019, 09:46 am Last Edit: Mar 23, 2019, 09:51 am by akouz
Just loaded the last version I posted (the 992 byte compile) and I am right now watching led 13 give 3 quick blinks followed by 3 long blinks followed by 3 quick blinks, a long wait and repeat.

Ok, I've reloaded you code, now it works better. Perhaps I corrupted something first time, sorry.

So far one error remains: after reset it gives 2 short blinks, not 3 blinks as it supposed to do. It is still a solid proof that your code is prone to errors.

GolamMostafa

#89
Mar 23, 2019, 09:54 am Last Edit: Mar 23, 2019, 10:21 am by GolamMostafa
So far one error remains: after reset it gives 2 short blinks, not 3 blinks as it supposed to do.
Are you saying so after doing an analysis on the codes or after testing the codes on an Arduino?

Go Up