<rcn-ee>
other then using v5.10.x-ti they are not any more tested then I tagged teh 2020-04-06 image 2 years ago... https://beagleboard.org/latest-images
<mattb0ne>
having some difficulties with windows 11 arrrgggg
<rcn-ee>
Sorry i tired the above on Buster, pyqt5 has more things that needed to be backported to Buster... Just grab a spare microsd and start fresh with bullseye, and set it up to mirror what your buster image does today..
<mattb0ne>
ok
<mattb0ne>
this sucks
<mattb0ne>
I was fine and someone when and updated a package and broke my whole setup
<mattb0ne>
so I would boot from SD with the bullseye image
<mattb0ne>
then input those commands and it will move the OS from the SD to flash memory?
lucascastro has quit [Ping timeout: 260 seconds]
<rcn-ee>
correct..
<rcn-ee>
after typing that first command, the microSD is now a "auto eMMC flasher" so if you have a bank of BBB"s you can flash them one at a time with the same microSD..
<mattb0ne>
would I restart and hold the button or the first one is already convereted
<mattb0ne>
converted*
<solrize>
if i want to run a cpu intensive dsp operation, is it reasonable to do the analog i/o on the pru's, and the math in the application processor?
Posterdati has joined #beagle
<zmatt>
solrize: what do you mean by "do the analog i/o" ?
mattb0ne has quit [Ping timeout: 250 seconds]
<zmatt>
if you want to process samples from the integrated adc on the cortex-a8 then just using the kernel driver to stream the data probably makes more sense than using pru
<zmatt>
but there are certainly situations where using pru to perform i/o and then streaming that data to the cortex-a8 (e.g. via a ringbuffer) for further processing makes sense
<zmatt>
your description is too vague to really make any kind of judgement on whether it does in your specific situation
<solrize>
zmatt, it's an audio dsp application, 8 khz samples, can i do that with accurate enough timing from linux?
nslu2-log has quit [Quit: Disconnecting from stoned server.]
<zmatt>
solrize: linux isn't responsible for the timing, that depends solely on the adc configuration
<zmatt>
(unless you use the sysfs mechanism to read a just single sample, but you obviously shouldn't)
nslu2-log has joined #beagle
<zmatt>
normally the adc periodically samples the enabled inputs, at a rate that depends on the configuration defined using device tree properties, and the linux driver will stream these to memory using DMA
<solrize>
zmatt, ah ok, i didn't realize that. yeah that would do it
<solrize>
and is there just one adc muxed between those pins?
<zmatt>
not really no, there are pwm outputs but no sigma-delta modulator or something... could be something that could be made with pru probably
<zmatt>
(dac)
<zmatt>
and yes it's a single adc shared between the 8 inputs, i.e. it will sample and convert the enabled inputs sequentially, not simultaneously
<zmatt>
if you want something better you may want to consider interfacing an external audio codec
<zmatt>
but it depends on the application... if you're doing 8 kHz sampling then it doesn't sound like you're aiming for particularly high quality anyway
<solrize>
in order to get slightly higher audio sample rate, and do more modulations
<solrize>
and the general conveniences of programming linux ;)
<zmatt>
ah
<zmatt>
yeah, that doesn't sound like it needs a particularly good audio quality
<solrize>
cool, pocketbeagle is still a nice board despite being kind of old by now thanks
<zmatt>
and for the output you could probably perform the sigma-delta encoding in advance for the various tones you need to generate and have PRU output those directly (and then add an analog low-pass filter)
<solrize>
oh interesting point yeah
<solrize>
or just add a dac... this is not so tiny any more but it is still ok
<solrize>
do you think the adc resolution matters much? i am wondering why the original design uses the pjrc teensy 3 (which has 13 bit adc's but is cpu limited) instead of the teensy 4 (much faster cpu, but 10 bit adc)
<zmatt>
up to 200 kHz sampling (shared across the inputs, so up to 25 kHz when having all 8 inputs enabled)
<zmatt>
am335x is what's on the pocketbeagle and beaglebone
<solrize>
right yeah, 12 bits
<solrize>
don't need 8 inputs but need about 4, two of them slow
<solrize>
well maybe a few more really slow, for stuff like battery monitoring
<zmatt>
that would just make things inconvenient
<solrize>
hmm they would interfere with the audio sampling?
<zmatt>
yes
<solrize>
oh blech. i see
<zmatt>
like, the best you could do is probably run the slow ones at half the sampling rate by using the sampling pattern { 0, 1, 2, 0, 1, 3 } (where 0 and 1 are the fast inputs and 2 and 3 the slow ones)
<solrize>
that sounds ok, or could just use a tiny mcu board for the slow stuff
<zmatt>
assuming the kernel driver tolerates having multiple steps for the same input (the adc is fine with that, dunno the driver)
<zmatt>
or some i2c adc
<solrize>
yeah
<zmatt>
or use a proper external adc for the fast stuff and the integrated one for the misc inputs
<zmatt>
plenty of options
<solrize>
two of the slow channels are to read a touch screen, so an mcu could do that whole thing and just report coordinates
<zmatt>
well the integrated adc is also a resistive touchscreen controller
<solrize>
yeah i guess so, if sampling and dma are how it is usually done
<solrize>
oh interesting
<solrize>
maybe can ditch the touch screen altogether, and use a phone for the UI
<zmatt>
all valid options
<solrize>
i wonder if the whole thing can be done as a phone app, with just the adc/dac external? hmm
<zmatt>
as if your phone doesn't have an audio adc and dac? :D
<solrize>
yeah maybe that suffices
<solrize>
oh right, need the rf stuff
<zmatt>
you can bet that your phone's adc and dac are better than what the pocketbeagle or a teensy has to offer
<solrize>
i'm a good linux programmer but don't know that much about hardware or phone apps
<zmatt>
and definitely more processing power
<solrize>
interesting
<solrize>
just using the 3.5mm headphone jack (which on my phone sucks pretty bad, and which is going extinct on newer phones though)
<solrize>
i guess getting a carefully chosen phone for the purpose is acceptable
<zmatt>
newer phones probably still support analog audio in/out via the usb-c port (via a passive converter) ?
<zmatt>
anyway, lots of ways you could implement this
<solrize>
there are analog pins in usb-c? omg
<solrize>
ok thanks
<solrize>
i'll look into stuff some more
<zmatt>
there's a weird but standardized hack to use the usb-c plug to transform analog audio yeah
<solrize>
they are going to send 240 watts of power and multi-ghz signals through it
<solrize>
and also analog
<rcn-ee>
scarry, i won't trust that signal. ;)
<zmatt>
well, when Audio Adapter Accessory mode is used there's no digital data going over it
<solrize>
ah you mean there are the two traditional signal pins, and these modes change their functions
<solrize>
so no using with a hub
<solrize>
ok
<zmatt>
and charge-through in that mode only supports 5V 500 mA
<rcn-ee>
actually in audio mode, tx/rx's get disabled... so your device only has to worry about 240 watt's thru Vbs/gnd.. so audio might be fine.. at full load..
<rcn-ee>
as long as that load doesn't change...
<zmatt>
2.5 W max
<rcn-ee>
ah, i see that at the bottom.. was thinking about the normal power charging..
<rcn-ee>
thanks!
<zmatt>
the audio accessory grounds both CC pins (which is how the phone recognizes it)
<zmatt>
which prevents charger current detection and PD communication
<solrize>
ok i will read this
<solrize>
yeah jeez, i sort of had the idea of using the phone to power the external stuff.. i thought there was a way to do that with usb-c
<zmatt>
hence no way to go above 5V 0.5A
<zmatt>
sure, but not in audio accessory mode
<solrize>
but 2.5w into the phone sounds like plenty, i hope, to be able to run the thing from external power
<zmatt>
anyway, all this is of course only relevant if you actually want to get into making a phone app
<zmatt>
which is its own set of headaches
<solrize>
yeah :(. i've never done it but it's closer to my clue area than this electronic stuff
<solrize>
ok well i'll think about this some more, i gotta go now before the bank closes. thanks 1e6 again