**** BEGIN LOGGING AT Sun May 29 02:59:58 2016 May 29 04:07:22 anyone home? May 29 05:02:35 m_w: Me!! May 29 05:10:43 hey May 29 05:11:15 pinctrl changes using devicetree overlay appears to be broken in the 4.4.9 kernel images May 29 05:11:28 unless I am doing something wrong May 29 05:11:42 I am very annoyed with this now May 29 05:20:54 http://pastebin.com/KnYyy5W1 May 29 05:21:53 the mux is never getting claimed May 29 05:22:18 so the light and are but nobodies home May 29 05:22:34 so the lights are on May 29 05:23:19 but nobodies home May 29 05:24:21 the device nodes are created but the pin mux is not updated properly May 29 05:24:38 and hence SPI no workie May 29 05:38:26 someone has some splainin to do May 29 05:45:16 m_w: are you familiar with Robert Nelson's bb-kernel May 29 05:45:17 ? May 29 05:52:05 enough to know that it is funky May 29 05:52:58 I am using the new debian image so I am using a rcn kernel May 29 05:58:34 * ZeekHuge will brb. May 29 06:07:10 how many people have started coding May 29 06:07:22 ? May 29 06:08:47 everyone should have May 29 06:09:17 coding period started last monday May 29 06:49:18 .. May 29 06:53:53 Hey Wormo ! May 29 06:54:04 Hi m_w May 29 06:55:11 I used that source tree, tried compiling module and compiling the complete tree, but the resultant modules are giving versioning error May 29 06:55:59 ZeekHuge: I referred to that possibility earlier May 29 06:56:06 the kernel and modules must match May 29 06:56:27 should i try building them locally on BBB ? May 29 06:56:31 the point of module versioning is to catch when you change definition of a struct or somethingn May 29 06:56:38 no May 29 06:56:54 I don't think you're getting what the messages are trying to tell you yet... May 29 06:56:57 have you tried installing the kernel and modules both? May 29 06:57:09 from the new build May 29 06:57:31 the point is that a definition changed so it broke binary compatibility May 29 06:57:42 the new kernel must be installed now to match May 29 06:58:01 m_w: nope. I am trying to just build use the modules. on the pre-built kernel. May 29 06:58:20 okay, but then how are external modules used ? May 29 06:58:44 you had to edit files outside the remoteproc dir didn't you? May 29 06:59:01 those would be the changes that broke compatibility May 29 06:59:27 if you just leave all the existing headers alone, you can write a compatible external module May 29 06:59:41 if you have to make changes, you just forced a kernel bump May 29 06:59:42 only the .config file and some remoteproc related files header files in the include/linux/ May 29 07:00:19 those header files not in drivers/remoteproc would be the culprits May 29 07:01:00 stuff in include/linux can be used by both main kernel and modules, structs they need to agree upon May 29 07:01:25 okay got it. May 29 07:01:38 module can not unilaterally decide that a struct with which it communicates to the rest of kernel is suddenly different :) May 29 07:01:39 ZeekHuge: Wormo: m_w: Are you people trying to port PRU kernel driver to 4.4 by any chance in your projects? May 29 07:02:19 ZeekHuge, you going to answer? May 29 07:02:22 So adding files cant cause versioning issues, but editing them can do. right ? May 29 07:02:29 kiran4399: yep, we are May 29 07:02:57 yes editing existing files May 29 07:03:01 kiran4399: if you are talking about the remoteproc drivers for pruss May 29 07:03:06 Cool!! May 29 07:03:10 ZeekHuge: Yeah.. May 29 07:03:17 when is the milestone for that? May 29 07:03:20 ZeekHuge: ^^ May 29 07:03:30 I mean when are you going to finish it? May 29 07:04:01 kiran4399: he has a patch that compiles, just needs to test with the corresponding kernel per our previous discussion May 29 07:04:27 Wormo: okay, as that may change some definition in it. Also, if that is the case, appending something to an existing file wont cause the problem either ? May 29 07:04:45 Appending a new definition is fine, yes May 29 07:04:56 cool ! got it . May 29 07:05:16 i will try to resolve the issue now. May 29 07:05:19 but those new structs used only by the driver normally don't go under include/linux May 29 07:05:34 so anyone got any ideas about the pinmux issue I was seeing earlier? May 29 07:06:03 is the pinmux broken ? May 29 07:06:06 :( May 29 07:06:22 the pinmux using an overlay May 29 07:06:52 Wormo: okay so this was about the "disagrees about version of symbol rproc_put" May 29 07:07:11 right May 29 07:07:29 and what about the pruss: no symbol version for module_layout message ? May 29 07:07:35 what did it mean ? May 29 07:07:48 " pruss: no symbol version for module_layout" May 29 07:07:48 I thought that was earlier May 29 07:07:55 yes, that was earlier May 29 07:08:20 you asked if i noted the difference between the two messages . May 29 07:08:21 right > May 29 07:08:22 ? May 29 07:08:26 so first you had no symbol info builtin May 29 07:08:39 no symbol version for module_layout May 29 07:08:45 http://askubuntu.com/questions/14627/no-symbol-version-for-module-layout-when-trying-to-load-usbhid-ko May 29 07:09:21 and it was warning about that, pointing out that you might be wreaking havoc by changing definitions willy nilly May 29 07:09:26 yep, i already read that :) May 29 07:10:00 and then when you got the symbol version in, it said aha, there *is* a symbol that is different between kernel and module May 29 07:10:29 so no ideas about the pinctrl/pinmux overlay issue then? May 29 07:11:22 I did tried something with pinumx when started, will have to go through my notes, an will put them in the repo too :) May 29 07:11:50 Nope sorry... I'd probably try going to non overlay, probably it will work if loaded via boot dtb May 29 07:12:07 ZeekHuge: good idea May 29 07:12:18 Wormo: symbol version == the versioning number ? May 29 07:12:25 I am certain it would May 29 07:12:27 *try May 29 07:12:41 but I am not looking for a workaround May 29 07:12:59 the versioning number we are talking about ? and the last message was about ? May 29 07:13:02 well I'm a stickler for proving that's the problem and not something weird I didn't think of, that's just me May 29 07:13:28 okay May 29 07:13:29 I meant going back to add earlier notes May 29 07:14:03 oh yes symbol versioning is the versioning number being referred to May 29 07:14:40 http://pastebin.com/KnYyy5W1 May 29 07:15:06 you can clearly see that the overlay loads and the pinmux is not be updated May 29 07:15:44 Wormo: okay. May 29 07:19:50 gcl-bot: .commands May 29 07:19:50 ZeekHuge: I'm sending you a list of my commands in a private message! May 29 07:23:57 http://stackoverflow.com/questions/37057238/device-tree-overlay-for-heartbeat-not-working May 29 07:25:45 doesn't mention which kernel was broken, but post is recent so could easily be the same problem May 29 07:25:58 does say going back to 3.x the overlay was fine May 29 07:26:11 yeah sounds like a regression May 29 07:28:09 I recall cape manager being known broken for early 4.x, but thought it was supposed to work again by now May 29 07:30:49 http://stackoverflow.com/questions/35743544/beaglebone-black-pinmuxing-does-not-change-by-using-device-tree-overlay?rq=1 May 29 07:34:14 did you compile the dts file to make the overlay, or it was a prebuilt one? May 29 07:34:28 prebuilt May 29 07:34:45 m_w: the file https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-SPIDEV0-00A0.dts May 29 07:34:49 then I tried a handwritten one May 29 07:34:59 yeah that one May 29 07:35:10 is quite different from the one that is generated by http://kilobaser.com/blog/2014-07-28-beaglebone-black-devicetreeoverlay-generator May 29 07:35:20 i tried p9_17 May 29 07:35:23 only . May 29 07:35:29 the doc I'm looking at mentioned that dtc differs between v4.x and v3.8.x May 29 07:35:35 dont know if i got it correct or wrong May 29 07:35:37 https://github.com/RobertCNelson/bb.org-overlays/blob/master/readme.md May 29 07:36:12 "Verify you have the latest (patched) dtc version: (this is only for v4.1.x+ for v3.8.x dtbo's use the older version)" May 29 07:36:29 you figure that they would put working overlays in the distro May 29 07:36:59 indeed May 29 07:37:32 i tried a PWM one too and it didn't seem to update the pinmux either May 29 07:45:45 I take it no dmesg comments when the overlay loads? May 29 07:47:48 m_w: that worked for mew May 29 07:47:50 *me May 29 07:47:57 http://paste.debian.net/712158/ May 29 07:48:02 line number 90 May 29 07:48:19 pin 87 got claimed May 29 07:49:03 http://paste.debian.net/712159/ May 29 07:49:17 uname -a May 29 07:49:59 http://paste.debian.net/712160/ May 29 07:50:06 its 4.4.9-ti-r22 May 29 07:50:11 *4.4.8 May 29 07:50:28 different kernel May 29 07:50:36 Linux beaglebone 4.4.8-ti-r22 #1 SMP Wed Apr 27 22:23:10 UTC 2016 armv7l GNU/Linux May 29 07:50:53 interesting May 29 07:51:30 you try the built in spidev one? May 29 07:52:44 you are using "bone-pinmux-helper" which may be a workaround May 29 07:53:24 yep May 29 07:53:58 and though the kernels are different, BB-SPIDEV0 wasnt working on mine either. May 29 07:56:37 so perhaps a bug report is in order May 29 07:59:46 can't go to the devicetree mailing list because this is out of tree May 29 08:03:04 http://beagleboard.org/Community/Forums May 29 08:03:10 straight to Pantelis Antoniou? May 29 08:03:12 https://groups.google.com/forum/?fromgroups#!categories/beagleboard/beaglebone-black May 29 08:03:42 wonder when mdp will be back May 29 08:10:56 so I am digging through the kernel to make sense of all of this May 29 08:11:55 the pinctrl is updated when the driver is probed May 29 08:12:13 m_w: https://groups.google.com/forum/?fromgroups#!searchin/beagleboard/overlay|sort:date/beagleboard/QiFPB9HjL4Y/njQioz-eAwAJ May 29 08:12:14 but the driver is already loaded May 29 08:12:23 "BB-SPIDEV0 needs to be loaded at bootup, not later, as it will fail if manually loaded... May 29 08:12:27 add it to /boot/uEnv.txt" May 29 08:12:34 cape_enable=bone_capemgr.enable_partno=BB-SPIDEV0 May 29 08:12:37 tried that May 29 08:12:46 Didn't help huh? May 29 08:13:00 but lets try it again just in case I missed something May 29 08:13:52 the trick is probably loading the overlay before the driver is probed May 29 08:14:48 this is really user friendly :) May 29 08:14:53 heh May 29 08:19:32 that worked May 29 08:20:31 I must have done something wrong eariler May 29 08:20:55 but now I understand what was happening May 29 08:21:41 if the driver is probed before the overlay is in place the pinctrl is never updated May 29 08:21:46 well yay, and this should be clearly documented rather than picked out of that random mailing list message May 29 08:22:16 google juice is low on this one May 29 08:22:17 because most people I saw struggling with it never got answered, and gave up to go back to 3.8.x May 29 08:22:51 still bugs me a bit May 29 08:24:52 thanks for your lazer eyes May 29 08:25:43 yw May 29 08:26:51 should we put something on elinux? May 29 08:27:26 http://elinux.org/BeagleBone_Black_Enable_SPIDEV May 29 08:28:07 It deserves another red box IMO May 29 08:28:30 since there are so many ppl getting stuck on it May 29 08:28:35 this wiki really applies to the older kernel May 29 08:29:12 look at the history May 29 08:29:46 it hasn't been updated since 2014 May 29 08:31:24 and the dts doesn't have the channel stuff in it May 29 08:31:53 "capemgr.enable_partno=" is now "cape_enable=bone_capemgr.enable_partno=" May 29 08:32:06 so I guess it could all be put under 'kernel 3.x' header and new section added for 'kernel 4.x' May 29 08:32:14 yeah May 29 08:32:48 there are still ppl using the 3.x stuff, including the ones who tried 4.x and gave up... May 29 08:33:31 well I am going to bed its 3:33am here. May 29 08:33:54 a mere 1:30 here but I should go soon May 29 08:33:59 gnight May 29 08:35:00 I can plug the information into the wiki tomorrow unless someone else takes care of it before I wake up May 29 08:35:32 not gonna be me, I'm going to church in the morning May 29 08:35:41 okay May 29 08:35:44 bye May 29 08:35:46 ttyl May 29 08:47:26 okay so if i got this correct, the probe function is called by the OS when it detects a device that the driver registered for. And the spidev driver registers for the SPI module, which is in fact already present on the SOC. As a result the spidev probe() is called by the OS as soon as the spidev driver registers itself. Also, as m_w stated, pinctr is only updated when the device driver is probed, and that will be at the boot for spidev (since its May 29 08:47:26 being probed at boot). So, to get the pins muxed, we need to overlay the dts before the probe() is called and that is why we need to load it at boot time. May 29 08:47:31 correct ? May 29 08:47:33 Wormo: ^^ May 29 08:54:07 think she has left .. May 29 08:54:39 hi ZeekHuge, I should be leavig May 29 08:55:07 Okay :) May 29 08:56:23 ttyl May 29 12:48:50 File am33xx.dtsi shows that spi should not be active but all spi is active(status="okay"). I can't find where DTS is located which activates all spi. May 29 12:48:50 Where could it be? May 29 16:39:26 devices in include files are set inactive and then the actual machine file sets them "okay" May 29 16:40:07 you should be looking at the amblahblah-boneblack.dts file May 29 16:40:43 speaking of which i have a patch to test... May 29 17:05:00 m_w: hi, I wonder why mcspi base address in dts file is 0x48030000 but when I'm getting with resources base addres is 0x48030100 May 29 17:05:32 lets see May 29 17:05:57 m_w: https://github.com/torvalds/linux/blob/master/drivers/spi/spi-omap2-mcspi.c#L1401 May 29 17:06:23 why base address is increment May 29 17:06:33 OMAP4_MCSPI_REG_OFFSET May 29 17:07:09 register is located from 0x48030100 May 29 17:07:10 ? May 29 17:07:28 reference manual will tell us May 29 17:08:37 http://phytec.com/wiki/images/7/72/AM335x_techincal_reference_manual.pdf May 29 17:08:50 section 24.4.1 May 29 17:13:08 Why can't I see it May 29 17:14:16 the are just offsetting the base so that the driver can use the same defines for define versions of the mcspi controller May 29 17:15:06 omap2 omap4 May 29 17:15:25 I think that is the idea May 29 17:19:21 you will see that the second register is at 110h May 29 17:19:35 the problem is when omap2 driver increment address after that my slave driver increment a second time May 29 17:20:02 huh? May 29 17:23:50 first time the address is increment when omap2 driver does it, next I remove omap2 driver and install my driver, my driver increment address for second time. May 29 17:26:03 I don't have to do it but if my driver is installed as the first one, it must increment base address. May 29 17:26:44 they should not be to effect each other May 29 17:26:49 be able May 29 17:28:02 https://github.com/torvalds/linux/blob/master/drivers/spi/spi-omap2-mcspi.c#L1401 seems to be doing things wrong. May 29 17:28:49 this is modifying the platform resource directly May 29 17:29:36 what happens when you probe, rmmod and probe again the master driver May 29 17:29:37 ? May 29 17:34:43 m_w: sorry for delay. My girlfriend turned off my computer by accident May 29 17:38:46 m_w: This is log for install driver several times http://pastebin.com/dXpG268k May 29 17:40:46 yeah that is what I expected May 29 17:41:11 the driver should not be modifying the platform resource May 29 17:41:56 exactly there is not be a pointer May 29 17:43:51 perhaps we can send a patch for the mcspi master driver May 29 17:46:17 I would like to do it but now better off omap2-mcspi but I don't find them May 29 17:46:54 what do you mean? May 29 17:50:16 I would like to do a patch but now it is better to turn off omap2-mcspi driver. May 29 17:50:39 okay that makes more sense May 29 17:51:22 you can blacklist the module May 29 17:53:08 is it in dts file or uEnv? May 29 17:56:13 https://wiki.debian.org/KernelModuleBlacklisting May 29 18:06:20 okay so if i got this correct, the probe function is called by the OS when it detects a device that the driver registered for. And the spidev driver registers for the SPI module, which is in fact already present on the SOC. As a result the spidev probe() is called by the OS as soon as the spidev driver registers itself. Also, as m_w stated, pinctr is only updated when the device driver is probed, and that will be at the boot for spidev (since its May 29 18:06:20 being probed at boot). So, to get the pins muxed, we need to overlay the dts before the probe() is called and that is why we May 29 18:06:23 m_w: ^^ May 29 18:07:50 yes May 29 18:08:52 for the most part, it is the omap2-mcpsi driver that changes the pinmux though May 29 18:13:59 okay then why did that worked for my custom-dts ? did it probe the omap2--mcpsi ? May 29 18:15:24 m_w: ^ May 29 18:17:59 Hey alexhiam ,mdp Are you there?Need some help with PRU firmware code... May 29 18:19:43 no May 29 18:20:16 you are using a special helper driver the manages the pinmux settings directly May 29 18:21:17 it calls pinctrl_select_state directly May 29 18:21:40 m_w: in modprobe.d I don't see anything about omap May 29 18:22:08 lemme power up my module May 29 18:23:01 ZeekHuge: for a pinmux associate to a driver via devicetree it is update upon probe May 29 18:25:08 http://lxr.free-electrons.com/source/drivers/base/dd.c#L352 May 29 18:25:57 pmezydlo: you have to create the file May 29 18:27:32 hey m_w Can you help me out a bit?I am just confused between using assembly or embedded c for the firmware code.I am unable to find much information about using the PRU c compiler. May 29 18:28:07 m_w, Almost all the examples I have seen so far are using the instruction set for the PRU. May 29 18:29:41 you are looking for C examples for the PRU? May 29 18:30:08 m_w, Yes the ones written in embedded c? May 29 18:30:35 m_w, Which we can compile using the C compiler May 29 18:33:40 m_w: thanks I blocked it. I'm going back to writing driver May 29 18:34:01 pmezydlo: good May 29 18:35:23 chanakya_vc: http://processors.wiki.ti.com/index.php/PRU-ICSS May 29 18:38:05 https://git.ti.com/pru-software-support-package/pru-software-support-package/trees/master/examples/am335x/PRU_Hardware_UART May 29 18:39:08 there are plenty of examples May 29 18:39:20 m_w, Yes I found some examples there and the compiler guide:http://www.ti.com/lit/ug/spruhv7a/spruhv7a.pdf May 29 18:40:27 Good idea to go through the guide?Seems to explain the C for PRU as well.Or looking through examples would be better? May 29 18:40:42 How should I go about it m_w ? May 29 18:40:44 or both May 29 18:41:05 just whatever help you learn more quickly May 29 18:41:36 I usually go straight for example code but some people like tutorials May 29 18:42:22 chanakya_vc: if you have a lot of C experience already then just looking at some examples should get you up and running, otherwise it's definitely worth working through the tutorials May 29 18:43:43 alexhiam, I do know C.But it's just that I have never used embedded C.Although I guess using it is more to do with knowing the PRU internal architecture May 29 18:44:25 alexhiam, m_w I have read up on the internal registers and stuff but it does get a bit confusing May 29 18:44:26 don't think of embedded C as a different language, it's just C with some additional limitations May 29 18:45:26 alexhiam, And then I am not very familiar with the syntax.For example the way you declare a register and then access one of its bits. May 29 18:46:17 So I would say I am not familiar with the standard practices employed in embedded C May 29 18:46:22 which register? May 29 18:47:15 Like I was reading up the code for simply switching on two led's based upon whether an input is high or not.So r30 register has to be declared May 29 18:47:22 that's mostly behind the scenes compiler stuff. Typically using C on a memory mapped architecture you essentially have variables that are mapped to registers, so you just set a bit in the variable to manipulate the register May 29 18:48:21 alexhiam, Okay so standard variables that I need to know of?Or they are user defined too? May 29 18:48:26 https://git.ti.com/pru-software-support-package/pru-software-support-package/blobs/master/examples/am335x/PRU_gpioToggle/PRU_gpioToggle.c May 29 18:48:29 chanakya_vc: this is probably a good place to start: http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs May 29 18:48:45 gtg May 29 18:48:49 alexhiam, Okay I was going through it May 29 18:50:29 so I guess with the PRU C compiler you do explicitly declare that in your code: `volatile register uint32_t __R30;` May 29 18:51:14 alexhiam, My question is where it says in the first example: CT_CFG.GPCFG0 = 0; this is some defined function or something? May 29 18:54:29 not a function, it's not being called. Grab the PRU-ICSSS Reference Guide from http://elinux.org/Ti_AM33XX_PRUSSv2#Resources May 29 18:54:56 Section 10 shows the PRU_ICSS_CFG Registers May 29 18:55:06 one of which is GPCFG0 May 29 18:56:56 so CT_CFG is going to be a struct defined in some PRU-ICSS specific header file that maps to the CFG registers, with a 32-bit member GPCFG0 that maps to the GPCFG0 register May 29 18:57:31 so the line `CT_CFG.GPCFG0 = 0` sets all the bits in the GPCFG0 register to 0 May 29 18:58:21 alexhiam, Okay...Got it in order to set all GPO pins to 0 right? May 29 18:59:33 not their state, "The General Purpose Configuration 0 Register defines the GPI/O configuration for PRU0." May 29 19:00:05 capture mode, shift register config, etc. May 29 19:00:13 alexhiam, Next question why are we xoring in the line gpo ^= 0xF? May 29 19:01:01 alexhiam, Okay got it.Set the congiguration of the GPI/O to output for PRU0 right? May 29 19:03:45 yeah, GPCFG0=0 is basically regular GPO mode. When you xor a value with a bitmask (like 0xf == 0b1111), it toggles all the bits that are set in the mask in the value. e.g. 0b1001100 ^ 0b1111 = 0b1000011. So what's that's doing is toggling the lowest 4 GPO bits every time through the loop May 29 19:04:03 and therefore toggling the state of the corresponding output signals May 29 19:07:54 alexhiam, Okay so next doubt is that which GPO pin is getting toggled.I mean does each bit in the r30 register map to a output pin? May 29 19:09:45 If so how do we know which ouptut pin maps to what address in the r30 register?Like if I just wanted to toggle only a certain pin on the P8? May 29 19:10:14 chanakya_vc: yup. Take a look at these P8 and P9 pinouts: https://github.com/derekmolloy/boneDeviceTree/tree/master/docs May 29 19:11:14 alexhiam, So in our case since four bits are getting toggled,four output pins are getting toggled? May 29 19:11:23 e.g. mode 6 on P8_11 muxes it to pr1_pru0_pru_r30_15, which means PRU0's output 15, which maps to the 15th bit in R30 on PRU0 May 29 19:11:28 yeah May 29 19:11:41 * chanakya_vc needs to read up a bit on registers May 29 19:12:03 running that on PRU0 would toggle PRU0 R30.0, R30.1, R30.2 and R30.3 May 29 19:12:43 which can be muxed to P8_45, P8_46, P8_43 and P8_44 (all mode 5) May 29 19:13:19 (the muxing is done separately through the control module, and on current kernels that's controlled through the device tree) May 29 19:19:26 alexhiam, So if I understand correctly,this mode is set through the device tree? May 29 19:21:09 alexhiam, I understood the part where the 15 bit is being toggled. But I did not get the line next to next it i.e. running it would toggle PRU0 R30.0 ,R30.1? May 29 19:21:10 yeah, the pin mode. And on 4.1+ you can use the config-pin command line utility, which uses the universal-io Device Tree overlay May 29 19:22:08 which line? May 29 19:22:19 running that on PRU0 would toggle PRU0 R30.0, R30.1, R30.2 and R30.3 May 29 19:22:53 that example from the TI lab, with ^ 0xf May 29 19:23:12 0xf = 0b1111, so it toggles bits 0-3 May 29 19:23:30 bit 0 == the right-most bit May 29 19:25:23 Okay,but when you say that it is mapped to the 15 bit,toggling the 1 ,2,3 bit won't work right? May 29 19:25:51 If we wanted to toggle P8_11? May 29 19:26:41 yeah, if you wanted to toggle pr1_pru0_pru_r30_15 (on P8_11) you'd do __R30 ^= (1<<15) May 29 19:27:13 or to set it `__R30 |= (1<<15)`, and `__R30 &= ~(1<<15)` to clear it May 29 19:30:50 if you haven;t done that sort of bitwise stuff it's probably worth reading through something like http://www.ocfreaks.com/tutorial-embedded-programming-basics-in-c-bitwise-operations/ May 29 19:36:41 alexhiam, I understood both.In the first you are shifting 1 by 15 places to make the bit at the 15 place 1. In the next one Next you are doing or with 1 at the 15 places and then doing and at the 15 place to make it 0 again right? May 29 19:37:18 * chanakya_vc just had a course on digital electronics this semester May 29 19:37:41 yup, and with the twiddle (~) to clear just the desired bits May 29 19:38:33 alexhiam, I will go through the link you gave.Are you going to be online for sometime more? May 29 19:38:46 Or you would be leaving? May 29 19:38:59 no, I'm off soon, but I'll keep my client online May 29 19:39:12 irc client, that is May 29 19:40:25 holiday weekend in the US, so mentors over here may be scarce today and tomorrow May 29 19:43:40 alexhiam, Ohh. I know about the holiday though.Memorial day right? May 29 19:44:15 yup May 29 19:44:54 aka barbecue weekend May 29 19:45:05 alexhiam, Okay I guess I will talk to the mentors on Tuesday. I will post queries on the IRC just incase you or some mentor happens to be online. May 29 19:46:00 sounds good. I'll check in from time to time, and will probably end up working tomorrow anyways... May 29 19:46:05 Ohh. I have never seen a barbecue. Don't have them in India :P May 29 19:46:18 Okay alexhiam ,Enjoy your holiday! May 29 19:47:42 thx May 29 19:47:51 * alexhiam goes afk May 29 20:56:40 alexhiam, still there?' **** ENDING LOGGING AT Mon May 30 02:59:58 2016