Instantiating and destructing library Objects dynamically??

Hi,

I'm working on a kit for young people (HERE). It has several different functions (AKA Lessons) that are selected, one at a time, with IR remote. That's basically working.

I am worried about how many different libraries I eventually need to use, and timer conflicts. Because I am using that "Easy Module" shield I can't move very much use of pins around.

The Question:

If I instantiate an object using a library that grabs a timer, use it, and later (In the same sketch) "destructor" it, does that free the timer/resources?

Can I repeatedly create and destruct an object like this?

Does every library that allows multiple objects to be created also have the ability to destruct them? Or only if it is "Well Behaved"?? (Why does that remind me of 5th grade??)

I have to have one big "Sketch" that has several mutually-exclusive loops. Once a loop is entered by a switch from the IR remote, it is only exited with hardware Reset. I think that UNO memory space will be OK.. I need to provide my UNO-compatible to users/classrooms with this Sketch pre-loaded. The Bootloader will be preserved so later a student can move to making their own sketches.

Any comments, suggestions, Education greatly appreciated!

terryking228:
If I instantiate an object using a library that grabs a timer, use it, and later (In the same sketch) "destructor" it, does that free the timer/resources?

That fully depends on the library and if if actually has a deconstructor to leave the timer in the same state as befor...

terryking228:
Can I repeatedly create and destruct an object like this?

I would say, why not? They are just like any other variable. And the moment you use a class anywhere the methods are included on compiling.

terryking228:
Does every library that allows multiple objects to be created also have the ability to destruct them? Or only if it is "Well Behaved"?? (Why does that remind me of 5th grade??)

The later, but it depends on the library what is does. As long as it doesn't alter external things (like timers) there is not much to destruct except from the local variables.

If I instantiate an object using a library that grabs a timer, use it, and later (In the same sketch) "destructor" it, does that free the timer/resources?

No you will need to write the destructor.

Can I repeatedly create and destruct an object like this?

Yes.

Does every library that allows multiple objects to be created also have the ability to destruct them? Or only if it is "Well Behaved"?? (Why does that remind me of 5th grade??)

You need to ensure that the destuctor is well behaved.

If you are sing a hardware reset to get out of the "program" why are you worrying about destuctors?

Mark

Thanks, @septillion

AND..

If you are using a hardware reset to get out of the "program" why are you worrying about destuctors?

Now THAT's a good question. Need to Think....

Need Coffee... . . .

OK, if I can Instantiate an object at "Runtime" (in Loop, not Setup) then you're right and may have saved my bacon and my hair...

I will do some experiments.

This discussion is exactly why I asked this before diving in.

The Arduino does not have an inherent "locking" mechanism that binds a resource to a particular object. Any library can access the registers any time it likes, but obviously two different libraries writing their own info to the registers will have undefined results. That's why you can't use two of the PWM pins when you're using the Servo library. The code will compile since it is valid code, it just doesn't do what you would expect it to because two different functions are trying to use the same resource for a different purpose.

Using the two libraries at separate times will be fine, as long as they fully initialize the hardware resources and don't assume it starts in a default configuration.

Where you will run into trouble, and there is really no way around it, is interrupts. You can only have one definition for an ISR per program, and there is no way to conditionally disable other ones unless the library using #if macros. This is why you can't use any pin change interrupts with SoftwareSerial; the SS library hogs them all for itself:

#if defined(PCINT0_vect)
ISR(PCINT0_vect)
{
  SoftwareSerial::handle_interrupt();
}
#endif

#if defined(PCINT1_vect)
ISR(PCINT1_vect, ISR_ALIASOF(PCINT0_vect));
#endif

#if defined(PCINT2_vect)
ISR(PCINT2_vect, ISR_ALIASOF(PCINT0_vect));
#endif

#if defined(PCINT3_vect)
ISR(PCINT3_vect, ISR_ALIASOF(PCINT0_vect));
#endif

The only way around this is to write all your ISRs in all your libraries to use a callback registering scheme like attachInterrupt() so that you can dynamically change what function the ISR points to during runtime.

Hi, and thanks for:

Where you will run into trouble, and there is really no way around it, is interrupts.

