pauledd thanked Jasem Mutlaq in topic INDI GPhoto Driver v2.0 7 days ago
pauledd replied to the topic 'help on indi wiringPi gpio crash' in the forum. 2 weeks ago

cheer!

was removed on August 17th 2017

must have missed that in my fork.
:woohoo:
All systems go! Time to haul my scope back on balcony

Read More...

pauledd replied to the topic 'help on indi wiringPi gpio crash' in the forum. 2 weeks ago

So far ... it seems to work, in my opinion you can close the issue on github.
Just some things in your code I want to mention :
- maybe change NULL to nullptr?
- maybe change from -std=c++0x to c++11?

indi_wiringpi_gpio
- I always have to add this crypt flag to CmakeLists.txt
( github.com/magnue/indi_wiringpi_gpio/iss...suecomment-379486642 )

indi_servoblaster_cap
- you should check to include <cstring> as I get compiler errors without it (gcc-6.x)
- I had to remove the code in "ServoBlasterCap::EnableLightBox" that checks if cap is parked.
I cannot activate the light of my flatfield-dustcover if closed but I have to, to make flats, maybe you can implement
some kind of checkbox to disable this check.
- maybe enable issues page on github for that repo so than I can bother you with my problems there :silly:

Read More...

pauledd replied to the topic 'help on indi wiringPi gpio crash' in the forum. 2 weeks ago

I maybe made a bit of progress.
This "Uninitialised value was created by a heap allocation" (wiringpi_gpio.cpp) seems to be related to the part
in the updateProperties() function where you test for NULL:

if (InputDigitalLP[i]->lp != NULL)
    defineLight(InputDigitalLP[i]);
if (OutputDigitalSP[i]->sp != NULL)
    defineSwitch(OutputDigitalSP[i]);
My thought was that "InputDigitalLP->lp" and "OutputDigitalSP->sp" needs to be initialized with something...
So I assigned NULL to it right after its creation in the "WiringPiGPIO::WiringPiGPIO()" constructor:
WiringPiGPIO::WiringPiGPIO()
{
    for (int i = 0; i < NUMBER_OF_PINS; i++)
    {
        InputDigitalLP[i] = new ILightVectorProperty;
        OutputDigitalSP[i] = new ISwitchVectorProperty;
                
                // added
                InputDigitalLP[i]->lp = NULL;
                OutputDigitalSP[i]->sp = NULL;
                //
    }
    OutputPWMNP = new INumberVectorProperty;

    setVersion(0,1);
    setDriverInterface(AUX_INTERFACE);
}

I really dont know If this is the right way to do it but a first tests with the new code show normal behaviour of the driver (compiled with gcc-6.x).
I can set gpio's, switch them, and save them successfully B).
I will report back if there is any new fail.

Read More...

pauledd replied to the topic 'help on indi wiringPi gpio crash' in the forum. 2 weeks ago

Ok, thanks Magnus_e.
In the meantime just out of curiosity and for personal pleasure :huh: I am playing with valgrind and it found some issues:

#valgrind --leak-check=full --show-leak-kinds=all --trace-children=yes --track-origins=yes indiserver indi_wiringpi_gpio

...
2018-04-10T07:36:51: Driver indi_wiringpi_gpio: ==4988== Conditional jump or move depends on uninitialised value(s)

2018-04-10T07:36:51: Driver indi_wiringpi_gpio: ==4988==  Uninitialised value was created by a heap allocation

2018-04-10T07:36:53: Driver indi_wiringpi_gpio: ==4988== Invalid read of size 8
full log: pastebin.com/X4Mruu6F

PS. Line Numbers refer to my cleaned code of indi_wiringpi_gpio (github.com/pauledd/indi_wiringpi_gpio_clean)

Read More...

pauledd replied to the topic 'help on indi wiringPi gpio crash' in the forum. 2 weeks ago

Ok, with 2017-07-05-raspbian-jessie.img (gcc-4.9.2) indi_wiringPi_gpio works.
Magnus_e I bet if you update your gcc or use any recent distro for Raspberry I am sure it will
crash on your system too.
It seems something changed from gcc-4.9.x to gcc-?? that made your driver unusable.
If I stay on gcc-4.9.2 (jessie) I think it will be only a matter of time until something indi related requires >gcc-4.9.x
and I will be back at this issue.

I think the issue has nothing to do with the systeminfo tabs, I removed that code completely but the issue persists.
It must be something in wiringpi_gpio.cpp.
I will try to take a look at valgrind, maybe I can get a hint where the problem originates from but I currently only get some kind of restarting loop if I try it with:

valgrind --trace-children=yes indiserver -v indi_simulator_telescope indi_simulator_ccd indi_wiringpi_gpio
and if I connect kstars it somehow never reaches the point where the driver gets fully initialized.

Read More...

pauledd replied to the topic 'help on indi wiringPi gpio crash' in the forum. 2 weeks ago

Magnus_e wrote:

