<Siegurd>
cp: cannot stat '/usr/lib/linux-image-5.10.186-bone76/*.dtbo': No such file or directory
<Siegurd>
root@BeagleBone:/home/debian#
weevoy has joined #beagle
Stat_headcrabed has quit [Quit: Stat_headcrabed]
<dinuxbg>
rcn-ee: Thank you for updating the debian packages for binutils-pru and gcc-pru. Can you please also update gnuprumcu?
starblue has quit [Ping timeout: 246 seconds]
marcheu_ is now known as marcheu
jfsimon1981 has quit [Ping timeout: 246 seconds]
starblue has joined #beagle
jfsimon1981 has joined #beagle
jfsimon1981 has quit [Ping timeout: 244 seconds]
brook has quit [Read error: Connection reset by peer]
<zmatt>
Siegurd: a lot of overhead is just happening in the linux kernel, setting up the spi transfer and such
otisolsen70 has joined #beagle
<zmatt>
Siegurd: pru could definitely bitbang spi faster than 10 MHz, but it could also service the SPI peripheral instead of using the linux kernel driver for that purpose
<zmatt>
Siegurd: btw the SPI peripheral can't actually do 30 MHz, it's either 48 MHz or 24 MHz (or other frequencies made by dividing a 48 MHz clock)
<zmatt>
btw, I've only glanced at the datasheet but wouldn't it make more sense to interface the AD7771's data output interface to a McASP instead of using the SPI interface to read data?
<zmatt>
McASP is made for this kind of thing
<Siegurd>
you mean DOUT0 DOUT1 DOUT2 DOUT3?
<Siegurd>
if so this require 4 SPI slave channels. Can BBB handle that much? If disable HDMA and EMMC?
<zmatt>
I'm not talking about SPI
<Siegurd>
I just never heard about McASP.
<zmatt>
and yes, mcasp0 does have 4 data lines available on the BBB, although you don't even need that: the AD7771's dout interface can be configured to use 4 DOUT lines with 2 channels per line, 2 DOUT lines with 4 channels per line, or even multiplex all 8 channels over a single DOUT line
<zmatt>
it seems it doesn't support dclk higher than 8.192 MHz
<zmatt>
anyway, that's stlil fine, you can use 4 data lines
<ds2>
can the McASP handle the bit ordering the ADI wants with 4 data lines?
<ds2>
wonder if there is a easier to use audio focused chip... they do similar things and may have drivers ready to go
<Siegurd>
I read that beagleboard does have some troubles with SPI slave mode is it true?
<zmatt>
bit-ordering? I don't see anything unusual about bit-ordering?
<zmatt>
iirc mcasp supports both little- and big-endian ordering anyway
<zmatt>
yeah it does
<ds2>
it isn't too bad
<zmatt>
Siegurd: the beaglebone itself doesn't but the linux kernel driver doesn't support SPI slave mode. note again however that this isn't spi and I'm not talking about the spi controller
<zmatt>
so spi slave mode is irrelevant here
<ds2>
McSPI will transfer data in slave mode
Whiskey` has quit [Ping timeout: 245 seconds]
<ds2>
you can throw together a driver in a couple hours....just don't expect to be able to upstream it
Whiskey` has joined #beagle
<zmatt>
yeah if you need spi slave mode you could do that or use pru to manage mcspi, or probably even do something disgusting from userspace. anyway, this is a digression since it's not relevant for using the AD7771
<Siegurd>
You are reading my minds) Thanks for example.
<zmatt>
note: this uses the mcasp tx clk/fs pins because I'm assuming it will be used in rx/tx synchronized mode in which the tx clk/fs pins are used for both tx and rx, which is how mcasp is most commonly used and last I checked the only mode supported by the linux kernel driver (although I do have a dirty patch against kernel 4.14 to enable independent rx/tx mode)
<zmatt>
the mcasp rx clk/fs pins are only neededif you want to use independent clocks for the mcasp's transmit and receive sections
<zmatt>
which effectively turns it into two separate ports, one rx-only and one tx-only
<zmatt>
you don't need the tx-section at all so you certainly don't need that
<Siegurd>
I agree all DOUTx pins are Output
<Siegurd>
setting up AD7771 evaluation board into DOUT mode is not that simple cuz of refractory solder and 0602 zero resistance resistors but I will try to configure it.
<zmatt>
wait, they made an *evaluation* board that makes it hard to evaluate dout mode? was the board designed by an intern or something? :P
GenTooMan has joined #beagle
<zmatt>
you know, I'm not even that surprised, I recall the eval board we had for one of their DSPs also made some terrible design decisions that unnecessarily limited the potential to use it for evaluating certain modes of operation
<Siegurd>
eval board for 120$ is designed for using with motherboard for 250$) If you want to use it in standalone mode - soldering iron comes in)
<zmatt>
-.-
GenTooMan has quit [Excess Flood]
<zmatt>
next problem you'll run into is how to do the relevant DT configuration for linux... I can help with that though I'd also need to take a quick look at my own notes and dts files I've written
GenTooMan has joined #beagle
<zmatt>
(I still want to make a PRU-based driver to bypass ALSA entirely, both to avoid its annoying limitations and to get accurate timestamps.... some day I'll get around to it)
<Siegurd>
thank you so much!
<Siegurd>
accurate timestamps its a pain in..... I used clock_gettime(CLOCK_REALTIME, &time_temp); on Rpi4 to measure 8000 nanoseconds timestamps. It didn't work very well
<zmatt>
yeah, and even timestamps done by the kernel are still horribly jittery
<zmatt>
so we're currently already using PRU for timestamping, but right now I'm timestamping the EDMA event of each transferred audio block, which is already pretty decent but it still has more jitter than necessary
<zmatt>
(I wrote a linux kernel driver for using eCAP as a clock source, so I can use the PRU eCAP as source for linux' raw monotonic time, allowing PRU's snapshots of the PRU eCAP counter to be related to CLOCK_RAW_MONOTONIC timestamps available in linux userspace
<zmatt>
)
<zmatt>
an additional bonus of using eCAP as linux clock source is that it's more accurate than its usual default clock source (which is timer1 running at 24 MHz) and it avoids round-off error in converting timer ticks to nanoseconds. by default, when using the 24 MHz clock source, linux uses a fixed-point approximation of 1000/24 resulting in slow drift of its raw monotonic time relative to hardware clocks ...
<zmatt>
...(i.e. 1 second of raw ...
<zmatt>
... monotonic time isn't 24,000,000 oscillator cycles), which was a problem I ran into when trying to implement network time synchronization using PTP
<Siegurd>
wow
<zmatt>
(we make active speakers that support streaming audio via the network and you need pretty tight synchronization between left and right speaker when doing so to ensure the stereo-image is not adversely affected)
<Siegurd>
today I can no longer solder the kit. I'll be back tomorrow. See ya!
Siegurd has quit [Quit: Client closed]
starblue has quit [Ping timeout: 244 seconds]
<zmatt>
now the big question... do I have a mcasp example in overlay-utils