**** BEGIN LOGGING AT Mon May 06 02:59:57 2019
May 06 13:57:27 * KotH pokes alan_o with a chocolate stick
May 06 14:41:49 <zmatt> why chocolate?
May 06 15:43:36 <alan_o> hi KotH
May 06 15:46:43 <KotH> alan_o: good morning :)
May 06 15:46:54 <KotH> zmatt: because chocolate!
May 06 15:49:23 <alan_o> zmatt: chocolate is always the answer
May 06 15:50:56 <zmatt> fair
May 06 15:53:19 <mawk> white chocolate I hope
May 06 16:03:31 <zmatt> white chocolate isn't chocolate, it's vanilla grease
May 06 16:04:21 <KotH> white chocolate shouldnt contain vanilla
May 06 16:04:26 <KotH> unless it's vanilla white chocolate
May 06 16:04:41 <KotH> but it should definitely be swiss ;)
May 06 16:08:30 <zmatt> okay, then it's sweetened grease I guess :P
May 06 16:08:39 <zmatt> ;)
May 06 16:10:19 <KotH> *g*
May 06 16:10:43 <bob_> what is the spi clk pin standard frequency
May 06 16:11:08 <KotH> bob_: 0.001 kilomegacycles
May 06 16:11:37 <bob_> thanks
May 06 16:13:13 <zmatt> does it have a "standard" frequency? typically frequency is configured by the userspace client
May 06 16:14:05 <zmatt> I think hardware and DT only specify a max frequency, not a "standard" frequency
May 06 16:18:00 <bob_> Oh i see so i just set it in my python code?
May 06 16:18:11 <zmatt> the hardware limit is 48 MHz.  the default overlays (both BB-SPIDEV* and universal) however impose a limit of 16 MHz for some reason
May 06 16:18:46 <zmatt> yeah
May 06 16:21:33 <bob_> gotcha thanks
May 06 16:22:15 <bob_> im new to the spi library and im trying to read a 10 bit adc would i use readbytes for this or one of the xfer functions?
May 06 16:23:23 <zmatt> that's not a question anyone can answer, the protocol required by the adc should be documented in its datasheet
May 06 16:24:10 <zmatt> note that readbytes/writebytes are just simplified versions of xfer
May 06 16:26:13 <zmatt> an spi data transfer always simultaneously writes and reads data (the same number of bits in both directions).  "write" just means the data that was read is discarded, while "read" means dummy data is written (e.g. all-zeros)
May 06 16:30:56 <bob_> ah i see thank you and the number of bits read and written in the transfer is set by bpw(bits per word) or is that wrong?
May 06 16:35:20 <zmatt> yes no sorta not really?
May 06 16:36:49 <zmatt> I should have said "the same number of words in both directions" ... but obviously the number of bits per word is also the same for both directions, so ultimately the same number of bits is transferred in total
May 06 16:37:18 <zmatt> in most cases you'll just want to use 8 bits per "word"
May 06 16:40:04 <zmatt> using 16 (or 32) bits per word is essentially equivalent to transferring in a multiple of 2 (or 4) bytes, and endian-swapping the data in both directions
May 06 16:41:31 <zmatt> using 4-7 bits is like 8 bits but with the most significant bit(s) unused, similarly using 9-15 bits (or 17-31) bits is like using 16 (or 32) bits but with the most significant bit(s) unused
May 06 16:41:52 <zmatt> such formats are rarely needed
May 06 16:49:24 <bob_> ok i see thanks a lot!
May 06 16:50:49 <zmatt> (when I say bits "unused" I mean unused in the data representation in memory.  they are not transferred at all on the spi bus)
May 06 17:00:14 <KotH> zmatt: 16MHz is probably to make sure that stuff works even if the software guy is stupid
May 06 17:00:45 <KotH> zmatt: i know way too many parts that start acting up way before they reach their spec'ed transfer rate
May 06 17:01:48 <zmatt> sure, but plenty of parts have a limit that's lower than 16 MHz, so limiting the clock speed to that isn't that great a solution
May 06 17:02:39 <KotH> probably someone had only seen 16MHz parts when he came up with that .dts
**** ENDING LOGGING AT Tue May 07 02:59:57 2019