**** BEGIN LOGGING AT Tue Mar 22 02:59:58 2016 Mar 22 07:59:52 Quiet on here this time of day! Mar 22 08:00:18 Will drop back later. Mar 22 08:09:05 Hello Mar 22 08:10:58 i request all the mentors to review my application and give their feedback on it. Mar 22 08:17:23 @Abhishek_ are you there? Mar 22 08:39:26 I had few questions about the idea which involves bit-banging I2C, UART & SPI for the PRU Mar 22 08:39:34 udayansinha: yes, but not completely. Leave your queries and I'll answer them when I'm able to Mar 22 08:39:47 I had few questions about the idea which involves bit-banging I2C, UART & SPI for the PRU Mar 22 08:40:47 I would be expected to write code only for implementing the master modes in SPI & I2C? Mar 22 08:42:58 I suppose writing slave modes isn't needed?.....it would be pretty impractical as I would have to continuously poll the pins eh? Mar 22 08:44:31 I got a little confused coz daunted posted on my draft asking for details about modes, master/slave config, etc.... Mar 22 09:08:17 paging jic23 Mar 22 09:09:51 Abhishek, here now, though intermittently and not for log. Mar 22 09:10:26 same with me here. Mar 22 09:10:45 long. Gah, somehow IRC brings out the worst in my typing. Mar 22 09:11:01 Anyhow, why the ping? Respond to master / slave i2c question? Mar 22 09:11:25 Yup, to the query posted above. Mar 22 09:12:32 Hmm... slave mode would indeed involve basically continuously polling the pins I think. Mar 22 09:12:57 Would be interesting but nowhere near as interesting as the master side of things from point of view of number of users. Mar 22 09:13:02 the PRU can do that Mar 22 09:13:22 I did see one possible reasoning being that the i2c slave support on the am355x-i2c controllers is rather slow? Mar 22 09:13:43 Would be an interesting project, but what the applications? Mar 22 09:13:46 Faking sensors? Mar 22 09:13:53 (slave support that is!) Mar 22 09:13:57 yeah as a master, PRU controls the bus...so I don't have to spend time polling..... Mar 22 09:14:15 probably.....or as a test jig for some master? Mar 22 09:14:26 Bit more complex in i2c because of clock stretching even when master. Mar 22 09:14:39 Basically i2c slave can say 'I'm not ready yet!' Mar 22 09:14:46 yeah plus all the stuff for syncing and handshaking Mar 22 09:15:08 Most of the rest of the timing is in control of the master. Mar 22 09:15:19 (possibly all of it - not read the spec for a while!) Mar 22 09:15:21 I was thinking GPIO interrupts instead of polling for slave mode...doesn't help with the complexity though Mar 22 09:15:39 yeah, I think polling would be the way to go. Mar 22 09:15:48 maybe I can suggest it in extras? or a idea for future additions? Mar 22 09:15:55 *an Mar 22 09:16:12 Could do... Mar 22 09:16:21 cool thanks Mar 22 09:18:05 Not sure there is any core kernel support for spi slaves anyway so that one would be 'interesting'. There are various discussions that google is feeding me but no code. Mar 22 09:18:24 i2c slave is much better supported, but you will need a recent kernel. This stuff should be done with current mainline. Mar 22 09:18:40 (not 4.1 which is I think last semi official beagleboard kernel) Mar 22 09:19:09 *hate windows - just took 10 minutes to connect to a share* Mar 22 09:19:37 hmm okay.... Mar 22 09:20:33 Don't worry about the kernel stuff - it's easy to forward port what you need of beaglebone support - I'm running 4.4 currently. Mar 22 09:20:53 Maybe, put it on your list of stuff to do before the project starts though. Mar 22 09:21:37 so my main focus remains master modes of SPI & I2C and UART...okay Mar 22 09:22:17 right...I already have that....going through a bunch of docs in the months before the project starts Mar 22 09:24:50 Hihi Mar 22 09:25:37 I was looking the project where there is a need to write API's for BeagleBone Blue Mar 22 09:26:09 Could anyone help me understand the exactly what is to be done ? Mar 22 09:33:59 ud - (sorry for lazy abreviation ;) Note for the UART that because of baudrate fun you'll probably want to use the hardware support on the PRU rather than bitbanging. Mar 22 09:34:35 mn - sorry, not my area and off to do some work now. Back later. Mar 22 09:34:46 yup, not many examples for that (PRU UART) Mar 22 09:36:47 yeah I forgot PRU have HW UART...my bad Mar 22 09:54:57 There is the assembly stuff for the PRU Uart I think from TI which should help with any 'interesting' sections of the datasheet. Mar 22 10:09:03 okay will look into them Mar 22 10:45:07 jic23 - what is the maximum speed expected to be achieved from the software SPI? Mar 22 10:46:19 according to AM335x datasheet, the hardware SPI has a peak speed of 48MHz in master mode and 16MHz in slave mode Mar 22 10:46:48 I am guessing something around 20MHz or better? Mar 22 12:22:47 udayansinha: you are asking what the max expected speed in master mode or in slave mode would be for a PRU SPI interface? Mar 22 13:17:37 Hello there Mar 22 13:18:50 anyone Working on PRU ideas for this year GSOC Mar 22 13:18:53 ?? Mar 22 13:55:01 udayansinha - difficult to be completely sure, but master wise, bitbanging you should be able to do 50MHz in any of the clock modes Mar 22 13:55:14 Not necessarily all that much that will talk to you that fast though. Mar 22 13:55:54 Slave mode, not quite as quick I would guess but not certain... Mar 22 13:56:41 So sure, 20MHz should be easy enough. In spi the big thing is usually keeping the OS (and here PRU transfer) overheads minimal to keep the throughput up. Mar 22 13:57:37 cf_khan - far as I can tell all the students on here are working on PRU project proposals! (or almost all anyway) Mar 22 14:27:03 udayansinha - http://exploringbeaglebone.com/chapter13 suggests he got SPI clocking along at around 23MHz but it look to be somewhat nefarious ;) Uneven mark space ratio fun and games to speed it up Mar 22 14:29:50 Interesting strategy and should bring theoretical maximum bitbanging up a touch as you only need to offset the data vs say the rising edge of the clock. Falling can be quicker as the data line and clock can be dropped together. Mar 22 14:35:52 right okay :) Mar 22 14:36:33 and 400kbps for I2C master I suppose? Mar 22 14:36:34 (slave being a possible optional later on) Mar 22 15:04:55 av500, ds2, karki_, nerdboy, panto-cloud, vvu can you please review my proposal? Mar 22 15:09:32 * karki_ just came back from a week long holiday in Singapore :) Mar 22 15:10:31 jic23- are you there? Mar 22 15:12:01 karki_: did you get my message? Mar 22 15:46:00 alexhiam: Hi1 Mar 22 15:46:11 ahoy Mar 22 15:46:22 alexhiam: I've been waiting for you since long!! Mar 22 15:46:29 alexhiam, Hey!Just wanted to ask you about rpmsg.Now In my understanding the rpmsg core driver is responsible for providing the Vring data structure and gives us the ability to write into buffers. Mar 22 15:46:38 alexhiam: can you please review my proposal? Mar 22 15:46:50 kiran4399: looking at it now... Mar 22 15:47:45 Now can my driver just replace the prus_rpmsg and work with the core rpmsg driver? Mar 22 15:48:43 chanakya_vc: i.e. reimplement an rpmsg driver for the PRUSS? Why would you want to do that? Mar 22 15:49:30 pru _rpmsg in my understanding is only exposing a character device file to the userland. Mar 22 15:50:27 The vring data structure and mailbox kick is provided by the core driver. Mar 22 15:51:16 chanakya_vc: oh. But aren't there examples in the TI workshop stuff that use rpmsg for kernel<->pru communication? Mar 22 15:52:13 Or the other way could be to write to this char dev file.That is my adapter driver+algorithim driver would write to this char dev file.And expose a spidev file to the userland to which the userland API's would write. Mar 22 15:53:52 That way we could just integrate in the existing system of rpmsg.But IMO ,it would cause additional software overheads. Mar 22 15:55:30 chanakya_vc: yeah, I don't like that method. But have you looked through all that workshop stuff? Surely there's something there that isn't using a char device? Mar 22 15:55:37 But I am pretty sure that RPmsg_PRu is only responsible for userland interface for the core Rpmsg driver. Mar 22 15:55:58 http://processors.wiki.ti.com/index.php/PRU-ICSS_Remoteproc_and_RPMsg Mar 22 15:56:58 chanakya_vc: I agree that you definitely don't want to go the char device route. It would be good if you could do some more research on that to figure out exactly what you would need to implement Mar 22 15:58:23 if that means just starting with the core rpmsg driver "from scratch" that's fine, but definitely take some time to make sure that's the case Mar 22 15:58:33 in other words I have no idea :P Mar 22 16:01:09 alexhiam, What I was thinking is to provide a driver just to provide a driver like the PRU_Rpmsg but to expose a spidev file.What I was thinking was that when we do ioctls for sending parameters we could send it via the existing rpmsg core to a certain specified buffer. Mar 22 16:02:13 And then when the PRU discovers a kick in its mailbox,we could code the firmware to pick up the parameters from that buffer?How does that sound to you? Mar 22 16:02:35 This is if we want to go through the rpmsg route at all. Mar 22 16:02:57 chanakya_vc: hmm, I think you'd want the ioctls to go through your driver so it knows the state of the firmware Mar 22 16:03:39 also remember that spidev is just a small part of Linux SPI, and it also needs to adhere fully to the SPI spec so it can be used from other device drivers Mar 22 16:04:56 considering that I'm inclined to say it would be better for the driver to fully implement the SPI API, and just use a slim rpmsg (or whatever) layer to pass everything to the PRU Mar 22 16:05:10 i.e. everything goes through that 'top level' driver Mar 22 16:05:43 that way you'd also be relying less on rpmsg, which might end up not being the best thing to use anyways Mar 22 16:06:21 The rpmsg core is designed to only talk to a kernel driver on the userland side I think that is it is not designed to expose a dev file.Everything would pass through the main driver. Mar 22 16:07:29 chanakya_vc: so it is sounding like just using the core driver is the way to go Mar 22 16:08:41 Or the other simpler way would be to just get the driver to write to custom circular buffers in the shared mem.And when the ARM processor would write to it,we could set up flags at certain bits in the shared mem. Mar 22 16:09:01 these bits could be continuously polled by the PRU Mar 22 16:10:15 chanakya_vc: or downcalls Mar 22 16:10:24 Whenever it discovers a flag,it could just start reading from the buffer.But this would involve a lot more coding than using Rpmsg Mar 22 16:10:36 be sure to mention all the possibilities in your proposal, ideally with some pros and cons Mar 22 16:11:40 Okay.But the ideas do sound doable right? Mar 22 16:12:37 kiran4399 and Kartik docs looking better... Mar 22 16:16:25 alexhiam, I also had some doubts regarding ioctls.What I understand is that they are some special functions that basically allow us to pass parameters from the userland to the driver right? Mar 22 16:16:56 chanakya_vc: right, by way of the same file descriptors used for data Mar 22 16:17:30 http://man7.org/linux/man-pages/man2/ioctl.2.html Mar 22 16:18:03 chanakya_vc: a good thing to do now would be to write a very simple driver that implements some ioctls Mar 22 16:20:32 alexhiam, And they are a part of the SPI specs in Linux .So I would have to include them because all userland API's use these only to pass parameters to SPI/I2C controllers right? Mar 22 16:20:54 chanakya_vc: yup Mar 22 16:21:46 Basically it is a way to tell my driver that the user is sending in parameters right?.And then my driver can follow the method of writing it to the shared mem right? Mar 22 16:21:50 alexhiam: and also.. Abhishek told me that there is a pwm subsystem driver which was written by panto earlier.. can you help me get a link? Mar 22 16:22:09 m_w, Thanks for the link.Will look it up :) Mar 22 16:22:25 kiran4399: it's in the drivers directory of beagleboard/linux Mar 22 16:22:54 here is a break down: http://opensourceforu.efytimes.com/2011/08/io-control-in-linux/ Mar 22 16:25:39 guys, just to reemphasize. No one is writing chardevs for spidev. That's a freebie if you write a proper spi driver. Mar 22 16:25:53 (seems people are getting confused on that point). Mar 22 16:26:25 Only reason to ever role your own chardev driver is if there isn't a suitable subsystem in linux. Mar 22 16:26:31 roll. Mar 22 16:26:37 Gah. Spelling out today. Mar 22 16:26:59 it is good to understand how it works though Mar 22 16:27:11 yes, everyone listen to jic23_! Mar 22 16:27:29 that goes for spi, i2c, uart, etc. Mar 22 16:28:50 Sure in general terms, but detailed understanding not needed for any of these projects to write drivers for standard stuff. Mar 22 16:29:01 this is true Mar 22 16:29:06 kiran4399: ok, put comments everywhere I'd like some more info. Otherwise looks good Mar 22 16:29:46 jic23_, alexhiam ,What I meant to say was to say that SPI driver would be exposing a spidev file.Char dev file is exposed by the PRU_rpmsg driver Mar 22 16:29:51 https://www.kernel.org/doc/htmldocs/device-drivers/spi.html Mar 22 16:30:42 Who is steve arnold here?? Mar 22 16:30:42 And I thought we could perhaps remove the layer of pru_rpmsg and let our driver directly talk to rpmsg core. Mar 22 16:30:58 kiran4399, nerdboy I guess. Mar 22 16:31:41 hey jic23_ ! Mar 22 16:31:50 Hi ZeekHuge Mar 22 16:31:59 Only passing through... Mar 22 16:32:03 so i have made some changes to the doc ! Mar 22 16:32:11 ahh .. No problem :) Mar 22 16:33:12 Trips backwards and forward to an X-ray machine next door to test some stuff. Only at PC for a few mins at a time. Mar 22 16:37:31 chanakya_vc: yeah, I gotcha. No need for that extra rpmsg char dev file Mar 22 16:39:11 kiran4399: Steve Arnold == nerdboy == mr_science Mar 22 16:39:26 alexhiam, their is a virtio based implementation too .. to communicate between pru -ARM Mar 22 16:39:36 it used vrings Mar 22 16:39:48 ZeekHuge, It is rpmsg Mar 22 16:39:56 and no the original rpmsg framework Mar 22 16:40:03 *not Mar 22 16:40:13 rpmsg is based on virtio I guess? Mar 22 16:40:27 is that mr_science guy hanging out here too? Mar 22 16:40:31 yes that is .. Mar 22 16:40:57 It implements the system of used and available buffers along with mailbox kicks. Mar 22 16:41:08 but vring based implementation is free of that srd-destination overhead i guess . Mar 22 16:41:31 * nerdboy forgets and leaves office laptop logged in... Mar 22 16:41:37 *src-destination Mar 22 16:43:19 ZeekHuge, Okay.But there could be unnecessary software overheads while all we want is the PRU to read/write from a buffer in the shared mem? Mar 22 16:44:40 alexhiam, So I could propose using the core driver right?And you would want me to write a driver to implement ioctls? Mar 22 16:45:05 chanakya_vc: that would be a good way to make sure you understand them Mar 22 16:45:09 but not required Mar 22 16:48:43 Okay. I will write it maybe after I complete my proposal.But I think a simple read/write to a custom buffer would be more efficient than Rpmsg.Also,the cross compilation task has to be done before 24? Mar 22 16:50:32 one thing to consider is how big are your data units Mar 22 16:53:33 ds2, I think that even if we were to write a byte at one time,custom buffers would gives us more freedom right?I am assuming that in rpmsg the size of buffers is fixed? Mar 22 16:54:22 chanakya_vc: for small stuff at low data rates, wouldn't having a tested framework outweigh a lot of things? Mar 22 16:57:47 chanakya_vc: it might be good to think about what the worst case scenario could be Mar 22 16:58:40 would it be high-rate single register reads from a sensor? reading the entire contents of an eeprom in one transaction? Mar 22 16:59:07 ds2, It would definitely.But I am assuming that the project demands to look at bigger data at higher rates.I mean if we were to bitbang in linux for higher data rates would be disastrous.It would def consume more CPU resources right? Mar 22 16:59:32 those are two extremes that might be good to consider for each possible method of arm<->pru 'protocols' Mar 22 17:01:45 alexhiam, Wouldn't that depend upon the type of sensor?I mean I donot think that all sensors have single registers?And SPI model dictates that at a single time we can only exchange data between a master register and a slave? Mar 22 17:02:02 *particular Mar 22 17:02:06 time Mar 22 17:02:41 chanakya_vc: I don't have any specific sensor in mind - I just mean high rate sampling from a device Mar 22 17:02:46 could be an ADC or something Mar 22 17:03:21 But if we were to interface with say a memory device? Mar 22 17:04:58 ZeekHuge: were you going to add anything on gpmc? Mar 22 17:05:29 yes,it would be data rate/volume specific Mar 22 17:08:19 ds2, So I think I will mention both in my proposal. However,I donot think it will be possible for me to decide on one without extensive testing. Mar 22 17:09:14 ds2, What do you think about that Mar 22 17:13:10 nerdboy, not really , was just investigating on its pros and cons . Mar 22 17:13:37 chanakya_vc, by shared memory, do you mean the one on the PRUSS subsystem ? Mar 22 17:13:46 right, so discuss that a little? Mar 22 17:13:52 sure .. Mar 22 17:14:08 well, so the point was on its usability.. Mar 22 17:14:31 probably doesn't need more than a few sentences Mar 22 17:18:13 Cha- spi doesn't mandate any particular register access patterns. Most decent sensors do burst reads with auto incremented register addresses. Mar 22 17:18:30 Same with eeproms iirc Mar 22 17:20:19 chanakya_vc: I am fine with that as long as the scheduling reflexthat Mar 22 17:21:20 _av500_, av500: someone else gonna lead the meeting tomorrow? Mar 22 17:21:33 or do you need someone? Mar 22 17:22:26 Zeek, in first paragraph note commercial boards often price sensitive as well! Mar 22 17:22:42 * nerdboy watches everyone else step back Mar 22 17:22:54 alexhiam: looks like you're elected Mar 22 17:23:04 Can't comment in doc as on phone... Mar 22 17:23:08 lol, I'm down Mar 22 17:24:31 ohk jic23b , how about the diagrams ? Mar 22 17:24:48 Zeek note that polled parallel reads require a true real-time OS as well if fast. Mar 22 17:25:02 Not got that far yet! Mar 22 17:26:05 In FPGA discussion might be worth mentioning even cheap FPGAs have lvds these days. Mar 22 17:27:22 Careful on pushing realtime. You are going to have a non trivial Fifo or blocksize as well... Mar 22 17:31:33 Maybe emphasise parallel driver userspace is only one option. Consumer drivers will be needed for specific things using a parport offload. Mar 22 17:32:28 jic23b, about that non-trivial fifo that you mentioned, wont that depend on the mode of operation ? Mar 22 17:33:19 like, we can have burst mode read, but we can also have read-leave mode , like just read when asked ? Mar 22 17:33:27 Reading from ADC at speed will need on at userspace boundary if not before. Mar 22 17:33:49 Sure could do slow stuff but not really interesting. Mar 22 17:34:03 yes thats true .. Mar 22 17:34:12 how about the flow diagrams ? Mar 22 17:34:30 did you reach there ? Mar 22 17:35:20 Diags looking much better. Mar 22 17:36:20 Make it clear where project scope lies. Mar 22 17:37:25 yeah.. the proposal at present is more focused on the parallel pru stuff than the kernel part.. Mar 22 17:37:35 have to work on that .. Mar 22 17:37:47 Also where not well defined make it clear that discussions need to be started or testing done as relevant. Mar 22 17:38:37 However don't throw too much all on one diag. Can repeat overview with different aspects brought out if needed. Mar 22 17:39:49 Yup. Mostly a kernel side project for this one. Mar 22 17:40:09 School run back later. Mar 22 18:03:25 alexhiam, jic23, bradfa, : I have incorporated some suggested changes and I have made more additions to the draft...could you read it and temme if I am missing anything more? Mar 22 18:04:12 https://drive.google.com/open?id=1Z057jsJVGK0YJzLluq5pCjtx_SI_IQ4F00oXNd9G4K0 Mar 22 18:05:22 the mentor meeting is tomorrow correct? Mar 22 18:06:58 yep Mar 22 18:07:51 is it only a mentor meeting? Mar 22 18:08:08 last meeting before proposal deadline, shouldn't students be involved? Mar 22 18:08:58 we can just use this IRC if you want students to be involved Mar 22 18:10:37 yeah otherwise the meeting happens in #beagle-mentors Mar 22 18:14:28 carpediem_: where's your proposal?? Mar 22 18:15:25 Working on it. Mar 22 18:15:33 I was looking for you for so many days Mar 22 18:15:41 Final stages Mar 22 18:15:44 Submitting ASAP Mar 22 18:16:00 carpediem_: can you just submit whatever you have now? Mar 22 18:16:12 so little time now to get feedback and update as needed! Mar 22 18:16:15 Have a look, this is for the first application. Working on the PyBBIO one currently. Mar 22 18:16:29 https://docs.google.com/document/d/1V5R3Plt-dWHpLL-S61gJmtnA8AfoLOlTPV8ISeWxP_Y/edit# Mar 22 18:17:16 carpediem_: needs to be on summerofcode.withgoogle.com or it's not real! Mar 22 18:18:59 OK. Will submit it ASAP. Mar 22 18:24:02 seize the day Mar 22 18:30:59 udayansinha - added a few suggestions/ comments to your doc. Mostly looking fine though. Maybe a diagram to show where you bits fit into the existing stack from pru to userspace might be useful? Mar 22 18:34:08 Jic23: are you referring to the example of using DDR3 main memory for soft-SPI? Mar 22 18:34:18 I might not choose to do that..... Mar 22 18:34:26 I will just be using the soft-SPI implementation as reference and using Rpmsg with it as my first approach Mar 22 18:35:13 *DDR3 main memory for soft-SPI data access by Linux Mar 22 18:41:36 Diags for where an spi driver sits in general. Can offer options at the interface to PRU level. Abhishek knows way more than me about that bit! Mar 22 18:42:15 Also include where other drivers sit on top and roll of spi subsystem core. Mar 22 18:42:52 Shows understanding of how project fits with wider world. Mar 22 18:44:24 jic23b: you know if a spi bus driver can be compiled as a module? i.e. does the spi subsystem do its enumeration right for a module loaded from userspace at some point after boot? Mar 22 18:45:02 don't know why it wouldn't, just never seen it because the spi controller is usually always present Mar 22 18:45:26 but of course wouldn't be in a bit-banged PRU implementation Mar 22 18:47:37 Yes spi bus drivers are often modules. Mar 22 18:48:20 Can enumerate at any time. Mar 22 18:48:30 cool Mar 22 18:48:41 and I imagine the same goes for i2c and uart Mar 22 18:48:45 Only autoloads if udev magic makes it do so. Mar 22 18:49:44 oh yeah, looks like it's a module on the beaglebone even Mar 22 18:49:48 Yes. There are usb connected masters for all 3 buses to give an illustration of why it must be possible. Mar 22 18:49:56 I guess I should have dug a little deeper :P Mar 22 18:50:05 good point Mar 22 18:51:08 Only tend to be builtin if needed for talking to a pmic (some old pmic drivers hook way to closely and have to built in for the system to boot) Mar 22 18:51:39 Almost any hardware support can be built as a module! Mar 22 18:52:39 cool. Just wanted to make sure that wouldn't be a roadblock for the PRU soft serial project Mar 22 18:52:53 Occasionally people are too lazy to make it work. This is ever more important with kernels targeting many sub arches Mar 22 18:53:12 Indeed not an issue. Mar 22 18:54:23 Tricky corner if several pru projects are going on will be rproc changes/additions. Mar 22 18:54:48 yeah, that could get ugly Mar 22 18:55:10 We might as a community want to work out how to have that sorted (more or less) before they start. Mar 22 18:56:10 Mainline kernel discussions on that may get ugly :) Mar 22 18:56:29 yeah, I hope the students do not take it personally Mar 22 18:56:53 Doesn't block any projects though only their ultimate path to mainline. Mar 22 18:57:32 * alexhiam was hoping that would all get sorted out during last year's gsoc :/ Mar 22 18:59:10 this time we have jic23b :) Mar 22 18:59:23 Oh dear, what I have I let myself in for... *groans* Mar 22 19:00:12 Haven't actually ploughed through it yet in order to understand the full arguments... In particular why the 'standard' routes are too heavyweight. Mar 22 19:00:49 Anyhow, as long as we do something sensible it'll be fine for the gsoc students and we can deal with mainlining in parallel. Mar 22 19:01:12 alexhiam, The cross compilation task has to be submitted before the project submission deadline? Mar 22 19:01:30 chanakya_vc: I forget... might as well Mar 22 19:01:38 should only take a few minutes Mar 22 19:02:36 Yup,should be a pull request right to jkridner's example on github right? Mar 22 19:02:53 yeah Mar 22 19:13:21 should tonghuix be added as a mentor? Mar 22 19:14:11 I have seen several people interested in the flightgear project Mar 22 19:14:57 and one proposal for this project has been submitted Mar 22 19:19:07 m_w: av500 or jkridner would have to do that Mar 22 19:19:24 being the admins Mar 22 19:24:23 well I doubt anyone else will be taking on such proposals Mar 22 19:51:17 anyone going to lfcs or elc coming up here? Mar 22 19:51:39 I would like to meet some of the other beagle people Mar 22 19:52:46 bradfa: there is someone interested in the serial terminal project on the ml Mar 22 19:56:19 m_w: ok, I'll try to take a look and respond by tomorrow morning Mar 22 19:56:37 m_w: thanks for the heads up Mar 22 20:04:53 * nerdboy maybe going to elc, not sure yet... Mar 22 20:44:32 alexhiam, For UART,would you suggest using the hardware UART on the PRU? Mar 22 20:45:24 Or you would prefer a bitbanged implementation? Mar 22 20:46:16 oh right... what's the deal with that again? Doesn't it just have direct access to one of the UARTs that's on the arm interconnect? Mar 22 20:48:45 alexhiam, I am sorry,I really did not get what you are trying to ask.Could you please repeat? Mar 22 20:52:08 chanakya_vc: I don't quite remember, but I feel like the PRUs don't actually have their own UART, they just have direct acces to one of the UARTs that the ARM uses Mar 22 20:52:49 direct access meaning not through the ARM interconnect (which leads to non-real-time behavior because it's shared) Mar 22 20:53:37 in other words, it might just be that they share one of the UARTs with the ARM, in which case I don't think there would be any benefit to using that Mar 22 20:53:41 Okay I am not sure of that. I will have to check.But if that's the case then I believe that a bitbanged implementation would be better? Mar 22 20:53:50 okay :) Mar 22 21:02:53 https://github.com/jstampfl/Pruuart Mar 22 21:03:39 Manual is unclear but suggest a separate uart. The link may be an implementation. Mar 22 21:06:17 interesting, pr1_uart0_txd and pr1_uart0_rxd signals on those pins Mar 22 21:07:23 "Internal peripheral modules (UART, eCAP, MII_RT, MDIO, and IEP)" Mar 22 21:07:54 "One 16550-compatible UART with a dedicated 192-MHz clock" Mar 22 21:08:57 got it's own uart clock as well Mar 22 21:09:41 looks like it is a separate UART, but only 1 in the PRUSS Mar 22 21:09:47 shared between the 2 PRUs Mar 22 21:10:19 Hello! New here, I'm currently researching some of the BeagleBoard ideas list but I'm interested in GSOC with BeagleBoard. Mar 22 21:10:41 I'm pretty lost, this stuff is overwhelming so far Mar 22 21:11:12 what topic are you interested in? Mar 22 21:11:27 hiriachi: have you looked at the ideas at http://elinux.org/BeagleBoard/GSoC/Ideas ? Mar 22 21:11:59 Yeah that's what I'm looking at now, so I'm reading into StratchX extension for BoneScript and BeagleBone Blue API Mar 22 21:13:54 I'm listening to Jason Kridner's 5 JS tricks for BeagleBone Mar 22 21:14:49 alexhiam, But using that would limit our options right? Mar 22 21:15:10 working on the API sounds fun to me, I'm not entirely sure what the project will require just by the description on the ideas list Mar 22 21:15:11 chanakya_vc: wouldn't be able to run 2 PRU UARTs Mar 22 21:16:09 alexhiam, Ohh.So we would have to go with the hardware one? Mar 22 21:17:04 I mean with the hardware one you couldn't have 2 uarts, because there's only 1 in the PRUSS Mar 22 21:17:17 ohh Mar 22 21:17:20 whereas with a soft UART you could potentially have 1 per PRU Mar 22 21:17:29 so bitbanged is def better Mar 22 21:17:45 with more control over all the parameters Mar 22 21:17:59 well, baud rate generation will be better with the hardware UART Mar 22 21:18:13 hard UART > soft UART Mar 22 21:18:27 but soft UART means twice as many Mar 22 21:18:37 could be interesting to do both Mar 22 21:19:28 Regarding the baud rate,as far as my understanding goes,it depends upon the internal uart clock of the controller right? Mar 22 21:19:41 I'd imagine the hardware UART should be fairly straightforward to implement, especially with that example jic23b linked Mar 22 21:20:32 well, with a hardware UART there's a clock, which is typically divided with one or more prescalers to generate the desired baud rate Mar 22 21:21:14 But I guess code for that would already exist.I mean if someone provided a hardware,they would also given a way for the arm to talk to it via the PRU? Mar 22 21:21:14 typically the frequency would be chosen such that it can accurately generate the standard baud rates, with the error potentially increasing for arbitrary rates Mar 22 21:21:42 that gps one is the first I've seen Mar 22 21:22:46 a full 16550 clone? Mar 22 21:23:17 "16550-compatible"... Mar 22 21:23:52 which I guess might just mean 'it's a uart' Mar 22 21:23:56 doesn't say what kernel version Mar 22 21:24:09 * nerdboy can't remember what's in angstrom Mar 22 21:24:15 3.8 maybe? Mar 22 21:24:29 3.2 before that iirc Mar 22 21:24:35 But I am assuming that wouldnot happen in software UART.I mean software one would be capable of generating any frequency lesser than the operating frequency of PRU's ? Mar 22 21:24:42 the dt overlay is nice and short Mar 22 21:25:10 chanakya_vc: there's cycles between for moving data, calculating, etc. Mar 22 21:25:52 alexhiam, But for communication between arm and pru wouldn't that affect the hardware one as well? Mar 22 21:26:03 nerdboy: right, if it's got an overlay and it ain't 4.1 then it's 3.8 Mar 22 21:26:29 chanakya_vc: I'd imagine there's a data FIFO Mar 22 21:26:47 possibly separate rx and tx fifos Mar 22 21:29:10 don't the real 16550s have 16 byte fifos? Mar 22 21:29:19 I would have to search on that. Mar 22 21:29:32 nerdboy: wikipedia agrees with you Mar 22 21:29:48 But I think I would have the hardware one as a secondary goal. Mar 22 21:29:52 oddly enough it usually does... Mar 22 21:30:30 alexhiam, What do you say about that.You would want both to be done? Mar 22 21:30:40 the math-y/technical stuff and the country pages are usually pretty good Mar 22 21:30:52 chanakya_vc: I think that sounds ok... Mar 22 21:31:01 even the bi-color cat page has genome stuff Mar 22 21:31:42 gcl-bot: w. bicolor cat Mar 22 21:31:51 gcl-bot: .w bicolor cat Mar 22 21:31:51 [WIKIPEDIA] Bicolor cat | "A bicolor cat or piebald cat has white fur combined with fur of some other color, for example black or tabby. There are various patterns of bicolor cat. These range from Van pattern (color on the crown of the head and the tail only) through to solid color with a throat locket.Where there is low-to-medium..." | https://en.wikipedia.org/wiki/Bicolor_cat Mar 22 21:32:07 nerdboy vs. gcl-bot Mar 22 21:32:53 * nerdboy 's house was recently adopted by a pregnant tuxedo kitty Mar 22 21:35:41 nerdboy: feel free to send overflow my way Mar 22 21:36:26 wife gave away one kitty and then stopped Mar 22 21:36:59 jic23b, you there ? Mar 22 21:37:33 next year needs a bb powered cat toy... Mar 22 21:38:04 agreed. Or maybe every project could be bb powered cat toys... Mar 22 21:38:42 beaglebone blue is the ultimate cat toy platform Mar 22 21:39:17 a ball with retractable spider legs? Mar 22 21:40:23 no need for legs... just vibrate motors properly sequenced Mar 22 21:40:59 should probably be able to fly as well Mar 22 21:43:08 gas jets stabilized by the gyro Mar 22 21:43:27 might surprise teh cat more then desired Mar 22 21:52:54 wife got them a little vibrator bug/mouse with rubber legs Mar 22 21:53:29 only works on hard floor, and they usually get it stuck in corner somewhere... Mar 22 21:54:05 * alexhiam backed http://getshru.com/ on kickstarter... it kinda sucks :/ Mar 22 21:54:24 terrible battery life Mar 22 21:54:58 :( Mar 22 21:55:20 +Lasting battery Mar 22 21:55:27 * nerdboy has backed few so far, nothing sucks yet... Mar 22 21:55:37 still waiting for pine64 Mar 22 21:56:31 only have basic arm64 profiles so far, but it works great on odroid Mar 22 21:57:12 chip and neo are both pretty cool Mar 22 21:57:31 I did back the chip Mar 22 21:57:36 and the tessel 2 Mar 22 21:58:44 yay, mtg time... Mar 22 23:19:29 nerdboy : done with the meeting ? Mar 22 23:20:46 more or less Mar 22 23:21:31 did you make more changes? Mar 22 23:21:38 *since this moring Mar 22 23:22:04 yes..i split a few weeks tasks, and added a few testing periods Mar 22 23:23:10 okay, lemme take a look Mar 22 23:23:25 okayy Mar 22 23:27:44 it's looking better... Mar 22 23:27:56 still have a few days to work on it Mar 22 23:28:02 okayy Mar 22 23:28:04 yess Mar 22 23:28:24 any suggested improvements? Mar 22 23:28:50 the mavlink stuff is "integration" Mar 22 23:30:01 you'll have to write a little code for that interface using mavlink headers Mar 22 23:30:15 write some code, test some code... Mar 22 23:30:17 for communication, right? Mar 22 23:30:20 okayy Mar 22 23:30:56 you'll also need to test your gl code Mar 22 23:31:17 okay.. Mar 22 23:31:27 so that should be done before i write my gl code? Mar 22 23:32:16 and for that part i would need to do some research, are you going to implement your own algorithms using gles2 interface? Mar 22 23:33:02 actually you need some testable reqs and you can start on tests Mar 22 23:33:07 not really..the algorithms are standard ones that i willl be using..i have a few reference papers whihc i will use Mar 22 23:33:17