**** BEGIN LOGGING AT Tue Oct 27 02:59:57 2020
**** BEGIN LOGGING AT Tue Oct 27 06:45:16 2020
**** BEGIN LOGGING AT Tue Oct 27 06:48:07 2020
Oct 27 16:51:39 <vedant16[m]> Does the pmic inside BBB, have the ability to turn off the ldo's on demand, say to turn off power to the connected peripheral
Oct 27 16:52:11 <vedant16[m]> This is the data sheet of that pmic
Oct 27 16:52:24 * vedant16[m] posted a file: tps65217.pdf (2065KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/lHeEYRkuuVaDaqapHmzESGuh/tps65217.pdf >
Oct 27 16:58:46 <Ragnorok> I expect if it's got a setting in I2C one could do that, but I don't know what effect it would have on other bits.  I thought the Black was using all the LDOs already?
Oct 27 16:59:38 <vedant16[m]> I don't want to use this in black, rather in a different circuit, but I can use this circuit for reference and maybe the driver too
Oct 27 17:00:06 <vedant16[m]> * I don't want to use this in black, rather in a different circuit, So I want to use this circuit for reference and maybe the driver too
Oct 27 17:00:13 <Ragnorok> I probably can't do much for you then.  I'm not well versed on power management.  There it is.
Oct 27 17:00:27 <vedant16[m]> Couldn't find a well supported and documented pmic
Oct 27 17:05:17 <Konsgnx> you can look through the pmic drivers. just see if you can access it through userspace.
Oct 27 17:06:23 <Konsgnx> the tps62517 is actually broken up into 3 seperate sections, power/regulator(or supply cant remember), video/bl, and system power button..in gpio i think
Oct 27 17:06:23 <zmatt> vedant16[m]: the LDOs can be individually disable/enabled and their voltage adjusted within a certain range
Oct 27 17:07:17 <zmatt> vedant16[m]: however I'm not clear what your purpose is here... ths tps65217 is fairly specifically designed for the am335x and not very flexible
Oct 27 17:07:52 <zmatt> for example there's no way to change the default settings of the LDOs and DCDCs nor the startup sequence
Oct 27 17:08:52 <vedant16[m]> <zmatt "vedant16: however I'm not clear "> I want to use this in a dev board I am making for the esp32.
Oct 27 17:09:01 <vedant16[m]> <Konsgnx "the tps62517 is actually broken "> Ohk..
Oct 27 17:09:02 <zmatt> why this specific pmic?
Oct 27 17:09:30 <vedant16[m]> zmatt I need lipo charging, and 3 ldo with 3.3V output
Oct 27 17:09:34 <Konsgnx> ? broken?
Oct 27 17:09:48 <Konsgnx> why 3 ldo?
Oct 27 17:09:58 <vedant16[m]> <zmatt "why this specific pmic?"> Because It's documented in the beagleboard and there's a driver
Oct 27 17:10:16 <Konsgnx> esp doesn't take drivers....
Oct 27 17:10:21 <zmatt> vedant16[m]: note that you can't reliably produce 3.3V from a LiPo due to voltage drop
Oct 27 17:10:29 <zmatt> how is a linux driver useful for an esp32 ?
Oct 27 17:10:35 <Konsgnx> you would need to re-write a lot of code to get it to work
Oct 27 17:10:48 <vedant16[m]> <Konsgnx "why 3 ldo?"> the dev board has a oled, rtc and sensor, I want to turn off power to those on demand
Oct 27 17:11:14 <Konsgnx> zmatt.... what are you talking about? 3.3v from a 4.2v battery is fine to make in 99% of use cases.
Oct 27 17:11:15 <zmatt> also the charger in the tps65217 kinda sucks... it has almost no useful status information, like battery voltage or rate of charge
Oct 27 17:11:25 <vedant16[m]> <Konsgnx "esp doesn't take drivers...."> ik, I can port it.
Oct 27 17:11:50 <Konsgnx> vedant16, why not use the standby functions of the individual devices?
Oct 27 17:11:59 <vedant16[m]> <zmatt "how is a linux driver useful for"> i2c part still remains same, am I right? I just need to replace those i2c calls with esp api
Oct 27 17:12:10 <zmatt> Konsgnx: a LiPo isn't "4.2V", it drops to 3.6V when still like 80% full
Oct 27 17:12:23 <vedant16[m]> <Konsgnx "you would need to re-write a lot"> better than writing from scratch?
Oct 27 17:12:39 <zmatt> I guess it you have sufficiently low dropout
Oct 27 17:12:59 <zmatt> vedant16[m]: nah, studying the driver would be more work than just reading the register docs in the datasheet
Oct 27 17:13:00 <Konsgnx> zmatt: https://electronics.stackexchange.com/questions/32321/lipoly-battery-when-to-stop-draining
Oct 27 17:13:37 <vedant16[m]> <Konsgnx "vedant16, why not use the standb"> I am not sure there's a sleep mode in those devices.
Oct 27 17:13:58 <zmatt> Konsgnx: maybe I worded it too strongly, it will depend on the LDOs and how much current you draw
Oct 27 17:14:16 <vedant16[m]> <zmatt "also the charger in the tps65217"> Ohk, but can you suggest one which works
Oct 27 17:14:30 <zmatt> vedant16[m]: why not just use 3 gpios connected to enable-pins of discrete LDOs ?
Oct 27 17:14:57 <zmatt> ehh, TI has lots of LiPo chargers with a wide variety of specs, and I'm sure other companies do too
Oct 27 17:15:00 <Konsgnx> yea, i'm with zmatt on effort of re-writing the driver. I would say use a single 3.3v ldo/buck and perhaps p-mosfets if you really need to cut off power. but check the standby currents first.
Oct 27 17:15:38 <zmatt> TI also has simple PMICs with multiple outputs and individual enables
Oct 27 17:15:53 <Konsgnx> rtc's and oleds tend to have really low quiescent currents
Oct 27 17:16:09 <zmatt> yeah gating power to an RTC sounds like nonsense
Oct 27 17:16:47 <Ragnorok> I have fiddled with a TI lipo charger, and we did the GPIO thing for our power domains.  Just seemed simpler, but then we have a Black, not a custom Soc circuit.
Oct 27 17:17:09 <Konsgnx> just make sure you're not running pixelflut in standby and just make the screen go black
Oct 27 17:17:18 <vedant16[m]> <zmatt "vedant16: why not just use 3 gpi"> But how do i take care of lipo charging. and also to make sure that when usb is connected, it will charge the battery and power esp32 from usb.
Oct 27 17:17:38 <vedant16[m]> Currently I use MOSFETs to control the peripherals
Oct 27 17:17:56 <Konsgnx> check sparkfun ref designs... it's sounding like you can just have a permanent always-on charge.
Oct 27 17:17:58 <Ragnorok> The lipo charger chip does all that charge/input switch/blah blah.
Oct 27 17:18:37 <Konsgnx> tps or any other pmic is 89% likely to be more effort to implement than gains you get from it.
Oct 27 17:18:47 <vedant16[m]> <zmatt "yeah gating power to an RTC soun"> Ohk, I'll consider this 😅. Can I send the schematics for verification, this is my first time.
Oct 27 17:18:57 <zmatt> vedant16[m]: I dug into chargers semi-recently, I can look up some part numbers... though of course it's possible your needs are completely different from mine
Oct 27 17:19:17 <vedant16[m]> <Konsgnx "yea, i'm with zmatt on effort of"> Yes I use mosfets
Oct 27 17:19:17 <zmatt> but they might not be, our application is a low power consumption wireless device
Oct 27 17:19:19 <Konsgnx> woa... emoji on irc.... mind blown
Oct 27 17:19:22 <zmatt> with usb charging
Oct 27 17:20:17 <Ragnorok> Konsgnx: There goes the neighborhood.
Oct 27 17:20:29 <Konsgnx> haha sounds like an esp application too. btw, esp's have really nice low power deepsleeps, but they can be hard to get out of sleep..
Oct 27 17:21:07 <zmatt> iirc we evaluated the esp but it had too high power consumption (though I didn't do that evaluation myself so I don't know if the conclusion was correct)
Oct 27 17:21:34 <vedant16[m]> <zmatt "but they might not be, our appli"> Kinda matches my usage
Oct 27 17:21:41 <Konsgnx> as in the regurgitate data/ check pins and so on. took me a bunch of perfboard to get the sleep draw below 5uA with a pushbutton wake trigger
Oct 27 17:21:57 <Ragnorok> I went w/ TI for the design b/c they have easy online tools to help with getting it all done.
Oct 27 17:22:01 <zmatt> anyway, for the lowest quiescent current you could look at the bq21061 linear charger (max 500 mA charging)
Oct 27 17:22:42 <zmatt> though we ended up selecting the bq25619 instead
Oct 27 17:22:55 <Konsgnx> zmatt, i would recomment taking a look again. the esp can connect to wifi in under 2 seconds if you have static ip set, and can draw negligible power with a small ram data section being kept.
Oct 27 17:23:13 <vedant16[m]> <Konsgnx "tps or any other pmic is 89% lik"> Ohkk, I'll look into this, the spark fun ones you suggested
Oct 27 17:23:48 <Konsgnx> I got "estimated" 1year+ with a hall sensor running permanently off a cr123A battery
Oct 27 17:24:26 <vedant16[m]> <Konsgnx "haha sounds like an esp applicat"> TI CCxxx series perform far better
Oct 27 17:25:30 <zmatt> Konsgnx: so, with the uC we're currently developing with I can connect to wifi in 20-30 ms if your access point doesn't suck, and I've managed to get sleep current (no wifi connection) down to 25 uA
Oct 27 17:25:37 <Konsgnx> vehant16: here's a good reference point: https://cdn.sparkfun.com/assets/8/6/4/2/0/XBEE3_Thing_Plus_Schematic.pdf
Oct 27 17:26:43 <zmatt> Konsgnx: or, powering off the wifi chip reduced the measured current to 10 uA but added iirc 100-200 ms additional time to reconnect to wifi
Oct 27 17:28:04 <Konsgnx> zmatt, let me clarify that I have never tried to get sub 2 sec connections as  the 6 seconds for a dhcp connection worked for us. we did have something less than 10uA static draw while sleeping and waking with a 6 second connect period came out to >1year runtime for our device.
Oct 27 17:28:05 <zmatt> this is with the cpu merely in sleep, I haven't experimented with hibernate yet
Oct 27 17:28:06 <vedant16[m]> zmatt Konsgnx Can I DM you the schematics, if you have time please take a look
Oct 27 17:28:54 <Konsgnx> zmatt, one more note, this was the esp8266, I'm sure the 32 has much better performance.
Oct 27 17:29:26 <vedant16[m]> <Konsgnx "vehant16: here's a good referenc"> this is nice, thanks
Oct 27 17:29:29 <zmatt> Konsgnx: it doesn't really matter at this point anyway, we've got significant time invested in the choice we made
Oct 27 17:29:56 <Konsgnx> but it sounds like you have it working acceptably zmatt.
Oct 27 17:29:58 <zmatt> in retrospect I would have preferred a device with more resources/community available
Oct 27 17:30:03 <Konsgnx> hahah
Oct 27 17:30:18 <zmatt> but I didn't pick the device originally
Oct 27 17:30:56 <Konsgnx> my feelings regarding going down the wl1837 path.... but no other popular 5ghz capable device.
Oct 27 17:31:33 <zmatt> Konsgnx: though I do like that it's a Cortex-M4F processor instead of the esp32's weirdass xtensa
Oct 27 17:32:26 <Konsgnx> haha, yea, that is nice.... but does it mimic netflix?
Oct 27 17:32:33 <zmatt> ??
Oct 27 17:32:35 <vedant16[m]> zmatt Why can't i dm you?
Oct 27 17:32:49 <Konsgnx> https://hackaday.com/2020/08/11/espflix-brings-streaming-video-to-the-world-of-microcontrollers/
Oct 27 17:33:17 <zmatt> vedant16[m]: please don't send unsolicited private messages regardless of whether you can
Oct 27 17:33:32 <vedant16[m]> <Konsgnx "https://hackaday.com/2020/08/11/"> I tried this, it stutters a lot
Oct 27 17:33:53 <zmatt> you really don't need to keep quoting people, it's annoying
Oct 27 17:33:54 <vedant16[m]> <zmatt "vedant16: please don't send unso"> I don't want to put the schematics on public channel. Just wanted to send that
Oct 27 17:35:00 <zmatt> vedant16[m]: I'm not hugely interested in looking at a schematic right now, and even less so if it's not public
Oct 27 17:35:10 <mru> my policy is, if you want free help, everything is done in public
Oct 27 17:35:43 <vedant16[m]> right. okay here's the schematics
Oct 27 17:36:06 <mru> that wasn't necessarily an offer of free help
Oct 27 17:36:06 <vedant16[m]> https://drive.google.com/file/d/1uI2dMT_TfqTAjuD3P5GYZpuZywWFunpU/view?usp=drivesdk
Oct 27 17:36:43 <vedant16[m]> mru: I can pay for consultation 😅😂
Oct 27 17:37:04 <mru> I doubt you're willing to pay market rate
Oct 27 17:37:27 <Konsgnx> ... what is market rate?
Oct 27 17:39:35 <vedant16[m]> anyways thanks for the help konsgnx and zmatt, I'll try to make changes on your inputs
Oct 27 17:39:59 <vedant16[m]> * anyways thanks for the help konsgnx and zmatt, I'll try to make changes based on your inputs
Oct 27 17:49:50 <kremlin> m
Oct 27 18:04:01 <Ragnorok> w
Oct 27 18:31:02 <Konsgnx> has anyone worked with the neon core in the beagleblack?
Oct 27 18:34:56 <mru> many have
Oct 27 18:37:34 <Ragnorok> Not directly.  I presume the code I compile works with it somehow.  lol
Oct 27 18:39:08 <zmatt> Konsgnx: I've neon-optimized code yeah
Oct 27 18:39:21 <zmatt> Ragnorok: it might, but rarely will
Oct 27 18:39:46 <Ragnorok> zmatt: I thought that after I hit enter; it's not likely the compiler is "just doing that".
Oct 27 18:40:05 <zmatt> though gcc sometimes uses it for 64-bit arithmetic, which is actually almost certainly a bad thing on the cortex-a8
Oct 27 18:40:58 <zmatt> single-precision floats will use neon with suitable compiler flags (e.g. -ffast-math though less severe flags suffice)
Oct 27 18:41:07 <Konsgnx> What does it do exactly? from what I am seeing, it can apply the same operation to 128 32-bit words at a time... is that a safe assumption?
Oct 27 18:41:18 <zmatt> Konsgnx: what? no
Oct 27 18:41:39 <zmatt> its widest operations are 128-bit
Oct 27 18:42:22 <Konsgnx> ya, 32 -128bit in the cache right?
Oct 27 18:42:23 <zmatt> e.g. int32x4_t or float32x4_t
Oct 27 18:42:34 <zmatt> you seem to be talking about how many registers it has maybe?
Oct 27 18:43:01 <zmatt> though I'm not sure it has that many
Oct 27 18:43:05 <Konsgnx> hmm maybe, i saw that and thought, i can process an array of 128 32-bit registers
Oct 27 18:43:13 <mru> 16 128-bit registers
Oct 27 18:43:14 <zmatt> no
Oct 27 18:43:28 <zmatt> yeah iirc it was either 16 or 32 128-bit registers
Oct 27 18:44:04 <Konsgnx> poop, 32x64 bit
Oct 27 18:44:30 <mru> yes, dual-view register file
Oct 27 18:45:27 <zmatt> ah yeah 16 128-bit registers / 32 64-bit registers (depending on view)
Oct 27 18:45:27 <Konsgnx> sooo. how would that relate to vector operations... does it help with thatL
Oct 27 18:45:31 <Konsgnx> ?
Oct 27 18:45:46 <zmatt> "help with that" ?  it's a vector math unit
Oct 27 18:46:13 <zmatt> it's its entire purpose
Oct 27 18:47:07 <Konsgnx> gotcha, so the same operation affects them all... could i view it as 64- 32bit registers?
Oct 27 18:47:34 <zmatt> in what sense?
Oct 27 18:48:06 <zmatt> like, there are operations that act on a single (8/16/32-bit) vector element
Oct 27 18:48:29 <Konsgnx> so say x by 3. can i have that affect 64 -32bit elements?
Oct 27 18:48:35 <Konsgnx> x being multiply
Oct 27 18:49:05 <zmatt> like I said the maximum vector size is 128-bit, e.g. int32x4_t
Oct 27 18:49:34 <mru> zmatt: no single-element ops in armv7
Oct 27 18:49:36 <zmatt> of course nothing is stopping you from making larger vectors out of those
Oct 27 18:49:55 <zmatt> mru: vdup, load/store single lane
Oct 27 18:50:10 <mru> right, but no arithmetic
Oct 27 18:50:24 <zmatt> I didn't say arithmetic :P
Oct 27 18:50:41 <zmatt> but yeah, I meant a limited few operations
Oct 27 18:51:23 <zmatt> of course you can just use a single element of a vector
Oct 27 18:51:41 <zmatt> and ignore the other element(s)
Oct 27 18:51:42 <mru> wastes power
Oct 27 18:51:44 <zmatt> which can be useful at times
Oct 27 18:51:55 <mru> but useful
Oct 27 18:52:41 <zmatt> neon has ops that the scalar pipeline doesn't, and moving data from neon to the scalar pipeline has high latency
Oct 27 18:56:57 <zmatt> Konsgnx: maybe an example will help, hold don...
Oct 27 18:57:26 <Konsgnx> i found this guy:https://www.element14.com/community/community/designcenter/single-board-computers/next-genbeaglebone/blog/2013/06/01/bbb-neon-and-making-tintin-bigger
Oct 27 19:01:00 <zmatt> Konsgnx: adapted from some real-world code: https://pastebin.com/hUDtrt6J
Oct 27 19:01:29 <zmatt> stereo fir-filter, both a neon-optimized version (using intrinsics) and plain C++ version
Oct 27 19:02:21 <zmatt> mru: hah, lol, no arithmetic ops?  vmlal_lane_s32
Oct 27 19:02:48 <zmatt> multiply vector by single element
Oct 27 19:02:54 <zmatt> (multiply-add)
Oct 27 19:02:59 <mru> affects a full vector
Oct 27 19:03:06 <zmatt> but uses single element as one operator
Oct 27 19:03:08 <zmatt> operand
Oct 27 19:03:29 <zmatt> I guess it all depends on the scope you use, but yeah use of single elements is limited but it's there
Oct 27 19:03:30 <mru> yes, there are vector-scalar ops
Oct 27 19:03:53 <zmatt> and of course for 64-bit integers the minimum vector size is 1 element anyway
Oct 27 19:05:12 <zmatt> Konsgnx: note that one loop iteration of the neon version corresponds to two loop iterations of the non-neon version
Oct 27 19:05:38 <zmatt> because it loads two coefficients into 'c'
Oct 27 19:07:41 <zmatt> I'm not sure why I used vld1q_s32() instead of just writing   int32x4_t x = vin[i];   ... I think I ended up doing that because gcc sucks and produced crap code if I didn't
Oct 27 19:09:43 <zmatt> in theory using neon intrinsics in C/C++ helps to avoid having to write optimized assembly code... in practice the compiler can be so fickle that tweaking your code to make the compiler not do stupid shit can be more effort than just writing the performance-critical loops in assembly :P
Oct 27 19:10:43 <mru> especially if you're using all the registers
Oct 27 19:10:57 <zmatt> I'm using only a handful of registers
Oct 27 19:11:18 <zmatt> I'm not talking about having trouble register-allocating or whatever, I'm talking about _really_ dumb stuff
Oct 27 19:11:35 <mru> I've seen it all
Oct 27 19:18:37 <zmatt> here's a great example I ran into: https://pastebin.com/SnQ7prVS
Oct 27 19:19:00 <zmatt> where the code output is greatly improved by deliberately sabotaging the "optimizer"
Oct 27 19:20:37 <zmatt> perhaps there are ARM cpus where the first code output is faster than the second, but the cortex-a8 definitely ain't one of 'em (and I have -mcpu=cortex-a8)
Oct 27 19:27:27 <mru> and still not optimal
Oct 27 19:28:23 <zmatt> probably hard to optimize further without additional assumptions
Oct 27 19:29:26 <zmatt> though this test case was mostly just intended to demonstrate gcc inexplicably breaking up nice, maximally aligned, full 128-bit vector loads into smaller separate ones
Oct 27 19:30:23 <mru> the loop can be made twice as fast for even n
Oct 27 19:30:37 <zmatt> not without a non-aliasing assumptions on the input and output pointers
Oct 27 19:31:13 <mru> that can be tested
Oct 27 19:32:55 <mru> and if the overall design is half-way sane, you'll know whether they can alias
Oct 27 19:33:08 <mru> if all the way sane, you'll know that they don't
Oct 27 19:33:20 <zmatt> of course, but in this case the compiler isn't allowed to assume that
Oct 27 19:33:46 <mru> true, but it can easily compare the pointers
Oct 27 19:34:01 <mru> if they differ by enough, unrolling the loop is safe
Oct 27 19:34:06 <zmatt> and again, this wasn't about getting optimal code output, it was an attempt to make a simple-as-possible testcase to demonstrate this particular pathological code output
Oct 27 19:34:56 <zmatt> I'm also not 100 sure whether unrolling this loop would make it faster on the cortex-a8
Oct 27 19:35:07 <zmatt> *100%
Oct 27 19:35:17 <mru> it would
Oct 27 19:35:28 <mru> about 2x
Oct 27 19:35:29 <Konsgnx> alright, you guys are definitely talking above my head, but what im hearing is that 20-bit sine waves can be generated at a rate faster than 10Mhz
Oct 27 19:35:36 <zmatt> mru: what makes you think that?
Oct 27 19:35:40 <Konsgnx> Thanks for all the fish!
Oct 27 19:35:49 <mru> instruction latencies
Oct 27 19:35:58 <mru> and years of experience optimising things like that
Oct 27 19:36:47 <zmatt> wouldn't you want software pipelining rather than unrolling?
Oct 27 19:37:06 <mru> unroll and interleave
Oct 27 19:37:15 <zmatt> (though that might require unrolling in this case I suppose)
Oct 27 19:39:02 <zmatt> the behaviour of neon loads on the a8 is one part where I haven't yet been able to achieve a useful mental model... I've definitely had cases where unrolling and software pipelining to attempt to hide load latencies had no or negative effect
Oct 27 19:39:50 <Konsgnx> I will say that it is annoying to find simple answers to "most efficient sine generation"... I know, lot's of architectures.
Oct 27 19:40:09 <zmatt> which kinda makes sense since the a8 is strictly in-order
Oct 27 19:40:44 <Konsgnx> current plan: taylor series expantion with help from neon to run against multiple angles at once.
Oct 27 19:42:32 <zmatt> mru: so increasing load-use distance has no obvious reason to be effective, since the load still needs to complete before the next instruction does regardless of whether that instruction depends on the load
Oct 27 19:43:45 <zmatt> Konsgnx: I'm guessing you need to adjust the frequency on the fly?
Oct 27 19:43:54 <Konsgnx> yup
Oct 27 19:44:06 <mru> zmatt: uh, no
Oct 27 19:44:25 <mru> loads are pipelined
Oct 27 19:44:52 <Konsgnx> would love to gen via pru, but i dont think i can do it there fast enough.
Oct 27 19:44:53 <mru> and neon loads on a8 are extra special
Oct 27 19:45:08 <zmatt> mru: I'm reasonably familiar with the a8 pipeline, I've read the paper
Oct 27 19:45:31 <mru> I've read the design specs
Oct 27 19:46:02 <mru> and also tested it extensively
Oct 27 19:47:21 <mru> either way, you have latency in the vadd as well
Oct 27 19:47:33 <zmatt> so what's wrong with my argument?  it still has to issue *and* retire the instructions in program order, so if the load stalls no instruction after it can retire
Oct 27 19:47:48 <zmatt> yeah fair, this looks is definitely unreasonably packed
Oct 27 19:47:52 <zmatt> *this loop
Oct 27 19:48:20 <mru> you need one instruction between the vadd and vst
Oct 27 19:50:31 <zmatt> I don't think that even suffices? I think the earlier the vst can issue is the 3rd cycle after the vadd
Oct 27 19:50:37 <zmatt> *earliest
Oct 27 20:22:09 <Ragnorok> I used a lookup table on the PRU to generate sine waves, but my resolution requirements where not strict.
Oct 27 20:23:13 <mm302> Ragnorok: how do you output that with a DAC?
Oct 27 20:23:47 <Ragnorok> I don't.  I needed PWM sine waves in digital form to simulate ADC input that wasn't yet available.
Oct 27 20:26:33 <mm302> talking about ADC, I strugglged finding any example on the web. adfruit/python and other examples seem to use ioctl and underlying kernel to deal with SPI, I found a couple of PRU examples that use SPI but they do software communication, not hardware so not using the BB spi0 perhiperal, pity there isn't much documentation on that
Oct 27 20:33:01 <Konsgnx> what unit of width is a lane in the neon core?
Oct 27 20:33:24 <Konsgnx> is the lane the 128bit reg?
Oct 27 21:04:47 <ds2> no docs??? what specific ADC docs is needed?
Oct 27 21:05:02 <ds2> SPI is as simple as you can get with a serial interface
Oct 27 21:23:16 <zmatt> mm302: you want to use the spi peripheral from pru?  iirc it's not a particularly hard peripheral to set up
Oct 27 21:25:02 <zmatt> as usual, make sure to use a DT overlay to ensure the kernel driver doesn't load (status = "disabled";) to avoid fighting over the peripheral but the peripheral is enabled anyway (ti,no-idle;)
Oct 27 21:26:44 <zmatt> to get to know the peripheral and experiment with it, it may be more convenient to first just map the peripheral into linux userspace rather than going straight for using it from pru (which is harder to debug)
Oct 27 22:30:38 <mm302> sorry I was in the kitchen, it seems an hard perhiperals there are a lot of options and right timing is very important, I see the main register is CH0CONF. but the python/device driver way is so much easier
Oct 27 22:31:11 <mm302> zmatt: looks like programming this directly requires an oscilloscope
Oct 27 22:31:26 <zmatt> how so?
Oct 27 22:32:22 <mm302> to see what happens/timing on the 4 lines
Oct 27 22:33:39 <zmatt> I mean, what happens on the 4 lines is an spi transfer :P
Oct 27 22:34:07 <zmatt> I also have some signal diagrams here: https://liktaanjeneus.nl/mcspi.h.html
Oct 27 22:35:45 <ds2> it may help to read some of the original SPI docs from Motorola
Oct 27 22:36:11 <zmatt> I'd imagine the McSPI chapter in the TRM is more useful
Oct 27 22:36:19 <mm302> it's just without measuring the pins output it's a quite a lot of guesswork
Oct 27 22:36:26 <ds2> the McSPI chapter overcomplicates things
Oct 27 22:36:57 <mm302> yes
Oct 27 22:36:59 <ds2> of the 4 wires, 1 is chip select. it is very straight forward. Line goes low when you want to do a xfer. SOme chips don't care about it
Oct 27 22:37:06 <ds2> then you have 3
Oct 27 22:37:34 <ds2> 1 is clock. you can either use the rising or the falling edge of it to indicate data is valid
Oct 27 22:37:35 <mm302> yes, I connected 5 wires, I haven't started the coding yet
Oct 27 22:37:40 <ds2> 5 wires?
Oct 27 22:38:13 <ds2> CS, MISO, MOSI, CLK...what's your 5th?
Oct 27 22:38:13 <mm302> 1 for analog input measure
Oct 27 22:38:28 <ds2> ah... for SPI purposes, lets ignore that
Oct 27 22:38:57 <ds2> the 3 wires are the 3 connections to a shift register (clock is clock), MISO and MOSI are the 2 ends
Oct 27 22:39:10 <mm302> true, I see on the ADC datasheet a lag between the data is sent an the data is received
Oct 27 22:39:25 <ds2> mm302: lag as in 8 bits of the clock?
Oct 27 22:39:50 <mm302> looks about 2 clocks looking at the diagarm
Oct 27 22:40:16 <ds2> all SPI is doing is filling and reading from that shift register. there is one on the McSPI and one on your device. data flows out of the beagle's MOSI and into the device's SIMO and the reverse for MISO and SOMI
Oct 27 22:40:31 <ds2> got a picture of it or link to the URL?
Oct 27 22:41:04 <mm302> yes, I'm aware of it, I'm just unsure about all the hardware registers I need to set
Oct 27 22:41:39 <ds2> the McSPI makes things complex as it tries to do optimizations like having a queue, interrupts, clock generators, etc
Oct 27 22:41:47 <zmatt> it sounds like you're not particularly familiar with spi or this adc, in which case I'd certainly recommend getting it working using linux spidev first
Oct 27 22:41:48 <ds2> if you are on the PRU, just bit bang it
Oct 27 22:42:04 <mm302> looking at the TRM, but I'll try over time, I was thinking about using the second PRU to capture those 4 pins so I can confirm if something is sent
Oct 27 22:42:40 <ds2> just do the xfer on the PRU... make your life simple. no need to be tied to the McSPI
Oct 27 22:43:13 <mm302> I was thinking about that, that's so much simpler, because I would determine the 4 pins state
Oct 27 22:43:31 <mm302> McSPI is overcomplicated I agree
Oct 27 22:44:10 <mm302> would be nice if TI added some perhipercals examples on top of the TRM
Oct 27 22:45:26 <zmatt> bitbanging using pru is certainly simpler, but has the downside of heavily occupying a core
Oct 27 22:45:40 <zmatt> but if you don't have something else for the core to do during the transfer, that probably doesn't matter
Oct 27 22:48:25 <mm302> I think I'll try more with the mcspi first in my spare time, if I fail I'll switch to using a PRU for that
Oct 27 22:49:23 <zmatt> if you haven't already done so, I'd suggest first getting the adc working from linux userspace, or if you want to work on getting mcspi working test initially with a loopback connection (mosi -> miso)
Oct 27 22:49:32 <zmatt> instead of testing with two major unknown factors
Oct 27 22:49:33 <mm302> if I capture n samples with 4 channels, do you know some linux software to plot it?
Oct 27 22:49:56 <zmatt> that sounds like a super vague question
Oct 27 22:50:44 <zmatt> I'm sure there are plenty of plotting libraries with various capabilities and output formats
Oct 27 22:50:47 <zmatt> e.g. gnuplot
Oct 27 22:51:27 <mm302> yes, I could use openoffice too, ok
Oct 27 22:53:56 <mm302> this is an example of nice diagram, what I had in mind: http://www.pctestinstruments.com/logicport/interpreters.htm
Oct 27 22:54:51 <mm302> handy to see the samples, but not essential
Oct 27 22:57:26 <ds2> gnuplot
Oct 27 22:57:41 <mm302> thanks ds2 and zmatt, bed time for me
Oct 27 22:57:54 <ds2> McSPI is nice if you have a lot to xfer and want to be notified when it is done
**** ENDING LOGGING AT Wed Oct 28 02:59:57 2020