**** BEGIN LOGGING AT Tue Nov 10 02:59:56 2020 Nov 10 09:14:58 Hello Nov 10 09:16:31 it possible to install an app, say PuTTY, into any development board or Launch pad?:] :] Nov 10 09:17:10 ehm, that seems like a weird question Nov 10 09:18:01 Whats the problem? Nov 10 09:18:17 TI uses the term "launch pad" just for certain eval boards for microcontrollers, which obviously can't run applications that were not developed for that microcontroller (nor would they even fit in memory) Nov 10 09:18:39 on the other hand linux-based boards like those from beagleboard.org (which this channel is for) will run any linux program Nov 10 09:18:50 Okay Nov 10 09:18:57 Thank you Nov 10 09:19:32 though you wouldn't want to on a beaglebone most likely Nov 10 09:19:43 run a GUI program like Putty that is Nov 10 09:20:15 I am searching for TI launchpad integration with PuTTY Nov 10 09:20:28 I have no idea what you could mean by that Nov 10 09:21:14 wait, how did you get here? is there still some web chat that mistakenly directs people into this channel instead of one for TI launchpads? Nov 10 09:21:40 I am a newbie so I have no idea where to ask..=( Nov 10 09:22:03 TI products are supported on their E2E forum (e2e.ti.com) Nov 10 09:22:10 OK Nov 10 09:22:18 thank you Nov 10 09:22:53 -_- Nov 10 09:58:21 Ti! Nov 10 19:11:49 mm302: most pins have either default pull-up or default pull-down (varies per pin), though this is mostly just to keep them from floating. normally you'd drive inputs push-pull (meaning drive it low when you want it low, drive it high when you want it high) hence then the internal pull doesn't matter. Nov 10 19:12:26 although the internal pull can be reconfigured, cape-universal generally doesn't define separate modes for this except for gpio mode Nov 10 19:13:13 so if you want pruin with a different pull direction, your options are to use a custom overlay or to just override the internal pull with a stronger external pull Nov 10 19:15:13 beware that P8.31-46 have external 100K pull-up/down resistors on the BBB itself, hence these cannot be reconfigured Nov 10 19:15:49 for most of them it is also not safe to override this with a stronger external pull resistor, since these pins are sampled at power-up to determine initial boot configuration Nov 10 19:18:11 hi zmatt, thanks for remembering my question Nov 10 19:18:30 see the P8 tab of my pins spreadsheet ( https://goo.gl/Jkcg0w#gid=1847985463 ) for an overview of which pins are critical for boot configuration Nov 10 19:18:48 oh that's why, I was using exactly those pins at the end of P8 because accessible by PRU1 Nov 10 19:19:18 so, be very careful with the ones marked bright yellow in the overview I linked Nov 10 19:19:27 so in the end I only used the pins that are pulled down, because easy for me Nov 10 19:20:34 what are you using them for that only drives them high but not low? (aka open-emitter / open-source) that's quite unusual, generally people use push-pull or open-collector/open-drain (i.e. driven low but not high, requiring a pull-up) Nov 10 19:21:07 I used the ones in yellow, P8_45 (bit 0), P8_46 (bit 1) and then 2 rows higher: P8_39 (bit 6), P8_40 (bit 7) Nov 10 19:22:03 I'm using these 4 to capture what's transmitted on the SPI between BB and ADC Nov 10 19:22:20 uhh, that should all be push-pull communication Nov 10 19:22:30 so internal pull should be irrelevant Nov 10 19:23:44 it's handy to have ground as default, there may be some others pulls by default not sure if it will conflict with those pull down though, I'll figure out hopefully Nov 10 19:24:55 just mske sure you don't connect yellow-marked boot pins to pins that have internal pull in a direction opposite to the boot pin Nov 10 19:25:22 (default internal pull that is) Nov 10 19:26:09 oh can it be a problem if they go up while the BB is booting? Nov 10 19:27:03 I haven't seen any smoke yet, so good sign Nov 10 19:27:09 if you mess with the levels of the yellow-marked pins at the moment of power-up (like within 25ms of the 3.3v going up or something like that iirc) then the BBB will fail to boot Nov 10 19:27:30 (and in a few cases the might be risk to the hardware, not entirely sure) Nov 10 19:27:38 *there might Nov 10 19:28:05 oh, good to know, thanks zmatt Nov 10 19:28:21 so preferably use the non-yellow marked ones Nov 10 19:28:28 I don't see how internal pull is relevant for your application Nov 10 19:28:32 yes Nov 10 19:29:11 it's handy as I'll be able to tell when the state is initially changed by SPI Nov 10 19:30:08 not sure what you mean by that... the internal pull becomes irrelevant the moment the net you're monitoring is driven push-pull, which for PRU outputs will be the moment you configure them to pruout mode Nov 10 19:30:51 while the ADC's outputs might be driven continuously from the moment of power up or only as needed during a data transfer, that should be documented in the datasheet Nov 10 19:31:11 these are PRUINs as I'm using PRU1 to just capture SPI, then I'll start PRU0 to do the communication Nov 10 19:31:14 (if it's actually SPI then it shouldn't drive its output (MISO) if it's not selected) Nov 10 19:31:22 yes I understood that part Nov 10 19:31:31 so with the pruouts I'm talking about pru 0 Nov 10 19:31:59 assuming you're monitoring those too Nov 10 19:32:05 but I'm actually going to try to actually use hardware SPI (using the SPI perhiperal) called from PRU0 Nov 10 19:32:09 ah Nov 10 19:32:35 have you first tested communication with the ADC simply from linux userspace? Nov 10 19:32:43 to avoid having multiple unknown variables at the same time Nov 10 19:33:13 I didn't know I could from userspace Nov 10 19:33:36 ehm, that's how 99% of people use SPI on embedded systems :P Nov 10 19:33:43 I wrote the capture functionality to see those variables hopefully Nov 10 19:34:37 capturing might help debug stuff, but you might still be faced with both your use of McSPI and the ADC itself being unknown factors Nov 10 19:34:56 so I'd personally start with just testing the ADC itself to confirm I'd understand what the communication flow looks like Nov 10 19:35:27 (using some tiny test program in a language of choice, e.g. C++ or python) Nov 10 19:35:51 I saw adafruit gives a nice simple python wrapper for that Nov 10 19:36:57 adafruit is mostly crap, I'd just use some spi library like spidev ("pip3 install spidev" if it's not installed already) directly Nov 10 19:38:22 I think I had a look at it, but then realised all the real logic is hidden in the kernel somewhere so I gave up trying to understand exactly what it does Nov 10 19:39:01 the purpose of that test is not to understand the McSPI peripheral but to verify you understand how to communicate with the ADC itself Nov 10 19:40:48 if you want to understand the McSPI peripheral you can do that from linux userspace too, using py-uio :D you'd use a tiny DT snippet to make the peripheral use the uio_pdrv_genirq driver that lets you map its registers into userspace (and even receive irqs from it) Nov 10 19:41:40 that's from the ADC datasheet, I need to send 1 (start), 1 (single), 000 (for ch0), wait 1.5 cycle, read 0 followed by 10 bits Nov 10 19:42:05 oh that's really weird Nov 10 19:42:41 why? Nov 10 19:42:45 so 17-bit transfer size in total? Nov 10 19:43:09 I send 5 bits and I receive 11 I believe Nov 10 19:43:37 clearly right timing is important Nov 10 19:43:49 well you wait "wait 1.5 cycle", which makes no sense unless you meant transfer 1 dummy bit Nov 10 19:43:51 so hopefully I'll see that with my capture app Nov 10 19:44:03 note that SPI has no "send" or "receive", you always do both at the same time Nov 10 19:44:19 "send" just means you ignore whatever you received Nov 10 19:45:00 there is different timing for reads and writes, following vs rising edge, not exactly sure now, but I'll confirm when I see the data Nov 10 19:46:05 yes both sides update their output on one edge and sample the input on the other edge Nov 10 19:46:11 (which one is which depends on spi mode) Nov 10 19:46:18 that may be some sort of cache on the BB perhiperal, but ADC response is sent a bit after the request Nov 10 19:47:43 exactly, which is why I said 17 bit transfer size: Nov 10 19:47:45 mosi 11ccc------------ (c = channel) Nov 10 19:47:45 miso ------0xxxxxxxxxx (x = data) Nov 10 19:47:57 that's 17 bits Nov 10 19:48:23 which is not a transfer size that's supported, but maybe the ADC is okay with additional dummy cycles Nov 10 19:48:24 right counting the waiting bit, yes Nov 10 19:48:43 there's no "waiting" in SPI, each clock cycle transfers one bit in each direction Nov 10 19:49:17 which adc is this? Nov 10 19:49:26 you can think of - bits as don't care Nov 10 19:49:43 yes I meant to say "- = don't care", I forgot Nov 10 19:51:27 thanks zmatt, I'm going to have dinner, I'm working a bit slowly on this so it may take me a couple of weeks to have the SPI up and running, I'm thinking about using interrupt or a trigger point to better capture just when needed Nov 10 19:51:40 what adc is this? (part number) Nov 10 19:52:19 I'm using a cheap DIP 8 channels: MCP3008 Nov 10 19:52:45 10 bits resultion Nov 10 19:54:30 ok so spi mode 0 Nov 10 19:56:05 or possibly 3 Nov 10 19:58:34 okay and additional clock cycles simply result in zeros Nov 10 19:59:59 and for debugging convenience you probably want a pull-up on MISO Nov 10 20:00:35 anyway, I kinda need to do shopping, have a nice dinner Nov 10 20:04:15 wait what, no, it first transmits the bits in reverse order and *then* zeros o.O Nov 10 20:04:35 how odd Nov 10 20:08:04 ah and it allows padding bits at the start also, that makes things more convenient Nov 10 20:09:05 this still looks like it would probably be easier to bitbang with pru than to use mcspi Nov 10 20:10:01 (also faster) **** ENDING LOGGING AT Wed Nov 11 03:02:41 2020