Back in the 1981 or so day when I had an early copy of the IBM PC1 Bios listing (Long story about how it was actually published in the TechRef), you could "Hook" an interrupt but still allow others to hook the same interrupt. As long as you were "Well Behaved" two functions could coexist.

OnceUponATime I had the great idea of making a list of libraries and what resources they used. Got bogged down fast.. ANYONE seen such an animal / attempt?

Any suggestions on how to (quickly??) assess a library for what it uses?

I THINK IrRemote uses interrupts. I need to keep it alive at all times as the users selects which task/lesson will be active.

Any suggestions on how to start managing this??

Look for "ISR" in the code.

Yes I think you can daisy chain interrupts on the AVRs

Mark

terryking228:
Hi, and thanks for:
Back in the 1981 or so day when I had an early copy of the IBM PC1 Bios listing (Long story about how it was actually published in the TechRef), you could "Hook" an interrupt but still allow others to hook the same interrupt. As long as you were "Well Behaved" two functions could coexist.

How did that work? Was there an array of callbacks available or was it a more informal "linked list" arrangement?

OnceUponATime I had the great idea of making a list of libraries and what resources they used. Got bogged down fast.. ANYONE seen such an animal / attempt?

I haven't seen one.

Any suggestions on how to (quickly??) assess a library for what it uses?

Search the code for interrupt vectors and hardware register names. This might actually be quite difficult for some libraries that use conditional macros like (spoiler alert!) IRremote.

I THINK IrRemote uses interrupts. I need to keep it alive at all times as the users selects which task/lesson will be active.

Yes it does. On most things it uses TIMER2_COMPA_vect, but for other boards like a Leonardo, ATtiny84 and ATtiny85 it can use something different. The full definition of the macros starts at about line 150 in IRremoteInt.h.

Hi,

How did that work? Was there an array of callbacks available or was it a more informal "linked list" arrangement?

Wow, I haven't hooked a BIOS interrupt in over 20 years. It was linked; you saved the pointer the interrupt vector pointed at, changed the vector to point to you, and at the end of your ISR you linked to the original pointer.

.. IBM Tales left for another day ..

I'd LIKE to take a few days and read a lot of library code. Winter always seems like there will be LotsOfTime.
Right after I finish this product code and write the lesson plans and materials, make the pseudo-PID code in my Kiln Controller work a lot better so I can fuse some glass, and get the woodstove monitor from all-over-my-desk to a plastic box and write that up. Actually I'm just plain happy I never have time to be bored or worry about retirement.

My priority is getting this SmartDuino project/code ready to bring 4 of them into a Vermont 3rd grade in 2 weeks.

Which libraries are you planning on using? I can take some time during the next couple days to look them over for interrupts and potential resource sharing issues.

terryking228:
Hi,
Wow, I haven't hooked a BIOS interrupt in over 20 years.

You really want to feel old?

I might have been in diapers back then. :smiley: Or nonexistent, depending on exactly how over it is.

I wrote a load of stuff for a 6809 30? years ago which had to deal with loads of asynchronous interrupts.

So I had to make the little routines re-entrant.

Method was to add a local variable space to the stack pointer, and use stack offset backwards from that for the locals Any new interrupt grabbed it's own bit of stack in the same way , and as they finshed, all released their stack areas. Plus push and pop for the registers I needed to use.

Fortunately the interupts were sufficiently infrequent so as not to run out of stack.

In assembly, of course.

It worked..

Allan

Ah, PC interrupts. The things you could do...

Interesting thought exercise. I just keep hitting the very hard, rigidly segmented Harvard architecture structure of the AVR every time. Not sure there is a way to change interrupt vectors at run time. I don't think so but if there is a way, you'll it find it implemented here: AVR libc for GCC

avr_fred:
Ah, PC interrupts. The things you could do...

Interesting thought exercise. I just keep hitting the very hard, rigidly segmented Harvard architecture structure of the AVR every time. Not sure there is a way to change interrupt vectors at run time. I don't think so but if there is a way, you'll it find it implemented here: AVR libc for GCC

There is, it's called a callback function. That's how attachInterrupt is able to work, and it has nothing to do with AVR libc.