**** BEGIN LOGGING AT Thu Mar 24 02:59:58 2016 Mar 24 07:02:53 Ch - all you need is open drain outputs then it will work with double pinning both i2c signals. Snag is the gpios don't seem to support this. Hence need a couple of transistors... Mar 24 07:03:03 No big issue. Mar 24 07:37:14 jic23, So all we need are transistor to drive the SDA down right? Mar 24 08:00:44 jic23b, Did you get my question regarding transistors? Mar 24 09:18:42 Hi chanakya, back now. Mar 24 09:18:54 Nope, look up open drain / open collector on wikipedia. Mar 24 09:19:27 What it does is ensure that the outputs only pull low if on. When off, they are 'tristate' - e.g. basically not connected. Mar 24 09:20:17 i2c needs pull ups anyway so result is you have an output that only does stuff when you drive it low. Rest of the time the bus sits hight unless the slave is manipulating it. Mar 24 09:20:44 Some GPIOs specifically allow for open drain, but don't think the ones on the am335x do. Mar 24 09:21:40 You can simulate it normally on a gpio, by driving output low and togging it between output and input for the pin. Can't do that here given they are different pins! Mar 24 09:23:36 Anyhow, will have this irc open all day, but only going to be at PC from time to time (and testing some interface cards so may drop off to reboot every now and then! Mar 24 09:27:16 jic23: says here it can do open-drain without the need of external transistors (same method that you wrote above) - https://e2e.ti.com/support/arm/sitara_arm/f/791/t/293683 Mar 24 09:39:08 you can, but only by writing to registers over the main bus. So, something like 40 clock cycles every time you do it. Mar 24 09:39:22 Non starter in this case. Just use a bit of breadboard and some transistors :) Mar 24 09:45:14 hmm...so I gotta ensure my bit-banging compensates for external circuit Mar 24 09:52:44 not really, you aren't going fast enough for it to matter - just need documenting. inherently bitbanging i2C on the PRU will require some level of external circuit. Mar 24 10:08:16 jic23, So as I understand it,we would basically connect a gpio pin to the base of a transistor with a open collector right?And the emitter would be grounded.So whenever we would need to pull down the SDA,we would apply a signal at the base? Mar 24 10:29:55 chanakya, yes - that's correct. Mar 24 10:51:55 alexhiam: are you there? Mar 24 11:09:33 Hey jic23 ! Mar 24 11:09:52 jic23, So we would have two gpio pins one attached to this transistor and the other for receiving data from the SDA right? Mar 24 11:22:56 you'll have two outputs attached to 2 transistors (needed to handle clock stretching) and two inputs connected to the collector on the transistor (which is also wired to the bus lines of the slave device) Mar 24 11:23:09 Hi ZeekHuge, Mar 24 11:23:42 jic23, what the difference between arm-linux-gnueabi and arm-linux-gnueabihf ? Mar 24 11:27:14 hf = hard float. So requires a hardware floating point unit on the processor. Mar 24 11:27:24 jic23, Okay so two GPIO inputs and two GPIO output pins are required.The input ones are basically going to poll the the SDA for any message to arrive right? Mar 24 11:27:40 Without means it's not specified whether there is one or not. I think convention means that it is emulating floating point. Mar 24 11:27:50 beagleboards all I think have hf, so use it. Mar 24 11:28:42 All sorts of handshaking in i2c. Every byte is acknowledged (or explicitly not acknowledged). Also you want to understand the magic of clock streching. Mar 24 11:28:44 yep hf works while this one here says to use non-hf https://github.com/jadonk/gsoc-application/blob/master/ExampleEntryJasonKridner/README.md Mar 24 11:29:59 Chanakya, if you have enough time read the i2c spec http://www.nxp.com/documents/user_manual/UM10204.pdf Mar 24 11:29:59 and in my case hf isnt working at all. Don't know how other applications did a successful compilation. Mar 24 11:30:15 jic23, Okay will do that.This stuff is a bit confusing for me.I am in my second year and have only had one course of basic electronics :) Mar 24 11:30:18 *applicants Mar 24 11:31:16 Don't worry about it - part of the point of GSoc is to introduce students to the stuff they wouldn't meet in a normal degree. Mar 24 11:31:28 I certainly didn't know about i2c at the end of my 4 years ;) Mar 24 11:31:56 Ah. hf will require a hard float kernel... Mar 24 11:32:19 could have sworn I'm using hf, but then I built the kernel too... Mar 24 11:32:32 oh ! ohk so that is the reason. got that. Mar 24 11:33:40 Chanakya, I'd suggest that you might want to start the project by lining up a few test parts and running them on the hardware i2c buses + making sure you can capture the waveforms and look at the result. Mar 24 11:33:59 Nothing like real waveforms to develop understanding of what is happening. Mar 24 11:34:31 Also be a little wary as there are parts out there that deliberately 'slightly' break with the i2c spec to avoid the need to pay a license fee. Mar 24 11:35:51 omnivision cameras are a classic on that... They are specified to not care about some the acknowledgements - so magically they will work on an i2c controller. Mar 24 11:36:36 Anyhow, got to go watch our intern here run a dataset on a machine. Back in a while - feel free to leave me questions in the meantime. Mar 24 11:48:28 jic23, If I correctly understood what you are saying,You would want me to write the firmware to implement the basics of I2C and test it right? Mar 24 11:49:08 jic23, Like get an analyser or something to test it? Mar 24 12:10:21 Hello. I'm pretty interested in BeagleBoard's GSoC projects. Especially ideas "SPI Flash Emulator (possibly via PRU)" and "PRU Framebuffer" sound interesting for me. Mar 24 12:10:27 but I don't have Linux kernel programming experince actually - I'm very interested in it, but never wrote a line in Linux Mar 24 12:10:38 I have a lot of experience with low level C on various MCUs Mar 24 12:11:36 also lot of experience with desktop Linux... not many with the embedded one - just some with the RPi Mar 24 12:11:53 do you think I'm a good person for this tasks? Mar 24 12:37:20 jic23, I have edited certain parts of the doc and those diagrams too (and highlighted the new parts using comments ). please have a look. Mar 24 12:37:33 https://docs.google.com/document/d/1GfnoWusWUeH2VsLbt1qJaRi20uNxCC8O_Xw1CHoGY9A/edit?usp=sharing Mar 24 12:38:20 Chanakya, I'm suggesting that first you should get experienced with another implementation - i.e. the hardware i2c implementations on the beagle. Mar 24 12:38:37 Step one, really understand the protocol - step two implement it. Mar 24 12:39:24 yup, get an analyser. There are very cheap ones out there... Mar 24 12:39:47 http://eud.dx.com/product/logic-analyzer-w-dupont-lines-and-usb-cable-for-scm-black-844148945#.VvPf6OKLRhF Mar 24 12:40:07 and sigrok will do the job nicely for i2c. Bit slow for spi. Mar 24 12:41:44 jic23, Okay.And isn't clock stretching required in slave mode.I mean if coding for an I2C master,it just has to detect when a slave is holding down the SCLK right? Mar 24 13:05:22 jic23, The SCLK is kept high using pull-up resistors? In that case we would need the open collector transistor to in-fact generate the clock? Mar 24 13:05:57 But still the clock stretching is only done by slave devices right? Mar 24 13:18:29 jic23: doh, good call on the npn, I was over thinking it with the separate IO pins Mar 24 13:19:00 I'm fine with slave mode being a stretch goal for spi and i2c Mar 24 13:25:32 Hey alexhiam ! Can you please have a look at my doc ... just the timeline is remaining now and i am working on it . Mar 24 13:25:46 https://docs.google.com/document/d/1GfnoWusWUeH2VsLbt1qJaRi20uNxCC8O_Xw1CHoGY9A/edit?usp=sharing Mar 24 13:27:58 Hey ds2 ! you there ? need some help ... Mar 24 13:29:12 Hi, Is there anybody can help me with bone101 project ? Mar 24 13:31:26 I'm writing my proposal for improving experience of bone101, I need to get some help regarding add python support Mar 24 13:31:27 alexhiam, Regarding clock stretching,that's required in slave mode right? Mar 24 13:33:15 chanakya_vc: only if it's needed Mar 24 13:34:22 like if data is being sent to userspace for responses in slave mode it would likely be required Mar 24 13:34:32 not sure if there's a max clock stretching time Mar 24 13:35:20 alexhiam, But I am proposing I2C in master mode?Would you want slave mode also? Mar 24 13:35:46 k, I thought you were proposing both Mar 24 13:35:55 leaving it out is fine Mar 24 13:36:35 I think it would not be possible to achieve in timeframe of GSOC. Mar 24 13:37:53 chanakya_vc: I like jic23's idea of spending some time at first using the protocols with the on-die modules Mar 24 13:38:00 For my master mode,I think I would have to still code the firmware to recognize when a slave is doing clock stretching? Mar 24 13:38:30 I'd like to see clock stretching supported. It shouldn't add too much complexity Mar 24 13:39:56 I would do that in the pre-coding period itself I guess.Atleast for one of the protocols.I will try and complete both before the coding period starts. Mar 24 13:40:21 chanakya_vc: I can't leave comments on your proposal, can fix the edit permissions? Mar 24 13:40:37 UART as well Mar 24 13:40:47 do you have access to an oscilloscope? Mar 24 13:41:13 a scope or logic analyzer would be pretty essential for this project Mar 24 13:41:21 alexhiam, I am writing a complete brand new proposal.Should be ready by tonight.Still I will edit the permissions Mar 24 13:42:18 I am a member of TI's CEPD lab in my college.I have access to all hardware over there. Mar 24 13:42:28 great Mar 24 13:43:08 I have changed the permissions Mar 24 13:43:35 well I guess I'll wait for the new proposal now Mar 24 13:43:47 Okay ;) Mar 24 13:44:09 Will most probably be done by tonight. Mar 24 13:45:08 I just wanted to ask you about Slew rate that you mentioned yesterday.Was that in reference to the external hardware we were going to connect? Mar 24 13:45:45 Slew rate would effect the clock definitely,if we use an open collector npn to pull down? Mar 24 13:46:10 won't be a problem in this case Mar 24 13:46:50 I was over complicating it and picturing a mux or digitally controlled spdt or something, where you would need to check the slew rate spec Mar 24 13:51:30 ch - yes to generating clock and yes to slave causing clock stretching. Mar 24 13:52:48 chanakya_vc - clock stretching is needed in master mode - not slave - unless your slave implementation needs to do it to keep up. Mar 24 13:54:27 for the i2c slew rate, you'll still need to be a little careful with the transistor choice, but most things should work. Just don't use a big power transistor :) Mar 24 13:54:48 zeek - looking at doc now... once I've found where I left my coffee.... Mar 24 13:58:33 seems like very few of the applying students have spent any time in here this year :( Mar 24 13:59:17 alexhiam... how does the doc look ? Mar 24 14:01:01 jic23, But I read that it is the slave that actually holds down sclk.The master only has to realize that SCLK is being held down?I think in master mode,that is what I would have to code? Mar 24 14:01:19 right Mar 24 14:01:45 alexhiam, That was for me? Mar 24 14:01:49 yeah Mar 24 14:02:18 basically just let go of the clock for every rising edge and wait for it to go high Mar 24 14:02:45 which will normally be right away, unless a slave is stretching the cycle Mar 24 14:03:00 alexhiam: I have uploaded blinky firmware on the Git repository Mar 24 14:03:44 It is meant to be used with CCS...so there should be no need for a separate program in Linux to upload the code onto the PRU memory space Mar 24 14:04:23 ZeekHuge: haven't looked to thoroughly yet, but looks good. A few comments to address still Mar 24 14:04:45 udayansinha: how's it loaded to the pru then? Mar 24 14:05:18 sure please add them on the doc or tell here whenever you get some time :) Mar 24 14:05:53 I mean the comments on there already, but I'll take a closer look later today and add any questions I have Mar 24 14:08:03 udayansinha: some more docs would be good. e.g. which pin/s is/are being toggled? How would you change the pin? Mar 24 14:09:52 wait I read it wrong....yeah the Linux program is required.....sorry my bad...will upload that too Mar 24 14:10:32 Erm....there are 16 bits....I am toggling the first 4 bits in this...... Mar 24 14:10:42 no prob. I'd also prefer to see it in it's own directory with its own README and Makefile as well Mar 24 14:10:54 right, so what pins does that correspond to? Mar 24 14:12:01 just some more inline comments to describe what it's doing would be good Mar 24 14:12:33 * alexhiam leaves to be a carpenter for the day... Mar 24 14:14:38 Pins 28-31 on the P9 header Mar 24 14:14:57 right I'll add these in the comments...and upload the Linux loader program Mar 24 14:15:27 and move em in a separate directory Mar 24 14:40:40 jic23, Would you want multimaster support in case I2C? Mar 24 14:42:50 Or that could be a secondary goal? Mar 24 14:54:44 ch - no. Not a feature I've ever cared about. Mar 24 14:55:03 Stick it down as a tertiary goal. It's moderately nasty to do! Mar 24 14:57:56 jic23, Okay.Not doing it would imply no need to care about conditions where two masters start simultaneous transmission. Mar 24 14:58:11 Would simplify work :) Mar 24 15:00:40 jic23: you had asked me to add a diagram showing how everything interacts with each other ....I just added one....could you look and temme if that's what you wanted? Mar 24 15:02:08 sure.. .link? Mar 24 15:02:40 https://drive.google.com/open?id=1Z057jsJVGK0YJzLluq5pCjtx_SI_IQ4F00oXNd9G4K0 Mar 24 15:03:00 rest of it is pretty much same except for minor changes here and there Mar 24 15:07:13 Nice diag and well worth having there - but that's a diag of how current pru to userspace works. Mar 24 15:07:55 yeah....I am planning to use the RPmsg framework itself Mar 24 15:08:09 you want one describing how the stackup works once you add the drivers you are developing as part of the project.... Mar 24 15:08:10 to get data from the SPI/I2C/UART interfaces Mar 24 15:08:18 So additional diagram. Mar 24 15:08:41 Same up to where you currently have userspace boundary. Mar 24 15:08:56 Above that add probably 3 more layers. Mar 24 15:09:02 For SPI they would be. Mar 24 15:09:21 1. SPI Driver (directly above the pru-rmsg) Mar 24 15:09:30 2. Spi Subsystem (above that) Mar 24 15:09:56 3. Device driver for whatever is on the spi bus. Mar 24 15:10:12 4. (I can't count) Subsystem for that - input, iio, hwmon etc. Mar 24 15:10:22 5. Userspace boundary. Mar 24 15:10:36 Linux kernel space is highly tiered! Mar 24 15:10:50 And there would be 3 sets of these in parallel eh....1 for each interface? Mar 24 15:11:06 although it would be unwise to use more than one at the same time Mar 24 15:11:06 nah, just one example would do or the doc will get too long and it'll show the same thing. Mar 24 15:11:13 Indeed, 1 at a time. Mar 24 15:11:30 will do :) Mar 24 15:11:31 Though you may well have multiple client drivers towards the top for spi / i2c. Mar 24 15:11:43 Ideally diag would show that as well... Mar 24 15:12:19 Then on that diag, highlight the bits that form key elements of your project. Mar 24 15:12:37 e.g. SPI Driver, SPI pru firmware. Mar 24 15:12:54 right yeah...should have thought of highlighting..... Mar 24 15:13:08 Makes it clear you get that, whilst crucial there can be a lot of existing stuff involved above and around what you are working on. Mar 24 15:13:50 Understanding those relationships is important bit of these projects (and kernel development in general). All about re-use of elements. Mar 24 15:14:21 yeah true Mar 24 15:15:04 Might also be worth inserting something near start of timeline about reviewing current directions of rpmesg and co - looks like it might be a bit up in the air at the mo. Not in a bad way, just not a fixed target! Mar 24 15:16:18 I have to go through more about RPMsg too.....read more basics Mar 24 15:21:34 Don't know if you saw discussion yesterday but looks like TI have thrown old implementation out and pretty much started again... Mar 24 15:24:59 yeah but it wasn't clear if they have completely discarded it or not :/ Mar 24 15:25:22 maybe good ol' char drivers if all's lost :/ Mar 24 15:33:53 Technically TI don't actually control what drivers for their hardware go upstream anyway so if they annoy us enough there is another way of doing it ;) Mar 24 15:34:01 Wouldn't be the first time! Mar 24 16:02:07 Hey Abhishek_, Mar 24 16:03:06 Abhishek_, as you instructed, i have tried to add details to the subsystem implementation .. please have a look : https://docs.google.com/document/d/1GfnoWusWUeH2VsLbt1qJaRi20uNxCC8O_Xw1CHoGY9A/edit?usp=sharing Mar 24 16:07:49 Hey rcn-ee ! It would be really great if you could provide your comments on this doc ! https://docs.google.com/document/d/1GfnoWusWUeH2VsLbt1qJaRi20uNxCC8O_Xw1CHoGY9A/edit?usp=sharing Mar 24 16:29:24 Abhishek_, ahh .... sorry if you are busy ... but did you read it ? Can definitely wait though :) Mar 24 17:08:57 jic23: i2c master implementation includes extended addressing to right? Mar 24 17:10:23 *too Mar 24 17:18:54 I2c 10 bit addresses rarely used and rarely supported... Mar 24 17:19:32 jic23, in UART also some kind of dev file is exposed to the userland? Mar 24 17:20:07 The driver would work in the same fashion as it works in case for I2C/SPI? Mar 24 17:21:32 Not really familiar with uart other than it being traditionally a maintainer grave yard.. Mar 24 17:22:13 okay so extended addressing is an extra? Mar 24 17:22:40 jic23, Data is also not readily available :( Mar 24 17:23:40 Yup. Mar 24 17:32:06 Copy what kernel bit banger does Mar 24 17:32:51 https://git.kernel.org/cgit/linux/kernel/git/jic23/iio.git/tree/drivers/i2c/algos/i2c-algo-bit.c?h=togreg&id=b8d1f261fe7e4967593a5637d62991b6197a03f8 Mar 24 17:33:08 I have my tree bookmarked :) Mar 24 17:33:27 Bit do addresd Mar 24 17:39:30 http://tldp.org/HOWTO/Serial-HOWTO.html Mar 24 17:41:04 alexhiam: there?? Mar 24 17:44:01 jic23: I was trying to understand the driver stack that you explained earlier....so (correct me if I'm wrong) we have the actual low level interface to the Soft SPI via RPmsg....above that we have some sort of transmission and reception control for this low level driver...above that we have the config for devices on the bus and finally just before the userspace we have the abstract file thing where all the settings and data Mar 24 17:44:04 right? Mar 24 17:46:08 jic23: I have put up the updated diag as well....just trying to understand what module does what in the whole stack Mar 24 17:53:51 hey ds2 ! there ? Mar 24 17:56:32 chanakya_vc: UARTs are typically exposed as a character device /dev/ttySx Mar 24 17:56:32 maintainer graveyard :D Mar 24 18:25:51 udayasinha - not quite. Mar 24 18:26:32 The subsystem cores (in the example say SPI and input) serve one real purpose and that is abstraction. Mar 24 18:26:45 Everything above doesn't want to know anything about the hardware below. Mar 24 18:27:13 Without a layer in between you'd have to say call spi_am335x_pru_spi_write Mar 24 18:27:33 You instead want to call simply spi_write and have some magic in between make the right things happen. Mar 24 18:27:51 yeah I got that....the spi driver right above the RPmsg framework is the real low level driver.....you're merely abstracting your way up right? Mar 24 18:27:53 It's not about transmission control or anything like that - it's about abstraction. Mar 24 18:28:06 Yup. Mar 24 18:28:17 the last one before the userspace is the one that presents the config and data in the form of files Mar 24 18:28:21 right? Mar 24 18:28:43 presents yes - is reponsible for knowing about them no. Mar 24 18:29:22 So take IIO sysfs interface. Mar 24 18:29:36 There you might find a file you can read from userspace to get an adc reading. Mar 24 18:30:06 The subsystem has created that file based on info from the adc driver. It might be in_voltage0_raw Mar 24 18:30:32 So userspace reads that file. Right at the top the filesystem subsystem has abstracted that read. Mar 24 18:30:34 this is the slave device subsystem? Mar 24 18:31:11 IIO is the subsystem responsible for presenting the stuff that the slave can do to userspace. Mar 24 18:31:30 The filesystem knows it is a sysfs file so passes it to the sysfs read_attr code. Mar 24 18:31:50 That then calls the callbacks that IIO core registered earlier. Mar 24 18:32:08 Those in turn call the read_raw callback of the ADC specific driver. Mar 24 18:32:31 That ADC driver creates a description of the spi transfers needed and requests those from the spi core. Mar 24 18:32:54 The spi core knows which spi master driver (bus adapter etc) has the adc on it. Mar 24 18:34:42 That then calls the relevant callback in that driver, spi_transfer_one_message Mar 24 18:34:56 So this is your SPI driver quite a few layers down from user space. Mar 24 18:35:19 but I gotta build all of those layers hmm Mar 24 18:35:26 No you don't. Mar 24 18:35:39 They are already there - all you have to do is bolt in the bits that are different. Mar 24 18:35:43 Two pieces. Mar 24 18:35:47 PRU firmware. Mar 24 18:35:51 SPI master adapter driver. Mar 24 18:36:03 + possibly a bit of stuff in rpmesg Mar 24 18:36:11 (though hopefully not) Mar 24 18:36:40 The point is to understand the function of the bits you are working on and how they fit into the whole. Mar 24 18:37:16 You absolutely must not replace any of the components elsewhere in the stack. Mar 24 18:37:37 So IIO subsystems present..this presents files to the userspace....then it's the slave specific driver.....then SPI core..then the actual master driver Mar 24 18:38:09 and the SPI core takes care of instances of both master as well as slave adapters right? Mar 24 18:38:27 no. As far as I know there is no SPI slave support in linux. Mar 24 18:38:48 Ooo....that explains for most of the SBCs don't seem to have it now Mar 24 18:38:56 *why Mar 24 18:39:09 It requires some really nasty handling - basically a PRU or similar before it can be done. Mar 24 18:39:44 And why would a big powerful board appear on SPI to some master? Just use a fast bus like ethernet if you have the grunt to do it. Mar 24 18:39:56 Honestly SPI slave is of limited interest to anyone. Mar 24 18:40:00 even for a PRU, it's a pretty much waste.....you'll have to poll the pins all the time for new data....any processing must be done on the fly while clocking in/out data Mar 24 18:40:14 alexhiam, ds2,jic23,m_w I have uploaded my draft proposal.Please have a look and let me know what you think of it. Mar 24 18:40:50 SPI/I2C slave modes is best handled by a hardware implementation I think.....you get interrupts to work with.....otherwise all the time goes waste in polling Mar 24 18:41:25 Having interrupt doesn't really help - handling them wouldn't be quick enough for spi slave. Mar 24 18:41:46 yeah gotta cap the bus rates Mar 24 18:41:47 Note that all fast stuff is done by polling. Crank up a network card and after a while it stops using interrupts and polls for new data. Mar 24 18:42:24 Not just capping. On a general purpose OS like linux, interrupts can take a long time depending on what else is going on. Mar 24 18:43:00 chanakya, only got a few mins, can you paste a link (I'm not a mentor - just a curious bystander - so can't look at the gsoc submissions) Mar 24 18:43:08 right....does the RT patch help with this? Mar 24 18:43:30 RT is about guaranteed timing - not fast timing. Mar 24 18:43:51 So helps, but doesn't solve. Could be done with a true realtime OS, but why would you? Mar 24 18:43:51 I know....but mostly real-time stuff tends to be faster as well Mar 24 18:44:08 even though it's not implied Mar 24 18:44:11 We aren't clocking out sensor data or similar, we can burst data far faster at a convenient time over a bus designed for that. Mar 24 18:44:46 Real time != faster Mar 24 18:44:50 real time is often SLOWER Mar 24 18:45:04 In bandwidth yes, in worst case it can be better. Mar 24 18:45:21 all real time means is there is a guarantee that things wil happen in bounded time Mar 24 18:45:25 Real question is does anyone have an application where spi slave on linux matters? Mar 24 18:45:35 yes Mar 24 18:45:36 I know......I know.....just saying...so far all the real-time systems I have met are also on the faster side.... Mar 24 18:46:13 take a look at the serious switching of ethernet packets. No real time guarantees, rediculous throughput rates. Mar 24 18:46:46 never worked with Ethernet....but I know it can be pathetic for worst case scenarios..... Mar 24 18:46:52 hey ds2 ! can you please take a look at this doc https://docs.google.com/document/d/1GfnoWusWUeH2VsLbt1qJaRi20uNxCC8O_Xw1CHoGY9A/edit?usp=sharing Mar 24 18:47:18 and I need some help on your last comments too Mar 24 18:47:19 the AM335x makes a great slaveback end for many apps - a slave SPI port is often useful there... much cheaper then a USB or ethernet link Mar 24 18:47:19 heard it's improving though....read some article about its possibility in replacing CAN in cars Mar 24 18:47:46 ZeekHuge: looking... have to be a quick look Mar 24 18:48:08 ohk .. Mar 24 18:48:47 ds2, So I didnt get your comment on page number 3. Mar 24 18:48:57 both of them .. Mar 24 18:48:59 ZeekHuge: strictly speaking GPMC doesn't always require fifos or fpgas.... many ADCs can drop in... worse case is some TTL level logic Mar 24 18:49:26 ok, maybe there is an app then. Talk to Mark Brown if you want to do it though... He's a nice friendly guy. Mar 24 18:49:27 ZeekHuge: you mean the DTO stuff? Mar 24 18:49:35 Also, http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/115941.html Mar 24 18:49:41 No the PRU stuff Mar 24 18:49:49 under the heading "Firmware" Mar 24 18:50:05 ds2: do you know about the blue project? Mar 24 18:50:16 ds2 - adcs on GPMC, where does the clocking control come from? Mar 24 18:50:24 ZeekHuge: oh the 2 PRUs? Mar 24 18:50:30 yes Mar 24 18:50:39 jic23: /CS or /RD prehaps? Mar 24 18:51:04 but only if the gpmc bus is clocking evenly. It's a memory bus so it won't. Fifo needed I think... Mar 24 18:51:08 ZeekHuge: there are 2 PRUs on the PRUSS...they can get input from different pins... one PRU shares a lot of pins with the LCD; the other doesn't Mar 24 18:51:23 jic23: DMA does an okay job (IMO) Mar 24 18:51:38 Ok isn't even sampling though... Depends what your target is I guess. Mar 24 18:51:51 ZeekHuge: the BeagleLogic approach is to PRUn does sampling, PRUn+1 copies data to DDR Mar 24 18:52:14 yes .. that is what I have tried to explain there too . Mar 24 18:52:20 jic23: well, if the sampling speed is close to the jitter of the bus, I agree; but for many sampling purposes, it can be slow enough that it doesn't matter too Mar 24 18:52:32 ds2, Have I made things confusing there ? Mar 24 18:52:34 sure, if slow enough should be fine I guess. Mar 24 18:52:41 ZeekHuge: other aspect of it is - there are 2 PRUs, the BeagleLogic strategy burns both Mar 24 18:53:07 Usually seen gpmc stuff used through an fpga that does the clock domain crossing via some fifos. Mar 24 18:53:15 yes .. that is why I have mentioned it to be the not the only approach. Mar 24 18:53:16 ZeekHuge: no no... I am just saying that you should make the work on either PRU0 either with 2 sets of firmware (compiled with #if's maybe) or generic coding Mar 24 18:53:31 Anyhow just curious to what people have gotten running on it :) Mar 24 18:53:35 jic23: not saying it can't be done that way... just saying it isn't required Mar 24 18:54:24 google was thin on examples when I looked (other than people failing to get it to work :) Mar 24 18:54:44 Anyhow, I should stop distracting from the purpose of this group! Mar 24 18:55:14 ZeekHuge: IMO - the GPMC burns more pins then I often have for my apps Mar 24 18:55:16 That will require some testing . isnt it ? And, I think beagleLogic provides us with lot of research in that.. showing that it may get very difficult for a single PRU. Mar 24 18:55:18 but that's MO Mar 24 18:55:32 ZeekHuge: it is hard, not impossible. I have done it Mar 24 18:55:42 On single PRU ? Mar 24 18:55:56 ZeekHuge: rather then push to DDR from the PRU; I pull from the ARM side (could be DMA) Mar 24 18:56:08 ZeekHuge: yes... one PRU to capture video; another PRU to generate video overlays Mar 24 18:56:21 so in my app I needed 2 PRUs. the burn one PRU was a non option Mar 24 18:56:26 ds2 - cool Mar 24 18:56:31 but that will be over L3 interconnect .. isnt it ? Mar 24 18:56:42 Zeek, crossed conversation here. Mar 24 18:56:46 ZeekHuge: it is the same one regardless Mar 24 18:57:00 or maybe not ;) Mar 24 18:57:05 DDR/ARM/DMA/PRUSS all sit on there Mar 24 18:57:09 jic23: close enough ;) Mar 24 18:57:16 oh sorry ! A DMA request would be over L4 interconnect Mar 24 18:57:44 ZeekHuge: ah, yes.... I needed code quick so I am burning cycles on the ARM with a memcpy on interrupt Mar 24 18:58:19 and I had a discussion on that with zmatt in #beagle, about the data transfer speed by using L4. Mar 24 18:58:33 saw that Mar 24 18:58:38 yes, you can saturate it Mar 24 18:58:56 Anyhow, I'm out for now. Good luck to all the students - look forward to seeing results. Feel free to cc me on any kernel stuff that people want review on jic23@kernel.org Mar 24 18:59:13 Any comments on my proposal ? Mar 24 18:59:28 STUDENTS: be sure to do a final submit...apprently it is not automatic Mar 24 18:59:42 Zeek, did you put in the progress through multiple versions on the linux side? Mar 24 19:00:01 ds2: Oh ! thank you for that :) Mar 24 19:00:18 jic23, that would be in the timeline ? isnt it ? Mar 24 19:00:59 Should i mention that in expatiation part also ? Mar 24 19:01:02 Yes, but it's more important than that. Right now (or earlier today anyway) your project looked like a huge amount of work. Point is to show that not all of it needs to be in place to have tangible benefits. Mar 24 19:02:07 Oh.. ahh .. Ohk. So I'll probably add a "Flow of project" section and mention in it .. will that work ? Mar 24 19:02:16 Yes. Mar 24 19:02:20 ZeekHuge: I can talk more later but I got a lunch appt and it is 1202 here. Sorry, gotta run Mar 24 19:02:31 Highlight also risks at various stages. Upstreaming fight back probably being the biggest! Mar 24 19:02:35 Sure :) I'll be here most probably. Mar 24 19:02:58 * ZeekHuge often falls asleep in his chair itself. Mar 24 19:03:07 jic23, I am some problems with the link.Can I forward it to the mail address you gave? Mar 24 19:03:21 *having Mar 24 19:03:25 Sure though can only give it a quick glance. Mar 24 19:03:39 Okay.I will send an invite to look. Mar 24 19:03:57 * ZeekHuge is amazed by jic23 's multitasking ! ;) Mar 24 19:04:22 Zeek, some of yours needs to be bounced in much wider lists than beagle specific ones (same is true for i2c / spi uart project btw) Mar 24 19:04:44 You'll need to be responsive to feedback for the project to be a success. Mar 24 19:04:54 I have sent it.Please take a look whenever you are free and post comments. Mar 24 19:05:24 ohk . Mar 24 19:05:59 chanakya, docs seems to be down... odd. Mar 24 19:06:22 Got a few more minutes as wife busy ;) Mar 24 19:06:29 It is behaving weirdly.What message is it giving Mar 24 19:06:47 Now i think should work Mar 24 19:06:52 jic23: updated my draft too with the diag Mar 24 19:07:05 it should be correct now Mar 24 19:07:14 jic23, ? Mar 24 19:07:27 udayan, I happen to be looking at yours whilst checking why I can't get to chanakya. Mar 24 19:07:36 okay :) Mar 24 19:08:05 Google Docs encountered an error. Please try reloading this page, or coming back to it in a few minutes. Mar 24 19:08:21 jic23, Did you get through.It shows that it has been shared with you sir. Mar 24 19:08:40 Or I think so atleast Mar 24 19:09:48 udayansinah - looks good. I'd be tempted to maybe give a concrete example. E.g. Touchscreen , input, etc. Also DT kicks in at all levels in this stack - not sure you need to show that though. Mar 24 19:10:11 chanakya, yeah, I got the email, it just won't let me in right now. Maybe a google server playing up somehwere. Mar 24 19:10:42 jic23, If you can't,I will mail you the doc.Maybe you could see it later? Mar 24 19:11:25 ah, could you send an invite to Jonathan.Cameron@gmail.com Mar 24 19:11:42 I fear chrome is playing games with me. Mar 24 19:11:55 okay lemme come up with something Mar 24 19:13:00 sent it.Did you receive? Mar 24 19:14:05 chanakya, I'm in. Mar 24 19:14:24 should a student submit the "hello world" program before submitting the proposal? Mar 24 19:14:38 Okay.It's not the final draft.Would be buliding on your suggestions Mar 24 19:15:02 join94, before the deadline i think. Mar 24 19:15:16 thank u Mar 24 19:47:57 hey bradfa ! please have a look at my proposal and suggest any corrections.. https://docs.google.com/document/d/1GfnoWusWUeH2VsLbt1qJaRi20uNxCC8O_Xw1CHoGY9A/edit?usp=sharing Mar 24 20:01:18 to how many projects can one apply ? Mar 24 20:02:07 join94: A maximum of 5 proposals across all possible orgs Mar 24 20:02:39 i.e. put all 5 in org for 5 projects or 2 in one org and 3 in the other, or 5 different proposals in 5 different orgs Mar 24 20:02:42 up to you Mar 24 20:02:58 but "Quality is better than Quantity" Mar 24 20:03:02 join94: iirc you can apply for up to 5 but google will only award a maximum of 1 to any student Mar 24 20:03:02 ZeekHuge: ok, I'll try to take a look, might not happen till tomorrow morning, ok? Mar 24 20:03:32 Sure ! Mar 24 20:03:44 Whenever you are free. Mar 24 20:04:33 bradfa, please add comments where you feel something is wrong/not clear Mar 24 20:08:03 Abhishek_, if you didn't notice that msg.. My proposal's here please have a look : https://docs.google.com/document/d/1GfnoWusWUeH2VsLbt1qJaRi20uNxCC8O_Xw1CHoGY9A/edit?usp=sharing Mar 24 20:08:19 m_w, Please have a look at the proposal?I think I have shared the doc with you. Mar 24 20:11:38 ZeekHuge: how fast can the PRU CLOCKIN be for the parallel capture? Mar 24 20:12:21 we can sample at 40 MSps Mar 24 20:12:51 so a signal with 20 MHz bandwidth can be detected. Mar 24 20:12:57 yes Mar 24 20:12:58 I am looking at it Mar 24 20:12:58 are you sure you have time for all three? Mar 24 20:13:24 There is a section below.. that explains the PRU part. Mar 24 20:13:40 m_w, Yes.I have made a timeline Mar 24 20:13:53 Please have a look at it. Mar 24 20:14:48 the timeline means nothing if you underestimate the time required to write the firmware and drivers for each Mar 24 20:15:24 each one is in a different subsystem with different requirements Mar 24 20:15:52 have you ever written a device driver for any of these subsystems? Mar 24 20:15:55 bradfa, is that part ok ? Mar 24 20:17:26 or even looked at them? Mar 24 20:18:39 m_w, I haven't.Yes I have been digging into i2c core.h and spi core.You would have noticed that I talk about the data structures and methods in them. I am confident that I can. Mar 24 20:19:45 And besides that I have left at least three weeks to cope up in the end.I think I can. Mar 24 20:20:47 you plan on sleeping? Mar 24 20:22:20 m_w, :) You could perhaps test me by giving some coding assignment after tomorrow? Mar 24 20:22:50 And it is currently 2 AM in my time-zone. Mar 24 20:23:05 we will see Mar 24 20:23:33 you going to work on the proposal more tomorrow? Mar 24 20:24:23 Yes I will.I have had suggestions from jic23b .Could you also maybe post comments? Mar 24 20:24:37 I am going to add diagrams to it. Mar 24 20:24:54 Hey mdp ! can you please take a look at my proposal : https://docs.google.com/document/d/1GfnoWusWUeH2VsLbt1qJaRi20uNxCC8O_Xw1CHoGY9A/edit?usp=sharing Mar 24 20:25:24 okay Mar 24 20:25:30 m_w, my proposal too please .. Mar 24 20:26:18 ZeekHuge, eager to get all mentors to look at his proposal ;) Mar 24 20:27:35 the more eyes the better Mar 24 20:27:43 Ofc I am.. had comparatively less time to get this far (timeline still remains) ... after the idea changes :) Mar 24 20:27:55 m_w, yes ... absolutely. Mar 24 20:30:13 chanakya_vc: no need to mention my name in the proposal Mar 24 20:30:34 Okay will remove all instances of it. Mar 24 20:30:45 my name is Welling not Wellings by the way Mar 24 20:31:44 Sorry for that :) Mar 24 20:47:55 so other mentors: does anyone else think that doing SPI, I2C and UART in PRU in one project may be too much work for one student? Mar 24 20:55:49 hi, Is visible my application in GSOC dashboard because i finalized my application and I would like to make sure that it is ok? Mar 24 21:34:32 okay... kind of back Mar 24 21:59:38 ds2,ARe you free?Can you take a look at my proposal? Mar 24 21:59:51 hello IRC Mar 24 21:59:52 not completely free... what's the link? Mar 24 22:00:30 I ahve shared it with the org Mar 24 22:00:35 have Mar 24 22:00:57 msg me the URL if you want me to look at it now otherwise, I won't get to it tonight Mar 24 22:01:03 til tonight Mar 24 22:01:36 phew ... Mar 24 22:01:39 Can i send you an invite to your mail? Mar 24 22:01:51 nevermind. just wait til tongiht Mar 24 22:01:54 * ZeekHuge was lost in some net split thing Mar 24 22:02:01 that was really scary Mar 24 22:03:07 ds2,I have sent you the invite.Please have a look at it whenever free. Mar 24 22:03:38 invites won't help... I have a seperate GSoC account and I don't have time to find that pw til later Mar 24 22:03:46 so either it is a public doc or nothing will happen to do til then Mar 24 22:04:55 https://docs.google.com/document/d/1uJnrXdMJB7tRFT49JOe2Bd7pBp3QfVsW0EndFHs8gzs/edit?usp=sharing Mar 24 22:04:59 Here you go Mar 24 22:05:30 If you are free please see it? Mar 24 22:10:55 chanakya_vc: please clarify on what you mean by that rpmsg section... the goal should be - HWstuff - PRU -> DRIVER -> i2c alg/uart (tty)/spi algs Mar 24 22:11:07 as describe it seems you want to do all sorts of userspace shannaigans Mar 24 22:11:23 you do not care about userland from your point of view. Your immediate consumer is another driver Mar 24 22:11:33 be it TTY layer, an I2C driver, or a SPI driver Mar 24 22:12:51 jkridner: I uploaded my proposal as a draft, I'm waiting for your feedback, I wrote my schedule and some implementation details for supporting python and C9. Mar 24 22:13:11 could you please comment at the place where you want the clarification.It would help me alot Mar 24 22:13:26 sorry, I can't do that easily w/o logging in Mar 24 22:13:40 if I can login easily, I could have gotten your proposal directly from there Mar 24 22:13:48 Ohkay,You could perhaps do that later? Mar 24 22:15:04 ds2,I mean to chose between core RPmsg and custom buffer to act as a means to pass message between ARM and PRU Mar 24 22:15:07 ds2: do you think that doing SPI, I2C and UART in one project is too much work for one GSOC? Mar 24 22:15:47 I was asking about this earlier and didn't get a lot of comments Mar 24 22:36:18 alexhiam,If you are there please check out my proposal Mar 24 22:37:48 I have sent you the invite Mar 24 22:44:47 m_w: I am okay with it either way Mar 24 22:45:05 chanakya_vc: then you need to talk about how is it getting out... i.e. registration as an i2c_alg, etc Mar 24 22:45:22 m_w: I personally think a I2C/UART/SPI driver is trivial but that's me :D Mar 24 22:46:20 you mean the i2c alg driver or the bitbanged implementation of i2c? Mar 24 22:46:36 the i2c alg driver Mar 24 22:46:45 bit bang i2c is pretty straight forward Mar 24 22:47:04 I have talked about it in brief.You would want more details on it? Mar 24 22:47:57 which page? Mar 24 22:48:05 you spend a lot of time on rpmsg and talk about userland Mar 24 22:48:19 there should be no userland piece unless you have a different project in mind Mar 24 22:48:54 No,In RPMsg I am talking about Vring data structures and mailbox in the DDR mem Mar 24 22:49:35 Basically comparing it to a scenario where we would use custom buffers for ARM to PRU communication Mar 24 22:49:42 okay Mar 24 22:49:46 why the long discussion on that? Mar 24 22:49:59 rpmsg is implemented already... are you planning to modify it or? Mar 24 22:50:02 <-- rather confused Mar 24 22:50:36 There are certain disadvantages if we would go for rpmsg core driver IMO Mar 24 22:50:52 I have written that. Mar 24 22:51:52 Infact I have written the advantages and disadvantages both,for both the ways.Using RPMsg or defining our own custom buffers in DDR memory Mar 24 22:52:28 yes, that is all fine Mar 24 22:52:39 this is suppose to illustrate connecting things up to normal APIs Mar 24 22:52:52 so more discussions on what APIs are you connecting to would be more in line with the project Mar 24 22:53:12 moving further along - what's with the CRC? please explain why it is even relevant for a UART Mar 24 22:53:38 Well it is a algorithim that is used for error detection Mar 24 22:53:43 Parity fails Mar 24 22:53:56 if more than two bits are corrupted. Mar 24 22:54:31 There are many such that exist.I can put it up as a secondary goal if you don't like the idea? Mar 24 22:55:29 wecan look at the HW side for I2C (the OC/OD stuff) later Mar 24 22:55:41 chanakya_vc: yes, I know what CRC is...how is that relevant to a UART?! Mar 24 22:56:11 CRC is applied to entire packets/messages. UART sees a character at a time Mar 24 22:56:29 it isn't like or not.. it is a lack of relevant Mar 24 22:56:56 hamming codes and ECC are also ways of dealing with errors but neither of htem are relevant in a normal UART Mar 24 22:56:57 Okay so not relevant.I will remove that Mar 24 22:57:16 a big part I see missing is a talk about which subsytem whih thing will go to Mar 24 22:57:32 i.e what was the I2C thing talk to, what does the UART thing talk to, what does the SPI parts talk to Mar 24 22:57:45 names of the subsystem/API/function calls would be good to mention Mar 24 22:58:03 there isn't time for me or any other mentor to walk through all the subsystem Mar 24 22:58:30 Okay I have mentioned at one place the add adapter routine that is called by the bus driver in the master driver Mar 24 22:59:05 And the associated data structure that are defined. Mar 24 22:59:12 But I will expand on that. Mar 24 22:59:46 Anything else? Mar 24 23:03:21 ds2: you ever written a controller driver before? Mar 24 23:03:25 uart stuff in the schedule seems a bit light Mar 24 23:03:36 m_w: yes Mar 24 23:04:07 what kind? is it mainline? Mar 24 23:04:16 ds2,What else would you suggest I put there? Mar 24 23:04:39 chanakya_vc: there is also a lot of talk about HW... let's focus on SW... and I fully second Jonathan's comment about userland stuff like the i2c-dev and spidev stuff Mar 24 23:04:59 chanakya_vc: how does a UART get exposed in Linux? Mar 24 23:06:01 sys/class/tty Mar 24 23:06:04 right? Mar 24 23:06:18 seriously? Mar 24 23:06:56 m_w, I am sorry if I am wrong :( Mar 24 23:07:00 /dev/ttyS* Mar 24 23:07:17 what does the name tty say? Mar 24 23:07:32 and what do you want to call the devices? Mar 24 23:07:37 ttyPRU? ttyP? Mar 24 23:07:50 those things would be nice to define Mar 24 23:08:29 http://free-electrons.com/doc/serial-drivers.pdf Mar 24 23:08:32 m_w: spi/i2c/uart drivers are pretty straight forward in Linux once you get the hang of it... in this case, the driver is largely take data from PRU and shove it into the subsystem and vice versa Mar 24 23:08:47 ds2,m_w: I would have to take a closer look at this. Mar 24 23:08:59 problem is the app needs to be somewhat convincing that one is able to "get the hang of it" Mar 24 23:09:00 :D Mar 24 23:09:34 ds2: this is true but these guys have little to no kernel experience Mar 24 23:10:12 ds2,Regarding the API's you mentioned earlier,you said that it would not be my job to work with API's and that I would be using the standard API's that exist right? Mar 24 23:10:32 m_w: *nod* hence I am also okay if they want to scale it back a little and pick one of them :D (wasn't intended to be vague in my answer to your Q)... one should know their limitations Mar 24 23:10:47 chanakya_vc: just looked through the updated app. Basically same comments from me as what's already on there Mar 24 23:11:08 chanakya_vc: it would not be your job to design the APIs outside of what you want to use for PRU-ARM Mar 24 23:11:37 I'd encourage you to spend some time looking into how these drivers are used by device drivers Mar 24 23:11:42 PRU-ARM might work okay with rpmsg or may be too heavy (I can see a follow up thing to optimize that comm path if needed) Mar 24 23:11:54 i.e. not from userspace Mar 24 23:12:37 i2c eeproms, for example, have pretty straight-forward protocols, so their drivers would be good to study Mar 24 23:12:58 to be fair... it is addressing this very confusion that we need examples Mar 24 23:13:06 too much crap is being circumvented in userland Mar 24 23:13:34 alexhiam, You would want me to look at the adapter drivers for these i2c eeproms? Mar 24 23:14:07 is adapter the right term for that? Mar 24 23:14:39 not sure... but to clarify - look at things like the omap-i2c driver Mar 24 23:14:41 maybe client is right one? Mar 24 23:15:16 you can just google 'i2c eeprom linux driver' Mar 24 23:16:35 ds2,So apart from talking about i2c algo driver , the subsystem and certain API's that would be used ,anything else? Mar 24 23:17:06 how realistic is the schedule Mar 24 23:17:20 alexhiam, Will do.I will look at Jonathan's comment and maybe change stuff? Mar 24 23:17:41 I have given a three week buffer to handle any unexpected delays Mar 24 23:18:08 the problem is you are brushing all this into the unexpected delays Mar 24 23:18:25 let's reserve unexpected delays for things that are truely unexpected. Mar 24 23:19:15 ds2,Okay,what would you suggest.Push UART as a secondary goal? Mar 24 23:19:45 it is like in the real world when managers try to schedule saturday and sunday then find that they are completely cornedwhen something unexpected happens Mar 24 23:20:12 your call Mar 24 23:20:23 know your limitations. Mar 24 23:21:09 ds2,If I do that would that be a considered a negative for my application? Mar 24 23:21:42 chanakya_vc: you got time to spend a few solid hours getting a better feel for how that stuff fits together and what the work would look like Mar 24 23:21:43 chanakya_vc: it depends, if you drop it hten schedule 4 weeks of vacation and partying, it would certainly be negative Mar 24 23:21:56 on the other hand, if you have legit things scheduled, it should be fine Mar 24 23:22:10 I'd suggest doing that - take some notes, sketch some diagrams - whatever works for you Mar 24 23:22:14 the problem is defining "legit things" :D Mar 24 23:23:54 ds2,I donot really have other commitments other than what I have mentioned in the timeline. Mar 24 23:24:57 ds2,All I am saying is that if I decide to drop UART ,would you give preference to an application that does do it? Mar 24 23:25:16 there is no yes/no answer to that Mar 24 23:25:28 Because I imagine that I2C/SPI might be a little trickier than it seems Mar 24 23:25:28 it depends on what is set out and how realistic Mar 24 23:25:49 projects that fail are good for no one. Mar 24 23:26:03 if you are more comfortable doing UART.... Mar 24 23:26:26 each has its thorns... I2C needs a decent OC/OD setup (there are special cases you can get away with, w/o that Mar 24 23:26:40 SPI might have speed issues and numberof chipselects Mar 24 23:26:42 and so forth Mar 24 23:28:06 Okay. I think I understand your point. Mar 24 23:30:52 ds2,One last confusion.In the userland I have to be only worried about certain API's right?I am not able to understand this.When we are exposing an I2C dev file,all APIs would work right? Mar 24 23:31:40 you are confusing a device driver with its userspace interface Mar 24 23:31:51 I have seen lots of this Mar 24 23:32:13 the device driver subsystem will take care of the userspace interface for you Mar 24 23:32:24 you just have to write the driver Mar 24 23:32:56 do not worry about userland Mar 24 23:33:04 there is no userland piece in what you are doing Mar 24 23:33:17 if you are concerned or modifying userland APIs, you are on the wrong track Mar 24 23:33:30 beyond any testing software that you may write Mar 24 23:33:42 to take this further, you should be able to set it so that it runs say a loopback code and then proceed to crash userland Mar 24 23:33:45 The master driver right(in case of SPI) right?This would talk to core driver.This would talk to the subsystem right? Mar 24 23:33:47 it should continue running. Mar 24 23:33:59 "core driver"? Mar 24 23:34:08 SPI core? Mar 24 23:34:12 you are writing the PRU facing version of the McSPI driver Mar 24 23:34:21 if you are going beyond a peer of the McSPI, you are in the wrong place Mar 24 23:34:35 does that clarify it? (trying to avoid terms that may be misunderstood) Mar 24 23:36:25 I thought the master driver(algorithim +adapter) was dependent on the SPI core driver? Mar 24 23:36:49 look at what the McSPI driver does Mar 24 23:36:57 (for I2C, it is the OMAP-i2c driver) Mar 24 23:37:07 uart is the 8250 driver Mar 24 23:37:11 those are your peers Mar 24 23:37:16 Like SPI core has a struct adapter_driver which defines an SPI adapter driver Mar 24 23:37:18 the PRU firmware is your "hardware" Mar 24 23:39:11 "Software-defined" hardware Mar 24 23:39:18 precisely Mar 24 23:39:51 if you are really really clever, (IIRC) TI wrote a UART driver for the PRUSS along with associated firmware Mar 24 23:40:07 the JTAG debugger idea didn't take off this year, did it? Mar 24 23:40:11 please credit/cite them if you find it and decide to use it Mar 24 23:40:18 Abhishek_: no bites, AFAIK Mar 24 23:41:19 I think the TI driver uses McASP not bitbanging Mar 24 23:41:45 m_w: what chip was that for? Mar 24 23:42:28 http://processors.wiki.ti.com/index.php/Soft-UART_Implementation_on_AM335X_PRU_-_Software_Users_Guide Mar 24 23:42:40 wow that got updated Mar 24 23:43:03 the one i saw was for another chip Mar 24 23:44:07 found it, you are right... that one also used the McASP Mar 24 23:44:13 the McASP makes handling buad rates much easier Mar 24 23:44:21 indeed Mar 24 23:44:35 the PRU would need to software divide 200MHz... which could get nasty Mar 24 23:44:43 exactly Mar 24 23:44:56 IIRC - 10% is good enough for most uses Mar 24 23:45:14 I think 115200 might work Mar 24 23:45:19 BeagleLogic does software division of sample rates Mar 24 23:45:23 a clever person would do the math and spec out the baud rates that don't work Mar 24 23:45:33 as in I can get 100/N MHz samplerates Mar 24 23:45:35 i.e only support 110, 300, 600, 1200 ;) j/k Mar 24 23:45:42 N = 1, 2, 3, .... Mar 24 23:45:45 ha Mar 24 23:46:15 you can dial into the old mainframe Mar 24 23:46:44 but specing it would show awareness of the issue Mar 24 23:47:03 i recall this very problem being discussed in school Mar 24 23:48:14 that is why we use a 18.432Mhz oscillator Mar 24 23:48:17 why do they use McASP to do UART through the PRUs I wonder Mar 24 23:48:35 m_w: or a 11.0592 MHz one Mar 24 23:48:44 or a 14.7456 MHz one Mar 24 23:48:58 or that's why using the stock 12MHz xtal on an 8051 won't work for all baudrates Mar 24 23:51:34 yeah... can't do more than 1200 on that IIRC Mar 24 23:52:23 I wonder what they are clocking McASP with Mar 24 23:52:41 slave mode/ master mode Mar 24 23:53:05 24.576 external clock on the BBB IIRC Mar 24 23:53:08 makes sense Mar 24 23:53:30 but wait.. isn't that for the HDMI framer? Mar 24 23:53:56 hmmmm Mar 24 23:54:15 mcasp is typically used for i2s right? Mar 24 23:54:35 ds2,So as far as I have realized McSPI comprises of core+adapter and are unique to AM35xx? Mar 24 23:54:42 yup Mar 24 23:54:57 the core is universal Mar 24 23:55:29 m_w, How does McSPI fit into this picture? Mar 24 23:55:35 it is for all SPI drivers Mar 24 23:55:54 mcspi is a controller driver for omap Mar 24 23:56:30 no Mar 24 23:56:38 the McSPI is present on many TI chips Mar 24 23:56:55 OMAP[2345], derivatives like the sitaras, etc Mar 24 23:56:57 Also on the CC3200 Mar 24 23:57:00 okay is ti chips Mar 24 23:57:18 wow the CC3200 has high end peripherals?! Mar 24 23:57:34 read this and see if it help clear things up: Mar 24 23:57:37 https://www.kernel.org/doc/Documentation/spi/spi-summary Mar 24 23:57:38 always thought it shares with the MSP430 Mar 24 23:57:55 But Alexhiam said that we would have mainline this project?Should we use something unique to TI for this(no expert on this) Mar 24 23:58:13 it is fine Mar 24 23:58:24 though mainlining can get tricky given the state of PRU support Mar 24 23:58:40 OTH - we should have no issue doing a full GPL firmware :D Mar 24 23:58:49 mainlining would be blocked for a long time Mar 24 23:59:30 I think it would have served the GSoC purpose if we can get beagle bone users to start doing things the proper Linux way Mar 24 23:59:38 mainlining would be the cherry on the sundae Mar 24 23:59:43 yeah Mar 25 00:00:24 I think that the mainlining process is going to take way too long for one gsoc Mar 25 00:00:45 no arguments on that Mar 25 00:00:57 the idea is you keep working on the project after Mar 25 00:01:22 ds2,m_w You would want that I use that McSPI for this right?And the idea earlier of writing a bus driver communicating with RPMsg core is not good right? Mar 25 00:01:34 if we want to mainline this, there needs to be a follow on clean up for DT Mar 25 00:01:47 as defined right now, it isn't to reasonable on the DT end Mar 25 00:01:57 chanakya_vc: NO! Mar 25 00:02:07 mcspi is a high end SPI controller Mar 25 00:02:17 the McSPI is an example what what the driver needs to do. the PRU will do the same job as the McSPI Mar 25 00:02:24 think of the PRU as way to add more SPI buses Mar 25 00:02:52 lemme see if I can find a simple SPI controller example in the kernel Mar 25 00:03:05 there is a bitbang SPI controller in there Mar 25 00:03:17 Okkay.I finally got what you are trying to say. Phewww..You were giving McSPI as an example. Mar 25 00:04:02 Excuse me, may I quickly interrupt as I have problems loging in to propose my GSOC project. After creating a wordpress account (beagleboardproject16.wordpress.com) I am unable to login as there is no reaction (including error) when entering this address and then clicking login. Help is appreciated. Mar 25 00:04:24 And I was thinking all my research into writing bus driver was waste. Mar 25 00:05:25 ds2,m_w,I will look at exactly how does this McSPI works and emulate the same model for PRU? Mar 25 00:05:37 no Mar 25 00:05:47 chanakya_vc: sort of... the McSPI has HW quirks and support for stuff you don't need Mar 25 00:05:53 too much going on there Mar 25 00:06:02 that is an understatement :D Mar 25 00:06:28 it is a bad example Mar 25 00:06:32 ;) Mar 25 00:06:46 ds2,m_w I donot think I will have the time to understand everything and update my proposal before the deadline Mar 25 00:07:12 start simple and add functionality Mar 25 00:08:09 I will maybe allot time to do so in the coding period. And ds2,I need to work upon your suggestion to update my proposal.So would that be fine with you? Mar 25 00:09:10 If I left the part about the details of the bus driver for the pre-coding or coding period?Like I would mention the basic framework. Mar 25 00:09:22 do your best with the proposal and be sure to officially submit a final PDF or it will all be for nothing Mar 25 00:09:44 it is understood you are not master kernel developers Mar 25 00:09:50 how much time is left? Mar 25 00:10:03 less then 24, IIRC Mar 25 00:10:09 18 hours Mar 25 00:10:10 saw a 33hr countdown this morning Mar 25 00:11:53 ds2,I will try my best to incorporate your suggestions. And I am sorry regarding the UART bit :) Mar 25 00:12:04 So, can anyone help me with my login problem? I assume I read the register isntructions right as another guy in the beagle IRC read it the same... Mar 25 00:12:11 the spi_gpio.c driver is a nice simple controller example Mar 25 00:12:59 m_w, Okay will look at it.Got to sleep now.Nearly 6 am here :) Mar 25 00:13:19 good night, set your alarm! Mar 25 00:14:16 beagleboardproje: not sure what is going wrong there Mar 25 00:14:42 so, I did the process right. Correct? Mar 25 00:15:49 what you listed does not look familiar Mar 25 00:16:23 do you have a gmail account? Mar 25 00:16:47 You mean my approach? I followed the instructions on https://beagleboard.org/register Mar 25 00:17:02 that is for adding an entry to the project list Mar 25 00:17:04 I do and I tried. Same result. I also turned off any addons Mar 25 00:17:07 is that what you want? Mar 25 00:17:27 yes, I would like to add an entry to the project list. Mar 25 00:17:38 ask in #beagle... it is not a GSoC thing Mar 25 00:17:49 and check the time Mar 25 00:17:57 IIRC - that website can get desynced so the auth never works Mar 25 00:18:05 ah Mar 25 00:18:16 I did and no one was able to help, so thought maybe you can Mar 25 00:18:32 are you on the beagle ML? Mar 25 00:18:38 if so, post something there Mar 25 00:19:13 to register a GSOC project go here:https://developers.google.com/open-source/gsoc/ Mar 25 00:19:44 it is pretty late in the game though Mar 25 00:19:50 I will try again tomorrow morning and then I will try the mailing list. Thanks. Mar 25 00:21:14 As I understand it I am also supposed to register the project on beagleboard.org. Anyway, thanks for the help. Mar 25 00:21:38 okay Mar 25 00:22:00 bye Mar 25 00:22:49 me thinks he is getting ahead of himself Mar 25 00:24:50 "Once accepted, the project must be registered on http://beagleboard.org/project" Mar 25 00:27:03 maybe just really confident Mar 25 00:27:13 :) Mar 25 00:45:29 Hi I found I just found out about GSoC and I know it's a little late, but if I have an idea I want to propose do I need to upload it as an first idea or may I only submit my proposal? Mar 25 00:45:51 you should talk to folks here first Mar 25 00:45:53 *idea first Mar 25 00:46:06 but wouldn't hurt to upload the app since that closes in like 15 hours Mar 25 00:50:14 thetonio96: what is your idea? Mar 25 00:52:57 An alarm system that communicates with wired and wireless (iot) sensors Mar 25 00:54:09 how will the beagle community benefit from the project? Mar 25 00:54:17 you do need to post the "draft" and not just the pdf Mar 25 00:54:35 if you want us to see it before it's too late Mar 25 00:58:12 Yea I'm trying to formulate that right now, but I don't not sure if I will be able to finish Mar 25 00:58:22 I guess the overall open-source community could benefit Mar 25 00:59:26 platforms are good, products less good Mar 25 01:00:11 I wanted to make it plugin-able, so you could connected with whatever platform Mar 25 01:00:25 what kind of software stack are you thinking? Mar 25 01:00:35 why do you want to do this instead of doing it on say a cortex-m0 SoC? Mar 25 01:01:04 is the beagle an IOT hub? Mar 25 01:02:25 bluetooth, wifi, zigbee? Mar 25 01:02:44 maybe a REST API for data to stream to whom ever wanted to listen (server, robot, ..etc) Mar 25 01:02:46 smoke signal? subaudible hints? Mar 25 01:04:48 wifi or ethernet for beagle and ESP8266 for the sensors Mar 25 01:05:07 okay Mar 25 01:07:49 are you writing the APIs from scratch or levaraging some existing code base? Mar 25 01:13:53 From what I searched think I will make it from scratch, but take in considaration other projects Mar 25 01:17:40 will it connect to the "cloud"? Mar 25 01:19:01 how will the network be secured? Mar 25 02:26:49 m_w: can you please review my proposal? Mar 25 02:27:13 https://docs.google.com/document/d/1bc2T1tu-WAkzB8M_SXzTmzQ7yzkAR1O_2jPslNjfO1c/edit?usp=sharing Mar 25 02:34:51 okay Mar 25 02:36:45 right in the intro, you say you are developing adrupilot and standalone ROS Mar 25 02:38:35 i would clarify that at bit **** ENDING LOGGING AT Fri Mar 25 02:59:59 2016