**** BEGIN LOGGING AT Fri Nov 09 02:59:58 2018 Nov 09 12:35:07 Hello everyone. I have 1 problem. How can ı c# interface program connect beaglebone black with ethernet ? Nov 09 12:35:31 ehh Nov 09 12:35:38 same as it would on any other computer Nov 09 12:37:29 basic network communication isn't hardware-dependent, it works the same on any linux system, and even works largely the same on mac and windows Nov 09 12:39:38 https://docs.microsoft.com/en-us/dotnet/framework/network-programming/socket-code-examples Nov 09 12:42:38 you're welcome Nov 09 14:34:56 zmatt: do you have a script showing how you set your emmc into slc mode? Nov 09 14:35:30 yates: I have a patched version of mmc-utils with a command that does a ton of sanity checks and then configures the eMMC into SLC mode with reliable writes enabled Nov 09 14:35:44 since the individual commands are tricky and error-prone, which is not good for OTP settings Nov 09 14:35:47 yes, i have your repo - so it's in there. Nov 09 14:36:24 branch 'custom', the last commit adds the command, can't miss it Nov 09 14:36:40 actually i built it yesterday on our dart and ran the query Nov 09 14:37:30 then check the commit for the command name, or probably you find it using ./mmc --help | grep slc or something like that Nov 09 14:38:00 oh wait - i may have pulled the wrong branch.. Nov 09 14:39:46 thanks matt! Nov 09 14:40:01 you do remember me, don't you? Nov 09 14:40:20 you helped me write that arm assembly ram check? Nov 09 14:40:33 (about 3 years ago?...) Nov 09 14:40:47 I recognize your name, but I don't remember that specifically Nov 09 14:40:52 I help a lot of people with a lot of things Nov 09 14:40:57 that was fun! painful, but fun... Nov 09 14:41:23 zmatt: it has been awhile Nov 09 14:42:54 back to the present: have you characterized the sort of write amplification you're getting with your applications and your specific emmc module? Nov 09 14:43:30 nope, nor do I have any idea how such a thing can even be determined, given that this eMMC gives zero information about it Nov 09 14:44:03 then how do you know, even with slc mode, you'll meet your lifetime requirement? Nov 09 14:44:26 we don't Nov 09 14:44:28 i guess one way is the ensure you meet it even with worst-case write amplification factor. Nov 09 14:44:38 though I don't have a concrete lifetime requirement specification either Nov 09 14:44:46 we do: 10 years Nov 09 14:44:58 I do try to ensure the amount of eMMC writes are minimized Nov 09 14:45:10 what's your "nominal" lifetime? what are you hoping to get? Nov 09 14:45:16 I have no answer to that Nov 09 14:45:36 zmatt: yes, that seems to be the most significant step you can take. Nov 09 14:45:55 more than 20 minutes? more than 20 months? Nov 09 14:46:03 lol Nov 09 14:47:06 10 years sounds like a reasonable lifetime to aim for Nov 09 14:47:25 I think that's also the specified lifetime of the am335x if powered on continuously Nov 09 16:09:39 zmatt: I tried again to boot from SATA on a AM572x EVM REV A.20. It loads U-Boot SPL from the ssd, but it fails with this message: "SPL: Unsupported Boot Device!". I'll try this recommendation when I have some time: http://bit.ly/2QuQOmn Nov 09 16:11:45 the message seems to indicate u-boot was built without support for SATA Nov 09 16:12:19 ah, rcn actually confirms that in the post you linked Nov 09 16:12:22 and explains why Nov 09 16:13:06 actually, hmm Nov 09 16:13:40 that's weird Nov 09 16:13:59 his instructions seem to imply u-boot should have sata support, since he's just saying to patch the boot script in u-boot Nov 09 16:14:14 oh sorry duh, probably u-boot supports sata but SPL doesn't Nov 09 17:48:52 nickserv Nov 09 17:49:50 Did there used to be another IRC chat specifically for the PRUs? I thought there was but can't find it now. Nov 09 17:50:27 uhh, no, not as far as I know Nov 09 17:50:42 why would there be a separate IRC channel for that? this one is already pretty quiet itself Nov 09 17:56:57 Lol, good point Nov 09 18:14:12 Aw! Nov 09 18:28:58 With respect to the PRUs, could someone explain the difference between DDR and DRAM? Nov 09 18:32:25 hunter2018: distance to pru, and thereby access time Nov 09 18:32:49 assuming with "DRAM" you mean the data rams embedded in pruss Nov 09 18:33:15 (the abbreviation DRAM is a bit unfortunate since that's more commonly used to refer to dynamic ram, which this isn't) Nov 09 18:33:27 SRAM? Nov 09 18:34:04 yeah, I just realized the D in DRAM is Data, not Dynamic. Nov 09 18:35:02 So the Data RAM is 8KB and each PRU has its own Data RAM Nov 09 18:35:29 Now, the DDR is that the same thing as the 12KB shared RAM? Nov 09 18:35:44 there are three data rams, 8K + 8K + 12K Nov 09 18:36:02 nominally they are for core0, core1, and shared, but in fact both cores can access all three Nov 09 18:36:09 Gotcha, Nov 09 18:36:26 so the DDR is the 512MB DDR3 RAM that the ARM also uses Nov 09 18:36:27 there might be differences in access priority, I haven't tested that Nov 09 18:36:42 yes, and a configurable chunk of that is reserved by the uio-pruss driver Nov 09 18:36:56 (remoteproc probably has a similar feature) Nov 09 18:38:17 Thanks! That clears up a lot for me Nov 09 18:41:32 Does the uio-pruss driver reserve a constant amount of RAM (depending on settings) while the BBB is running, or does it only use as much as is currently being used? Nov 09 18:41:54 My company is designing an UHF RFID transceiver and we are looking for an alternative to the Razz Pi micro controller. Can you help? Nov 09 18:42:07 the amount of memory reserved is fixed at the time the driver probes Nov 09 18:42:46 Randal: do you have a concrete question? Nov 09 18:43:39 (note: this is a community chat room, not a sales or support department of beagleboard.org itself) Nov 09 18:45:18 Looking for a micro controller to support the Impinj R500 RFID transceiver Nov 09 18:45:34 hunter2018: the default isn't much though iirc Nov 09 18:45:50 Randal: what sort of interface does it use? Nov 09 18:45:58 do you have a link to the datasheet? Nov 09 18:46:05 zmatt: Thanks Nov 09 18:46:44 Heh? Nov 09 18:47:22 "Heh?" ? Nov 09 18:47:40 The computer did something funny. Nov 09 18:47:50 I am milti again. Please hold. Nov 09 18:48:17 "again" ? I don't think I've seen your name before Nov 09 18:48:32 Yea! Nov 09 18:49:06 Does anyone else see the ChanServ [#nginx] channel logo in here? Nov 09 18:49:19 set_: ?? Nov 09 18:50:23 zmatt: I see a maroon colored support thing from when I first sign in on this irc thing. But it should show on nginx and not on beagle. Nov 09 18:50:45 support thing = a couple of sentences Nov 09 18:50:56 set_: I have no clue what you could be talking about Nov 09 18:51:07 Okay. I guess you cannot see it. Good. Nov 09 18:51:41 In the #beagle chat on Freenode, the #ngix moto/starter script is shown on my end. Nov 09 18:52:19 hunter2018: default size seems to be 256 KB Nov 09 19:01:13 Regarding booting from a SATA drive (an mSATA drive in my case) on the Beagleboard-x15, recompiling u-boot according to http://bit.ly/2QuQOmn and installing it in the eMMC/uSD works. Directing the CPU to boot directly from SATA does not work, yet. Nov 09 19:01:39 yeah, for the latter you'll need sata support in SPL Nov 09 19:14:14 zmatt: you helped me with some PRU assembly code earlier this year, can you help me understand what this snippet does? https://pastebin.com/HvJT7C3r Nov 09 19:14:44 I believe it is making a structure called Params with two fields start and end. Nov 09 19:14:49 yep Nov 09 19:15:08 However, what does the .assign Params, r18, r19, params line do? Nov 09 19:15:14 and creating a variable named "params" of that type, which actually resides in the register span r18-r19 Nov 09 19:15:44 Gotcha, makes sense. What are things like .assign and .struct called? Assembler directives? Nov 09 19:15:51 so params.start and params.end become synonyms for r18 and r19 Nov 09 19:15:52 yep Nov 09 19:16:21 How do you know which assembler directives are available for PASM? Nov 09 19:16:29 it also lets you do things like lbbo ¶ms, addr, offset, SIZE(params) Nov 09 19:16:50 I don't see them on the page containing the assembly instructions Nov 09 19:18:12 TI doesn't make documentation for pasm easy to find unfortunately Nov 09 19:18:28 but https://github.com/beagleboard/am335x_pru_package contains a reference guide pdf Nov 09 19:18:36 (of pru, but including pasm) Nov 09 19:22:28 zmatt: I got my server set up on the BBB w/ web address up and running. Now, onto making magic makings. Nov 09 19:22:36 Cool! Found it on page 39. Nov 09 19:30:40 Also, with this macro definition https://pastebin.com/KLtgjetb I understand everything except the skip: line. I can't find any info on skip in the reference guide. Nov 09 19:31:00 because it's just a label Nov 09 19:31:03 for the branch Nov 09 19:31:31 Oh, gotcha! Nov 09 19:32:03 labels inside macros are automatically made unique for each invocation of the mario Nov 09 19:45:22 zmatt: If I am making a .ini file on my BBB for setting up https on my website, what dir. should it be located in? Nov 09 19:45:32 I am using uWSGI. Nov 09 19:46:03 Should I use /etc/ Nov 09 19:46:07 what do you mean with "a .ini file for setting up https" Nov 09 19:46:25 uwsgi is irrelevant for this Nov 09 19:46:29 uWSGI config files use the .ini format. Nov 09 19:46:31 it's webserver config Nov 09 19:46:36 nginx Nov 09 19:46:44 I stopped using nginx. It stopped working. Nov 09 19:46:53 ... Nov 09 19:47:00 I cannot configure anything w/ that stuff right now. Nov 09 19:47:04 so what are you using instead then? Nov 09 19:47:10 uWSGI Nov 09 19:47:55 I have my own website being served from the BBB w/ uWSGI right now. It is just one page but it I can configure it from that point onward. Nov 09 19:48:00 oh, it has an integrated webserver Nov 09 19:48:17 I have the info. on making the .ini file but I do not know where I should place it. Nov 09 19:48:22 yes...webservers! Nov 09 19:48:39 is it meant for production use? does it even support https? Nov 09 19:48:44 Yes! Nov 09 19:48:48 Yes to both! Nov 09 19:49:09 I have my .crt and .key files already. Nov 09 19:49:09 well then you already know more about it than me Nov 09 19:49:23 I have zero experience with uwsgi Nov 09 19:49:52 Okay. No issue. But, by rules, I figured you might know where .ini files are supposed to be placed. Nov 09 19:50:12 I am going ot make it in /etc. Nov 09 19:50:14 I have no idea where uwsgi expects its config files Nov 09 19:50:18 Okay. Nov 09 19:50:33 Another ASM questions. The command sbbo &r2, r1, 5, 8 //copies 8 bytes from r2/r3 to the memory address r1+5. Nov 09 19:50:46 just curious, how did you obtain the .crt ? Nov 09 19:51:09 However, what if instead of trying to copy 8 bytes you try to copy 7? Since the registers are each 4 bytes long (32 bit) what will be copied? Nov 09 19:51:44 hunter2018: it would copy r2 and the first three bytes of r3 Nov 09 19:52:33 load/store instructions work for any byte-range of the register file Nov 09 19:52:47 same for xin/xout Nov 09 19:54:12 set_: just curious, how did you obtain the .crt ? Nov 09 19:55:12 zmatt: Thanks! Nov 09 19:58:20 zmatt: Here is the full assembly code you helped me write earlier this year: https://pastebin.com/BBj0HAez It's function is to read out samples from an ADC and store them to RAM. Now I would like to average a number of samples together before writing them to memory. So for instance I would average 10 samples and write this average to the RAM, effectively reducing the data rate by a factor of 10. Nov 09 19:59:03 do you have enough time for that? iirc you were rather starved for time? Nov 09 19:59:29 There are 8 channels, and the data is stored in r10 to r17 temporarily before being written to memory. Nov 09 20:01:45 ah right you get the data in bursts, so the time-critical part is inside the two loops but you have time after that Nov 09 20:02:48 Yes, but the area I was starved for time was while it is clocking out the two sets of 32 bits. There is a long waiting period between this. Nov 09 20:02:59 Exactly, you beat me to it. Nov 09 20:03:38 So I'm using these 8 registers to clock data into and I'm thinking I'll need another 8 registers to store the running average. Nov 09 20:03:38 btw there's usually better filters than averaging, but I guess it would be a start Nov 09 20:03:49 Good to know Nov 09 20:04:20 also you'll probably want to average over 8 or 16 samples, not 10 ;) Nov 09 20:04:44 Makes sense :) Easier to divide at the end Nov 09 20:05:19 Also, technically I don't have to average, I could just sum. It would be easy to divide by the number of samples in my python script Nov 09 20:06:12 you could also reduce the loop count from 32 to 29 (if doing averaging across 8 samples) and add a 3-iteration loop of wbs DCLK; wbc DCLK; after theat Nov 09 20:06:15 *that Nov 09 20:06:22 and them sum the values Nov 09 20:06:24 *then Nov 09 20:06:42 I'm assuming not all 32 bits are actually useful... 32-bit resolution is an awful lot Nov 09 20:06:56 Yeah, only the last 24 bits are useful Nov 09 20:07:02 oh, the last 24? Nov 09 20:07:11 The first 8 are status and the channel number I believe Nov 09 20:07:17 ah Nov 09 20:07:31 in that case you'll want to discard those instead Nov 09 20:08:05 Yeah, if it were C I would do a bitmask, set the top 8 bits to 0 and then repeatedly add them. Nov 09 20:08:05 (or stick them into byte-registers to be able to double-check them) Nov 09 20:08:11 yeah you could do that Nov 09 20:08:14 but you can also avoid it Nov 09 20:08:27 either is fine, it only saves 8 cycles Nov 09 20:09:32 I just wish I had more registers. I want to do r20 = r20+r10 (r10 has the newest sample) in a for loop 8 or 16 times. Nov 09 20:09:45 But, I think I need to be smarter about it. Nov 09 20:09:56 yeah, sounds fine to me Nov 09 20:10:12 you have 30 registers at your disposal, I don't see the problem Nov 09 20:10:34 But then I could just write r20 -> r27 into memory instead of r10 -> r17 Nov 09 20:10:40 Aren't some of them reserved? Nov 09 20:11:32 only r31 is reserved (doesn't behave like a normal register). r30 is kinda reserved since it controls outputs (but other than that it's a normal register) Nov 09 20:11:54 other registers may have special uses in some circumstances, but are not reserved otherwise Nov 09 20:12:51 Wait, why did we define D0 -> D3 as bits of r5 at the top? Does r5 also map to pin inputs? Nov 09 20:13:15 look at lines 49 and 66 Nov 09 20:13:28 Oh yeah, we copy r31 to make a snapshot Nov 09 20:13:34 Gotcha! Nov 09 20:13:41 using r31 directly was not reliable enough iirc Nov 09 20:13:59 because the data remains valid for only a few short amount of time Nov 09 20:14:00 Ok, well then I think I can figure it out. I just thought I didn't have enough registers for my simple plan to work Nov 09 20:14:21 Is there an easy way to zero the top 8 bits of a register? Nov 09 20:14:27 beware btw that you can't use the loop instruction for the outer loop, you'll need to manually keep a counter Nov 09 20:14:40 yeah, mov r10.b3, 0 Nov 09 20:14:54 Ok, why can't I use a loop? Nov 09 20:15:43 there can only be one hardware loop active at any time. any "loop" instruction overwrites the hardware loop state Nov 09 20:15:56 Gotcha, Nov 09 20:16:43 I would have thought mov r10.b3, 0 would only set the 3rd bit of r10, but I guess .b3 means the 3rd byte? Nov 09 20:16:55 yes, the third bit would be .t3 Nov 09 20:17:07 (and isn't supported as a mov target) Nov 09 20:18:32 Cool! And I won't have to worry about overflow since I'm adding multiple 24 bit values and storing the result in a 32 bit register (unless I try to average more than 256 samples) Nov 09 20:18:43 yep Nov 09 20:19:54 in case it's useful, this is a C++ model of the semantics of the pru hardware loop: https://pastebin.com/AXK7Pu0r Nov 09 20:20:21 The reason I'm doing this is that the code works great at writing 8CH, 24-bit, ADC data at 16kHz into the RAM. So good, that the ARM has trouble moving the data to an SD card or the network fast enough. Nov 09 20:20:21 where taken branches would invoke jump() and all other instructions invoke next() Nov 09 20:20:44 you could post-proces on the arm core instead Nov 09 20:21:00 that would definitely make implementing better filters easier Nov 09 20:22:21 Ideally I wanted the ARM to also run a flask webserver that would let you monitor the data, but I couldn't get it to do this and also make use of the data the PRU was pushing to RAM. Nov 09 20:22:48 really? how big is the ringbuffer? Nov 09 20:22:49 I thought that slowing down the data rate 10x (16x) would give the ARM more time to do other things. Nov 09 20:23:20 that sounds really weird, we have no problem running a heavy node application at the same time as audio processing software Nov 09 20:23:26 which involves samplerates higher than yours Nov 09 20:24:40 we also support receiving 192 kHz stereo from the network and run it through a resampler down to 48 kHz Nov 09 20:25:08 Interesting, I made my ring buffer hold 5000 samples (1 sample being 8 channels at one snapshot in time) Nov 09 20:25:26 Wow, is this done in Python? Nov 09 20:25:42 the audio processing isn't obviously Nov 09 20:25:55 It's done in C? Nov 09 20:25:59 C++ yes Nov 09 20:26:46 Interesting, well that's encouraging! Nov 09 20:26:51 the resampler using arm neon intrisics to get good performance Nov 09 20:27:12 (but that's because we use a filter that's a fair bit more cpu intensive than averaging across 4 samples ;) Nov 09 20:30:22 (for 192 -> 48 kHz conversion we use 168 multiplies (32x32->64) and additions (64-bit)) Nov 09 20:30:34 per output sample Nov 09 20:31:23 my final optimized version does so using 2.6% (mono) or 3.7% (stereo) cpu load Nov 09 20:32:41 also, if non-realtime stuff is causing problems with realtime tasks, be sure to give those realtime threads realtime priority Nov 09 20:33:15 Wow! Well, thanks again for the help! I've got to go do weekend things. Enjoy your weekend!! Nov 09 20:33:30 (e.g. using sched_setscheduler(0, SCHED_FIFO, ¶m) ) Nov 09 20:33:45 ah, need to do some shopping **** ENDING LOGGING AT Sat Nov 10 02:59:59 2018