gcc version 4.9.2 

Ok, this is really old ... ;)
I will try to get a version close to yours and recompile and see if thats the cause.

Read More...

pauledd replied to the topic 'help on indi wiringPi gpio crash' in the forum. 2 weeks ago

thanks, I recompiled with your wiringpi version but same error...
What gcc version are you using on your Raspberry ?

Read More...

pauledd replied to the topic 'help on indi wiringPi gpio crash' in the forum. 2 weeks ago

I would call this driver dead for now.
And now Raspbian is also on the list...
Just tried a fresh Raspbian Stretch (Release date: 2018-03-13), and a fresh indilib install together with fresh indi_wiringpi_gpio driver from git.
It crashes again at the same position with:

...
Child process 4635 died
2018-04-08T16:02:50: Driver indi_wiringpi_gpio: WiringPiGPIO::ISNewSwitch CONNECTION
2018-04-08T16:02:50: Driver indi_wiringpi_gpio: WiringPiGPIO::ISNewSwitch CONNECTION
2018-04-08T16:02:50: Driver indi_wiringpi_gpio: Impossible IPState 891304457
2018-04-08T16:02:50: Driver indi_wiringpi_gpio: Impossible IPerm 171389027
2018-04-08T16:02:50: Driver indi_wiringpi_gpio: Impossible ISRule 542462019
2018-04-08T16:02:50: Driver indi_wiringpi_gpio: stderr EOF
2018-04-08T16:02:50: Driver indi_wiringpi_gpio: restart #1
...
I ordered an cheap usb-relay module in the hope that indi_usbrelay2_roof driver is more ... functional.

Read More...

pauledd replied to the topic 'help on indi wiringPi gpio crash' in the forum. 2 weeks ago

Magnus_e wrote: Don't really know how this could happen on Gentoo and not Raspbian. Perhaps Valgrind can give som info about memory use.


Well, I can now add Ubuntu Mate to the non working list, I am back at the issue.
I currently try to condense your code down to the very basic things and exclude that systeminfo stuff.
Did you test on Raspbian only? And what version did you use?

Read More...

pauledd replied to the topic 'move away from gentoo on raspberry?' in the forum. 1 month ago

I'll get just another new SDCard and try Ubuntu Mate... it doesn't hurt to try it :)

Read More...

pauledd created a new topic ' move away from gentoo on raspberry?' in the forum. 1 month ago

Hi there
Sorry this might be a bit off topic.
I noticed there are a few gentoo on RaspberryPi users here, including me.
I really love gentoo and its endless possibilities to configure it in every detail one can imagine.
I love my gentoo desktop which already lasted more that 4 years and I will of cause keep it.
But as it takes every time several days for me to reinstall gentoo on an RPI after a sdcard crash
or major updates that require to rebuild @world... configuring crosscompile environment, creating backups of the rootfs...
I simply start to feel this might be an overkill for the RPI.
So I really consider to move to a binary based distro like Ubuntu Mate.
The only point that makes me hesitate is the question, can I be as flexible as I am currently on gentoo?
I like to compile indlib... etc. right from git code. Can I do that lets say on Ubuntu mate too?
I know that I wont have the the freedom of compile flags as on gentoo's use flags, but shouldn't I be able to compile
those packages that need special compile flags manually as I did on gentoo?
Is there any benefit I miss on continuing using gentoo on my astro RPI except to adhere to gentoo?

Read More...

pauledd replied to the topic 'DIY Flatfield Dustcover with RPi' in the forum. 2 months ago

Success!
I reduced circle 1 radius to be only 80% of the circle 2 radius. I even had to reduce the servos travel distance in the calibration tab.
[video]
I had another problem where the cover. It wont open in the most extreme position (most force needed) but I could
solve that by moving the rod that holds the close magnet just a little tiny bit away from the dustcap, that reduced the force of the magnets.
The last problem seemed to be solved too. It locked as if the dustcap would not close planar anymore to the foam gasket.
But the cap was not bending as I first thought. The problem was the hole mechanics was to tight/stiff. The axis of the hinge on which the cap is attached needs to have a certain backlash so that the cover can lay/adapt planar on the foams surface.

I will now do some more dry tests before I heft my scope back into the wilderness :)

Read More...

Eric thanked pauledd in topic No any icon in the new build kstars 2 months ago
pauledd replied to the topic 'DIY Flatfield Dustcover with RPi' in the forum. 2 months ago

Ok, thanks I will try decreasing circle1. However thats strange :huh: where are the 30° gone? I designed circle1 with the exact diameter as circle2, that shouldn't that give the same angle range as the servo does... in theory :lol: I'll investigate further!

Read More...

Login



3rd Party

Choose from the numerous 3rd party INDI drivers to suit your needs!

Got Problem?

Check out the FAQ, the forum, and the bug tracking system to resolve any issues you might have!
You can also subscribe to INDI newsletter and development mailing lists to get the latest updates on INDI!