mboehmer Posted January 22, 2019 Posted January 22, 2019 Short update: soft SPI as included "default" in 4.19 kernel works on C2, with about 3.39us time per bit (no data line change). Changing the data line adds a bit of delay, yielding in 4.68us per bit. Seems be limited by I/O access speed in the SoC. @TonyMac32: great job Now I "just" need 1wire in
TonyMac32 Posted January 22, 2019 Posted January 22, 2019 6 hours ago, mboehmer said: Now I "just" need 1wire in Compliments @martinayotte: https://github.com/armbian/build/blob/master/patch/kernel/meson64-next/general-meson64-overlays.patch#L133 Add it to the armbianEnv.txt file. :-)
martinayotte Posted January 22, 2019 Posted January 22, 2019 6 hours ago, mboehmer said: Now I "just" need 1wire in 5 minutes ago, TonyMac32 said: Compliments @martinayotte: Yes ! Done more than 1 month ago in DEV : https://github.com/armbian/build/blob/master/patch/kernel/meson64-dev/general-meson64-overlays.patch#L133
mboehmer Posted April 8, 2019 Posted April 8, 2019 Hi, so 1Wire seems to work, but doesn't accept the param_w1_pin setting in armbianEnv.txt (not a big deal). @Tony: can you change your example so that three 1Wire masters with three different pins are being used? I still fail on that, but need that to test the temperature stuff here Thanks in advance, Michael
TonyMac32 Posted April 8, 2019 Posted April 8, 2019 1 hour ago, mboehmer said: Tony: can you change your example so that three 1Wire masters with three different pins are being used? I think @martinayotte is the man for that job, I don't have as much experience with the fixup scripts as he. Now, it may be worthwhile to simply make a custom overly for your purposes.
martinayotte Posted April 8, 2019 Posted April 8, 2019 49 minutes ago, mboehmer said: so that three 1Wire masters with three different pins are being used First, why do you need several W1 master ? You can have several slave devices on the same bus ...
martinayotte Posted April 8, 2019 Posted April 8, 2019 2 hours ago, mboehmer said: so that three 1Wire masters with three different pins are being used? In case you still wish to have more than one bus, here is the DTS for an Dual-W1 overlay, note that the pin 0x5b is GPIOY16 for bus1 while 0x5a is for GPIOY15 for bus2 : /dts-v1/; / { compatible = "amlogic,meson-gxbb"; fragment@0 { target-path = [ 2f 00 ]; __overlay__ { onewire@0 { compatible = "w1-gpio"; pinctrl-names = "default"; gpios = < 0xffffffff 0x5b 0x06 >; status = "okay"; phandle = < 0x01 >; }; }; }; fragment@1 { target-path = [ 2f 00 ]; __overlay__ { onewire@1 { compatible = "w1-gpio"; pinctrl-names = "default"; gpios = < 0xffffffff 0x5a 0x06 >; status = "okay"; phandle = < 0x02 >; }; }; }; __symbols__ { w1a = "/fragment@0/__overlay__/onewire@0"; w1b = "/fragment@1/__overlay__/onewire@1"; }; __fixups__ { gpio = "/fragment@0/__overlay__/onewire@0:gpios:0", "/fragment@1/__overlay__/onewire@1:gpios:0"; }; };
mboehmer Posted April 8, 2019 Posted April 8, 2019 4 hours ago, martinayotte said: First, why do you need several W1 master ? You can have several slave devices on the same bus ... Agreed, I know the 1Wire bus , we use that sensors now for almost 10 years to identify hardware cards in our systems. It is a topological problem: one SMD mounted sensor gives the DC/DC temperature, and the ID of the board - it's a DS1822, so its family ID is different from the two other sensors (DS18B20). The latter ones are attached by cable, and measure temperatures of PMTs on top and bottom side of the glas dome (call it north and south pole). For these, we need to simply know where they are located, and using different masters (mapped to different pins on different connectors) takes out a lot of possibilities to go wrong. Temperatures on both poles are kind of "last resort" to find out the orientation of the dome, in case our other sensors fail. North pole (the one pointing towards the sea surface) usually is 1.8K warmer than the other one pointing down to sea floor - heates air tends to rise up... Besides, I *hate* the software overhead to "separate" one sensor and then talk to it (done similar approaches on FPGA, with 16 sensors defining preamp card positions, so I used one master for sending and sixteen masters for receiving, tailor made ) WIll try your fix tomorrow, and try to extend it to three masters (which should be "simple"). Thanks for your great support! Michael
mboehmer Posted April 8, 2019 Posted April 8, 2019 3 hours ago, martinayotte said: (A) target-path = [ 2f 00 ]; (B) gpios = < 0xffffffff 0x5b 0x06 >; Just two questions on your code: (A) do you program FPGAs or uCs? You see very rarely people usings "strings" like that (students always look somehow confused if I do in my course ) (B) I can use the "normal" coding like: gpios = <&gpio GPIOY_16 GPIO_OPENDRAIN> taken from meson-gxbb-gpio.h and gpio.h?
martinayotte Posted April 8, 2019 Posted April 8, 2019 21 minutes ago, mboehmer said: (A) do you program FPGAs or uCs? I'm working with both, along with many other things ... 21 minutes ago, mboehmer said: (B) I can use the "normal" coding like: gpios = <&gpio GPIOY_16 GPIO_OPENDRAIN> taken from meson-gxbb-gpio.h and gpio.h? That is what we usually doing with DTS in Mainline kernel, but it is requiring to be compile into DTB from the kernel tree, otherwise, on the board itself, the meson-gxbb-gpio.h and gpio.h are not present. So, I've actually log on my NanoPiK2 thru SSH, decompile the /boot/dtb/amlogic/overlay/meson-w1-gpio.dtb, and added the second bus, that it is why it is not in plain text but into numeric values understood by overlay loader.
mboehmer Posted April 8, 2019 Posted April 8, 2019 1 hour ago, martinayotte said: So, I've actually log on my NanoPiK2 thru SSH, decompile the /boot/dtb/amlogic/overlay/meson-w1-gpio.dtb, and added the second bus, that it is why it is not in plain text but into numeric values understood by overlay loader. Good tip, indeed, was always running a full image compilation... changed your file accordingly, and got three W1 masters. Will add cables tomorrow (not in office any more) and check, but seems very promising! Thanks again for your great help!
mboehmer Posted April 10, 2019 Posted April 10, 2019 Another question regarding dtbo... maybe you have an idea? I want to disable the spi-gpio by default, and have an overlay dtbo to activate it in case I need it. I can set status="disabled" in meson-gxbb-odroidc2.dts, but fail on the dtbo. I tried renaming it to spigpio in device tree (seems the dtc doesn't like names with "-" in it???), and using the file // Two SPI masters for ONC STRAWb /dts-v1/; /plugin/; / { compatible = "amlogic,meson-gxbb"; fragment@0 { target = <&spigpio>; __overlay__ { status = "ok"; } } } but I get a "not found" error message on booting.
martinayotte Posted April 10, 2019 Posted April 10, 2019 2 hours ago, mboehmer said: but fail on the dtbo. It seems that "spi-gpio" is not in the symbol table, so in such case "target" is not working ... But I gave it a try with "target-path" and it worked : /dts-v1/; / { compatible = "amlogic,meson-gxbb"; fragment@0 { target-path = "/spi-gpio"; __overlay__ { status = "disabled"; }; }; };
mboehmer Posted April 10, 2019 Posted April 10, 2019 20 hours ago, martinayotte said: It seems that "spi-gpio" is not in the symbol table, so in such case "target" is not working ... But I gave it a try with "target-path" and it worked : /dts-v1/; / { compatible = "amlogic,meson-gxbb"; fragment@0 { target-path = "/spi-gpio"; __overlay__ { status = "disabled"; }; }; }; A lot to learn I have. More complex simple things are. Will try tomorrow morning! EDIT: confirmed working! Thanks
martinayotte Posted April 16, 2019 Posted April 16, 2019 7 hours ago, mboehmer said: Any news on that subject from expert side? Which news, since you've confirmed that my latest overlay is working ?
mboehmer Posted April 16, 2019 Posted April 16, 2019 Sorry, wrong thread... I was refering to the interference between I2C and GPIO usage. Time for some days off
Recommended Posts