alunduil has quit [Read error: Connection reset by peer]
alunduil has joined #nixos-aarch64
pkral has joined #nixos-aarch64
jackdk_ has quit [Remote host closed the connection]
ryantrinkle has quit [Ping timeout: 240 seconds]
c00w has joined #nixos-aarch64
NekomimiScience has quit [Ping timeout: 252 seconds]
jackdk has quit [Ping timeout: 272 seconds]
angerman has quit [Ping timeout: 252 seconds]
c00w has quit [Ping timeout: 265 seconds]
elvishjerricco has quit [Ping timeout: 260 seconds]
alunduil has quit [Ping timeout: 272 seconds]
cstrahan____ has quit [Ping timeout: 272 seconds]
davidtwco has quit [Ping timeout: 260 seconds]
pkral has quit [Ping timeout: 272 seconds]
chessai has quit [Ping timeout: 272 seconds]
lirzhv has quit [Ping timeout: 260 seconds]
rajivr___ has quit [Ping timeout: 260 seconds]
feepo has quit [Ping timeout: 260 seconds]
lovesegfault has quit [Quit: WeeChat 2.7]
davidtwco has joined #nixos-aarch64
davidtwco has quit [Ping timeout: 245 seconds]
chessai has joined #nixos-aarch64
pkral has joined #nixos-aarch64
cstrahan____ has joined #nixos-aarch64
chessai has quit [Ping timeout: 272 seconds]
pkral has quit [Ping timeout: 260 seconds]
cstrahan____ has quit [Ping timeout: 260 seconds]
h0m1 has quit [Ping timeout: 245 seconds]
h0m1 has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
cap_sensitive has joined #nixos-aarch64
<cap_sensitive>
Hi. I'm trying to enable the w1-gpio-pullup module on a rpi4 with linux_rpi4 and rpi foundation's bootloader. I'm trying to integrate this pull request into my /etc/nixos config: https://github.com/NixOS/nixpkgs/pull/67989
<{^_^}>
#67989 (by kwohlfahrt, 19 weeks ago, open): nixos/hardware.deviceTree: Allow use of dtmerge
<cap_sensitive>
When I do nixos-rebuild switch, I got the following error: error: syntax error, unexpected $undefined, at /nix/store/wsfcfqcjfgsnndjhv5pd5rw6bvsr2hpq-linux-4.19.75-1.20190925/dtbs/overlays/w1-gpio-pullup.dtbo:1:1
<clever>
nixos is expecting a list of modules in overlays
<clever>
and if it encounters a file when it wanted a module, it import's that file
<clever>
hence, the error about it parsing dtbo as nix
<cap_sensitive>
It builds!
<cap_sensitive>
clever: And the w1-gpio module works! THANK you so much
<clever>
cap_sensitive: last time i messed with one-wire on the rpi (before device-tree support was added), it had trouble driving things over an reasonable cable length
<cap_sensitive>
I spend the whole night looking for alternatives (found a w1-gpio-cl module that requires manual configuration but it works), but this solution is so nice
<clever>
an AVR running at 5v can drive long cables with zero trouble
orivej has quit [Ping timeout: 268 seconds]
<cap_sensitive>
clever: I'm planning to use long-wires (O(1m)). Currently I'm using the 3.3V power. If I switch to the on-board 5V, I should have no trouble running the long wires?
<clever>
the rpi can only output 3.3v on the gpio lines
<cap_sensitive>
But physical pin 2 is a 5 V output?
<clever>
the gpio pins will be damaged if you apply 5v to them
<clever>
and the problem i had, was how fast the one-wire data line returns to high
<cap_sensitive>
OK. Then I have a problem
<clever>
changing the pull-up resistor may help
<cap_sensitive>
Noted
<clever>
i didnt measure things with a scope to confirm things when i had issues
<cap_sensitive>
Yeah we have plenty scopes. We'll measure it if we have problems
<clever>
i remember the datasheets being pretty clear on the required rise times
<clever>
should be easy to whack a smaller pullup in, to fix things
<cap_sensitive>
clever: Thanks!
<clever>
though, fall-times might become an issue if its too strong
<clever>
i think each gpio is limited to 16mA
<clever>
and depending on the capacitance of the entire cable length, you may not be able to suck energy out of it fast enough to pull it low
<clever>
so the rpi wouldnt be able to receive anything from the one-wire network
<DigitalKiwi>
You can also use it to connect 5V logic out to 3V logic in, that's when you want to power the 74AHCT125 with 3V, it can safely read 5V logic on the input pins.
<DigitalKiwi>
is that what you want
<clever>
but one-wire is doing both directions on a single pin
<clever>
so you need something that understands one-wire, and can change the direction on the fly
<makefu>
i never had any issues with directly connecting 3.3v output of an esp8266 to a 5v logic of an ws2812
<clever>
makefu: some 5v chips are designed to accept a 3.3v signal as high still
<clever>
makefu: and some chips that run at 3.3v can accept 5v on their inputs (avr can, rpi will smoke)
<makefu>
yep totally right, that is the power of hardware electronics stuff. it may work even if out of spec
<makefu>
just wanted to say that i never used a level shifter for attaching an uC to led stripes :)
<DigitalKiwi>
if it doesn't need it that'd save a few dollars
<cap_sensitive>
So what's the schematic for this? 5V -> converter -> thermistors -> 1 wire to pi?
<makefu>
the cool thing with the ws2812b is that only the first LED will see the out-of-spec output level of the uC. after that the level will be 5v again
<cap_sensitive>
And somehow the converter knows 1-wire and won't smoke the pi?
* DigitalKiwi
is not good with the leccy
<DigitalKiwi>
that chip did help me find a bug in kicad though lol
<DigitalKiwi>
searching for dip 14 almost guaranteed a segfault
<DigitalKiwi>
makefu: if the first chip is a few feet away from the pi will that be a problem
<DigitalKiwi>
like...5 feet
<makefu>
DigitalKiwi: that is definitly the case. i had issues like that and what i did was essentially adding a 'step-up' led right next to the esp
<DigitalKiwi>
now in the middle of 36+2 agdaboi i had to make some sparkling nixos/haskell and they were out (only had done the background) and got glitter on everything ;_;
<DigitalKiwi>
the wood is for my nixos lambdas so this is ontopic
<DigitalKiwi>
that have a raspberry pi so double ontopic
<thefloweringash>
cpus seems to cap out at 16, probably due to `
<thefloweringash>
didn't do any builds, going to head off for the night, but things look pretty positive
<samueldr>
amazing
<gchristensen>
oh cool
<gchristensen>
I was just going to check in about if it was a good time to provision that server
<samueldr>
I'm thinking it would be okay if the VMs are limited, and that we just run more of them on one host
<samueldr>
not sure if there's a drawback to that though
<sphalerite>
ah, nice! I hope builds work, last time I tried there were some… issues
<sphalerite>
you'll very probably need to enable haveged in the VM or add a virtio random source via qemu (not sure of the exact details of how to do that), otherwise you'll get some very odd-looking hangs as things wait for entropy
<gchristensen>
samueldr: can you tell me what makes you think that would be the right way (many small VMs)? to clarify -- I'm not saying I disagree in an underhanded way
<samueldr>
not really sure, but I was thinking about if there are limitations we can't easily work through
<samueldr>
like the number of CPUs
<gchristensen>
ah, cool
<samueldr>
though IIRC the number of CPUs can be fixed
pbb has quit [Ping timeout: 272 seconds]
pbb has joined #nixos-aarch64
pbb_ has joined #nixos-aarch64
pbb has quit [Ping timeout: 272 seconds]
orivej has joined #nixos-aarch64
t184256 has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
t184256 has joined #nixos-aarch64
orivej has quit [Ping timeout: 268 seconds]
mDuff has quit [Ping timeout: 268 seconds]
lovesegfault has joined #nixos-aarch64
<samueldr>
I took a peek at the build-vm-script, it needs native build, I guess we're a step removed from working
* samueldr
tries with nixpkgs.crossSystem set
lovesegfault has quit [Ping timeout: 258 seconds]
<samueldr>
things are weird, will report back after the build
<samueldr>
though cross-compiling doesn't start on aarch64, while it starts on x86_64
<samueldr>
oops
<samueldr>
I was building the qemu for armv7l, and not the system, while the system was still wanting to build native
<samueldr>
(now fixed, I think)
<clever>
samueldr: my hydra is also building armv7 now, on an rpi4 with a 32bit kernel