**** BEGIN LOGGING AT Sun Jun 28 02:59:58 2020 Jun 28 03:03:31 yeah i mean Srikanth it's hard to help someone who doesn't pose a specific problem Jun 29 00:11:59 zmatt: does _function mean I should not call it from outside its class Jun 29 00:12:46 I guess I am confuesed as to how I actually use it Jun 29 00:13:17 underscore prefix means you shouldn't use it unless you really know what you're doing I guess Jun 29 00:13:36 ok Jun 29 00:13:42 how do I send bytes Jun 29 00:13:42 I added an .io method in the latest commit Jun 29 00:15:34 you can give it data to send and/or how many bytes to receive, and it will return once the data has been sent and at least that many bytes have been received, or when an error occurs Jun 29 00:16:22 it's a bit primitive, but should be adequate Jun 29 00:19:13 is the io method on the main branch Jun 29 00:19:15 i pulled Jun 29 00:19:16 (the reason for combining the two is both to avoid receive fifo overrun while waiting to transmit data, and because there's not really any way to check on transmission status without implicitly clearing the overrun flag if an overrun happened, so I needed to ensure I can report if this happens) Jun 29 00:19:21 yes it is Jun 29 00:19:42 bottom of src/uio/ti/icss/uart.py Jun 29 00:20:28 see it Jun 29 00:28:25 hmm just realized my overrun handling is still flawed... not that it matters hugely, you'll want to avoid overruns entirely anyhow Jun 29 00:29:01 you mean exceeding the capcity of the FIFO Jun 29 00:29:02 ? Jun 29 00:29:14 yeah, so received data is lost Jun 29 00:35:53 so unpacking what I get back from the io Jun 29 00:35:53 https://pastebin.com/2MqBaaWh Jun 29 00:36:12 it looks like a tuple Jun 29 00:36:21 when I read it but I am not getting back all 3 letters Jun 29 00:36:38 (3, bytearray(b'HR'), 0) Jun 29 00:37:02 i cannot get that last letter Jun 29 00:37:11 even though I i request 3 bytes Jun 29 00:38:02 no, you sent b'HRY' while discarding any data received, and then you sent whatever bytes(3) is but didn't set any minimum number of bytes to receive Jun 29 00:38:23 it seems bytes(3) is b'\x00\x00\x00' Jun 29 00:39:24 ok now I got it Jun 29 00:39:39 wait I think Jun 29 00:39:40 keep in mind that you can always receive more data than you asked for Jun 29 00:40:02 and with this overflow issue Jun 29 00:40:37 ? Jun 29 00:40:48 there is a command that will have the digitizer spit out the current reading non stop. If I have that going through the UART Jun 29 00:41:08 it will overflow but do I care I would just miss out on some of the values Jun 29 00:41:21 or will it blow up the the program if you overrun Jun 29 00:41:22 right, that's what you'll probably want to use with PRU so it doesn't have to sent any commands, and it wouldn't have any trouble receiving the data Jun 29 00:41:34 ok Jun 29 00:41:50 and I just have it loop to read constantly Jun 29 00:42:16 I mean, it will only overrun if you don't handle it fast enough... though to be honest at 9600 baud it's not like you can receive data very quickly anyway Jun 29 00:43:28 it would take about 17 ms to fill up the fifo and cause an overrun Jun 29 00:45:37 well loop back testing is complete first a little dinner than we hook up the loadcells Jun 29 00:45:46 the blocking flag you have in the io Jun 29 00:45:51 what is that for ? Jun 29 00:46:18 it means it'll wait (until send_data has been sent and at least recv_bytes have been received) Jun 29 00:46:31 otherwise it'll do what it can and then return instead of waiting Jun 29 00:47:08 ok cool Jun 29 00:47:24 this is really neat. I guess i will not see the real impact until i crank up the baudrate. Jun 29 00:47:40 but at least interactively it seems fully functional for my needs Jun 29 00:48:16 in the end this is mostly meant to perform initialization on pru's behalf anyway Jun 29 00:48:33 for which the fifos should be adequate to prevent overrun regardless of baudrate Jun 29 00:49:43 right Jun 29 00:50:15 eventually I need to make the control loop for the PRU which will be polling data coming through on the UART Jun 29 00:50:37 i have all the components ready now just need to pull them together Jun 29 00:50:38 well you won't need to poll, just use the send-continuously thing Jun 29 00:51:20 i guess by poll i meant use the data coming in to change PWM settings and stuff Jun 29 00:52:08 I still need to work through how that all will work conceptually Jun 29 00:54:15 but basically one PRU will be doing the decode. and the other will have to clear the FIFO, change the eCAP and write values to shared memory for the OS **** ENDING LOGGING AT Mon Jun 29 02:59:57 2020