this page.. finally opened the door to using my BME280 sensor. ( hope yet true, realized not yet .. desires move to enjoy other things again )
[my picture]
the problem is (entirely) partly lack of documentation, but also just failure to understand what it is that I wanted. (i know exactly what i want.. i can't see why this is so f'ing hard) I think in part I have always avoided drivers. (but now see that I understand them completely because they are just circuits that you talk to like the temp sensor. . but the vague reference terms required and lack of documentation is a bit infuriating) They always seemed to technical for me. Now I realize I have already written a driver.. sorta, the hard way.. but using the tools I had, I implemented almost every part of the process that constitutes a driver. (but playing with the actual frequencies that control data transmission.. i have seen the charts but i2c protocols handles that translation) I could have done it in any language, but I am certainly most comfortable in TCL. but. who else actual gets to use it?
if I can make this into a driver, I can use and .. any one else.. and that would be fun. and
it would consume less resources.
and hopefully, maybe I can encourage, write, a little something somewhere about how to do this that others get see. First, I will make it work... (maybe next time.. in the episode of BME280)
this has become a great way to document the process and retrieve information later. And it also leads to clearer thinking about the solution .. or so I feel . (yes, I still appreciate this very much, and posting it for my record and your enjoyment / interest i hope)
the key came from here : https://gnats.netbsd.org/56438 (and it still may hold the key.. but I found some other drivers I'd like to look at .. and the pi2 is still running netBSD .. but the sensor is on the PI3 now because it works.
peace, namaste (the divine in me honors the divine in you)
In /etc/rc.conf, use modules=YES and gpio=YES
In /etc/modules.conf include:
gpiosim
gpioiic
In /etc/gpio.conf put the following:
gpio0 attach gpioiic 5 0x03 0x0
Change gpio0 to whatever gpiosim attaches to.
I was already doing much of this, but the modules.. I was not. the last line there convinced me to remove gpiosim, as it was something they where testing.
gpio0 attach gpioiic 5 0x03 0x0
this line was similiar to what I had created to connect my device, but I knew I wanted it to be something else, and actually wonder if I can find I way to tell this person they appear not to be correct.. and he was grounding out is connection or simply making it fail because .. well it is was odd... but once you get it makes sense
the 5 0x03 .. is how you identify your pin positions
5 is the offset.. so you move to pin position 5... and then the mask comes telling your which pins to select.
the offset is 5..
in binary this is
00000011
this means to select pin 1 .. pin 2 .. skip 3 .. skip 4 .. skip 5 .. skip 6 .. etc .. but when include the offset ..
this means to select pin 5 .. pin 6 .. skip 3 .. skip 4 .. skip 5 .. skip 6 .. etc ..
unless his device is different than mine.. pin 6 is ground..
BME280 -
SDA - pin 3
SCL - pin 5
this is using the built in i2c bus of the pi I believe. otherwise I think it can be simulated, maybe that is what he is doing... anyway..
the correct command for me was
gpio0 attach gpioiic 3 0x05 0x0
5 in binary is 101 .. the last 1 is first. and it means yes, take pin 3 .. skip 4. take pin 5
took me a minute to figure this out, up it is clear.
Here is my current config, that I believe is working to bring the BME280 up and attaching it to an iic3 bus, with
gpioiic0 at gpio0: SDA[3] push-pull tri-state pull-up, SCL[5] push-pull
iic3 at gpioiic0: I2C bus
In /etc/rc.conf, use modules=YES and gpio=YES
In /etc/modules.conf include:
gpioiic
In /etc/gpio.conf put the following:
gpio0 attach gpioiic 3 0x05 0x0
So at this point I have a working device ( i think) on /dev/iic3
I have also found a file that uses a /dev/iic .. https://gist.github.com/cr1901/76af0b3db9e9001a8d5b
[my picture]
and i have a pi3 with a 7 inch screen attached. I want to use this with the above. it must also work with netBSD.
so I am running between them working on them. and basically find that getting this driver to work ..
is probably not in the near future.
I am not sure if it is the driver structure is overly complicated because of the
good reason -> netBSD tries to be machine agnostic, so the protocols are inherently vague accommodate all the machines it can run on
bad reason -> over complicated
the reason I do complain a bit is that I have worked with these temp sensors for a number of years. but always used tools like
i2c
to read them them.. then I used TCL and a program called PIIO ..
my temp sensor is an I2C or IIC .. this should mean .. I DON'T WANT TO DEAL WITH THE INNER PROTOCOLS
yet somehow. somehow.. as i am investigating the code .. and i hope i am wrong..
they are asking me to set things like the speed at which my thing is gonna answer?
protocols? iic? why do i not have to set this in linux? seems to work there, no effort
so If I can figure out what I am missing that is apparently obvious to everyone or clouded intentionally, maybe
i dunno..
not many drivers on netBSD to handle little projects like mine.. yet it is a great hobby OS with incredible potential for usability
useradd -u 8118 -G wheel -m marc
passwd marc
-- ssh in from remote using newly created user. user already added to wheel, and -m created a home directory. -u set user id to my id to keep things tidy.
export PKG_PATH="https://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/$(uname -p)/$(uname -r|cut -d_ -f1)/All"
this is a fancy way of having the path name dynamically created based upon the system run
uname -p = earmv7hf
uname -r|cut -d_ -f1 = 9.2
so for this particular port.. this is works
export PKG_PATH="https://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/earmv7hf/9.2/All"
pkg_add pkgin
pkgin update
i discovered I was using the stable kernel, which is fine, but that means all the binaries are out of date ;( so I was going to do this anyway, might as well just get everything from pkgsrc.
getting the pkgsrc directory
The current directory contains files related to the HEAD branch of the CVS repository. In this directory there is an additional file called pkgsrc-readmes.tar.{bz,gz,xz} that contains all pkgsrc READMEs with information about categories and packages.
The stable directory is a symlink to the latest pkgsrc-20xxQy.
The pkgsrc-20xxQy. directories contain files related to the -20xxQy stable branch of the CVS repository. In these directories there is an additional file called pkgsrc-20xxQy.tar.{bz,gz,xz}, which contains the state of pkgsrc when it was branched.
ftp ftp://ftp.NetBSD.org/pub/pkgsrc/pkgsrc-2021Q4/pkgsrc.tar.gz
or dynamic form that fetches the current pkgsrc
ftp ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz
tar -xzf pkgsrc.tar.gz -C /usr
looked at top and discovered 'biowait' was holding tar up.
translation: the sd card is slow .
wait time is over 2+ hours
obtaining sources:
ftp -i ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-9.2/source/sets/
$ for file in *.tgz
do
tar -xzf $file -C /
done
thermalPi$ cd /usr/pkgsrc/misc/tmux/
how to install modular xorg
/etc/mk.conf
X11_TYPE=modular
cd /usr/pkgsrc/meta-pkgs/modular-xorg
make install -- building yourself takes hours. it was done before I woke up, i didn't time it properly.
but then.. the piuserland.. which I LITERALLY CAME TO netBSD on PI for ..
wouldn't compile
so i tried to pkgin piuserland
only to have it fail, because the xorg stuff I install conflicts with the userland stuff that it needs.. the pkgin binaries are always behind, but I thought I setup the (STABLE) .. things are different on the ARM .. they don't get the CPU to update constantly. be nice if it did. because the incredible amount of ridiculousness i just went thru .. lol
whatever.. it did work.
xfce4 is not ready on netBSD for ARM .. the video driver didn't look very good either for the 7inch screen. acceptable.. but barely and in the end.. no.
after tons of effort to see it work in the netBSD and freeBSD land.. I will return to using piOS.. which is a fine alternative since you can grab one using Debian.
yes, i think Debian is the best linux. biggest user base.
there are some fun alternatives, but none as complete and robust as Debian, debian developers and users are very good. appreciate them very much.
and with that I can start playing in TCL again. I am sure I will return and hammer this out .. it is never as hard as it appears..
the last of my work on that computer. openbox is nice, having obmenu is better, but it has fallen behind and python ditches you because staying constant isn't what they do.
someone rewrote it and it apparently works.. but i can't remember now .. perhaps I had already decided the driver was done and I was ready to play again.
startx
for obmenu --
pkgin install git
pkgin install gobject-introspection
git https://github.com/0x10/obmenu2
cd obmenu2