<d1b2>
<Attie> it looks like that ADC is 8-channels to 8x SDO pins, so that's not directly SPI compatible...
<d1b2>
<Attie> if you're okay with only using a single channel, then you can take the spi-controller applet and run with it as it stands, otherwise you'll need to make an oct-SPI type applet
egg|laptop|egg has quit [Remote host closed the connection]
<whitequark>
daveshah: remember we talked about non bonded out ice40 jtag? suppose i could bond it out, is there any specific die i have to look for?
<d1b2>
<daveshah> it is bonded out on some earlier parts
<whitequark>
do you know which?
<d1b2>
<daveshah> you can find the pinout on some early schematics (TRST becomes NC in newer pinouts, the other pins are just regular IO)
<d1b2>
<daveshah> I think all of the larger LP/HX packages
FFY00 has quit [Read error: Connection reset by peer]
FFY00 has joined #glasgow
egg|laptop|egg has joined #glasgow
jstein has joined #glasgow
nicoo has quit [Remote host closed the connection]
nicoo has joined #glasgow
<d1b2>
<bburky> It should be possible to write a Python FUSE driver that makes fake /dev/spidev* and /dev/i2c* devices which map to glasgow i2c/spi right? Possibly as a glasgow script? Use FUSE to translate the linux read/write/ioctl/whatever into the appropriate glasgow interface command.
<d1b2>
<bburky> Would be neat if that actually works. Might allow using standard linux tools with glasgow.
<electronic_eel>
@bburky are you sure that you can create a userspace i2c host driver with FUSE? I'm a bit in doubt if FUSE provides the necessary ioctl and similar for that
<d1b2>
<bburky> But yeah, if there's a native /dev/i2c-pseudo-controller or something that looks much less like a hack.
<d1b2>
<Attie> @bburky - you won't be able to access the nodes as /dev/*, but if you're happy with /path/to/my/mountpoint/i2c or similar, then it hink it should work
<d1b2>
<Attie> but there are likely other / better options, like what electronic_eel linked
<d1b2>
<bburky> Yeah. Though I think you could bind mount it into /dev if your really wanted to. The OS still wouldn't know about it, but it might help convince some command line tools that expect the device to be there.
<d1b2>
<Attie> probably a bad idea to do that, but a symlink might do the job for existing tools
<d1b2>
<bburky> Yes, if the tools respect symlinks that would be better.
<electronic_eel>
@bburky what is your goal in the end? use device drivers that are already in the linux kernel with devices connected to glasgow? or call linux commandline tools that implement some i2c communication themselves and you just want an i2c interface for them?
<d1b2>
<bburky> No specific use case. But it might be a way to reuse existing tools with glasgow. Like for example avrdude supports a linuxspi programmer.
<electronic_eel>
with a commandline tool that implements the protocol itself it may work
<electronic_eel>
(with fuse)
<electronic_eel>
but when you want to use an in-kernel driver then you'll need a host driver that hooks into the respective kernel framework. you can't do that with FUSE
<d1b2>
<bburky> Ah, yeah, you're right. There are a lot of in kernel i2c and spi device drivers I think. You wouldn't be able to use those. You'd need something like the i2c-pseudo-controller you linked that lets the kernel know about the adapter.
FFY00 has quit [Ping timeout: 258 seconds]
<sorear>
> 1500 boards
<modwizcode>
It would be nice to have an actual spi and i2c pseduo driver in the kernel for that situation. I have a hacky module that implements bare minimum but even that was hard since to make a device you need to find a real device reference of some sort to be the parent of the fake module.
bgamari has joined #glasgow
bgamari_ has quit [Ping timeout: 256 seconds]
<d1b2>
<icb> Fewer than 25 boards away from 1000% funded too