**** BEGIN LOGGING AT Fri Jun 10 02:59:59 2016
Jun 10 05:52:38 <Visaoni> ds2: took care of all that stuff and updated the elinux page.
Jun 10 08:13:11 <ZeekHuge> Wormo: there ? have a quick question .
Jun 10 08:14:34 <ZeekHuge> or jic23 ?
Jun 10 08:16:00 <ZeekHuge> okay so ... A variable inside a defined inside a driver cant be changed by some other driver right ? unless it erroneously does that or , the first driver provides some API.
Jun 10 08:17:12 <ZeekHuge> So if a driver has some critical data and is *NOT* using multi-threads, then, is there still a need to use mutex_locks ?
Jun 10 08:17:28 <ZeekHuge> Abhishek_: ^
Jun 10 08:18:52 <ZeekHuge> oh ! well, I got it. So :
Jun 10 08:19:06 <ZeekHuge> Each process in kernel is actually a thread ..
Jun 10 08:19:54 <ZeekHuge> and that DEFINE_MUTEX defines a global mutex variable, ie through out the kernel region.
Jun 10 08:20:39 <ZeekHuge> now, different drivers use this same mutex variable and thus keep themselves kind of synchronized.
Jun 10 08:20:49 <ZeekHuge> The makes sense I think.
Jun 10 08:24:36 <jic23> Yeah, there is no memory separation in kernel. Anything can in theory trash anything else ;)
Jun 10 08:30:27 <jic23> Which is one reason kernel bugs are really really nasty ;)
Jun 10 08:30:53 <jic23> and the usual argument for the microkernel approach + userspace drivers..
Jun 10 08:32:38 <jic23> hohum. Working on an ancient (well 10 ish year old) PCI frame grabber firmware today.  It glitches and drops pixels every now and then. Seriously tedious because at some point the cpld it uses had a small revision which means it no longer programs when running off the PCI Bus.. Hence need to keep dropping offline to reboot PC after flashing it.
Jun 10 08:38:58 <jic23> Really tedious...
Jun 10 08:41:13 <jic23> Longing for the simplicity of a bit of kernel development.  Particularly as the firmware for these devices is schematic only....
Jun 10 08:54:27 <ZeekHuge> jic23: okay, mutex locks will only be required when more than one drivers are using same device or resource. right ?
Jun 10 08:54:51 <ZeekHuge> *are using -> want to use
Jun 10 09:17:18 <jic23> ZeekHuge - or you have any possible concurrent accesses.  Say sysfs or chardev reads at the same time or any interrupts or interrupt threads at all.
Jun 10 09:17:46 <jic23> Can't have a mutex interrupt context however, so be careful with that!
Jun 10 09:18:00 <jic23> Though absolutely can in the threaded handler.
Jun 10 09:18:12 <jic23> back later.
Jun 10 11:42:43 <ZeekHuge> how do we set private data for a char dev file ?
Jun 10 11:45:35 <ZeekHuge> got it ... its in the open function :(
Jun 10 11:45:55 <ZeekHuge> I have been trying to understand this for last 2 hours :( :( :(
Jun 10 11:45:57 <ZeekHuge> :(
Jun 10 15:44:57 <kiran4399> alexhiam: there?
Jun 10 16:37:07 <chanakya_vc> alexhiam, There?
Jun 10 16:37:39 <chanakya_vc> alexhiam, Can you check this out and see if this is working:https://github.com/chanakya-vc/BBB-Gsoctry/blob/master/updated_spi/pru_spi0.c
Jun 10 16:41:06 <kiran4399> alexhiam: http://pastebin.com/kKq6YJhj
Jun 10 16:41:22 <kiran4399> I think we need to change the pin muxing for the eqep encoders.
Jun 10 16:41:22 <chanakya_vc> alexhiam,  I have installed sigrok. But then I realized that I don't have male to female connecting  wires.Got to go the lab to get that.Will do so on Monday.
Jun 10 16:48:12 <kiran4399> alexhiam: I think the pins which we the eqep wants is taken by tda998x.. I think we need to think about pin muxing..
Jun 10 17:08:27 <alexhiam> kiran4399: yeah, you'll have to disable hdmi
Jun 10 17:09:13 <alexhiam> kiran4399: in /boot/uEnv.txt, uncomment the #dtb=am335x-boneblack-emmc-overlay.dtb line
Jun 10 17:09:24 <kiran4399> alexhiam: I am using the robotics cape to see which pin to use for what..
Jun 10 17:09:28 <kiran4399> alexhiam: is it ok?
Jun 10 17:10:59 <alexhiam> yeah, the pinout will be the same on the blue
Jun 10 17:12:35 <alexhiam> kiran4399: also, I'm fine with just using the 3x eQEP channels for now and ignoring the 4th PRU encoder channel, then getting back to that later
Jun 10 17:13:02 <kiran4399> alexhiam: ok
Jun 10 17:16:02 <kiran4399> alexhiam: since I could get the 6050 perfectly working.. do you want me to start with the apis for imu?
Jun 10 17:16:20 <alexhiam> 6500 you mean? (that was the issue, right?)
Jun 10 17:16:21 <kiran4399> alexhiam: I mean I can switch between things whenever I am bored..
Jun 10 17:16:44 <kiran4399> alexhiam: 6500?? 6050 was perfectly working and 6500 will be working..
Jun 10 17:17:05 <kiran4399> alexhiam: because the driver supports 6050, 6500 and 9150.
Jun 10 17:17:37 <ds2> there is a subset of registers that allows 6050, 6500, 9xxx to look the same
Jun 10 17:17:40 <alexhiam> wasn't the issue that it was a mpu-9250 (6500+mag) instead of a mpu-9150 (6050+mag)?
Jun 10 17:19:54 <kiran4399> I don't think so.
Jun 10 17:20:05 <kiran4399> alexhiam: I think the boards imu is dead!!
Jun 10 17:20:13 <alexhiam> what's the DT that's working?
Jun 10 17:20:26 <kiran4399> BBBMPU6050-00A0.dts
Jun 10 17:20:59 <alexhiam> https://github.com/kiran4399/bb_blue_api/blob/master/install_files/2016-05-01/overlays/BBBMPU6050-00A0.dts#L52
Jun 10 17:21:01 <alexhiam> that one?
Jun 10 17:21:34 <kiran4399> yes..
Jun 10 17:25:28 <chanakya_vc> hey bradfa,there?
Jun 10 17:25:59 <alexhiam> chanakya_vc: I'll try that out in a bit, my logic analyzer is occupied at the moment
Jun 10 17:26:13 <chanakya_vc> Ohh alexhiam ,np.
Jun 10 17:27:35 <chanakya_vc> I hope that this one would work,although I couldn't find any logical error with the earlier one.
Jun 10 17:28:39 <bradfa> chanakya_vc: hi, I'm here but not for long, what's up?
Jun 10 17:29:14 <chanakya_vc> Nothing,here is the updated code:https://github.com/chanakya-vc/BBB-Gsoctry/blob/master/updated_spi/pru_spi0.c
Jun 10 17:29:58 <alexhiam> chanakya_vc: why 0x80? https://github.com/chanakya-vc/BBB-Gsoctry/blob/master/updated_spi/pru_spi0.c#L72
Jun 10 17:30:03 <chanakya_vc> I am pushing the makefile and instructions to compile and load it to the PRU's in about an hour
Jun 10 17:39:49 <chanakya_vc> alexhiam,Hmmn..You are right.Actually I want to give an option to give MSB first transfer or LSB first transfer. But in case of 0x80 it will be left shift << not right shift >>
Jun 10 17:40:11 <alexhiam> right
Jun 10 17:40:25 <alexhiam> or right shift by i instead of 7-i
Jun 10 17:41:49 <alexhiam> there's many way to do it, and many ways to confuse yourself :P
Jun 10 17:43:24 <chanakya_vc> alexhiam, I have corrected it. Please do see if this works
Jun 10 17:44:22 <chanakya_vc> If it doesn't then I will have to come up with something new.This approach doesn't seems to be working.
Jun 10 17:44:49 <alexhiam> chanakya_vc: btw, try to give more descriptive commit messages
Jun 10 17:44:57 <chanakya_vc> bradfa, Please do check out my code whenever you can
Jun 10 17:45:06 <alexhiam> "Update pru_spi0.c" doesn't really say anything
Jun 10 17:45:47 <chanakya_vc> alexhiam, I will. I am not committing to the wip branch as of now. This is a rough work branch to my rough work branch :P
Jun 10 17:46:06 <bradfa> chanakya_vc: ok, I'll try to
Jun 10 17:46:06 <alexhiam> still, you don't want to form any bad habits ;)
Jun 10 17:46:35 <Wormo> there can be as many wip branches as you want
Jun 10 17:47:15 <bradfa> wip it good
Jun 10 17:49:18 <alexhiam> chanakya_vc: Wormo has a good point, would be nice if you were doing everything in the PRU-I2C_SPI_master repo so it's all in the same place
Jun 10 17:49:34 <chanakya_vc> bradfa, Wormo ,alexhiam,Next commit on the wip branch with proper commit message and updated Readme to help people to actually let people duplicate my result.
Jun 10 17:50:17 <chanakya_vc> Okay alexhiam .Tend to be lazy sometimes with commits sometimes ; ). Will be careful now
Jun 10 17:51:51 <Wormo> chanakya_vc: I just did a little demo of 'git rebase -i' at LUG meeting last night, if your wip turns into something good you can copy it as a non-wip branch and clean up its history
Jun 10 17:52:20 <Wormo> (before pushing, that is)
Jun 10 17:55:06 <chanakya_vc> Wormo, ohh. Is it the same as merging wip with master? And then deleting wip?
Jun 10 17:57:01 <Wormo> not the same, it means if the wip branch had lots and lots of little commits trying and undoing, lots of typo fixes because you weren't being super careful while experimenting, all that can be cleaned up into a smaller number of sensible commits with good log messages that are easy to follow
Jun 10 17:57:21 <kiran4399> alexhiam: did you check with the overlay?
Jun 10 17:58:06 <alexhiam> kiran4399: to answer your question, yeah, would be god to get started on the APIs. A good start would be to get the current repo setup with travis-ci just building the Strawson code
Jun 10 17:58:17 <alexhiam> kiran4399: check what?
Jun 10 17:58:24 <Wormo> you make sure that anything good from all the flailing got preserved, and can be picked out of all the noise later, but don't have to stress over careful log messages etc while in the experimenting mode
Jun 10 17:59:06 <kiran4399> alexhiam: you asked about the overlay right?
Jun 10 17:59:39 <alexhiam> kiran4399: yeah, just pointing out that the one in the repo uses mpu6500
Jun 10 17:59:44 <alexhiam> that's the one that works, right?
Jun 10 17:59:57 <kiran4399> 6050 is the one which I tested and worked great..
Jun 10 18:00:27 <kiran4399> btw.. I hope you know that I tested a breakout board..
Jun 10 18:00:33 <kiran4399> not the strawson cape..
Jun 10 18:01:04 <alexhiam> kiran4399: when you say 6050 you mean the overlay named BBBMPU6050-00A0.dts in your repo? Because that's got mpu6500 in it: https://github.com/kiran4399/bb_blue_api/blob/master/install_files/2016-05-01/overlays/BBBMPU6050-00A0.dts#L52
Jun 10 18:01:53 <kiran4399> alexhiam: ok.. thats funny..
Jun 10 18:02:12 <kiran4399> so it means it should work for 6500, 6050 without any issue..
Jun 10 18:02:23 <alexhiam> well it makes sense, because the mpu9250 is an mpu6500 inside, not a 6050
Jun 10 18:04:54 <kiran4399> alexhiam: btw.. is there a kernel driver for adc?
Jun 10 18:05:06 <alexhiam> yeah
Jun 10 18:05:12 <kiran4399> which one/
Jun 10 18:05:36 <alexhiam> http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver's_Guide
Jun 10 18:06:06 <alexhiam> already built by default
Jun 10 18:06:50 <alexhiam> that page may be outdated
Jun 10 18:08:39 <kiran4399> alexhiam: i'll see.
Jun 10 18:08:57 <kiran4399> alexhiam: btw.. I am making different overlays for each device..
Jun 10 18:09:23 <kiran4399> alexhiam: do you think it would be better if I make everything in one overlay.. which would serve as a base overlay for beaglebone blue?
Jun 10 18:13:09 <alexhiam> kiran4399: makes sense to use separate overlays for testing, then we'll need to combine those into the base boneblue.dts eventually
Jun 10 18:13:59 <kiran4399> alexhiam: same with the apis right?
Jun 10 18:15:36 <alexhiam> kiran4399: you mean doing them separately?
Jun 10 18:18:33 <kiran4399> alexhiam: like this..https://github.com/kiran4399/bb_blue_api/tree/master/libraries/test
Jun 10 18:18:55 <kiran4399> alexhiam: would be good for unit testing.. what do you think?
Jun 10 18:19:09 <ZeekHuge> http://paste.debian.net/735382/
Jun 10 18:19:18 <ZeekHuge> I got my driver up and speaking to pru
Jun 10 18:19:24 <ZeekHuge> ;(
Jun 10 18:19:26 <ZeekHuge> tears
Jun 10 18:19:30 <ZeekHuge> all day !
Jun 10 18:19:37 <ZeekHuge> see that 15th line ?
Jun 10 18:19:43 <ZeekHuge> pru_parallel_example
Jun 10 18:20:57 <ZeekHuge> http://paste.debian.net/735384/
Jun 10 18:21:02 <ZeekHuge> driver ^
Jun 10 18:21:13 <ZeekHuge> *more tears*
Jun 10 18:21:20 <ZeekHuge> Wormo: ^^
Jun 10 18:21:20 <alexhiam> kiran4399: for sure, build + unit tests in travis-ci would be best. Where's that code from though? did you just write it all?
Jun 10 18:22:50 <kiran4399> alexhiam: no.. I just broke the robotics_cape.c to pieces with some minute modificaitons..
Jun 10 18:24:03 <kiran4399> alexhiam: oh.. crap.. you mean the name in the beginning?? I am sorry.. looks like I forgot to remove it.. I hope it is ok right?? will I face some copyright issues?
Jun 10 18:24:32 <alexhiam> kiran4399: that's what I mean ;)
Jun 10 18:24:35 <alexhiam> just fix it, no worries
Jun 10 18:25:53 <ds2> ZeekHuge: great! have you verified you can get data from the PRU end?
Jun 10 18:26:34 <ZeekHuge> I haven't but I am pretty sure. It will work
Jun 10 18:26:45 <alexhiam> ZeekHuge: awesome!
Jun 10 18:27:17 <ds2> ZeekHuge: there is some quirks
Jun 10 18:27:35 <ZeekHuge> and sorry ds2, I said it will be up by morning ... but I was trying to understand and I was getting confused very easily ..
Jun 10 18:28:15 <ds2> ZeekHuge: hehe... went through most of that before
Jun 10 18:28:54 <ZeekHuge> ds2: you mean , you ? getting confused ?
Jun 10 18:29:01 <ZeekHuge> really ?
Jun 10 18:30:26 <ZeekHuge> alexhiam: Thank you .. I will soon put up a post  ( assuming nothing now will cause much confusion )
Jun 10 18:31:05 <ds2> *nod*
Jun 10 18:31:35 <ZeekHuge> ds2: I cant even imagine that, you all are so ... intelligent.
Jun 10 18:31:38 <ds2> had to sort through the code to figure it out
Jun 10 18:31:38 <ds2> that's were you see how much overhead there is
Jun 10 18:33:22 <ZeekHuge> anyway .. I am so happy ! after the whole I've been just moving all over the code and ! finally !
Jun 10 18:33:35 <ZeekHuge> hhh ... so now next steps ..
Jun 10 18:35:02 <ZeekHuge> getting blinking led n number of times ...  using the parallel_example device file and a bit playing around the code ..
Jun 10 18:42:20 <chanakya_vc> Congrats ZeekHuge
Jun 10 18:43:05 * chanakya_vc didn't understand Zeekhuge's code but it looks like a big deal
Jun 10 18:43:41 <chanakya_vc> alexhiam, Got a chance to test my code. Is it working?
Jun 10 18:45:10 <chanakya_vc> *Did you get a chance to test my code?
Jun 10 18:49:17 <alexhiam> chanakya_vc: still not seeing any data... seems odd...
Jun 10 18:49:24 <alexhiam> P8_11 and P8_12, right??
Jun 10 18:54:08 <chanakya_vc> Yes alexhiam
Jun 10 18:54:14 <chanakya_vc> I wonder what is wrong
Jun 10 18:54:39 <chanakya_vc> Because earlier atleast it was showing the clock alexhiam
Jun 10 18:56:19 <chanakya_vc> One mistake again I found,I have declared _R30 to be a uint8 register
Jun 10 18:56:39 <chanakya_vc> This must be it alexhiam .It should be uint32_t register
Jun 10 18:57:30 <chanakya_vc> Please correct it and see if it works.
Jun 10 18:58:19 * chanakya_vc needs coffee.Committing so many careless errors.
Jun 10 18:59:48 <alexhiam> chanakya_vc: ah, that was the issue
Jun 10 18:59:52 <alexhiam> almost there: http://pasteboard.co/1Aksk3ru.png
Jun 10 19:00:39 <alexhiam> chanakya_vc: you're setting all the pins low after each bit: https://github.com/chanakya-vc/BBB-Gsoctry/blob/master/updated_spi/pru_spi0.c#L79
Jun 10 19:01:09 <alexhiam> as a rule of thumb you shouldn't ever set the entire register without a bitmask
Jun 10 19:03:20 <alexhiam> because it leads to side effects like that
Jun 10 19:05:48 <chanakya_vc> Okay alexhiam,The clk doesn't look uniform because of this.
Jun 10 19:05:57 <alexhiam> yup
Jun 10 19:07:22 <Wormo> ZeekHuge: Way to go!
Jun 10 19:07:39 <Wormo> looking forward to your post!
Jun 10 19:15:00 <foreverska_> I know that the compiler is likely to optimize this out but Leftshift is an unnecessary step if both the value and the shift are static.  I would personally XOR against a Hex number directly.  Just a personal opinion though.
Jun 10 19:15:26 <chanakya_vc> alexhiam, In the plot you sent,are MOSI and clk correctly identified? I mean I donot understand why is MOSI high intitially
Jun 10 19:16:03 <chanakya_vc> foreverska_, Toggling is better in your opinion?
Jun 10 19:16:45 <alexhiam> yeah, they are. that's just the state they were in before your first '__R30=0x0000;'
Jun 10 19:18:18 <chanakya_vc> alexhiam, Okay in the centre it shows 0s:0ms:0us,is that the beginning?
Jun 10 19:18:23 <foreverska_> Not sure on that question, I just mean personally I'd write #define CLKPIN 0x4000 _R30^=CLKPIN
Jun 10 19:20:41 <foreverska_> then _R30 &= ~CLKPIN for a reset;
Jun 10 19:20:49 <alexhiam> chanakya_vc: that's the trigger point, I had it set to trigger on a falling edge on the clock (because you have CPOL=1). So that should be line 124 I think
Jun 10 19:22:25 <alexhiam> chanakya_vc: also, careful with toggles. You can use them if you want, but when your program starts up you have no idea what state the pins are in, so you want to make sure to set them explicitly before using any toggles
Jun 10 19:22:44 <alexhiam> and by toggle I mean xor
Jun 10 19:23:15 <chanakya_vc> alexhiam, I do set the register to zero before main(), L51
Jun 10 19:23:25 <alexhiam> oh right
Jun 10 19:23:37 <chanakya_vc> *line 51,so that's why I am surprised at MOSI
Jun 10 19:23:51 <ZeekHuge> Wormo: :)
Jun 10 19:23:54 <chanakya_vc> being high
Jun 10 19:24:07 <chanakya_vc> in the beginning alexhiam
Jun 10 19:24:10 <alexhiam> again though, not always good to set the entire register, you don't necessarily want to change the state of any other pins
Jun 10 19:24:23 <ZeekHuge> chanakya_vc: dont worry, I will soon write a post, once I am confident enough ..
Jun 10 19:24:41 <ZeekHuge> you will be using rpmsg as well ?
Jun 10 19:24:47 <alexhiam> chanakya_vc: that first falling edge of mosi is line 51
Jun 10 19:24:57 <alexhiam> the clock was already 0
Jun 10 19:27:15 <alexhiam> chanakya_vc: then that first rising edge of the clock is line 61
Jun 10 19:29:39 <chanakya_vc> alexhiam, Okay got that. But then the data to be written will be  on the rising edge write as CPHA=1?
Jun 10 19:30:19 * alexhiam pulls up the spi wiki page...
Jun 10 19:30:35 <alexhiam> https://upload.wikimedia.org/wikipedia/commons/6/6b/SPI_timing_diagram2.svg
Jun 10 19:30:38 <chanakya_vc> alexhiam, Clock will go from high to low and then when it is rising again it will sample data?
Jun 10 19:31:21 <alexhiam> ok, yeah, read on rising
Jun 10 19:34:09 <chanakya_vc> alexhiam, So the plot doesn't make sense to me because MOSI should not change before the second rising edge there?
Jun 10 19:34:38 <alexhiam> depends on the data
Jun 10 19:34:40 <chanakya_vc> The first is due to line 61 getting the clock in high state(idle state)
Jun 10 19:35:21 <alexhiam> check your logic, it doesn't look quite right to me
Jun 10 19:36:00 <alexhiam> for one line 33 is always setting the data back to 0...
Jun 10 19:37:40 <chanakya_vc> line 33? alexhiam? Could you please point it out on Github with a link?
Jun 10 19:38:02 <alexhiam> oops, 133
Jun 10 19:38:09 <alexhiam> lol
Jun 10 19:38:11 <chanakya_vc> Okay : )
Jun 10 19:38:15 <alexhiam> line 33 isn't doing much
Jun 10 19:38:22 <chanakya_vc> Yes it isn't
Jun 10 19:38:24 <chanakya_vc> :P
Jun 10 19:39:37 <chanakya_vc> alexhiam, Yes that can be removed.I did that because I thought that in the next cycle,the previous state of MOSI should not sampled before I toggle it
Jun 10 19:39:54 <chanakya_vc> or change it according to data
Jun 10 19:40:07 <alexhiam> easiest just to use an else
Jun 10 19:44:33 <chanakya_vc> Okay alexhiam I will work upon it today and maybe ask you tomorrow to check it out?
Jun 10 19:44:47 <alexhiam> sure
Jun 10 19:45:22 <chanakya_vc> alexhiam, Mean while I am pushing this code to the wip branch along with an updated readme on how to load and compile the code.
Jun 10 19:45:38 <alexhiam> awesome
Jun 10 19:46:11 <chanakya_vc> alexhiam,  So do check it out in about an hour or so.And let me know if I missed something.
Jun 10 19:46:54 <chanakya_vc> alexhiam, And when you say commit message,you mean when I say git commit -m "",the message in the quotes right?
Jun 10 19:48:01 <chanakya_vc> foreverska_, I will look into your suggestions. My first priority is to get the waveforms correctly :P
Jun 10 19:48:35 <chanakya_vc> foreverska_,  That seems to be a challenging task in itself right now :P
Jun 10 19:49:25 <foreverska_> lol I know the feeling.  I spent a long time getting pulse widths right in my project.
Jun 10 19:53:52 <chanakya_vc> foreverska_, Haha. You do understand the pain then :P
Jun 10 19:54:42 <chanakya_vc> And foreverska_ Do check out my website vaibhavchoudhary.com. I am still working on it. Tell me what do you think of it?
Jun 10 19:56:59 <foreverska_> It's very trendy.  Besides a notable lack of spaces after punctuation it looks good.
Jun 10 19:58:04 <chanakya_vc> Yes it was pointed to me by the prof whose name is written there:P
Jun 10 19:58:41 <chanakya_vc> foreverska_, It was a bit embarrassing, I will correct that.
Jun 10 19:59:22 <chanakya_vc> But first the waveforms ;)
Jun 10 20:34:13 <alexhiam> chanakya_vc: yeah that message
Jun 10 20:34:39 <chanakya_vc> Yes on it alexhiam
Jun 10 20:35:37 <chanakya_vc> Ohh you were talking it about the commit message
Jun 10 20:35:44 <chanakya_vc> alexhiam, ^^
Jun 10 20:35:47 <alexhiam> yeah
Jun 10 20:37:53 <chanakya_vc> Okay.Got it alexhiam .
Jun 10 21:08:20 <chanakya_vc> alexhiam, Just one last question,TI guys won't have a problem me using the example makefile right?
Jun 10 21:08:28 <chanakya_vc> I mean the code is mine. I will probably modify the makefile but it would still be based on theirs?
Jun 10 21:08:39 <alexhiam> chanakya_vc: just be sure to follow their license
Jun 10 21:08:52 <alexhiam> if the repo has a license the makefile falls under it
Jun 10 21:09:01 <alexhiam> e.g. keep their copyright, etc.
Jun 10 21:09:12 <alexhiam> just make sure you've read and understand it
Jun 10 21:10:02 <chanakya_vc> alexhiam,  The code file is completely mine. I am no longer writing it under the PRU halt example.So that wouldn't be a problem right?
Jun 10 21:10:12 <alexhiam> yup
Jun 10 21:11:57 <chanakya_vc> alexhiam,  But it does contain the two lines regarding including the empty resource table.But that is generic.I mean it is supposed to be there in all codes written for PRU
Jun 10 21:12:28 * chanakya_vc thinks license and copyright are so difficult to understand for an engineering student
Jun 10 21:13:28 <chanakya_vc> alexhiam, I will leave the makefile as it is.There seems to be no copyright message on top unlike the code
Jun 10 21:14:55 <chanakya_vc> Perhaps when I will modify it,I will maybe write a copyright message myself?Do I need one for my code too?
Jun 10 21:34:44 <alexhiam> you should have a license on your code (which typically requires a copyright)
Jun 10 21:34:55 <alexhiam> otherwise it's in the public domain as soon as you push it
Jun 10 21:35:12 <alexhiam> which is ok too...
Jun 10 21:41:03 <chanakya_vc> alexhiam, To be honest I have no idea as how to write a license or a copyright message on the top of the code.
Jun 10 21:41:51 <chanakya_vc> I am just pushing it. I think I will deal with all this stuff later when I am merging the final code with master
Jun 10 23:31:54 <Abhishek_> chanakya_vc: not a good idea. Someone can go back and pick up a previous version of your code with no license header and use it however they like
**** ENDING LOGGING AT Sat Jun 11 02:59:58 2016