zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
t184256 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has quit [Ping timeout: 246 seconds]
t184256 has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
t184256 has joined #nixos-aarch64
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has joined #nixos-aarch64
<clever>
$ anbox session-manager
<clever>
[ 2019-11-04 12:31:03] [session_manager.cpp:133@operator()] Failed to start as either binder or ashmem kernel drivers are not loaded
orivej has quit [Ping timeout: 268 seconds]
<clever>
virtualisation.anbox.enable ahh
zupo has joined #nixos-aarch64
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 246 seconds]
ryantrinkle has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
ryantrinkle has joined #nixos-aarch64
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
FRidh has joined #nixos-aarch64
vika_nezrimaya has joined #nixos-aarch64
<samueldr>
branching off of a previous discussion
<samueldr>
SPI bus speed... how does it work?
<samueldr>
let's imagine I tried to use a raspberry pi (1, 2, 3 ?) to drive an sd card in spi mode
<clever>
samueldr: the bus master will just toggle the clock line at a given speed, and data is then moved on either the rising or falling edge of the clock
<clever>
samueldr: there are ~3 ways to drive an SD card with an rpi, using either of the onboard mmc controllers (it has 2), or using the spi bus in master mode
<samueldr>
clever: the raspberry pi IS the sd card in my situation
<samueldr>
emulating an SD card on another (black box) device
<clever>
samueldr: ah, then you want to configure the spi device for slave mode
<clever>
and the incoming clock will cause bytes to be shifted into the fifo, from the data pins
<clever>
then you can read things, and react to them
<samueldr>
great
<samueldr>
thinking I could still try and build that first using SPI
<samueldr>
then evaluate the needs for better perfs
<clever>
the specs say it will start at 10khz, which is pretty slow
<clever>
and only if the "sd card" claims to be faser, will the host go faster
<samueldr>
it needs 25mhz for sd card AFAICT
<samueldr>
ah
<clever>
25mhz is just the highest speed that mode can support
<samueldr>
right
<samueldr>
then probably no issues
<samueldr>
tried to find the info about the raspberry pi, but couldn't
<clever>
`The Pi only supports being the SPI master`
<samueldr>
ugh!
<clever>
`The Pi does have a peripheral which is documented to support a SPI slave mode. No one has managed to get it to work`
<clever>
> The Pi has one hardware peripheral which supports I2C/SPI in slave mode. It works in I2C slave mode. It does not work in SPI slave mode (rather no one has managed to get it to work, of course you are welcome to try and may succeed where others have failed.)
<{^_^}>
error: syntax error, unexpected IN, expecting ')', at (string):270:59
<clever>
samueldr: you could have an AVR uC take the role of spi slave, and then buffer some data before sending it to the rpi
<clever>
samueldr: the wiki also briefly mentioned, that the "sd card" can stall and say "im busy, keep waiting"
<clever>
so the avr can just do that, until the rpi has an answer
<samueldr>
yeah :/
<samueldr>
though at that point I can just plug the AVR to my computer
<samueldr>
and forgoe the pi entirely
<samueldr>
the pi was for rapidly prototyping it in a handy all-in-one package
<clever>
main benefit of staying with the pi, is the parallel gpio
<clever>
you could have an 8bit wide bus, between the avr<->rpi
<clever>
so you dont have to use as high of a clock rate
<clever>
-rw-r--r-- 1 clever users 25M Nov 4 19:52 simple.vcd
ryantrinkle has joined #nixos-aarch64
<samueldr>
>> Revision C is the latest revision and is being prepared for mass production. It provides 16 I/O pins with a maximum frequency of approx. 100 MHz
<samueldr>
>> Maximum frequency achievable in practice depends on many factors and will vary greatly with specific interface and applet design. 24 MHz non-DDR can be achieved for most interfaces with minimal effort.
<clever>
[clever@amd-nixos:~/apps/audiorig]$ nix-build '<nixpkgs>' -A gtkwave -o gtkwave
<samueldr>
I think this seals it, glasgow it'll be, once ready