I use to put cpu performance code into the Korn Shell. I just would like to revisit a discussion I had with Bill about pulling in optimized hardware code functions outside the run time compiler.
Anyone got any ideas how to avoid the run time compiler to use some of the better written optimized i2c C functions. I keep seeing issues related to munging up the i2c bus due to timing mismatches.
As a long-time writer of device drivers, I agree it would be madness to rely on any kind of JIT for low-level device access. However the "-contrib-i2c" node appears to have all its driver interface functionality in C++, so possibly the timing issues are coming from the interop layers.
I'd suggest contacting the node's author to see if there are any timing or usage constraints which you might be running into. If that doesn't work out, then you could possibly write a custom node, moving any timing-critical logic into C/C++, and accessing the I2C driver directly.
Has anyone actually done any raw i2c testing on the Pi? It may well be that performance isn't terribly hot anyway.
Remember, the Pi was designed for teaching not for industrial use. The GPIO design on the Pi is actually rather weak I believe.
Certainly, I've never even bothered trying since a general purpose OS like Linux doesn't really sit all that well with the near real-time requirements of GPIO. I've always found it a lot easier to use an Arduino or ESP8266/ESP32 for hardware interfaces. Even though it meant that I've had to learn some C/C++ along the way.
I regularly see people struggling with the Pi GPIO and resorting to Python to try and get things working but this stuff is so cheap now that a couple of dollars spent on an ESP8266 seems like a no-brainer.
Linux and Windows are definitely not real-time operating systems, but carefully designed kernel-level device drivers should be able to handle the requirements of even quite demanding devices. The question of where you draw the divide between driver and user functionality is crucial though, and if you leave any kind of time-critical stuff to the user level it will almost certainly fail at some point. (I speak from experience )
Indeed - I've gone down this route extensively, and nearly all my devices are/will be ESP8266-based, using MQTT to communicate.
That said however, an RPi, if it's not overly loaded with a mass of other tasks, should easily be up to running I2C and Node-RED together. It would be interesting to see some performance tests on various models with similar software setups...
Molesworth, contrib-i2c is using i2c-bus for the low level. Where are you seeing C++ in contrib-i2c?
I now see where i2c-bus has its cc files and plan on exercising them once I can get contrib-i2c to show up in node red console.
My local NPM list it properly installed, but I can see the nodes in node-red. Any ideas as to how to fix this?
node-red-contrib-i2c still needs to resolve the GIT version with the NPM version so I can pull it in to the palette within the console and not with NPM on the command line.
One other thing NPM seems to stop processing the flows after 18-36 hours. Is there any issue with the virtual machine size? This looks a lot like java running out of space. On RPI I think there is a 256 value set I haven't looked into. Not that I'm not an expert on this, but I would like to know if this is known before wasting time looking at this, once I figure out how to get some sort of working dtrace package.
And includes a link to the Github repo - GitHub - fivdi/i2c-bus: I2C serial bus access with Node.js - which is the driver interface I was meaning. The node itself will be using an interop layer between C++ and Javascript, which is likely where the performance hit comes from.
So, you are saying that 'node-red-contrib-i2c' does not work currently, but if I learn the i2c protocol, and how my chip responds to it I would be able to make a function node with java that would get the readings?
"YES" If we can get node-red-contrib-i2c updated from 0.5.2 to 0.5.5 on the NPM server. Its out of date
So we just need niels to push that version to npm ?
"YES" If we can get node-red-contrib-i2c updated from 0.5.2 to 0.5.5 on the NPM server. Its out of date
> Its all seems to fully work with me using an i2c Pi add-on board (4tronix PiCon Zero)
It is different on the Pi 4 4GB running latest Debian.
You can see from my listings I am where you are but the nodes don't show up inside the node-red console. For some reason it needs to be installed in the pallet manager to show up. If the NPM is updated then the install within the console should be a happy camper.
[{"id":"72c11be2.fdeb14","type":"python-function","z":"352b627d.9c316e","name":"MCP9808 I2C Inquiry","func":"import time\nimport Adafruit_MCP9808.MCP9808 as MCP9808\nimport os\n\nfrom unittest import TestCase, skipIf\nfrom time import time as now\n\n# Define a function to convert celsius to fahrenheit.\ndef c_to_f(c):\n\treturn c * 9.0 / 5.0 + 32.0\n\n# Default constructor will use the default I2C address (0x18) and pick a default I2C bus.\n#\n# For the Raspberry Pi this means you should hook up to the only exposed I2C bus\n# from the main GPIO header and the library will figure out the bus number based\n# on the Pi's revision.\n#\n# For the Beaglebone Black the library will assume bus 1 by default, which is\n# exposed with SCL = P9_19 and SDA = P9_20.\nsensor = MCP9808.MCP9808()\n\n# Optionally you can override the address and/or bus number:\n#sensor = MCP9808.MCP9808(address=0x20, busnum=2)\n\n# Initialize communication with the sensor.\nsensor.begin()\ntemp = sensor.readTempC()\n\ntempc = ('{0:0.3F}'.format(temp))\n\nmsg['topic'] = \"tempc\"\nmsg['payload'] = tempc\n\nreturn msg","outputs":1,"x":300,"y":70,"wires":[["9208f1fb.9caf8","c0562b67.8b2088"]]}]
I had an installation fail of node-red-contrib-i2c 0.5.2 on my raspi 4.
Raspian Buster and nodered up-to-date today.
End of the debug-log:
...
151 verbose Linux 4.19.97-v7l+
152 verbose argv "/usr/bin/node" "/usr/bin/npm" "install" "--no-audit" "--no-update-notifier" "--save" "--save-prefix=\"~\"" "--production" "node-red-contrib-i2c@0.5.2"
153 verbose node v12.15.0
154 verbose npm v6.13.4
155 error code ELIFECYCLE
156 error errno 1
157 error i2c-bus@1.2.5 install: `node-gyp rebuild`
157 error Exit status 1
158 error Failed at the i2c-bus@1.2.5 install script.
158 error This is probably not a problem with npm. There is likely additional logging output above.
159 verbose exit [ 1, true ]
However I can confirm, that node-red-contrib-i2c 0.5.5 directly from git seems to work (at the moment just tested the i2c scan node. Installation:
~/.node-red $ npm install --unsafe-perm https://github.com/nielsnl68/node-red-contrib-i2c
> i2c-bus@4.0.11 install /home/me/.node-red/node_modules/i2c-bus
> node-gyp rebuild
make: Entering directory '/home/me/.node-red/node_modules/i2c-bus/build'
CXX(target) Release/obj.target/i2c/src/i2c.o
SOLINK_MODULE(target) Release/obj.target/i2c.node
COPY Release/i2c.node
make: Leaving directory '/home/me/.node-red/node_modules/i2c-bus/build'
+ node-red-contrib-i2c@0.5.5
added 2 packages from 2 contributors and audited 2159 packages in 19.962s
3 packages are looking for funding
run `npm fund` for details
found 9 vulnerabilities (2 low, 1 moderate, 6 high)
run `npm audit fix` to fix them, or `npm audit` for details
After "systemctl restart nodered" I see the i2c nodes in the palette and the palette manager.
Triggering the i2c scan node with a timestamp inject and debugging the msg.payload shows the addresses of my two i2c devices at address 32 (0x20) and 39 (0x27) (these are two PCF8574 port expanders):
[ 32, 39 ]
14/2/2020, 13:37:29node: 3fb33af4.40472emsg.payload : number
32
14/2/2020, 13:37:29node: 3fb33af4.40472e
msg.payload : number
39
Would be nice, if v0.5.5 could be installed from the palette-manager.