**** BEGIN LOGGING AT Tue May 12 03:00:16 2020 May 12 03:13:24 probably learning new things about what a term means is good huh? May 12 03:14:48 Yep. Not just product placement! May 12 03:15:07 Actual vocab. can do the body good. May 12 03:15:45 I was looking for pots. I never purchased one before today. Seriously. May 12 03:16:00 So, I got a couple for using it w/ the BELA. May 12 03:16:06 potentiometers you mean? May 12 03:16:15 Yes. May 12 03:16:20 are you using them for control or positioning? May 12 03:16:43 control, I guess. I am not sure yet. I do not want to position anything yet. May 12 03:17:09 Give me a couple of "run downs," please. May 12 03:17:24 Control is for ______ while position is for ________? May 12 03:17:54 Ok well for positioning you have to use a different type of pot because they wear. Trim pots are used for being set once in a blue moon. Standard pots are used for things like voltage volume control etc. May 12 03:18:17 I got some standard 10K ohm ones. May 12 03:18:40 I also got a sliding one that was 10K ohm too. May 12 03:19:19 we for audio you want to use logarithmic taper and linear taper for most other things May 12 03:19:53 Oh. I saw on their page a photo of one. logarithmic was not listed. I hope they tell me exactly what type to get. May 12 03:20:01 I probably bought the wrong type. May 12 03:20:35 GenTooMan: I was going to type up an entire ensemble of ideas for you to review. But! May 12 03:20:37 they may call it audio taper or something like that. however you are just making linear adjustments not changing volume. May 12 03:21:17 Oh. May 12 03:21:26 Okay. May 12 03:21:39 audio taper is only needed if you want sound to seem linear when you adjust it because your hearing is logarithmic. May 12 03:22:07 I am new to DSP and sound in general. May 12 03:22:36 I think they are actually using the am335x for a general purpose chip for sound arch. May 12 03:22:55 I do not know if they have the DSP onboard the BELA at all. May 12 03:22:59 I am just not sure. May 12 03:23:29 I remember reading they had amplifiers or I heard that on their YouTube video. May 12 03:24:33 zmatt had some discussion with me regarding doing that. As I was thinking about 8 audio inputs and routing of data. If you want to look at amplifiers go to TI's audio amp selection some of those you can directly hook to an I2S type output (IE the output that feeds the HDMI framer on the BBB) May 12 03:25:32 hmm? May 12 03:26:32 Doing a Cape? May 12 03:26:42 Or doin' a Cape? May 12 03:26:45 Ha. May 12 03:27:27 no processing multiple audio channels with the AM335x and how much processing time might be left over for other things. May 12 03:27:38 Oh. May 12 03:27:51 GenTooMan: no idea what you mean by that May 12 03:28:10 zmatt I think FFT discussion was involved too May 12 03:28:32 YOu guys. Are you hiding something again? May 12 03:28:51 and no there's no DSP on the bela cape May 12 03:29:01 I know. I just read again. May 12 03:29:09 So, they are using the am335x. May 12 03:29:19 General Purpose! May 12 03:29:25 It works. May 12 03:29:36 But, they use some odd Xenomia image. May 12 03:29:53 I didn't do it! May 12 03:29:57 It is supposed to make their ideas of relevant priority. May 12 03:30:24 So, instead of multiple processes running in parallel... May 12 03:30:41 They run in order of priority due to the image. May 12 03:30:44 GenTooMan: oh I misread what you said I guess, you meant I had a discussion about signal processing on the am335x, and the rest of your sentence was unrelated May 12 03:31:20 "I go first, no you go first." May 12 03:31:39 set_: xenomia allows for real-time processing yeah, more so than linux-rt May 12 03:32:21 That is what I understand. But, real-time means what exactly? You know it can mean as soon as the button is pressed but their is latency. May 12 03:32:22 Still! May 12 03:32:27 the reason for that is achieving very low latency May 12 03:32:57 Right. Low, key word. It is not easy. I am not saying what they have done is not an achievement. May 12 03:32:58 it is. May 12 03:33:08 It is an achievement. May 12 03:33:58 I guess that is why they used C++ instead of Python. May 12 03:35:12 I mean, they'll have lots of reasons to use C++ instead of python... primarily performance but also that using python in combination with xenomai would be challenging :P May 12 03:35:27 The dang site just kicked me. May 12 03:35:43 mothblur_ <<< set_ May 12 03:35:49 Dang it. May 12 03:37:03 xenomai...I remember that this imaging was a big deal years ago. Now, I rarely hear of it. May 12 03:39:24 now, I can see that I, set_, was kicked. How can I see my own demise? May 12 03:40:26 well, I think real-time linux is adequate for many applications and way more convenient than xenomai, even though xenomai still offers better latency guarantees May 12 03:49:09 mothblur_ why not use hexchat for windows from your PC May 12 03:49:47 What is that? May 12 03:50:11 IRC client so you won't get kicked off from a web client? May 12 03:50:38 set_: if you're authenticated to your own nickname you can get rid of your old connection with /msg nickserv ghost set_ (which will disconnect the old connection that's using the name "set_" so you can then change your name tp set_) May 12 03:51:33 Okay. May 12 03:52:16 To the both of you, okay. May 12 03:52:24 I will work on it. May 12 03:55:03 What are you two doing up so late? May 12 03:55:33 I just woke up May 12 03:55:35 Your moms are going to beat you senseless! Happy Mothers Day! May 12 03:56:01 Day late and a dollar short! May 12 03:56:20 @zmatt: You just woke up. Dang. May 12 03:57:56 @zmatt and GenTooMan: I am dealing w/ the BELA forums. I must have made a mistake w/ the Xenomai image. May 12 03:58:09 that sounds likely May 12 03:58:17 (you making a mistake) May 12 03:58:25 I cannot get libraries/AudioFile/AudioFile.h to register on my board. May 12 03:58:40 I have this file that needs programming. But! May 12 03:58:52 Oh and yes, I know. I made/make mistakes. May 12 03:59:01 I know nothing about bela but I feel confident it's just you May 12 03:59:11 It is most likely me. May 12 03:59:17 You are right. Calm down. May 12 03:59:33 No pointing fingers! May 12 03:59:53 Anyway, like I was saying... May 12 04:00:33 BELA. it works but then the update did not go as planned. May 12 04:00:48 I received errors. That is all. May 12 04:01:32 ... May 12 04:01:50 Instead of picking and placing the .h files, I am just going to see if someone over there knows exactly what has happened on my end. May 12 04:03:26 I am on lecture1 and trying to make things work. I probably have the incorrect image or something. May 12 07:16:23 Is there a cross toolchain for the BBB? May 12 07:17:16 Not just kernel, but applications? May 12 08:53:38 my kernel does in pru_rproc.c at pru_rproc_vring_interrupt() , does both rproc_vq_interrupt() .. kick both RX and TX Vrings... May 12 09:03:41 alright, the linaro arm-linux-gnueabihf toolchain seems to work May 12 09:04:20 at least for my trivial needs May 12 09:45:30 thinkfat_: yeah it's a good toolchain build in my experience... I've had linux kernel misbuilds with some versions of debian's arm-linux-gnueabihf toolchain in the past and using the linaro one solved that May 12 09:46:37 rob_w: the comment above it explains why it kicks both rings May 12 09:47:54 rob_w: looks like it can either use a pru interrupt or a mailbox? May 12 09:56:21 zmatt: true May 12 09:56:41 yes either the irq or mb .. but i am looking at the irq path May 12 09:57:07 using a single irq seems fine May 12 09:57:28 *single event May 12 09:57:52 does that mean that a single irq is used to irq both sides of the vring ? May 12 09:58:28 a single pru event is used for both types of wakeup sent from pru to arm May 12 09:58:41 and linux will figure out which of the two it was May 12 09:59:18 it's not "both sides of the vring", it's "the linux side of both vrings" May 12 10:01:09 for the tx vring it means "I've processed your message and put the buffer in the return-queue for you to reuse", for the rx vring it means "I've filled the buffer you provided with a message and put it in the return queue for you to process" May 12 10:02:11 ("I" here being pru) May 12 10:03:15 in the former case , do you think the arm-to-pru irq gets fired .. ( feels like to me) May 12 10:04:30 the arm-to-pru irq will get fired 1. for the tx ring, when arm has filled a buffer with a message and queued it for processing by pru 2. for the rx queue when arm has provided a buffer for pru to fill with a message May 12 10:04:46 *for the rx vring May 12 10:06:13 but if you want to see whether linux is kicking the vring (and why), just enable dynamic debug messages May 12 10:06:44 i am . .thats why im actually in there May 12 10:07:21 can you pastebin the log you're getting? May 12 10:08:08 since i ve hardly any debug method from pru ( beside scope on my adc line on the pru) .. and it seems that i do recieve a arm-to-pru irc on pru after the fact that the arm processed ... which seems tobe theat former case you described May 12 10:09:24 if you send a message to arm via the rx vring then it should get kicked shortly thereafter yes (once linux has received the message and requeued the buffer for reuse) May 12 10:09:55 ok so thats whats happeninng May 12 10:09:57 unless the packet is marked as "do not notify" May 12 10:10:17 hmm ok ? May 12 10:12:29 oh hmm my notes say it's a flag on the queue, not on the packet? odd May 12 10:13:47 my point is this so the arm-to-pru is fired after the arm put pack the last recieve queue ... which is basicly what i want but for a different reason May 12 10:13:52 pff, it's been a whlie since I looked at my notes on rpmsg... christ it's so excessively complicated May 12 10:14:25 rob_w: it's fired so pru knows when a buffer is available for it to use May 12 10:14:34 without polling May 12 10:15:16 but my rpmsg side on pru is polling it think ? .. or looking for a avail buffer May 12 10:16:04 normall the pru sees the arm irq and rpmsg_recieve() or not .. May 12 10:16:53 I don't remember much about the pru side of rpmsg, other than that I looked at the code and observed that it had undefined behaviour and could easily get miscompiled if the compiler were actually a decently optimizing compiler (which it isn't, "fortunately") May 12 10:17:35 and that it looked slow and complicated :) May 12 10:19:10 yeah ,, well its hwat i ve right now ... so nevermind thx May 12 10:19:51 but it's mostly complicated in the details due to the levels of indirection, the basic idea is pretty straightforward May 12 10:19:55 i only need rpmsg for my setup now , then i only want the right irqs fired and dma`s ready filled May 12 10:20:39 so i am trying to hack my way into it from a rpmsg point of view but then only direclty fire and trigger forwared in my dma areas May 12 10:20:56 I mean, the irqs are just to kick you alive if you're sleeping... I think usually there won't be much reason for pru to do anything with the irq sent to it by arm May 12 10:21:08 the pru->arm irq is really the only one that matters May 12 10:22:52 for a syncrhonized start i love to have the arm-pru irq to be accurate so some degree May 12 10:23:18 that's not what the kick irq is for, since you don't know the meaning of the irq May 12 10:23:48 it just says "hey yo, there's something for you to look at" and then you're expected to investigate why it sent you the irq May 12 10:24:26 alternatively, you can just poll the queues May 12 10:24:48 (which is perfectly acceptable for pru) May 12 10:26:26 ok .. i was talking then about the kick_irq vs the actual arm->pru which i see in my pru_firmware ?!? May 12 10:26:42 if you just want to stream data from pru to arm, you'd do in a loop: grab a free buffer (from the master queue of the rx vring) or complain and die if none is available, fill it with data, place the buffer on the slave queue of the rx vring, trigger the event May 12 10:26:50 kick_irq is what linux calls the arm->pru event May 12 10:27:15 I don't really understand why it's an "irq" since it should be an event, not an irq May 12 10:28:25 hmm wait May 12 10:29:43 but I think it's just making a mess of terminology to confuse the enemy May 12 10:30:56 now that I think of it, I think the trm does that too (calling both the inputs and the outputs of the intc "irqs" to minimize clarity of discussion) so I guess the kernel isn't really to blame May 12 10:32:02 actually it doesn't May 12 10:32:03 hm May 12 10:32:22 okay then the kernel is to blame for creating confusion :) May 12 10:33:56 I guess it's just confusing to me to use a linux irq number to designate an event delivered to another core that's not running linux May 12 10:34:22 but maybe that's just me not being used to it May 12 10:35:04 pruss_intc_trigger(irq) is documented correctly( "trigger a PRU system event", "@irq: linux IRQ number associated with a PRU system event") May 12 10:36:53 anyway, unless you want to sleep the pru core while waiting on a vring, I would just completely ignore the kick irq on the pru side May 12 10:38:25 i think u shed some light now .. . May 12 10:39:02 my pru code is looking for the flag .. which is the signal arm->pru May 12 10:40:45 then i go look to read a incoming rpmsg on pru ... then pru might send back something, arm gets that , after processing and reputting the queue for use it again raises the pru flag but rpmsg_recieve() is empty .. May 12 10:41:04 yep that's completely normal May 12 10:41:27 and from there on i idle inside the pru polling the next flag .. May 12 10:41:47 really, for a strict request-response structure you'd only need a single vring May 12 10:42:14 i think i am getting there .. well i want both .. May 12 10:42:15 but rpmsg is designed to allow more general messaging patterns than that, hence separate vrings for each direction May 12 10:44:34 my plan is to use initial rpmsg ( or later config) but then let the pru only signal if a new dma was filled and the arm is doomed to read those dmas in-time May 12 10:45:45 your use of the word "dma" makes no sense here May 12 10:45:46 so the signalling of that "yeah you can reuse that rpmsg queue" is too much for me and crossed in on the begin of my dma loop May 12 10:46:37 ive created multiple dmas which i propagate to the pru and it fills those ... actaully from then on no rpmsg payload is needed May 12 10:46:45 you mean "buffers" I think? May 12 10:47:33 "dmas" makes no sense, "dma" is a term that just refers to memory being autonomously accessed by hardware outside of the (main) cpu May 12 10:47:46 i.e. all memory access by pru is technically considered to be "dma" by linux May 12 10:48:29 i use (i think ddr3) areas which i get from dma_alloc_coherent() and let the pru write there .. May 12 10:48:46 yeah those are just buffers, same as the buffers allocated for rpmsg May 12 10:49:40 so buffers , i use it like that .. May 12 10:50:22 pru could tell me via signal or even by some dataflag inside a buffer when its clean and ready to be used May 12 10:50:49 so arm can concentrate on the real data to be secured or treated May 12 10:50:50 so you're basically just putting *another* layer of indirection on rpmsg :) May 12 10:51:54 no rpmsg is fine for controlling my pru and its runtime parameters, when the pru then knows what to do ,i should only "sample" and fill my buffers, arm then focuses only on reading those May 12 10:52:11 so both , and yes some layers more cant hurt, aye ? ;-) May 12 10:52:35 ah ok so it's a reimplementation of some of the functionality of rpmsg? :) May 12 10:55:02 I mean you can just use your own event for pru->arm signalling and ignore rpmsg entirely once you're running May 12 10:55:08 rpmgs is to static and overloaded for my data load but good enought for configurations .. the final data needs to flow May 12 10:55:36 there's no technical reason why rpmsg can't be used for flowing data May 12 10:55:54 I think May 12 10:56:19 or at least vrings... is rpmsg some elaborate protocol on top of it? I thought it was basically nothing but maybe I just don't remember properly, like I said it's been a while since I looked at it May 12 10:56:26 well it doesnt use multiple rings for each side ... that is not what i want May 12 10:56:58 anyway u sehd some real light again for me , always a honor to talk to you .. need some food and coffee now May 12 10:57:09 only the rx ring would be relevant for streaming data from pru to arm May 12 10:57:24 (since the tx ring is for packet sent from arm to pru) May 12 10:57:27 *packets May 12 10:57:50 okay rpmsg does have some protocol around it, but it still looks like it's pretty much just like UDP or something May 12 10:58:28 based on a quick glance May 12 11:00:38 yeah, this is all pru_rpmsg_send is: https://pastebin.com/pCRmyEgV May 12 11:01:15 grab a free buffer from the queue, fill it, place it in the return queue, send the vring irq May 12 11:01:47 if you just do this manually you can also avoid the memcpy() by just writing your data directly into the buffer May 12 11:02:11 m May 12 11:38:36 zmatt: re ., yeah i basicly planning to shortcut this via my buffers whihch i ve 3 for now May 12 11:39:05 i still dont know how much time is left on the arm side when the pru fires up and runs to is demise May 12 11:39:52 but i want a event about a buffer beeing rdy so i try to hack me into the events to without bothering the vrings May 12 11:47:03 aren't you going to be streaming data at a steady pace as it comes from your ADC or something? why would you need an event to indicate when a buffer is ready? May 12 11:48:05 or even if you don't, if you do have an option of waiting for a buffer, just poll instead of using an irq May 12 11:48:43 ohhhhhh it just occurred to me that you're intending to use the irq itself as indication the buffer is released, rather than merely as a wakeup May 12 11:48:55 I wouldn't do that, use a counter or something like vring does May 12 11:49:31 (or better yet, instead of using multiple buffers just use a single ringbuffer) May 12 18:57:42 Does beagle have a device that has two ethernet's? May 12 19:00:39 Pauly95: well no beaglebone variant has two ethernet ports, but the beagleboard-x15 does May 12 19:01:00 ok thank you May 12 19:51:29 * rob_w_ grumbles about the virtio event flag to ignore stuff May 12 20:17:16 I still get the feeling you're trying to force a square peg through a round hole by using things in ways they were not designed for May 12 20:33:37 zmatt - I fixed that issue with Internet over USB on BBB and resizing problem May 12 22:12:48 hi everyone May 12 22:13:45 anyone online? May 12 22:22:22 Hello. May 12 22:22:24 ! May 12 22:22:42 I am doing things but I am sure if you ask a question, someone might be able to help you. May 12 23:50:07 Guess what? May 12 23:50:53 I know not everyone is using the Xenomai image w/ a BELA Cape but I got the Shepard Risset to work on the speaker w/ the Cape and the BBB. May 12 23:51:27 So, I told the fellow, "it helps when someone elevates their tone while the sound is playing." May 12 23:51:31 Haaaaaaaaaaw! May 12 23:51:49 Or even acting like it is mania. It is nice. May 12 23:53:32 I have a circuit that is a slow turn on fan circuit, but I'm not positive. I didn't write what the circuit did in my notes. May 12 23:56:12 mystery ... what the heck May 12 23:57:00 Hmm. Nice. Not everything was meant to be, right? May 12 23:57:05 It works? May 12 23:57:43 Like a pot but digital? May 12 23:59:12 I got some background on mania, the Shepard Risset, and mental health if you are interested, GenTooMan? May 12 23:59:52 If you get bored and have extra time, look here: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4777920/. May 13 00:00:21 It has math in it, too. Sheesh. May 13 00:04:45 Nice heh? May 13 00:18:25 I just read until the end of the conslusion. GenTooMan: did you read that part yet? May 13 00:44:59 Anyway, I read it all. They have some .wav files of the testing music at the end. Risset Gilando! May 13 01:31:11 Ok I'm glad you had fun reading it May 13 02:14:06 GenTooMan: Did you read it? May 13 02:27:06 glanced only I don't oft read psychological studies often they are a bit too subjective instead of objective. Most people hate objective writting because it is boring. May 13 02:31:34 Oh. May 13 02:31:38 Okay. No issue. May 13 02:32:23 how many psychologists does it take to screw in a light bulb? May 13 02:32:30 How many? May 13 02:32:40 one but it has to want to change... May 13 02:32:44 :D May 13 02:32:46 Ha! May 13 02:33:01 "You shall grow in your quest!" May 13 02:33:43 I've been digging up old projects and seeing how far I got in them. It's kind of weird but funny. May 13 02:34:11 I stopped b/c i got pressed for time in new projects. May 13 02:34:26 Let 'em rust and wither! May 13 02:43:55 GenTooMan: What projects seem to stand out in your old projects? May 13 02:44:48 a motor controller I never finished. May 13 02:48:17 Oh. W/ what chip? **** ENDING LOGGING AT Wed May 13 02:59:58 2020