**** BEGIN LOGGING AT Wed Jul 06 02:59:58 2016 Jul 06 05:51:57 ds2, m_w Abhishek_ : Sorry .... I am very very late for the report. I was here all night and in the morning when driver wasnt getting probed ... I mean I was asleep. Report will be ready in 30-45 minutes. Jul 06 15:38:13 hey bradfa ,there? Jul 06 15:39:45 hi chanakya_vc Jul 06 15:41:33 bradfa, I was able to resolve all issues and successfully compile the module. However on insmoding it showed that vermagic number turned out to be different Jul 06 15:41:48 :( Jul 06 15:42:17 Could you compile the module on your end and insmod and see if it does work? Jul 06 15:43:31 chanakya_vc: ok I will try to do this during the meeting Jul 06 15:44:19 Okay bradfa . I have started to work on the one using the SPI subsystem. Jul 06 15:45:11 chanakya_vc: have you tried compiling it on the target? Jul 06 15:45:52 http://derekmolloy.ie/writing-a-linux-kernel-module-part-1-introduction/ Jul 06 15:46:20 I was going to do that only m_w . But then I got lazy. Jul 06 15:46:32 I will do it. Jul 06 15:47:19 hello world! Jul 06 15:47:57 hey pmezydlo Jul 06 15:48:05 I don't have vim installed on BBB so I write the code on my host and scp that onto the BBB m_w . Jul 06 15:48:32 chanakya_vc: try sshfs, saves a step Jul 06 15:48:39 And it becomes a huge pain to edit it in nano on the BBB. Jul 06 15:48:50 or install vim ;) Jul 06 15:49:01 Right alexhiam :P Jul 06 15:49:04 (or better yet emacs :P) Jul 06 15:49:36 emacs vs vim, the classic debate :P alexhiam Jul 06 15:49:50 * alexhiam has just been using sublime and sshfs to mount bbb dirs recently Jul 06 15:50:22 vim is really great ! its magical ! those split screens, spell check, column marking ,, visual mode an editing many lines at ones, and record and repeat thing ! Vim is really great ! Jul 06 15:50:54 https://xkcd.com/378/ Jul 06 15:51:09 ZeekHuge, I find vim a bit difficult to use. I mean any place where they have given the basics Jul 06 15:51:17 ? Jul 06 15:51:29 I think it really just comes down to which keyboard macros you learned first Jul 06 15:51:33 vim is great Jul 06 15:51:48 chanakya_vc: tried vimtutor ? Jul 06 15:52:04 av500: I'm going to have to drop pretty early. Jul 06 15:52:22 amragaey: didn't see your status report!!! Jul 06 15:52:36 <_av500_> jkridner: ok Jul 06 15:52:43 I'm writing it now, sorry for late jkridner Jul 06 15:52:59 m_w, Haha :P Jul 06 15:53:28 yeah .. that was nice. Jul 06 15:53:31 :) Jul 06 15:54:21 The bit about eddy currents changing the air density caught my attention :P Jul 06 15:54:35 ewww vim Jul 06 15:54:42 pure vi! Jul 06 15:54:57 busybox even Jul 06 15:55:18 ZeekHuge, Well to be honest, I did give it a try. Jul 06 15:55:36 I didn't spend much time on it. Jul 06 15:56:19 I started with how to save and how to edit. Jul 06 15:56:29 Hello everyone!! Jul 06 15:56:29 It was stackoverflow then .. Jul 06 15:57:08 ds2 vi is directly derived from ed right? Jul 06 15:57:30 howdy kiran4399 Jul 06 15:57:44 chanakya_vc: I guess... vi is curses based, ed is line based Jul 06 15:57:55 there is the ex mode in vi.... Jul 06 15:58:51 Okay ds2, I guess all of us here have our favourite choices of text editors. I just have to decide to make one of those my favourite :P Jul 06 15:59:10 Right now its Sublime text. Jul 06 15:59:23 kiran4399: I'd like to see you get rid of all those compiler warnings, which won't take long. Then we need to make sure you're getting the data from the sensors correctly. Once those two things are all set I'd say we're ready to dive into the PRU Jul 06 16:03:53 hi Visaoni, you see my response on the ml? Jul 06 16:04:20 alexhiam: Hi alexhiam!!! Jul 06 16:04:29 m_w, ZeekHuge Look at the warning on the link that m_w shared :P People from liberal arts background might take offence. Jul 06 16:04:30 alexhiam: yeah.. sure. Jul 06 16:04:36 alexhiam: I'll do it.. Jul 06 16:04:44 hey alexiam, I did. I'm not convinced it's rpmsg. I've had enough weird stuff going on that I'm really not certain what the issue is at this point Jul 06 16:05:09 Visaoni: that's where showing us all what's going on would really help! Jul 06 16:05:11 <_av500_> hello Jul 06 16:05:17 who's on first ? what's on second? i don't know is on third... Jul 06 16:05:20 you're right about it being time to throw up a number of test cases that demonstate various things working or not Jul 06 16:05:53 hi all Jul 06 16:05:59 hi Jul 06 16:06:01 hi Jul 06 16:06:03 howdy! Jul 06 16:06:32 jkridner: Will I get any beaglebone blue during this month? Jul 06 16:06:40 hi Jul 06 16:06:45 <_av500_> 0) Welcome Jul 06 16:06:59 kiran4399: you'll know when it's ready Jul 06 16:07:01 <_av500_> 1) Who's here? Jul 06 16:07:10 hi Jul 06 16:07:11 me Jul 06 16:07:27 me@ Jul 06 16:07:34 ^ Jul 06 16:07:47 Namastey everyone! Jul 06 16:07:55 <_av500_> 5 Jul 06 16:08:03 <_av500_> 6 Jul 06 16:08:17 <_av500_> ZeekHuge: ? Jul 06 16:08:20 ZeekHuge: wake up! Jul 06 16:08:20 kiran4399: nope.... new schedule has me getting prototypes Aug 5. Jul 06 16:08:38 jkridner: ok.. so will I get in the month of august? Jul 06 16:08:42 yes .. sorry ! Jul 06 16:08:45 I am here Jul 06 16:08:47 <_av500_> ok 7 Jul 06 16:08:53 kiran4399: I've got some hacky prototypes, but no time to complete assembly/debug---working on the real one. Jul 06 16:09:04 kiran4399: 50/50 chance. :-) Jul 06 16:09:35 <_av500_> 2) beaglebone blue for everybody! Jul 06 16:09:39 <_av500_> jkridner: you have the stage :) Jul 06 16:09:49 :-) Jul 06 16:09:54 <_av500_> 2.5) just kidding Jul 06 16:10:03 did anyone get a SeeedStudio BeagleBone Green Wireless yet? Jul 06 16:10:09 <_av500_> not me Jul 06 16:10:34 <_av500_> 3) reports Jul 06 16:10:48 really ? to everyone ? Jul 06 16:10:51 i think Visaoni needs another green... Jul 06 16:11:17 unless there's no more weirdness Jul 06 16:11:18 no me Jul 06 16:11:20 not Jul 06 16:11:24 <_av500_> nerdboy: hw issues? Jul 06 16:11:26 heh, just more Jul 06 16:12:20 SeeedStudio BeagleBone Green Wireless sounds interesting Jul 06 16:12:26 <_av500_> nerdboy: Visaoni: hw issues? Jul 06 16:12:30 seems like there was initially Jul 06 16:12:47 _av500_: I wouldn't say so for certain, but it would certainly explain some things Jul 06 16:13:11 suspected microusb power Jul 06 16:13:20 I've tried it without, still doesn't work Jul 06 16:13:45 er, tried it on a dedicated power outlet (not PC usb port) Jul 06 16:14:13 Visaoni: you have a BeagleBone Black? Jul 06 16:14:20 green Jul 06 16:14:27 only a green? Jul 06 16:14:30 yes Jul 06 16:14:44 * nerdboy 's green works fine off desktop usb or 1A brick Jul 06 16:15:10 * alexhiam hasn't had power issues with the green either Jul 06 16:15:17 <_av500_> nerdboy: so you are getting some ersatz hw to Visaoni ? Jul 06 16:15:35 Visaoni: you using a wifi dongle or anything like that? Jul 06 16:15:53 alexhiam: nope, no dongles. Jul 06 16:15:59 hmm Jul 06 16:16:09 * nerdboy not sure where to order ersatz hardware... Jul 06 16:16:11 only things that were plugged in at the time were the sensors I was trying to make work Jul 06 16:16:34 which worked fine for nerdboy with the same setup/code Jul 06 16:16:40 Visaoni: and what happened? Jul 06 16:16:44 we were just talking about it yesterday, ie asking/getting a black or something Jul 06 16:17:20 alexhiam: reading the bmp180 results in a -121 remote IO error Jul 06 16:17:45 Visaoni: have you talked to kiran4399? he was getting a -121 from the same driver... Jul 06 16:18:03 perhaps we should defer to after the meeting though.... Jul 06 16:18:25 yeah, let's not keep the eager reporters waiting... Jul 06 16:19:12 who's on first? Jul 06 16:19:21 <_av500_> right Jul 06 16:19:31 <_av500_> nerdboy: but please resolve that quickly Jul 06 16:19:36 <_av500_> time is of the essence Jul 06 16:19:58 <_av500_> before we start reports here, any other urgent issue? Jul 06 16:20:26 av500: if I'm not urgently needed, I will read the backlog for the reports. must run off to a meeting. Jul 06 16:20:30 <_av500_> ok Jul 06 16:20:42 <_av500_> just want to hear from students that they are working full steam Jul 06 16:20:45 <_av500_> and no blockers Jul 06 16:21:23 quickest resolution is send him another one, just not sure what the quickest mechanism is... Jul 06 16:21:24 <_av500_> I assume silence means agreement Jul 06 16:21:26 no issue this side Jul 06 16:21:38 <_av500_> or silence means all are coding and not listening :) Jul 06 16:21:50 <_av500_> 5) situation reports Jul 06 16:22:03 <_av500_> as ussual 2 quick "here's where I am" reports Jul 06 16:22:28 <_av500_> volunteers? Jul 06 16:22:34 pmezydlo: did you say next week last week? Jul 06 16:22:57 yeah I can Jul 06 16:23:05 <_av500_> ok, and a 2nd? Jul 06 16:23:47 <_av500_> guys? Jul 06 16:23:50 yes Jul 06 16:23:52 <_av500_> ok Jul 06 16:23:57 <_av500_> pmezydlo: you are go! Jul 06 16:24:02 Hello Jul 06 16:24:33 Lately I've been working on user api. I want to move the slave framework to its final version. Jul 06 16:24:50 First I'm going to talk about how the driver’s supposed to work Jul 06 16:25:03 driver's Jul 06 16:25:05 * Jul 06 16:25:33 In the first phase, the driver downloads data concerning CS line (on/off)(polarise) and the direction pins of (input output) McSPI from the DTS file. Jul 06 16:25:49 Next it sets McSPI controller, interrupt and settings loaded from DTS. Jul 06 16:26:16 Now, the driver waits for the user application, which gives the driver basic information about the transfer (length, bits per word, sub-mode). It also sets the transfer length counter, which is decremented after each received word. When the counter is at 0, the driver generates interrupt. Jul 06 16:26:38 and Jul 06 16:26:39 It orders the driver to set the transfer. The driver allocates buffers and sets controllers. Jul 06 16:27:22 Application orders to activate the controller. Controller immediately generates interrupt of empty tx buffer. Interrupt loads buffer. Jul 06 16:27:34 When the transfer comes to an end, McSPI generates end of word count interrupt. In this moment, the driver signalizes to the application that data is ready to be received. Signalization is realized with pull. Jul 06 16:28:07 Then the user receives data. Transfer is cleaned (buffers freed etc.) Jul 06 16:28:21 Now we can proceed to the next transfer. Jul 06 16:28:49 <_av500_> does an spi slave always know the transfer size? Jul 06 16:28:55 <_av500_> what if the host keeps clocking? Jul 06 16:29:02 how does it keep up? Jul 06 16:29:35 yes slave driver must know how long is transfer Jul 06 16:30:29 master device keeps clocking Jul 06 16:30:52 The master must adapt to the slave Jul 06 16:30:57 pmezydlo: wait, so you're loading the tx buffer before the spi master has asserted the cs signal? Jul 06 16:31:19 Yes, unfortunately Jul 06 16:31:50 data from a previous transfer are returned in the next transfer Jul 06 16:32:12 so this cannot keep up at all? Jul 06 16:32:29 is the app in userspace? Jul 06 16:32:42 No way Jul 06 16:33:14 mcspi does not allow you to add data during transfer Jul 06 16:33:17 could you setup a lookup table in kernelspace for command-response type applications? Jul 06 16:34:24 what do you mean? ^^ Jul 06 16:34:43 pmezydlo: why does it not allow? there is a fifo Jul 06 16:35:19 the spi spec is very open - there's no reason you can't require an extra word or two for processing time Jul 06 16:35:37 <_av500_> spi has a spec? :) Jul 06 16:35:42 lol Jul 06 16:35:52 spi has a wiki page ;) Jul 06 16:36:02 <_av500_> +1 Jul 06 16:36:09 <_av500_> pmezydlo: how is CS handled? Jul 06 16:36:11 old motorola docs could be considered a spec ;) Jul 06 16:36:24 <_av500_> if during a transfer the host decides to deassert CS, will your driver notice? Jul 06 16:36:59 cs line interrupt is not supported Jul 06 16:37:10 in mcspi controller Jul 06 16:37:17 so you're using a gpio pin? Jul 06 16:37:21 that's a bummer Jul 06 16:37:58 yeah good way Jul 06 16:38:18 ok I have a problem and I want to describe it Jul 06 16:39:03 pmezydlo: would be great to have a block diagram of what a transfer would look like Jul 06 16:39:11 I have a problem with errors during the transfer. Bytes are either moved or losed. I’m not using high speeds, such as 500kHz. During some transfers it’s ok even with 15 Mhz, while with others it’s bad even with 500kHz. I’m using cs line. Jul 06 16:39:38 alexhiam: ok I'll do it for the next meeting Jul 06 16:39:46 you're using a gpio for cs? Jul 06 16:39:57 yes Jul 06 16:39:59 what are you using for a spi master? Jul 06 16:40:01 We are in the middle and now I know that it will be hard to finish everything. For the next week my main goal is to finish user api, make tests and solve the problem with transmission errors. Jul 06 16:40:27 pmezydlo: isn't the user api done by the spi framework? Jul 06 16:41:05 for spi master I use spidev and second bbb Jul 06 16:41:36 are you loading the whole fifo or just trying to do a word at a time? Jul 06 16:41:47 (how big is the fifo?) Jul 06 16:41:53 Are you sure /CS handling in the McSPI is not supported? Jul 06 16:41:59 2x32byte Jul 06 16:42:23 I think we should go into command-response suggestion of alexhiam after meeting, not sure how else to keep up with the master since no clock-stretching or flow control of any kind... Jul 06 16:42:24 yeah is supported but cs line interrupt is not suported Jul 06 16:42:27 ds2: would that actually be better? doesn't it still need to go through the driver? Jul 06 16:42:50 alexhiam: IIRC - when I did my driver, it helps Jul 06 16:42:58 pls wait Jul 06 16:43:01 donno if it is "better" Jul 06 16:43:16 <_av500_> pmezydlo: thansk for the status Jul 06 16:43:31 <_av500_> please go on to discuss after the meeting Jul 06 16:43:32 no problem thats all Jul 06 16:43:39 Wormo: yeah, that's the only way I can see it working, besides requiring X extra leading words. Unfortunately not very dynamic that way though... Jul 06 16:43:45 <_av500_> henrix_: you are on Jul 06 16:44:04 Hi all Jul 06 16:44:17 I started 2 weeks a go to port the soundcard drivers of CTAG face2|4 Audio Card to BB-X15 Jul 06 16:44:27 At first I had some problems with SPI (no clk / data signals) Jul 06 16:44:37 Found some bugs in device tree => clk signals worked, but still no data signal Jul 06 16:44:47 Did some measurements with oscilloscope and tried another adapter Jul 06 16:45:04 Turned out that one of the adapters had a loosy contact and I tried some other pull up / down configs => SPI works now Jul 06 16:45:12 Verified all codec registers Jul 06 16:45:18 Next thing was i2s Jul 06 16:45:37 Tried several configs (codec is clk master / CPU is clk master), but everytime an audio transmission was initiated I got a lot of kernel errors Jul 06 16:45:47 Turned out that error is caused by dsp firmware (although not used by soundcard driver) Jul 06 16:46:00 After temporarily moving DSP firmware soundcard driver works fine Jul 06 16:46:06 So soundcard drivers are successfully ported Jul 06 16:46:17 Moreover I fixed IFFT bug when reconstructing a sine from frequency spectrum Jul 06 16:46:28 what's the dsp firmware? Jul 06 16:46:39 <_av500_> x15 has DSP Jul 06 16:46:46 <_av500_> its proper TI chip :) Jul 06 16:46:48 ah Jul 06 16:47:02 with a ti firmware blob pre-loaded? Jul 06 16:47:05 Bug were twiddle factors for IFFT (have to be complex conjugated), so FFT and IFFT work fine now Jul 06 16:47:32 was his own DSP code from another project I think Jul 06 16:47:43 ahh Jul 06 16:47:52 no it is already in bb x15 image Jul 06 16:48:01 ok interesting, I thought it was yours Jul 06 16:48:09 thanks for the bugs, ti! Jul 06 16:48:15 yeah:-P Jul 06 16:48:20 I started to implement a convolution reverb but for tests and so on I first want to fix DSP firmware bug to use our soundcard simultaneously with DSPs Jul 06 16:48:42 so it's currently not using the on-board dsp? Jul 06 16:48:56 it's all done by the cpu? Jul 06 16:49:05 When i'm developing on DSPs I use the firmware Jul 06 16:49:12 it might just be a RAM allocation error, cmem carve-out and DSP code matching Jul 06 16:49:25 When I'm working on soundcard drivers I temp move the DSP firmwaree and everything works fine Jul 06 16:49:45 Now I want to use both simultaneously to continue to work on my DSP lib Jul 06 16:49:48 so does it not find the firmware and default to cpu only? Jul 06 16:50:00 no, the soundcard driver don't use anything of DSPs Jul 06 16:50:04 need to figure out the memory map and see if there is DSP and kernel overlap Jul 06 16:50:09 ah, ok Jul 06 16:50:17 Yes, I think this is the bug Jul 06 16:50:40 for this is the cmemk kernel module Jul 06 16:50:44 yes Jul 06 16:50:59 but it's not included in my kernel because it belongs to ti linux utils Jul 06 16:51:07 and this is where I am now Jul 06 16:51:14 I try to compile cmemk kernel module Jul 06 16:51:30 But there's not much information about this process Jul 06 16:51:32 need to figure out what memory DSP firmware thinks it has, and try to give that memory to cmem if possible Jul 06 16:51:53 or, recompile the DSP with TI tools... Jul 06 16:52:02 yeah, first I need the cmem module Jul 06 16:52:06 henrix_: did you see the email from rcn this morning? Jul 06 16:52:13 moment Jul 06 16:52:13 ugh, ti blocks my vpn :o Jul 06 16:52:17 you don't have cmem module loaded at all? Jul 06 16:52:23 no, not with my kernel Jul 06 16:52:31 ohhhh that's bad Jul 06 16:52:37 <_av500_> ah, cmem Jul 06 16:52:37 it's not available in the beagleboard kernel Jul 06 16:52:41 <_av500_> blast from the past :) Jul 06 16:52:43 so I have to integrate it Jul 06 16:53:01 it is in meta-ti layer Jul 06 16:53:05 i.e. cross compile it together with my kernel Jul 06 16:53:20 so at least you can use that as a reference point for building the thing Jul 06 16:53:32 "cmemk should be working now as of 4.4.14-ti-r34 (pushed last night) Jul 06 16:53:34 " Jul 06 16:53:38 how nice Jul 06 16:53:44 oh, perfect Jul 06 16:53:53 https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-4.4.y/patches/x15/fixes/0001-x15-mmc-cmem-debugss.patch Jul 06 16:54:07 there are also some TI docs on cmem/edma stuff Jul 06 16:54:40 yes, i check the TI wiki for cmem troubleshooting Jul 06 16:54:52 *checked Jul 06 16:55:03 But this is great. I will try the new kernel Jul 06 16:55:34 Then I have to integrate my soundcard drivers in 4.4 but this (hopefully) shouldn't be a problem Jul 06 16:56:01 So this is my next goal. Jul 06 16:57:06 finish;-) Jul 06 16:57:17 *of presentation Jul 06 16:57:18 <_av500_> thx :) Jul 06 16:57:34 <_av500_> do we have two for next week? Jul 06 16:58:28 yeah ! me ! Jul 06 16:58:28 one, at least Jul 06 16:58:40 https://git.ti.com/ipc/ludev/blobs/master/src/cmem/README Jul 06 16:58:44 <_av500_> ZeekHuge: noted Jul 06 16:58:47 <_av500_> and Visaoni ? Jul 06 16:58:49 ah one more thing. come opencl support with the dsp firmware patch above? Jul 06 16:59:15 <_av500_> ok, so ZeekHuge and Visaoni for next week Jul 06 16:59:19 <_av500_> thx everybody Jul 06 16:59:33 <_av500_> I need to leave Jul 06 16:59:37 <_av500_> see you all next week Jul 06 16:59:43 thank you _av500_ :) sure Jul 06 16:59:52 thanks _av500_! Jul 06 17:00:01 thanks Jul 06 17:00:01 <_av500_> keep on coding Jul 06 17:00:12 OpenCL support with patch above?;-) Jul 06 17:00:20 thanks _av500_ Jul 06 17:01:46 well, at least that answers that question... Jul 06 17:01:58 "This implementation of CMEM's loadable kernel module supports the use of the Linux kernel's CMA framework" Jul 06 17:02:09 nice Jul 06 17:04:41 so not just any old cmem, but a modern version Jul 06 17:06:28 jkridner: How do you get a Bone Green Wireless? Jul 06 17:07:53 jkridner: I never got a BBB or anything per spreadsheet, I'm wishing I had green now to help with anemometer project, is there any chance of getting one now if I update spreadsheet? Jul 06 17:09:34 *one for Wormo and one for Visaoni Jul 06 17:10:20 Abhishek_, Wormo, nerdboy: please update the spreadsheet and send me an e-mail request as well. I'll forward on the request and see if Seeed will provide for free.... otherwise, I'll buy. Jul 06 17:10:29 Ok thank you Jul 06 17:12:23 on a semi-related topic... is there a known issue with greens (or blacks I suppose) having issues with network-over-usb after forced shutdowns/resets? Jul 06 17:14:00 not that i know of Jul 06 17:14:03 I've yet to figure out what fixes it beyond some variable amount of time. kind of a pain when everything is essentially locked up for however long after I managed to lock the thing up Jul 06 17:14:21 Visaoni: I can't see a -121 from the driver having anything to do with power... Jul 06 17:14:50 the supply isn't current limited for external devices, and the sensor's only gonna draw a couple mA at most Jul 06 17:14:52 default doesn't do black usbnet without setup. only white/green have ftdi on usb Jul 06 17:15:01 nerdboy, have you done hard reboots or only clean ones? Jul 06 17:15:10 both Jul 06 17:15:23 alexhiam: I don't know that it's related to power. that was the main difference in setup between nerdboy and myself when his worked and mine didn't Jul 06 17:15:39 I've tried it on a dedicated brick though and the sensors still don't work, so I don't think it's that Jul 06 17:15:43 pull power brick, use reset button, use power button, send ssh -t reboot Jul 06 17:15:46 * alexhiam has reset and pulled power /many/ times and never had anything get corrupted.. Jul 06 17:15:49 ...yet Jul 06 17:15:54 are they configured for the correct i2c address? Jul 06 17:16:02 i.e. does anything show up with i2cdetect? Jul 06 17:16:14 it looks like it should here Jul 06 17:16:23 should be, it's the same code and hardware for both of us Jul 06 17:16:29 ie, all the "parts" of imu have the right id Jul 06 17:16:31 a lot of sensors have a pin that lets them jumper to different addresses Jul 06 17:16:47 the grove boards are cheap Jul 06 17:16:51 Visaoni: how are you probing? Jul 06 17:17:00 for a error 101, check the I2C addressing. Jul 06 17:17:02 I think these jumpers are soldered Jul 06 17:17:02 only i2c is exposed via connector Jul 06 17:17:06 121 I mean Jul 06 17:17:32 int pin must be soldered on, no spi Jul 06 17:17:58 int pin on the bmp180? Jul 06 17:18:08 imu board Jul 06 17:18:14 alexhiam: for the sensor? I haven't poked at that in a little while so I don't have the freshest memory on what all I'd poked at Jul 06 17:18:21 i assume it's for 9250 Jul 06 17:19:11 Visaoni: I mean probe the driver - DT? /sys/bus/i2c/devices/i2c-X/new_device? Jul 06 17:19:15 it's a pad on the board labeled INT Jul 06 17:19:22 is it a 121 with both sensors? Jul 06 17:19:47 alexhiam: ah, we were mostly just playing with some Adafruit python libs. I'm not sure what it went down to under the hood Jul 06 17:20:21 121 is just for the stuff on the imu. the other sensor is, well, not exactly uart Jul 06 17:20:35 ah, ok... 121 is coming from the driver Jul 06 17:20:48 kernel driver that is Jul 06 17:21:02 neither are uart.. Jul 06 17:21:13 the imu isn't Jul 06 17:21:30 the other sensor (temp/humidity) is on the grove uart connector but not uart Jul 06 17:21:44 yeah, that's i2c Jul 06 17:21:51 grove is all those things Jul 06 17:21:54 dht is uart, imu is i2c Jul 06 17:22:06 dht? I though it was a bmp180? Jul 06 17:22:20 dht is temp and humidity Jul 06 17:22:22 and aren't the dht ones 1-wire? Jul 06 17:22:33 yes, but they use the grove uart connector Jul 06 17:22:43 green has one each of those connectors plus i2c extender board Jul 06 17:22:53 dht? doesn't that have some funky timing Jul 06 17:22:59 oh right, bmp is pressure Jul 06 17:23:12 bmp is part of 9250 Jul 06 17:23:25 what?! it has a bmp in there? Jul 06 17:23:28 is it even true I2C ? (vs I2C co-existant - like the SHT1x series) Jul 06 17:23:50 ds2: funky timing? in what sense. it's not fast, if that's what you mean Jul 06 17:24:06 no, it isn't pure I2C Jul 06 17:24:10 I hate the I2C "compatible" Jul 06 17:24:14 ds2: yeah, the dht is the funky custom 1-wire protocol Jul 06 17:24:29 it's *not* like sht1x Jul 06 17:25:13 afaik 9250 python is pure smbus subset Jul 06 17:25:28 so technically i2c Jul 06 17:25:37 9250 is i2c Jul 06 17:25:46 not saying protocol like the sht1x Jul 06 17:25:54 saying it is about as I2C as the sht1x Jul 06 17:26:10 no, sht is a real bastard Jul 06 17:26:26 hehehh.... I see you have spent quality time with the sht1x Jul 06 17:26:29 9250 is not like that tat all Jul 06 17:26:39 enough so that you wish they put an extra 'i' in that name? ;) Jul 06 17:26:55 the 9250 is decent Jul 06 17:27:04 sht2x are supposed to be i2c Jul 06 17:27:17 i *might* touch one of those... Jul 06 17:27:33 you could do better then the 9250 using 6500 + better mag Jul 06 17:28:33 side thought - wonder if we would be better off with a HIH family sensor on the ADCs Jul 06 17:28:51 i think 9250 is actually 2 6500s (not 6050) plus the ak and bmp Jul 06 17:29:38 uses internal i2c bus even if you talk to the "part" via spi Jul 06 17:30:32 this is the MPU9250 right? Jul 06 17:30:39 * nerdboy actually surprised you can still use 6050 commands Jul 06 17:30:41 there is no BMP in there Jul 06 17:30:53 6500 has 6050 compatibility Jul 06 17:32:06 it's a 9250 + bmp Jul 06 17:32:20 ah makes more sense Jul 06 17:32:48 should look up if the bmm stuff is better then the ak stuff... so many things to research.... Jul 06 17:34:09 wait, so the grove board is a 9250 + bmp180? Jul 06 17:34:17 correct Jul 06 17:34:31 Visaoni: so neither the BMP nor MPU responds? Jul 06 17:34:37 (on your board) Jul 06 17:35:18 ds2: I don't think we ever got around to trying the MPU now that I think about it Jul 06 17:35:49 Visaoni: see if you can read the WHOAMI register on all the possible addresses (there should be either 4 or 2) Jul 06 17:35:51 have you checked the continuity on your grove cable? could be as simple as a bad crimp pin Jul 06 17:38:07 alexhiam: I haven't. I will... doesn't look like I have a nice thing that'll fit so I guess I'll just have to jam some wire up there Jul 06 17:38:52 ds2: I'll give that a shot as soon as I can get back in Jul 06 17:38:57 Visaoni: you could connect it to the green and check it on the connector pins (with power not connected!) Jul 06 17:39:45 oh, that's a nice idea Jul 06 17:43:17 or just pop a scope on the SCL/SDA lines Jul 06 17:43:30 put i2cdetect -y -r 1 in a loop Jul 06 17:43:42 if it either line never wiggles, you have a layer 1 problem Jul 06 18:04:47 should be devices at 68 and 77 Jul 06 18:05:23 grove connector is i2c-2 (third i2c bus) Jul 06 18:08:23 Visaoni, nerdboy: do you have universal-io loaded? Jul 06 18:09:15 if so the i2c buses will be enumerated in order, so it should be /dev/i2c-2 Jul 06 18:17:34 alexhiam: continuity seems good, although my probes seem to suck Jul 06 18:18:20 from what I was able to determine before, I think the green (at least) automatically loads universal-io. I do recall /dev/i2c-2 being the grove connector Jul 06 18:18:32 the beaglebone-universal-io stuf is under /opt/source Jul 06 18:19:19 I ask because linux numbers the buses in the order their enumerated, so it doesn't actual correspond to the I2C subsystem numbering Jul 06 18:19:52 i don't currently have green-overlay or other enabled in uEnv so default shows: Jul 06 18:19:54 4: P-O-L- 0 Override Board Name,00A0,Override Manuf,univ-emmc Jul 06 18:22:50 same here nerdboy Jul 06 18:29:49 sigh.... overlay crap Jul 06 18:29:56 just scan all the busses Jul 06 18:30:08 i2cdetect -l I think will list buses it knows about Jul 06 18:32:23 ds2: i2c-x i2c OMAP I2C adapter I2C adapter for x in [0,2] Jul 06 18:32:50 so based on Alexhiam's info - you probally don't have that universal overlay loaded Jul 06 18:33:09 you mean 0,2 or 0...2? Jul 06 18:33:31 if you really mean 0...2, then nix my comment about Alexhiam's info Jul 06 18:33:34 0...2 Jul 06 18:33:55 * Visaoni realizes how that looks now Jul 06 18:34:07 does i2cdetect -y -r 2 show anything at the suspect addresses? Jul 06 18:35:37 assuming I'm reading this right - it sees 54, 55, 56, 57 Jul 06 18:36:18 hmmm that's the EEPROM address Jul 06 18:36:22 that sounds like those eeproms Jul 06 18:36:29 so the order looks different.... Jul 06 18:36:41 I find it odd that BOTH the IMU and BMP are dead Jul 06 18:36:44 that's really 2?? Jul 06 18:36:52 lunch beckons...bbl Jul 06 18:37:01 yep, that's 2 Jul 06 18:37:10 weird.. what's on 0 and 1? Jul 06 18:37:48 0 - 24, 50... 1 is still working Jul 06 18:37:54 and by the looks of it will be working for a bit Jul 06 18:39:23 ohhh, that is I2C2, the EEPROMs are on that bus Jul 06 18:39:30 I can never keep them straight... Jul 06 18:40:28 nothing on 1 Jul 06 18:40:58 0x24 is the PMIC, so 0 is I2C0 Jul 06 18:43:06 and yeah, it is I2C2 on the grove connector Jul 06 18:44:45 so if I2C2 54-57 is the EEPROM, then the IMU isn't getting detected Jul 06 18:45:56 do a full poweroff, remove power cable, make sure grove board is connected, power up. then try reading the whoami registers Jul 06 18:46:13 those show as UU UU UU UU Jul 06 18:46:14 i2cdetect doesn't always work, and could potentially put devices into a weird state, so skip that part Jul 06 18:46:35 it's 68 and 77 for the mpu/bmp parts Jul 06 18:46:43 right, those addresses are reserved by the capemgr driver, not actually in use without capes attached Jul 06 18:47:00 77 - so it's definitely a bmp180 and not a bmp280? Jul 06 18:47:19 yup Jul 06 18:50:44 Visaoni: do a '# pip install -U serbus' then try this python script: http://pastebin.com/iaa1eVqh Jul 06 18:51:10 that should print 0x55 if it's reading the bmp180 ID register Jul 06 18:52:17 * alexhiam heads towards lunch... Jul 06 18:54:53 alexhiam: IOError: could not write to I2C device Jul 06 19:04:20 it doesn't work with quickwrite (i2cdetect -q default) Jul 06 19:04:36 i2cdetect -y -r 2 should work Jul 06 19:05:14 $ i2cdetect -y -a 1 Jul 06 19:05:14 Error: Can't use SMBus Quick Write command on this bus Jul 06 19:05:45 on *any* i2c bus in this case... Jul 06 19:06:14 hm, -y -r 2 only finds the EEPROM stuff Jul 06 19:06:33 most of the examples on the intarweb use the broken way Jul 06 19:06:59 you don't see any id numbers at all? Jul 06 19:07:49 well, i sent email to jason so hopefully expedited shipment... Jul 06 19:08:02 mostly all --, a few blank and the nthe EEPROM UU Jul 06 19:09:06 https://bpaste.net/show/7cad2b9341cb <= should look like that Jul 06 19:09:08 * Visaoni wishes he had something else to test the board with Jul 06 19:09:27 nope, no numbers at all Jul 06 19:10:00 (well, other than the legend) Jul 06 19:27:10 [alexanderhiam] Visaoni: no arduino? Jul 06 19:31:24 * nerdboy has a couple but not with grove connectors... Jul 06 19:31:34 no arduino arduino but I do have some dip 8-bit avrs banging around Jul 06 19:32:29 I'd need to jam wires up the grove connector pins I suppose Jul 06 19:37:53 * nerdboy does minor cable surgery and repurposes old pc case cabling, etc Jul 06 19:38:27 some with leds and switches even Jul 06 19:39:17 this one? http://www.seeedstudio.com/item_detail.html?p_id=2386 Jul 06 19:39:21 could order another Jul 06 19:39:45 that's the one Jul 06 19:40:52 usually the old cdrom audio cables only have 3 conductors but look like they have 4 Jul 06 19:41:19 sounds like you found that out the hard way Jul 06 19:41:29 nerdboy: could you order another 10dof board and some spare cables shipped to Visaoni? Jul 06 19:41:54 I'm sure the org would reimburse Jul 06 19:42:08 Visaoni: do you have a scope? Jul 06 19:42:29 would be good to confirm that the I2C lines on the grove connector are actually moving Jul 06 19:43:08 alexhiam: unfortunately not Jul 06 19:43:20 already asked for that Jul 06 19:43:21 any other i2c devices? Jul 06 19:43:34 apt-get sez: Jul 06 19:43:37 Suggested packages: Jul 06 19:43:37 codeblocks eclipse ninja-build Jul 06 19:43:49 eclipse on arm? really?? Jul 06 19:43:55 yucky Jul 06 19:44:14 alexhiam: nothing that I know works... have one or two things I've been meaning to poke at that might be i2c (don't remember now what they use) Jul 06 19:44:27 * nerdboy *might* use eclipse tcf-agent on arm... Jul 06 19:44:47 but eclipse is just ridiculous Jul 06 19:44:56 Visaoni: access to a nearby hackerspace or school lab that would have a scope? Jul 06 19:45:27 he's getting new hardware, don't want to waste *too* much time... Jul 06 19:45:27 there's always beaglelogic :D Jul 06 19:45:38 this isn't blocking yet? Jul 06 19:45:45 hackerspace probably Jul 06 19:46:17 not really. this stuff basically comes in at the top level of everything Jul 06 19:46:25 * nerdboy will test fork of RTIMULib2 Jul 06 19:47:17 is bb ssh/console "stable" without any grove things connected? Jul 06 19:47:17 still have the ADC firmware stuff to plug away on (which also hopefully sooner than later will benefit from a scope so...) Jul 06 19:47:30 no Jul 06 19:47:47 seems to be fine as long as I'm able to issue shutdown normally Jul 06 19:47:56 Visaoni: ohh, about that, one PRU is generating the clock and the other the data?? Jul 06 19:48:15 I bought an Instek GDS-1054B. Should arrive by next week. Jul 06 19:48:19 once I start having to use the buttons to power down then it's a crapshoot for if the networking stuff will come back up Jul 06 19:48:24 then you can still run pru/arm code and connect to adc? Jul 06 19:48:34 alexhiam: pretty much Jul 06 19:48:46 Visaoni: how are you synchronizing them? Jul 06 19:48:52 That's a 50MHz, 4 channel scope Jul 06 19:48:54 there's an adc dt overlay that supports like 3 adc parts Jul 06 19:49:29 have you looked at that yet? Jul 06 19:49:41 me? Jul 06 19:49:52 Visaoni: ^^ Jul 06 19:50:12 alexhiam: I was thinking just use a shared register flag. there's basically just one bit where PRU1 needs to tell PRU0 to continue and that's it Jul 06 19:50:35 also, pru can setup/use edma interface if that helps Jul 06 19:50:49 * nerdboy was looking at that yesterday Jul 06 19:50:54 but PRU1 needs to read/set the bits at the right part of the clock cycle Jul 06 19:51:00 nerdboy: the device tree stuff would all be for the built-in adc though yes? not sure how that's relevant Jul 06 19:51:09 no Jul 06 19:51:19 looks like external parts to me Jul 06 19:51:58 i think dt overlay bits set pins/register stuff mostly Jul 06 19:52:11 or do you just trigger it to start, clock for a bit while it's sampling, then read the results whenever you get to it? Jul 06 19:52:26 but that would make sure it's all configured properly i believe Jul 06 19:52:27 perhaps I'm thinking too serially... Jul 06 19:53:01 alexhiam: as far as I understand it the clock just controls the ADC read timing. it has an internal fifo and generates signals when data is available Jul 06 19:53:21 http://processors.wiki.ti.com/index.php/PRU_Linux-based_Example_Code#PRU_edmaConfig <= can you use the edma clock/dma stuff? Jul 06 19:53:23 k Jul 06 19:53:24 then there's a little dance you go through to get it to start the data output Jul 06 19:53:47 right, that's the part where the lack of clock synchronization might bite you Jul 06 19:53:59 if you have to send a series of commands or something Jul 06 19:54:14 * nerdboy likes diagrams almost as much as Wormo Jul 06 19:54:28 yay diagrams! Jul 06 19:54:29 the controls are all on separate lines. none of the timing diagrams show the clock or mention it Jul 06 19:54:54 * alexhiam can't look at the diagram because ti doesn't like my vpn Jul 06 19:54:54 that ^^ looks like what you want to do Jul 06 19:55:14 clock/poll/read Jul 06 19:55:41 *pooling for interrupt Jul 06 19:55:47 *polling even Jul 06 19:57:34 nerdboy: were you thinking write straight to the shared memory or just use DMA instead of rpmsg? Jul 06 19:58:04 don't need rpmsg, do you? Jul 06 19:58:13 basically - does the DMA stuff have potential timing issues Jul 06 19:58:22 Jul 06 19:58:25 Visaoni: remind me, is the PRU just sending raw samples to the arm, or is it doing some maths? Jul 06 19:58:35 just raw samples Jul 06 19:58:37 seems like the right/reasonable approach Jul 06 19:58:46 use the dma controller Jul 06 19:58:50 if it's raw samples at a high rate you'll need to dma it in chunks Jul 06 19:59:47 basically there's short bursts where I need the samples from. my plan so far has been to store those reads in local PRU RAM and then ship it off in chunks. once it's gone, start the next round Jul 06 20:00:48 then yeah, dma is good. Or just ioremap, process, then signal for the next burst, since the time between bursts really doesn't matter Jul 06 20:01:39 so would I still need to store in PRU RAM first? Jul 06 20:01:44 yeah Jul 06 20:02:01 alright, that's what I thought Jul 06 20:02:19 whichever way you get it to the arm, you'll want to buffer in pru ram as your sampling Jul 06 20:02:42 dma is probably fastest way to move to main memory, no? Jul 06 20:02:56 depends on chunk size I think Jul 06 20:03:14 but won't interrupt the cpu that way Jul 06 20:03:22 ioremap is easier though I think Jul 06 20:03:23 that part needs some testing/optimization Jul 06 20:03:52 dma has some overhead but it mostly looks like boilerplate Jul 06 20:03:53 the time between bursts could be huge, right? how often do you need to measure wind speed? Jul 06 20:04:04 not sure which is "easier" Jul 06 20:04:26 my easier above == less lines, quicker to implement Jul 06 20:04:27 well, there will be at least two bursts in quick succession for each axis. after that... good question Jul 06 20:04:28 it will most likely need multiple bursts Jul 06 20:04:42 more if you want to stuff like average Jul 06 20:05:34 need to see what data looks like Jul 06 20:06:07 I'm inclined to say, for now at least, that you can take your bursts, do all your kernelspace/userspace processing on the data, then signal the pru to take the next samples once everything's calculated Jul 06 20:06:20 otherwise you'll need more complex buffering Jul 06 20:06:48 then you'll see if it can do all that at a good rate Jul 06 20:07:06 i'm thinking it will need N reads in sequence Jul 06 20:07:07 you can also increase your burst size and do more averaging on the raw samples Jul 06 20:07:15 starting with 1 is good Jul 06 20:07:52 that works Jul 06 20:08:15 I think a KISS policy with the sampling and buffering is important at this point, esp. considering how little time is left! Jul 06 20:10:21 leaving room for growth... Jul 06 20:18:26 seems like you get the dma clock for free? as opposed to "clocking" yourself via pru timing/execution? Jul 06 21:30:09 well, at least one meta-ti recipe is current v5 => pru-icss_git.bb Jul 06 21:30:37 but ti-pru-sw-edma-driver_1.00.00.bb is old old old and for the wrong machine Jul 06 21:33:20 as long as edma kernel support is enabled (which it should be) it should work Jul 06 23:03:49 hmm, everything seems to have built on beaglebone: [100%] Built target RTIMULibDemoGL **** ENDING LOGGING AT Thu Jul 07 02:59:59 2016