**** BEGIN LOGGING AT Wed Jul 27 02:59:58 2016 Jul 27 03:58:35 ds2: Wormo_ : Can I submit report bit late ? I have to get done a few things .. before that ... I dont have much to write in the report ... It will definitely be there well before the meeting ... but late as compared to my usual timings on report . Jul 27 04:57:38 how can I mention an old commit in a new commit message ? Jul 27 04:57:42 nerdboy: ^ Jul 27 04:58:11 other than adding link to that commit Jul 27 05:03:47 use the hash Jul 27 05:40:49 ZeekHuge: thanks for mentioning, I was just going through the submitted reports Jul 27 05:52:56 okay . :) Jul 27 05:56:41 I am still under the impression that you shouldn't have to iio_push_to_buffer() for every byte, wish somebody who did iio driver before would chip in... Jul 27 05:57:50 Wormo_: this is what I am doing https://github.com/ZeekHuge/BeagleScope/blob/wip/driver/beaglescope_driver.c#L236 Jul 27 05:58:23 I asked jic23 about it .. and he suggested to go with iio_Push_to_buffers for now. Jul 27 05:58:53 and here he is .. Jul 27 05:58:55 well if he says so, guess there's no quick way to get the whole 14-byte buffer Jul 27 05:59:04 it just surprises me Jul 27 05:59:07 Morning jic23 :) Jul 27 05:59:11 ZeekHuge, wormo. Jul 27 05:59:24 nice to have you chime in Jul 27 05:59:31 jic23: https://github.com/ZeekHuge/BeagleScope/blob/wip/driver/beaglescope_driver.c#L214 Jul 27 05:59:36 Normally not an issue as data comes in one sample at a time... Jul 27 06:00:00 Easy enough to add support for a multi byte push I think. Jul 27 06:00:41 Ultimately though this will want to use the 'dma buffer' interfaces... Jul 27 06:01:05 Using the normal slow ones is just step 1... Jul 27 06:01:20 that makes sense Jul 27 06:01:57 what's a good example iio driver using dma Jul 27 06:02:00 On the multi byte push, the sticky corner is the demux to multiple clients stuff. Jul 27 06:02:24 There isn't one in mainline unfortunately. Jul 27 06:03:15 What tree are they (it?) in so far Jul 27 06:03:23 There was a version of the fake dummy driver originally. Will dig out something in a few mins. Run for train time Jul 27 06:03:59 whenever you get a chance, the brute force method is fine for now, knowing it's just temporary Jul 27 06:15:06 Wormo, other thing is that for 'dma stuff to make sense need to drive those read sizes up. Normally done at a page size.. 4k Jul 27 06:15:10 Or similar Jul 27 06:16:10 Wish cgit had a mobile friendly interface... Jul 27 06:17:47 42 bytes is quite small, seems like PRU could use a virtio driver with decent sized buffers Jul 27 06:18:15 rpmsg really being for messages per the name... Jul 27 06:22:20 Increasing the size will be actually about how fast is PRU0 in sending all that data at once .. Jul 27 06:22:51 so ... what is happening as of now is .. that PRU0 is just storing those 44 bytes and then sending them .. Jul 27 06:23:22 and rpmsg supports 512 Bytes of buffer Jul 27 06:23:38 actually 256 bytes ... Jul 27 06:23:44 for each side . Jul 27 06:23:51 so total of 512 bytes Jul 27 06:24:34 but to use that full buffer for a single message from PRUs ... we will first have to store 512 bytes in the PRU0 Jul 27 06:24:35 but 256 in one direction? Jul 27 06:24:49 and then make it send that at once Jul 27 06:25:31 one from PRU to ARM and the other from ARM to PRU Jul 27 06:26:21 then in data flowing from PRU, it's really a 256 buffer available, 512 would only be for bidirectional data flow yes? Jul 27 06:26:57 yes . Jul 27 06:27:08 and there is much larger space actually .. Jul 27 06:27:10 On 'dma buffer' stuff in IIO there are users in analog's tree Jul 27 06:27:14 https://github.com/analogdevicesinc/linux/tree/xcomm_zynq/drivers/iio/adc Jul 27 06:27:43 a total of 256Kb .. but each buffer is only of 256 bytes Jul 27 06:27:58 Cfi* but not straight forward.. Jul 27 06:28:09 and the each buffer is kicked separately .. Jul 27 06:29:45 The dummy driver patch got dropped from there as well Jul 27 06:31:00 Will dig it out. I know Lars Peter Clausen wants to rework some of that stuff to handle data planes so they arent pushing drivers upstream in meantime.... Jul 27 06:31:06 Ok Jul 27 06:35:40 the rpmsg buffers http://lxr.free-electrons.com/source/drivers/rpmsg/virtio_rpmsg_bus.c#L90 Jul 27 07:50:25 jic23: there ? Jul 27 07:51:38 i was working on sampling frequency .. and I am getting it from in_voltage0_sampling_frequency Jul 27 07:51:59 so that will be used for buffer capture Jul 27 07:52:10 but what about the clock duty cycle ? Jul 27 09:56:00 ahh Wormo_ ? Jul 27 13:47:36 jkridner, just merged your pull request, thanks for revision and merge. Jul 27 15:03:19 amragaey: great. I'm sill working the state diagram. really complicated. Jul 27 15:11:47 our meeting in 50 minutes? Jul 27 15:15:07 45 Jul 27 15:25:06 amragaey missed a standup status report so he is first this week Jul 27 15:32:14 hi everyone Jul 27 15:35:47 pmezydlo: any headway on the DMA issue? Jul 27 15:36:33 dma in my driver is the same as the mcspi Jul 27 15:36:53 for tx channel should be similar Jul 27 15:37:28 the documentation is written that you have to set the count of words Jul 27 15:38:39 I set the counter and now after enable dma i have a segmentation fault Jul 27 15:39:30 m_w: for now thats all ^^ Jul 27 15:40:27 null pointer dereference again? Jul 27 15:40:32 wait for 5 min I put an logs Jul 27 15:40:57 yes but I dont know where Jul 27 15:47:58 m_w, There? Jul 27 15:49:17 This is log: http://pastebin.com/wUPkFxKq Jul 27 15:53:46 yup Jul 27 15:55:55 Just wanted to ask you a few questions m_w ... Jul 27 15:56:09 go ahead Jul 27 15:56:28 quickly though, the meeting starts soon Jul 27 15:57:16 Please take a look at the driver that's there:https://github.com/chanakya-vc/PRU-I2C_SPI_master/blob/wip_on_spi/SPI_Driver/pru0_spi-subsystem.c Jul 27 15:57:26 pmezydlo: is the latest code commited? Jul 27 15:57:37 chanakya_vc: okay Jul 27 15:57:40 m_w: ok i found again mistaken dma tx with tx_dma_addr. Jul 27 15:57:54 So my first doubt is regarding the ioremap declarations in the struct pru0_spi Jul 27 15:57:56 ah Jul 27 15:57:58 I need to test now Jul 27 15:58:36 after the meeting we'll talk about it Jul 27 15:59:06 Now if I declare instances of that struct in all the other functions and then call the members, won't request_mem_region() run again and again? Jul 27 15:59:37 chanakya_vc: okay you are going about it wrong Jul 27 16:00:27 chanakya_vc: what is going on here?: Jul 27 16:00:33 https://github.com/chanakya-vc/PRU-I2C_SPI_master/blob/wip_on_spi/SPI_Driver/pru0_spi-subsystem.c#L33 Jul 27 16:01:16 These are the pointer declarations to the shared mem address Jul 27 16:01:21 in the PRU-ICSS Jul 27 16:01:33 So I am confused, where to put these Jul 27 16:01:35 why are there function calls in the struct? Jul 27 16:01:49 makes no sense Jul 27 16:02:10 Okay my mistake Jul 27 16:02:34 Ah so I should only declare the pointer variables in the this struct? Jul 27 16:03:04 And then maybe do the function calls in tranfer_one function? Jul 27 16:04:02 1 min Jul 27 16:04:06 remap in the probe and save the pointers in the struct Jul 27 16:04:19 But if I do that, I would have to do iounmap in transfer_one only. Because it will lead to conflict in memory once the transfer function is called again Jul 27 16:04:38 no Jul 27 16:05:16 Okay so members of the probe function are local to that of the transfer function? Jul 27 16:05:51 well, we're missing one student today... Jul 27 16:06:00 are we missing mentors too? Jul 27 16:06:25 yeah got it m_w . My mistake Jul 27 16:06:31 Sorry for that. Jul 27 16:07:02 who has the mtg today? Jul 27 16:07:15 * jkridner looks at _av500_ Jul 27 16:07:44 morning all Jul 27 16:08:06 * alexhiam rushes to catch up on reports... Jul 27 16:08:35 only 5? Jul 27 16:09:13 meeting starts now, right? Jul 27 16:09:26 * alexhiam is in a new timezone Jul 27 16:09:29 how has stednup? Jul 27 16:09:30 yes Jul 27 16:09:31 somebody went out of town and apparently did not push areport... Jul 27 16:11:30 well it appears that the meeting is not starting Jul 27 16:11:37 we are 6 minutes late to start. Jul 27 16:11:43 do we have 6 students? Jul 27 16:11:46 nerdboy: did you run last week? Jul 27 16:11:54 nerdboy: shouldn't we have 7? Jul 27 16:12:01 I ran the meeting last week Jul 27 16:12:04 1) ATTENDANCE! Jul 27 16:12:04 * nerdboy does not "run" Jul 27 16:12:08 1 Jul 27 16:12:10 Hi ! I am present . Jul 27 16:12:15 i'm Jul 27 16:12:16 Hi Jul 27 16:12:20 thanks m_w. Jul 27 16:12:20 Namastey everyone Jul 27 16:12:21 3 Jul 27 16:12:22 4 Jul 27 16:12:27 amragaey: yt? Jul 27 16:12:58 who are we missing? Jul 27 16:13:11 jkridner: yes, but i got a "going out of town" /msg at the last minute Jul 27 16:13:28 visaoni is not here Jul 27 16:13:29 oops, that's 5 not 4 Jul 27 16:13:36 Visaoni and amragaey Jul 27 16:14:49 kiran4399: Sounds like great progress on the PRU stuff! Sorry I haven't had a chance to look through it much, you been getting any feedback in here? Jul 27 16:15:44 alexhiam: I badly wanted to talk to you.. Jul 27 16:15:52 alexhiam: I made the sysfs entries.. but Jul 27 16:16:17 alexhiam: I get only the servo directory in /sys/class/.. but I don't get any sysfs entries when I insmod. Jul 27 16:16:19 :( Jul 27 16:16:29 Abhishek_: happy birthday!!! ;) Jul 27 16:16:46 kiran4399: what do you see in dmesg? Jul 27 16:17:03 alexhiam; I don't see anything. Jul 27 16:17:07 relating to my driver.. Jul 27 16:17:18 Yes,there Jul 27 16:17:28 kiran4399: why aren't you using the standard pwm api? Jul 27 16:17:37 Thanks pmezydlo ! Jul 27 16:17:52 m_w: aren't?? I'm using it!! :-D Jul 27 16:18:01 m_w: do you know who is supposed to present their progress this week? Jul 27 16:18:05 m_w: you mean for the PRU firmware driver? Jul 27 16:18:22 yes Jul 27 16:18:41 Oh yes ! I had that notification today morning, I missed it then . Happy birthday Abhishek_ ! Jul 27 16:18:42 amragaey is supposed to report today Jul 27 16:18:45 m_w: alexhiam: https://github.com/kiran4399/bbb_pru_firmware/blob/master/driver/servo_sysfs.c Jul 27 16:18:47 alexhiam: certainly attendance needs to be agenda item #1. I think we should also cover any blocking issues on projects before going into the status presentation. Jul 27 16:18:48 m_w: seemed easier to just implement some sysfs entries for now, since there's no need for anything but duty cycle Jul 27 16:19:16 alexhiam, m_w: any objections in going around the room to verify no blockers on the projects? Jul 27 16:19:21 jkridner: true. I guess I'm leading the meeting today :P Jul 27 16:19:41 alexhiam: :-) Jul 27 16:19:47 ok... Jul 27 16:19:56 2) BLOCKING ISSUES!! Jul 27 16:19:56 alexhiam: m_w: I've created 4 things.. period, enable, duty_cycle, polarity.. Jul 27 16:20:40 kiran4399: oh... no need for polarity or period, and if we do want those then we definitely want to use the pwm api... but we'll pick that up later... Jul 27 16:20:52 m_w, yes I'm here Jul 27 16:20:54 we're very quickly approaching the end of GSoC! Jul 27 16:20:55 alexhiam: ok.. Jul 27 16:21:07 let's go around and report any blocking issues.. Jul 27 16:21:17 anybody else stuck? Jul 27 16:21:29 say 'no' if you're not stuck so we know you're all awake ;) Jul 27 16:21:36 no Jul 27 16:21:41 nope Jul 27 16:21:52 not really Jul 27 16:21:53 I'm stuck with DMA Jul 27 16:22:13 s chanakya_vc unblocked? Jul 27 16:22:19 os Jul 27 16:22:34 ? Jul 27 16:22:36 I would like to know how it should look like (DMA and my driver) Jul 27 16:22:47 no Jul 27 16:22:52 ds2, I am still haven't been able to figure out the interrupt from PRU->ARM Jul 27 16:23:11 And I have a few other doubts about the firmware. Jul 27 16:23:17 ok, that's everyone I think. let's run through the 2 blocking issues real quick, one at a time Jul 27 16:23:27 pmezydlo: you first Jul 27 16:23:32 alexhiam: for blockers, I find it best to call out a student and get positive confirmation that they can proceed. perfect, thanks. Jul 27 16:23:53 I removed just a segmentation fault Jul 27 16:24:03 s/a /each / Jul 27 16:24:04 pmezydlo: "how should it look" is very vague, what exactly are you stuck on? Jul 27 16:25:02 hmmm Jul 27 16:25:35 now I rewrite the DMA with omap2 Jul 27 16:25:35 pmezydlo: or what component do you need help with? Jul 27 16:26:05 I thought that the channel dma is similar in the two controllers Jul 27 16:26:21 omap2 and my spi slave driver Jul 27 16:26:30 pmezydlo: this is ARM->PRU shared RAM? is it both directions? Jul 27 16:26:44 no PRU Jul 27 16:26:48 McSPI controller Jul 27 16:26:52 oh right, sorry Jul 27 16:26:57 I remember now :P Jul 27 16:27:08 seems like it should be pretty similar... Jul 27 16:27:14 MEMORY to DEVICE direction for now Jul 27 16:27:37 meaning RAM -> SPI FIFO? Jul 27 16:28:24 at the beginning without fifo Jul 27 16:28:34 oh, so just 1 word at a time then? Jul 27 16:28:40 straight to the register Jul 27 16:29:21 I turned on the transfer did not cause a call back and word isn't load to register Jul 27 16:29:40 code link? Jul 27 16:30:26 https://github.com/pmezydlo/SPI_slave_driver_implementation/tree/DMA_transfer Jul 27 16:31:44 so your implementation of the DMA transfer is from scratch? or based on omap2-spi? Jul 27 16:31:49 I want to start from the beginning - working on dma slowly, with better understanding Jul 27 16:32:09 there might not be time for that at this point.... Jul 27 16:32:19 yeah all DAM stuff based on omap2 Jul 27 16:32:31 in my driver Jul 27 16:32:43 did you start with the omap driver and add the slave stuff? Jul 27 16:32:55 DAM DMA Jul 27 16:33:00 dma is a topic for a book Jul 27 16:33:07 yes m_w DMA Jul 27 16:33:15 because then a diff with the original would show you what you've changed of the DMA code Jul 27 16:33:51 he started from scratch and added stuff as he went Jul 27 16:34:04 yes exactly Jul 27 16:34:38 from the beginning of a new independent driver Jul 27 16:34:41 but I see a lot of DMA related code in that repo. Is that all written from scratch? and if so how was it tested as it was developed? Jul 27 16:35:16 it is very similar to the host driver from what I remember Jul 27 16:35:26 so the allocation of channels works well Jul 27 16:35:33 so I am guessing the host driver was used as the reference Jul 27 16:35:55 but it's hard to test DMA so step by step Jul 27 16:36:23 pmezydlo: have you used printks and looked at registers to see exactly where it's failing? Jul 27 16:36:53 ok it's a good idea Jul 27 16:37:23 maybe there is a problem with the trigger transfer Jul 27 16:37:44 I can give it another look with your latest commits after the meeting Jul 27 16:38:01 there is no visible connection with any interrupts Jul 27 16:38:03 pmezydlo: so, we all know that you're having some DMA trouble now, and it sounds like there's some more debugging that can be done. Alright if we move on the chanakya_vc's issue for now? Jul 27 16:38:14 * alexhiam has to run soon Jul 27 16:38:15 Okay alexhiam Jul 27 16:38:36 chanakya_vc: I assume you've looked at this: https://git.ti.com/pru-software-support-package/pru-software-support-package/blobs/master/examples/am335x/PRU_PRUtoARM_Interrupt/PRU_PRUtoARM_Interrupt.c Jul 27 16:38:48 are you having trouble on the ARM side? Jul 27 16:38:50 thanks alexhiam Jul 27 16:38:54 and m_w Jul 27 16:39:15 1) Yes I am not sure as how to detect a interrupt on the arm side Jul 27 16:39:37 Like in the driver Jul 27 16:39:44 chanakya_vc: have you talked to Abhishek_? Jul 27 16:39:52 or looked at previous PRU projects? Jul 27 16:40:06 the ARM side should look the same I would think.. Jul 27 16:40:10 So that the PRU can tell ARM that it has written to the miso buffer Jul 27 16:40:41 pmezydlo: does PIO w/interrupts work reliably? Jul 27 16:40:48 Actually m_w gave me this idea yesterday only, so I haven't had the chance to talk to Abhishek_ Jul 27 16:41:03 ds2: yes Jul 27 16:41:16 That's one of my problems. Jul 27 16:41:37 so all pio based on interrupts Jul 27 16:41:44 chanakya_vc: why arent you using resource table to configure PRU Interrupt controller ? Jul 27 16:41:59 that thing actually works Jul 27 16:42:05 pmezydlo: have you tested it with a demanding master that wants to clock out things back to back? Jul 27 16:42:18 ZeekHuge: sounds like you've got that figured out already? Jul 27 16:42:52 ZeekHuge, Okay. But how to detect it on the arm side? Configuring the pru interrupt controller will do stuff for me on the pru side right Jul 27 16:43:02 yes . Though I dont know how to catch that on the kernel side, but I can probably tell how to get an interrupt to the ARM Jul 27 16:43:08 ds2: SPI master's clock has 0,5MHz Jul 27 16:43:35 Okay ZeekHuge , perhaps you can help me out Jul 27 16:43:43 ds2: for PIO it works well Jul 27 16:44:04 Earlier I was simply polling for the flag Jul 27 16:44:25 pmezydlo: any plan (probally post GSoC) to test it with a much faster master? Jul 27 16:44:52 alexhiam, ds2 I have one more problem Jul 27 16:44:56 chanakya_vc: the PRU interrupt to ARM is like yet another interrupt for the ARM, so catching it in the kernel would be like other interrupts and mentors would know how to do that. Jul 27 16:45:17 chanakya_vc: you need to get the right irq number to pass to request_irq Jul 27 16:45:43 ds2: this is my test result: https://github.com/pmezydlo/SPI_slave_driver_implementation/wiki#photos-from-tests with much faster clock Jul 27 16:45:56 ds2: and that irq number == system event generated by the PRU ? Jul 27 16:46:16 Regarding MISO.I took a look at this:https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus Jul 27 16:46:17 [WIKIPEDIA] Serial Peripheral Interface Bus | "The Serial Peripheral Interface (SPI) bus is a synchronous serial communication interface specification used for short distance communication, primarily in embedded systems. The interface was developed by Motorola and has become a de facto standard. Typical applications include Secure Digital cards and..." Jul 27 16:46:29 keep it down gcl-bot! Jul 27 16:46:34 Here the MISO is sampled inbetween the clock cycle Jul 27 16:46:41 :D Jul 27 16:46:58 wouldn't that cause the clock to become non uniform Jul 27 16:46:59 gel-bot: always helpful Jul 27 16:47:15 alexhiam, m_w ds2? Jul 27 16:47:31 If I sampled after toggle would that be all right? Jul 27 16:47:45 yes Jul 27 16:48:11 ZeekHuge: it depends on mappings with the ARM INTC Jul 27 16:49:17 As with MOSI, MISO will only depend upon CPOL. Because whether the slave writes on the rising edge or the falling edge will not have an effect Jul 27 16:49:30 in my opinion Jul 27 16:49:43 as the clock transition time is very less Jul 27 16:50:02 20 Mhz for half cycle Jul 27 16:50:26 20 PRUSS1_EVTOUT0 pr1_host[0] output/events pr1_host_intr0_intr_pend Jul 27 16:50:26 exported from PRUSS1(1) Jul 27 16:50:26 21 PRUSS1_EVTOUT1 pr1_host[1] output/events pr1_host_intr1_intr_pend Jul 27 16:50:26 exported from PRUSS1(1) Jul 27 16:50:26 22 PRUSS1_EVTOUT2 pr1_host[2] output/events pr1_host_intr2_intr_pend Jul 27 16:50:27 exported from PRUSS1(1) Jul 27 16:50:28 23 PRUSS1_EVTOUT3 pr1_host[3] output/events pr1_host_intr3_intr_pend Jul 27 16:50:30 exported from PRUSS1(1) Jul 27 16:50:34 24 PRUSS1_EVTOUT4 pr1_host[4] output/events pr1_host_intr4_intr_pend Jul 27 16:50:35 what do you think alexhiam ds2, m_w ^^? Jul 27 16:50:36 exported from PRUSS1(1) Jul 27 16:50:38 25 PRUSS1_EVTOUT5 pr1_host[5] output/events pr1_host_intr5_intr_pend Jul 27 16:50:40 ppmezydlo: that looks like you it is from a slow scope... reason I asked is back to back high speed traffic seems to cause drop outs of interrupts (had something like that a few years ago) Jul 27 16:50:41 exported from PRUSS1(1) Jul 27 16:50:42 26 PRUSS1_EVTOUT6 pr1_host[6] output/events pr1_host_intr6_intr_pend Jul 27 16:50:45 exported from PRUSS1(1) Jul 27 16:50:46 27 PRUSS1_EVTOUT7 pr1_host[7] output/events pr1_host_intr7_intr_pend Jul 27 16:50:59 this is the mapping .. so irq depends on the host used. Got it. Jul 27 16:51:23 before we dive in, what isn't there suppose to be presentations? Jul 27 16:51:31 chanakya_vc: I wouldn't recommend trying to get tricky with the clack modes, there's a reason there's 2 bits Jul 27 16:52:27 at least one presentation Jul 27 16:52:38 who's on first? Jul 27 16:52:41 from amragaey Jul 27 16:52:55 yes Jul 27 16:53:11 alexhiam, But inorder to diffrentiate the cpha, I would have to sample inbetween the clock. There is no other way Jul 27 16:53:30 And I haven't seen that anywhere Jul 27 16:54:13 chanakya_vc: I think you're not quite groking the clock modes, but lets let amr_ragaey present now Jul 27 16:54:34 Hi all Jul 27 16:54:51 I'm still working on BBUI Jul 27 16:55:26 you can find my latest output here : http://amragaey.github.io/bone101/Support/bone101/UI/ Jul 27 16:55:27 amr_ragaey: can you share a link for everyone to see the status? Jul 27 16:55:33 (read my mind) Jul 27 16:56:15 so, I had a problem before in events and wasn't able to make the pin hovering Jul 27 16:56:51 Events is the object responsible for listening to user actions on the BBUI Jul 27 16:57:23 I managed to solve it by adding a new event to the old implementation that is called "pinHover" Jul 27 16:58:00 it works in the same time with 'selectPin', I check the current active probe name and compare Jul 27 16:58:12 it's category with pin category to make hovering works in this event Jul 27 16:58:40 amr_ragaey: I think a new event handler is not needed. Jul 27 16:58:54 * nerdboy not the .js guy Jul 27 16:58:55 why? Jul 27 16:59:57 maybe I'm wrong, but I thought there was already a mousemove event listener active that is only active during the SEL state... Jul 27 17:00:05 * jkridner tried to name the states to make it simpler to discuss. Jul 27 17:00:46 isn't selectPin a mousemove event only active at this time? Jul 27 17:01:00 so, you'd just need to add a conditional statement within that same event handler. Jul 27 17:01:22 yes, I tried to do this hovering inside PinSelect and get a bad output. Jul 27 17:01:23 no need to add an additional handler because it would be active in 100% the same conditions. Jul 27 17:01:42 not pinSelected (which is a 'click' event) Jul 27 17:01:54 it would need to be in selectPin (a 'mousemove' event). Jul 27 17:02:10 I tried to highlight pins being hovered, by using the function that draws a lighter background on the hovered pin, but the event listens for 'mouse move' which keeps drawing this background over and over again while moving the mouse over pins and ends up the pin is 'white' colored Jul 27 17:02:14 I don't like some of the names when you try to figure out what they do. Jul 27 17:02:56 and there is some funniness in that the selectPin mousemove event handler enables the pinSelected click event handler. It seems to me they can both be turned on when entering the SEL mode. Jul 27 17:03:57 We have an 'exit' and 'exitHover' that works the same way, and I was inspired from this analogy. Jul 27 17:04:31 'exit' is a 'click' event. 'exitHover' is a 'mousemove' event. Jul 27 17:05:04 yes, I turned on the two events and selectPin was working, but it's drawing the highlight over and over on mousemove Jul 27 17:05:20 similarly, in what I'm calling the SEL mode (per my e-mail), there is 'selectPin' (a 'mousemove' event) and 'pinSelected' (a 'click' event). Jul 27 17:05:31 which ends up the pin become white Jul 27 17:06:28 it will be easy enough to collapse these into a single handler... Jul 27 17:06:37 here I can say, I needed an assistant to event to block this duplicates which is pinHover Jul 27 17:06:56 assistant event* Jul 27 17:06:58 the bigger step is adding the wire draw on the probes upon the pinSelected event. Jul 27 17:08:02 If you're sure of that, I'll figure this again after doing some other progress becuase it took me long time. Jul 27 17:08:05 amr_ragaey: the wire draw code from the old version should be a good reference. Jul 27 17:08:29 amr_ragaey: like I said, it'll be trivial to fix. better I show you in code than by words. Jul 27 17:08:30 yes, I'm working now in this part Jul 27 17:09:30 I added a new object "ui.wire" that is responsible for all wire drawings inside canvas, I added a function for drawing LEDs wiring, and is working now to finish the rest of wiring functions for different buttons. Jul 27 17:10:20 wire.LEDs() is the same as the old implementation Jul 27 17:10:56 but it draws the wires wrong, there's something has to be modified with lines and dimenstions. Jul 27 17:11:44 k. Jul 27 17:12:41 where's the PRU code? Jul 27 17:13:12 well, the pinSelected now is listening to 'click' event, that has no logic. Jul 27 17:13:56 as the user is clicking before in 'selectPin' event. Jul 27 17:14:09 let me know if http://beagleboard.github.io/bone101/Support/bone101/UI/fsm/ helps. Jul 27 17:15:20 selectPin is not for clicking... it is a mousemove event. Jul 27 17:16:38 it is used to update the text within the probe to say what pin number is about to be selected. Jul 27 17:17:17 the same event handler already also highlights the pin over which it is being hovered in http://jadonk.github.io/Beaglebone-UI/BBUI.html. Jul 27 17:17:31 ok fsm looks good but I need to figure out new names. Jul 27 17:18:36 c(pin) == pinSelected Jul 27 17:19:06 cd(l,a) == clickDown Jul 27 17:19:13 cd(d) == clickDownDigital Jul 27 17:19:52 r(active) == release (in the active probe area) Jul 27 17:20:19 h(dm) == digitalMenu Jul 27 17:20:37 anyway, I thought it would be clearer if there was some shorthand on the event types.... Jul 27 17:20:41 mousemove = h Jul 27 17:20:46 mouseup = r Jul 27 17:21:00 mousedown = cd Jul 27 17:21:03 click = c Jul 27 17:22:18 well, let me know if this helps you move faster.... Jul 27 17:22:22 what is the empty states. Jul 27 17:22:40 empty states are just for drawing purposes.... so that the arrows don't overlap each other. Jul 27 17:22:51 I will probably need to update the tool to handle that condition. Jul 27 17:23:07 aha Jul 27 17:23:09 good, how much is done with fsm till now (perecentage) ? Jul 27 17:25:04 I think it is complete except for sub-states. Jul 27 17:25:43 I think this make the progress faster, I'll check it today and give you feedback Jul 27 17:25:54 will make* Jul 27 17:26:05 I just push the h(pin) or selectPin events. Jul 27 17:26:19 I think we are way over time... any update on the Python stuff? Jul 27 17:26:39 just a last question on BBUI Jul 27 17:27:06 how do I use global states as you mentioned in the topic ? Jul 27 17:28:50 alexhiam, I will have to start working in Python integration part ASAP, you would support me in that, right ? Jul 27 17:29:28 right... in theory... though very busy at work ATM.... Jul 27 17:30:15 I will need a starting point (branch name/ files) Jul 27 17:31:16 not sure what you mean about using global states. there are a number of global variables that reflect some state outside of the major state machine. Jul 27 17:32:22 'There is some additional global state, such as if a probe is on or off.' How do I check globally if the probe is on or off Jul 27 17:34:58 each probe has an onOff state variable. Jul 27 17:36:35 aha, OK. Jul 27 17:39:26 I can see the function onOfftest(event) in clicked event/ Jul 27 17:40:28 so I have to set a new property to pobe and check it through the function. Jul 27 17:41:57 I added the substates to the diagram... Jul 27 17:42:27 remember that these states only have to do with what event handlers are active such that you know what you are paying attention to in the UI. Jul 27 17:43:07 other global state, such as if the play/record timer (kinda confused on the terminology used there) is active, etc. are not necessarily part of the event listener state. Jul 27 17:44:46 amr_ragaey: always be sure to compare against the working code.... remember, the goal was to make this rather complicated code readable such that the few relatively minor issues (such as dimensions, voltage scale, etc.) could be resolved easily. Jul 27 17:47:13 ok, i'm not sure about all things, but will get the state diagram and will follow your instructions Jul 27 17:49:05 alexhiam: are we wrapped up (or were we wrapped up 50 minutes ago)? Jul 27 17:56:20 right.. that's a wrap! Jul 27 17:57:42 thanks jkridner, alexhiam Jul 27 18:29:19 and that was one report? Jul 27 18:32:55 lost focus after a while Jul 27 19:05:44 haha ! Jul 27 19:06:47 ZeekHuge: sounds like you made lots of progress, and that's why you delayed your report a bit to be able to announce it Jul 27 19:09:52 Wormo_: Actually the 'variable sampling' part was not actually ready at that time .. So delayed the report and was working on it .. Jul 27 19:11:13 and I wanted to do it and only then report "have completed the driver". Jul 27 19:11:20 :) Jul 27 19:11:35