**** BEGIN LOGGING AT Wed Nov 11 03:02:41 2020 Nov 11 04:34:54 Having trouble connecting my Beaglebone wireless green to wifi, once I connect it I get to the login page and enter my wifi info but it does not do anything after that, I'm using Mac OS. Any suggestions? Nov 12 01:20:20 whats next_idx Nov 12 01:21:30 is that a standard function not getting much from google Nov 12 01:22:06 are you talking about https://github.com/mvduin/py-uio/blob/master/pru-examples/fw-c/stream.cc#L64-L69 ? Nov 12 01:23:11 yeah working on integrating the buffer Nov 12 01:23:16 just trying to understand the pieces Nov 12 01:24:01 note that generally speaking, a completely contextless question like "whats next_idx" is very unlikely to get a useful response from anyone since people can't read your mind to understand wtf you're talking about. even I had to assume you were talking about py-uio and search where that identifier is used Nov 12 01:24:41 (since I do not, generally speaking, remember every identifier used in every piece of code I've written :P ) Nov 12 01:25:16 fair point, I assume it was some standard function since my text editor has it highlighted as such Nov 12 01:25:20 and, I mean, the definition (as highlighted in my link_ seems pretty straightforward... what do you not understand about it? Nov 12 01:25:47 it's not, so I'm guessing you're misunderstanding your text editor's syntax highlighting Nov 12 01:26:11 it is just an iterator right? and oyu are passing it size of the message Nov 12 01:26:24 widx Nov 12 01:26:31 widx is not a size Nov 12 01:26:42 pointer Nov 12 01:26:48 to the start of the next message Nov 12 01:27:33 I sort of get the circular buffer concept with the two pointer with a read and write pointer Nov 12 01:28:09 just looking for it in the code Nov 12 01:28:22 it's the write-pointer of the ring buffer, which points to the next message that will be written. note that although I'm using the words "read-pointer" and "write-pointer" (being fairly common terminology for ringbuffers), they're not actual pointers but indices into the ringbuffer Nov 12 01:28:32 hence the name widx Nov 12 01:29:00 ok now that makes more sense Nov 12 01:29:20 next_idx simply increments an index, taking care to wrap around from the end of the ringbuffer to the beginning Nov 12 01:31:42 why is DDRLayout necessary? If we have the buffer at the start of shared we always know where it is and I do not understand how num_msgs is used Nov 12 01:32:11 note btw, like I mentioned before, although this example aborts if it can't send a message (due to the ringbuffer being full), in your case it probably makes more sense to just not send a message, given that the messages are just data points for the GUI and you'll probably want PRU to keep running even if the GUI is sluggish to process data points Nov 12 01:32:54 ehm, PRU needs both pieces of information in DDRLayout Nov 12 01:33:31 ideally I would just like it to loop and overwrite Nov 12 01:34:51 you could hardcode num_msgs (the size of the ringbuffer) in the PRU program and the python client, but that's just not a great idea especially since the memory region where the buffer is located has configurable size Nov 12 01:36:02 overwriting messages that have not yet been processed is very very hard to get right and would require much more complicated logic on both sides Nov 12 01:36:20 ok nevermind Nov 12 01:36:57 (for very dubious benefit) Nov 12 01:37:02 lol Nov 12 01:37:21 so writing to this buffer will be much faster than my gui can read. Nov 12 01:37:32 depends on how fast you're writing this buffer Nov 12 01:37:43 and how big the buffer is Nov 12 01:38:18 well I am not going to have anything else in shared memory, so I might as well make it pretty large Nov 12 01:39:30 but I think the write will always crash into the read index eventually Nov 12 01:40:01 the GUI can and almost certainly should process these messages in batches, e.g. once every GUI update (triggered by a timer or triggered by vsync if you want the smoothest gui) you read all "messages" (data points) in the buffer at that time Nov 12 01:40:58 to avoid losing any data points, the buffer would need to be big enough to allow that many messages to reside in it Nov 12 01:41:20 i.e. num_msgs >= (pru update rate) / (gui update rate) + 1 Nov 12 01:41:43 I see so rather than one at a time I just clear the entire buffer into a numpy array or something Nov 12 01:42:19 ok I get the c code Nov 12 01:42:23 now staring at the python Nov 12 01:42:39 one question that I have is how do I incorporate my struct in there or does it not matter Nov 12 01:43:03 do I just add to SharedVars Nov 12 01:43:10 and I am good to go? Nov 12 01:43:25 "Message" is the data point you want to communicate Nov 12 01:43:43 the "id" is just an example payload Nov 12 01:43:52 you'd replace that by your actual data Nov 12 01:44:22 ok Nov 12 01:45:20 hmm, I just realized it would be a very good idea to add one more sanity check... let me do that Nov 12 01:46:51 ok Nov 12 01:51:24 pushed Nov 12 01:53:21 so, in your gui the while-loop with sleep would obviously not be there, instead you'd have your gui update function (triggered e.g. by a timer or some sort of vsync signal) Nov 12 01:54:27 which should check if the core is halted (if so, probably dump the error and exit), otherwise process any messages (data points) in the buffer (e.g. copy the values into numpy arrays) and update your graphs or whatever Nov 12 01:54:47 doing a whole bunch of recv_message()s in a loop can absolutely be optimized better Nov 12 02:12:18 ok Nov 12 02:12:42 ah wait I was looking at stream.py, stream-c.py has no recv_message() Nov 12 02:14:40 so it is ok ? Nov 12 02:14:49 i just see the assign statement Nov 12 02:24:04 ? Nov 12 02:24:16 btw I just pushed a small cleanup of stream-c.py Nov 12 02:24:46 (just slightly restructured and nicer error-handling) Nov 12 02:41:01 ok Nov 12 02:41:06 pulling Nov 12 02:41:42 ok, I actually pushed another update: I now maximize the size of the ringbuffer and I increased the rate at which pru fires messages (to just under 20K msgs/s) Nov 12 02:43:04 so even this dumb unoptimized code seems to keep up okay Nov 12 02:43:26 msg size must be the total size of of the structure Nov 12 02:43:41 msg size is sizeof(Message) Nov 12 02:43:45 on both sides Nov 12 02:44:03 just to verify that python's idea of how big that struct is agrees with PRU's idea of how big that struct is Nov 12 02:45:05 (since a disagreement on that point could cause PRU to write outside the shared memory region and clobber something random in memory) Nov 12 02:56:03 so as I add fields to message say I have Id which is u32 and now I put position which is another u32 Nov 12 02:56:15 I would just just do something like 2*u32 Nov 12 02:56:34 uhh, what do you mean? , just add your fields to the Message Nov 12 02:56:47 *to the Message struct in both python and C Nov 12 02:58:22 I am talking about DDRLayout Nov 12 02:58:30 you should have no need to add anything to that Nov 12 02:58:41 ok why is the msg size only a u16 Nov 12 02:58:49 in that struct Nov 12 02:59:17 why not? that allows a message size of up to 65535 bytes, which is almost certainly way larger than needed **** ENDING LOGGING AT Thu Nov 12 02:59:56 2020