Re: Server Runtime for 9.1 / 32 bits / ARM

Hi Norbert, 

My answer below. I am CCing Louis which may be answer better than me. 

On Wed, Dec 5, 2018 at 8:07 AM Norbert Schlemmer <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="3TyyGISsDQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">norbert....@...> wrote:

Hello Mariano

1) what is the difference between these applications:

.) HardwarePeripheralsCoreApp / HardwarePeripheralsCoreTestApp

and

.) RaspberryHardwareInterface*App  (from <a href="http://vastgoodies.com/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fvastgoodies.com%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFuxnr60lH1eJZumpU0ZdEEA3DfSQ&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fvastgoodies.com%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFuxnr60lH1eJZumpU0ZdEEA3DfSQ&#39;;return true;">http://vastgoodies.com/) ?

Honestly, I don't know what the former are. I have always used the latter RaspberryHardwareInterface*App. 

 

I got HardwarePeripheralsCoreApp up and running under Raspberry using VastEcap1_b413_712c7456f909_linux, but RaspberryHardwareInterfaceViaDaemonTestApp doesn't work.

what is the "better" source to start ?

I don't know where Louis is documenting all these but for RaspberryHardwareInterfaceViaDaemonTestApp to work you need:

a) libgpiod installed in your OS. Probably something like "sudo apt-get install pigpio". 

You should be able to do "sudo pigpiod" to start the libbpio deamon. But the Smalltalk wrapper does this for you if it is not running. But just that you know that you need pigpiod.

 

b) Entries in the .ini file:

[PlatformLibrary Name Mappings]

RaspberryGpio=libpigpio.so

RaspberryGpioDaemon=libpigpiod_if2.so

RaspberryGpioUltrasonicDaemon=libpigpioultrasonic.so

2) OneWireDevice class>>#diviceDirectoryNamesMatching:

has a problem with the patternToMatch: '.*' -> '-*' or '*'

example: /sys/bus/w1/devices/28-020691770dfc/w1_slave

No clue what that is, sorry. 

Let us know how it goes.

Cheers, 

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.
<a href="javascript:" target="_blank" gdf-obfuscated-mailto="3TyyGISsDQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">mp...@...

Hi Norbert and Mariano,

RaspberryHardwareInterfaceCoreApp v0.11 and RaspberryHardwareInterfaceViaDaemonTestApp v0.02 are the latest and the two applications to load and use.

The applications whose names don't start with "Raspberry" are old.  The project started out as a port of the Raspberry Pi hardware interface code from Squeak.  It turned into a rewrite because of the differences between the way Squeak and VA Smalltalk handle platform calls and the way the original author dealt with the interface object.  Once I started the rewrite I renamed things to better separate stuff and to allow for both a daemon and non-daemon interface (the Squeak code only had a daemon interface).  We have a non-daemon interface but it currently crashes the VM.  I keep it around in the hope the the VM problem will someday be fixed.  No pressure on the guys at Instantiations as the daemon interface is fine for the vast majority of the cases.

Norbert, if Mariano's answer about the test program not working didn't solve the problem, please post more about it and we will see if we can help.

As for the problem with the OneWireDevice, much of the code for a lot of the devices that can be connected to the Raspberry Pi was ported/copied as is with little to no testing as I don't have the devices to test with.  The OneWireDevice code and perhaps other stuff uses the Squeak file I/O interface that is different from our CFS interface.  I knew there would be problems there but ran out of time to play with it and without hardware to test with I decided leave it as it is and wait for someone like yourself to find the problems.

If you can figure out how to fix the problem I will add the fix to the system.  If you need help ask and I will see what I can do.  I warn you I am juggling three projects at the moment, so fixing it on my own is not a high priority but I will take small amounts of time to help.

Lou

On Wednesday, December 5, 2018 at 6:46:02 AM UTC-5, marianopeck wrote:

Hi Norbert, 

My answer below. I am CCing Louis which may be answer better than me. 

On Wed, Dec 5, 2018 at 8:07 AM Norbert Schlemmer <[hidden email]> wrote:

Hello Mariano

1) what is the difference between these applications:

.) HardwarePeripheralsCoreApp / HardwarePeripheralsCoreTestApp

