**** BEGIN LOGGING AT Sun Jul 03 02:59:58 2016 Jul 03 03:19:25 Wormo: Hi ! Nope, figured that out .. Jul 03 03:19:29 :) Jul 03 05:49:21 Hi ! Jul 03 05:49:45 what does .dwattr thing means here ? Jul 03 05:49:48 https://gist.github.com/ZeekHuge/68458821a6bbad52f31f9e9eedb771df Jul 03 05:50:13 its the asm file generated by the compiler for main_pru0.c Jul 03 05:51:27 main_pru0.c : https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/firmware/main_pru0.c Jul 03 05:52:03 these are called dwarf tags and I have no idea what dwarf tags mean in assembly. Jul 03 05:52:11 ds2: alexhiam Abhishek_ Wormo ^^ Jul 03 05:54:45 if anybody could tell ??? or else I will have to go through this : http://www.dwarfstd.org/doc/Debugging%20using%20DWARF.pdf Jul 03 06:20:02 ZeekHuge: dwarf tags are for debugging Jul 03 06:21:23 it's a format for embedding info useful only when debugging, doesn't effect execution Jul 03 06:21:24 yeah, so what do they mean ? like in the gist .. those .dwattr and .dwtag thing ? Jul 03 06:21:33 oh .. okay Jul 03 06:22:46 https://en.wikipedia.org/wiki/DWARF Jul 03 06:22:46 [WIKIPEDIA] DWARF | "DWARF is a widely used, standardized debugging data format. DWARF was originally designed along with Executable and Linkable Format (ELF), although it is independent of object file formats. The name is a medieval fantasy complement to "ELF" that has no official meaning, although the backronym 'Debugging..." Jul 03 06:25:15 Wormo: when PRU1 send data to one of the scratch pad banks, it interrupts PRU0 Jul 03 06:25:24 PRU0 code is in C Jul 03 06:25:46 so, in C we have an intrinsic function called __xin() Jul 03 06:25:59 to grab data from these scratch pads Jul 03 06:26:17 but it can only take 44 bytes of data at a time Jul 03 06:26:35 and that is why I was diving into the asm code Jul 03 06:27:51 further .. this might corrupt the data https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/docs/clpru_and_C_usage.notes#L146 Jul 03 06:29:24 corrupt the data? Jul 03 06:29:58 what's the exact concern Jul 03 06:31:03 nice notes but I don't see discussion of data corruption where you point Jul 03 06:38:58 okay so when we use the __xin instruction, the data gets transferred from scratchpad to internal registers of the PRU. The C language internally is using these registers as is in those notes. So that might change data in the internal registers Jul 03 06:39:34 Wormo: and I tested it just now, that RPMsg is not going to help much on the PRU side. :( Jul 03 06:40:34 it can only have small buffers (until getting very very deep into the asm code ) and it is interrupting ARM after all those small buffers. Jul 03 06:40:47 The C compiler should really be juggling the registers properly to free up the ones __xin() needs Jul 03 06:41:20 the small buffers question is a different matter though :/ Jul 03 06:42:11 when you embedd asm then save/restore of registers can be your concern, but this was __xin() implemented by the compiler right? Jul 03 06:42:38 It would be pretty bad of it to stomp over its own registers Jul 03 06:45:53 Not that compilers don't have bugs, but unless it's actually got a corruption symptom, I tend to assume the compiler is doing ok... not having unlimited time to check over the compiler's work as well as my own ;) Jul 03 06:47:45 Wormo: okay. And __xin() allows to use any base register. So I should assume that is will manage it internally ? https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/docs/clpru_and_C_usage.notes#L255 Jul 03 06:48:32 For now yes, though it wouldn't hurt to ask somebody a lot more familiar with clpru Jul 03 06:49:16 I've made some assumptions based on gcc behavior with builtins and inline asm Jul 03 06:51:24 gcc juggles the registers decently if you tell it which registers you're clobbering in the asm, and handles it's own builtins fine with just the occasional exception from a bug Jul 03 06:52:20 okay. Jul 03 06:52:34 Btw, I have been working since last meeting Jul 03 06:52:46 and its quite near to completion .. Jul 03 06:53:07 I hope mentors are not disappointed. Jul 03 06:53:16 btw I see some improved commit messages Jul 03 06:54:58 yeah .. the suggestion by nerdboy , something like - "imagine you will be back to your code after an year to remove a bug, commits should help then" Jul 03 06:55:25 that was good advice, and good you're taking it Jul 03 07:18:22 Wormo: busy ? Jul 03 07:18:37 heading out soonish, something quick? Jul 03 07:19:13 ahh ... how can i do repeat something in vim ? Jul 03 07:19:34 you use a number right before the command Jul 03 07:19:48 100dd = delete 100 lines Jul 03 07:19:50 i mean ... I copy pasted something huge and after ever 2nd line i have to delete the whitespace Jul 03 07:20:17 oh I'd do a regex for that particular thing Jul 03 07:20:33 regex ? Jul 03 07:20:35 googling Jul 03 07:20:55 trailing whitespace you can delete with a regular expression Jul 03 07:21:11 :% s/ *$// Jul 03 07:21:30 % = shortcut for whole file Jul 03 07:21:50 oh, that was an example ... Is there something with which i could record my steps and iterate them ? Jul 03 07:22:06 yes that's the macro record function Jul 03 07:22:21 see 'q' to save, and '@' to play back Jul 03 07:22:24 record with 'q' ? Jul 03 07:22:28 okay Jul 03 07:22:34 q and then another letter Jul 03 07:22:51 the second one is the "register" where it gets stored Jul 03 07:23:13 e.g. qz to record then @z to play back Jul 03 07:24:13 so 'q' to start recording then 'qz' to save and '@z' to play it . right ? Jul 03 07:24:46 or qz itself to record. Jul 03 07:25:09 actually just 'qz' to start, plain 'q' to end, '@z' to play back Jul 03 07:25:37 or 'qw', 'q', '@w' etc Jul 03 07:25:51 you can use counts with the @ which makes it quite useful Jul 03 07:26:01 yepi ! Jul 03 07:26:06 that worked ! Jul 03 07:26:14 cool Jul 03 07:26:15 haha ! it looked cool ! Jul 03 07:26:39 yup :) Jul 03 07:26:41 and then 21@z to repeat it 21 times Jul 03 07:26:47 exactly Jul 03 07:27:32 remember to put move-to-next-area-of-interest as your last action in the recorded macro Jul 03 07:28:07 e.g. if you want to do something to all matching lines, you search for the next before closing the record Jul 03 07:28:26 (or just go down to next line, if it's relevant to all lines) Jul 03 07:31:04 yep .. already did that. As it will only repeat what i did after starting the recording. Jul 03 07:31:43 quick learner Jul 03 07:40:20 :) Jul 03 07:40:31 but slow performer :( Jul 03 07:41:21 technically it's not uncommon for a project to start out slower than planned, because you don't know enough up front to estimate accurately Jul 03 07:41:45 picking up speed as you go along is a good sign Jul 03 07:43:58 the best estimates are for things you've done N previous projects almost the same, new parts that you haven't done before are always a schedule risk Jul 03 07:55:13 ... Jul 03 19:14:29 hi ! Jul 03 19:14:33 anyone there ? Jul 03 19:14:45 I am trying to read from /dev/rpmsg30 Jul 03 19:14:54 i mean, I want hex values Jul 03 19:15:01 I tried hexdump Jul 03 19:15:04 xxd Jul 03 19:15:11 but none of them is working Jul 03 19:15:21 they just dont print anything Jul 03 19:15:38 though cat is printing things Jul 03 19:18:55 what kind of "things"? Jul 03 19:20:04 * nerdboy checking out a new test image/qtwebkit thing Jul 03 19:20:34 notice my "things" are somewhat more descriptive... Jul 03 19:36:52 things = message that pru is sending ie the content of /dev/rpmsg30 Jul 03 19:37:06 but anyway, got it working Jul 03 19:37:19 xxd -c 1 /dev/rpmsg30 Jul 03 19:37:33 it was waiting for more data to come in. **** ENDING LOGGING AT Mon Jul 04 02:59:58 2016