and

.) RaspberryHardwareInterface*App  (from <a href="http://vastgoodies.com/" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fvastgoodies.com%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFuxnr60lH1eJZumpU0ZdEEA3DfSQ&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fvastgoodies.com%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFuxnr60lH1eJZumpU0ZdEEA3DfSQ&#39;;return true;">http://vastgoodies.com/) ?

Honestly, I don't know what the former are. I have always used the latter RaspberryHardwareInterface*App. 

 

I got HardwarePeripheralsCoreApp up and running under Raspberry using VastEcap1_b413_712c7456f909_linux, but RaspberryHardwareInterfaceViaDaemonTestApp doesn't work.

what is the "better" source to start ?

I don't know where Louis is documenting all these but for RaspberryHardwareInterfaceViaDaemonTestApp to work you need:

a) libgpiod installed in your OS. Probably something like "sudo apt-get install pigpio". 

You should be able to do "sudo pigpiod" to start the libbpio deamon. But the Smalltalk wrapper does this for you if it is not running. But just that you know that you need pigpiod.

 

b) Entries in the .ini file:

[PlatformLibrary Name Mappings]

RaspberryGpio=libpigpio.so

RaspberryGpioDaemon=libpigpiod_if2.so

RaspberryGpioUltrasonicDaemon=libpigpioultrasonic.so

2) OneWireDevice class>>#diviceDirectoryNamesMatching:

has a problem with the patternToMatch: '.*' -> '-*' or '*'

example: /sys/bus/w1/devices/28-020691770dfc/w1_slave

No clue what that is, sorry. 

Let us know how it goes.

Cheers, 

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.
[hidden email]

Hi Louis

I'm using a DS18B20 temperature sensor with the “One-Wire” communication protocol, and using the RaspberryHardwareInterfaceCoreApp.

OneWireDS18B20ThermometerDevice listDevices do: [ : aString |
        | myTemperature|
        myTemperature := (OneWireDS18B20ThermometerDevice idString: aString) temperature.

        Transcript
                cr;
                show: ('Temperature %1' bindWith: myTemperature)
].

To get this device running, I had to change OneWireDevice class>>#diviceDirectoryNamesMatching: because the directory pattern has to be '-*' instead of '.*'

and the return values (commented " self baseDirectory , '/' , ").

The complete path of the device is /sys/bus/w1/devices/28-020691770dfc/

It seems that the disk system is needed for “One-Wire” devices.

br

Norbert

Hi Louis

I'm using a DS18B20 temperature sensor with the “One-Wire” communication protocol, and using the RaspberryHardwareInterfaceCoreApp.

OneWireDS18B20ThermometerDevice listDevices do: [ : aString |
        | myTemperature|
        myTemperature := (OneWireDS18B20ThermometerDevice idString: aString) temperature.

        Transcript
                cr;
                show: ('Temperature %1' bindWith: myTemperature)
].

To get this device running, I had to change OneWireDevice class>>#diviceDirectoryNamesMatching: because the directory pattern has to be '-*' instead of '.*'

and the return values (commented " self baseDirectory , '/' , ").

The complete path of the device is /sys/bus/w1/devices/28-020691770dfc/

It seems that the disk system is needed for “One-Wire” devices.

br

Norbert

Hi Louis

.) please have a look to RaspberryHardwareInterfaceViaDaemonSubApp class>>#shutdown, should be #shutDown (typo)

I added #shutDown and kept #shutdown just in case.  Normally I don't like duplicates like this but when one ports/rewrites interfaces like this there is often a blending of styles.

 #shutdown should be deleted, because the base class implements #shutDown

.) the OneWire* classes are independent of pigpio library, maybe we should use a appropriate sub application for these classes.

I agree with your assessment.  Do you think the OneWire* classes should be in their own sub app or moved up to the main app?  I'm on the fence and could go either way and I'm open to suggestions from anyone.

own sub app for OneWire*

Thanks for your work and Ideas.  Maybe when you get some time you can tell us something about what you are doing.

have no real project with Raspberry, just interested in these technologies. The "real projects" with VA are running under Windows and with Oracle

regards

Norbert