**** BEGIN LOGGING AT Thu Apr 23 02:59:59 2015 Apr 23 15:08:04 shubhangi: How's it going with your final project? Apr 23 15:25:30 Abhishek_: Writing paper Apr 23 15:25:57 going for publication to a journal? Apr 23 15:26:02 Abhishek_: yes Apr 23 15:26:09 nice, which one? Apr 23 15:26:30 Abhishek_: ieee pes Apr 23 15:26:35 power systems Apr 23 15:26:52 http://www.ieee-pes.org/publications/transactions Apr 23 15:29:45 https://drive.google.com/file/d/0Bw03ajxXQwSoQ09aVlVLZ0hObWs/view?usp=sharing Apr 23 15:30:23 not yet finished Apr 23 15:34:54 we have the results . just need to finish the paper Apr 23 15:39:47 Abhishek_: You have any experience with running matlab codes on BBB. I know it can execute simulink models but i need to run m files Apr 23 15:47:33 * Abhishek_ saw Mathematica installed on his RPi2 Apr 23 16:02:23 shubhangi: why wouldn't it run .m files? Apr 23 16:03:04 not to be nosy or anything, but was idling away and saw your discussion, so was intrigued by crunching some ML stuff on the beaglebone :) Apr 23 16:05:05 neemo: afaik you can't install matlab on bbb. the matlab support package for bbb ( which runs on you host pc ) compiles simulink models and executes them on the board Apr 23 16:05:34 http://in.mathworks.com/help/supportpkg/beagleboneio/examples/getting-started-with-matlab-support-package-for-beaglebone-black-hardware.html Apr 23 16:05:46 shubhangi: true dat, though I would suggest an alternative Apr 23 16:05:50 interesting Apr 23 16:05:51 sudo apt-get install octave Apr 23 16:06:04 lol :D Apr 23 16:06:11 as long as it's just basic crunching, and you don't need proprietary or obscure packages Apr 23 16:06:15 I mean, it will work Apr 23 16:06:21 seriously, it will work Apr 23 16:06:44 though if a function you want to use is not in octave then it would become difficult Apr 23 16:06:45 I just finished doing the first assignment on the ML Coursera course through my BBB Apr 23 16:07:26 and it did it, albeit slowly, but it did it and even printed nice ascii graphs for me (didn't know it does that, was suprised positively) Apr 23 16:07:46 it will work .. just that theres lots of code .. will have to be re-written Apr 23 16:08:02 it drives a quadruped . controls 12 servos Apr 23 16:08:05 so, as long as the stuff you need/want to do is mostly in the matlab core, and some of the more popular packages that got ported to octave Apr 23 16:08:45 it will work, as in matlab, with the add benefit it installs on the BBB in like, 2 minutes Apr 23 16:08:49 * shubhangi wonders if there's enough time left this semester Apr 23 16:09:05 for me, it's just one day, one more exam to go Apr 23 16:09:12 yeah, well, cutting the code always helps, I mean, hardware has it's limits Apr 23 16:09:16 3 more to go Apr 23 16:09:26 good luck to both of you then! Apr 23 16:09:28 :) Apr 23 16:09:42 thanks :) Apr 23 16:09:43 thanks :) Apr 23 16:10:09 may long nights and good grades follow you where ever you go :) Apr 23 16:10:47 thanks for the octave thing. Apr 23 16:11:02 i'll get it running Apr 23 16:11:36 took me a total of 15 mins Apr 23 16:11:44 10 of which we're spent crunching the data on the BBB Apr 23 16:11:52 even with all vectorized stuff Apr 23 16:12:21 also, the lovely plot package for octave/linux, attempted to plot a gradient descent graph in ascii Apr 23 16:12:24 in 3D no less! Apr 23 16:13:00 * neemo is highly amused by Octave right now Apr 23 16:13:25 * Abhishek_ wonders if he should replace his everyday laptop with a RPi 2 Apr 23 16:13:41 yes Apr 23 16:14:14 you'll attract a lot of curious faces though Apr 23 16:14:35 which is maybe a good thing, depending on how you look at it Apr 23 16:14:52 for bonus points, replace the keyboard with a switch-plug board :) Apr 23 16:15:24 you mean the mechanical IBM M kind Apr 23 16:15:26 ? Apr 23 16:16:09 I was thinking something akin to the 1800s telephone operator switch boards Apr 23 16:17:18 IBM Ms are godly, I mean any mechanical is <3, I use cherry blues mostly, when I'm not churning on a lenovo laptop Apr 23 16:18:20 * neemo loves the clickytie clacks on them Apr 23 16:19:28 clickity* (?), well that's how you spell it Apr 23 16:24:40 * anujdeshpande uses the TVS ones, which is weird because they also make scooters.. Apr 23 16:25:29 I have one of the chiclet wireless kinds. Apr 23 16:28:06 * Abhishek_ remembers hearing of people who have sneaked in a Pi inside a model M Apr 23 16:28:32 anujdeshpande: are they a huge we-build-everything type of company, or did they just diversify in those two, oddly different, areas? Apr 23 16:28:56 no, not really. just this and scooters i think .. Apr 23 16:29:19 * anujdeshpande wouldn’t know though. apparently samsung is huge in construction too .. so can’t tell about such things Apr 23 16:29:19 Abhishek_: well, use a a tablet for a screen and ssh into the Pi and I can see that being a decent setup to test stuff Apr 23 16:29:41 well, to be fair, samsung is technically, south korea Apr 23 16:29:52 Abhishek_: why the pi ? won’t it make you sad, and when you need more pins, it’ll make you mad. Apr 23 16:29:53 * Abhishek_ is still eagerly waiting for the X15 Apr 23 16:30:21 that rhyme :D Apr 23 16:30:43 samsung + maybe couple of more of their family conglomerates, but yeah, they do *everything* Apr 23 16:31:05 anujdeshpande: lol :) Apr 23 16:33:12 ordered some missing parts, I'm looking to get my BBB run a touchscreen and Android soon Apr 23 16:33:46 * neemo wonders if vmayoral is online and available to chat about the MPU9250 drivers ? Apr 23 16:33:57 Abhishek_: what touchscreen did you order? Apr 23 16:33:58 neemo: I am Apr 23 16:34:08 Oh, awesome! Apr 23 16:34:11 what'd you like to discuss? Apr 23 16:34:35 was wodering how you guys used the MPU9250 drivers to get data for the beaglepilot Apr 23 16:34:53 neemo: The one you can see on the top post of theembeddedkitchen.net Apr 23 16:35:22 of course we do Apr 23 16:35:32 it's the main sensor we use when flying our vehicles Apr 23 16:35:39 I saw the drivers in diydrones github, but was getting some compile error Apr 23 16:35:43 errors* Apr 23 16:35:43 did you had a look at AP_InertialSensor library in APM? Apr 23 16:35:48 which branch did you tried? Apr 23 16:35:54 so opted for this guys drivers just for testing https://github.com/richards-tech/RTIMULib Apr 23 16:36:11 master Apr 23 16:36:12 https://github.com/diydrones/ardupilot Apr 23 16:36:33 was compiling and random stuff poped up, but it's possible it was due to old version of beagle image Apr 23 16:36:49 I'm running the current latest one, and will try to recompile once more Apr 23 16:38:39 anyway, was wondering how you guys sorted out reading data from the MPU9250, for the cubesat project, I'll have to read the mag data as quickly (and use the least resources of the ARM core) as possible and push it to the PRU for some processing Apr 23 16:38:51 so was wondering if you know what the optimal road is Apr 23 16:39:36 since, from what I;ve researched, I can either read the data to the ARM core (via the driver you used), use memory access from the PRU to read the SPI interface, or bitbang the SPI at the PRU itself Apr 23 16:40:10 so if you have experience with the cons and pros of all of these techniques, I'd be very happy to hear them :) Apr 23 16:42:55 I coded the userspace driver APM is using right now Apr 23 16:43:43 the BBB does a good job with SPI transactions and we can easily get 4000 per second. Apr 23 16:43:43 vmayoral: I know, that's why I'm asking for advice :) Apr 23 16:44:11 both for how to use the driver optimally and if you researched some of the other options for reading the sensor Apr 23 16:44:19 I'm not convinced the PRU is needed at all Apr 23 16:44:35 I'm not either Apr 23 16:44:50 especially not if using the SPI subsystem Apr 23 16:45:10 well, it's probably not an issue to run everything on the ARM Apr 23 16:45:25 but the idea was to offload the work to the PRU, no? Apr 23 16:45:31 so, what's the point of going into the PRU? Apr 23 16:45:39 what kind of real-time do you need? Apr 23 16:46:03 essentially, not to complex linear transformations of the incoming data Apr 23 16:46:20 and doing that as fast as the sensor can give the data Apr 23 16:46:36 so via SPI, that's the slowest part at 1Mhz clock Apr 23 16:47:06 20MHz Apr 23 16:47:13 20? Apr 23 16:47:30 I thought the MPU datasheet said 1Mhz Apr 23 16:47:39 1MHz max for accessing the full set of registers Apr 23 16:47:46 ah! Apr 23 16:47:47 20MHz for data and the interrupt registers Apr 23 16:47:51 so 20Mhz for data Apr 23 16:48:13 how many bytes per sample? Apr 23 16:48:53 16bit per readout, 9 readouts if we're taking gyro+compass+accel, if I'm not mistaken Apr 23 16:49:27 so just under 140kHz Apr 23 16:49:44 sample rate Apr 23 16:49:47 should be Apr 23 16:50:16 ostensibly, you could opt to read only the mag data if that's what you need in ultra fast sampling Apr 23 16:50:25 but why use an IMU then Apr 23 16:50:32 I highly doubt it's sampling the sensors that fast Apr 23 16:50:45 y Apr 23 16:50:56 that's just the max sample rate the SPI bus could support Apr 23 16:50:57 I'll check the datasheet though Apr 23 16:51:00 y Apr 23 16:51:19 though the question is, how much time is wasted on the ARM -> PRU -> ARM data transfer Apr 23 16:51:29 that's why I'm mentioning the two other options Apr 23 16:51:55 neemo: I'd also make sure to properly check the "right" way to access the magnetometers in the MPU9250 Apr 23 16:52:06 getting the PRU to read the SPI interface (it should be able to, based on the TI manual), or bitbanging it Apr 23 16:52:29 8kHz max gyroscope Apr 23 16:52:39 4kHz max accel Apr 23 16:53:51 8Hz mag Apr 23 16:55:51 I read the 8Hz in the features section, and it seemed way to low Apr 23 16:55:53 looks to me like the mag is fixed to 8 samples/sec Apr 23 16:55:57 but seems so Apr 23 16:56:08 I don't see a setting for it in the register map Apr 23 16:56:18 so there you go! no PRU needed Apr 23 16:57:05 which means more of the timeline could focus on the framework and APIs Apr 23 16:57:28 cc nerdboy Apr 23 16:58:26 fair enough Apr 23 16:59:20 I was sticking to the PRUs based on the ideas page description, but yeah, without better sensors, no hard real-time needed Apr 23 17:00:23 btw, can I email you guys directly with stupid questions about the project, eg. when you're not around on IRC (all them time zones) Apr 23 17:00:33 Hey !! Are the number of slots finalized Apr 23 17:00:34 or to which list should I post with such stuff ? Apr 23 17:00:50 Atleast you can tell number of students applicants ? Apr 23 17:02:19 alexanderhiam nerdboy: ^ about the PRUs, also emailing :? Apr 23 17:02:32 neemo: use the ml if you don't think irc messages will get to us Apr 23 17:02:53 the gsoc one? or some other? Apr 23 17:02:57 yeah Apr 23 17:03:30 I'm sure they'll get to you, the 14 hour difference is kinda clunky sometimes Apr 23 17:03:33 kk, gsoc it is Apr 23 17:04:41 alexanderhiam: should I be changing the PRU related stuff in the proposal then, eg. the timeline? Apr 23 17:05:13 I mean, the PRU algorithm *could* be useful, but only with a vastly more capable magnetometer Apr 23 17:05:31 neemo why don't you put a draft of a revised timeline in a melange comment Apr 23 17:06:00 that way it's easier to compare and see the differences Apr 23 17:06:28 and I'd need to ask nerdboy or someone who has more experience with them then I, with what kind of sampling rates to expect from a dedicated magnetometer Apr 23 17:07:19 alexanderhiam: On it. I'll add comment then on what've talked about today & yesterday Apr 23 17:07:27 great Apr 23 17:07:36 they'll be in in a bit, since my VPN is crapping out again >.> Apr 23 17:07:41 * alexanderhiam has a meeting now Apr 23 17:11:42 alexanderhiam: av500 Is the meeting for final slots for gsoc if so please tell us after finalizing Apr 23 17:13:14 tejas: Are you applied to other organizations as well? Apr 23 17:13:28 yup Apr 23 17:14:58 tejas: http://www.google-melange.com/gsoc/events/google/gsoc2015 Apr 23 17:16:27 alexanderhiam: so u will be telling on 25th...right ?? Apr 23 17:16:48 27th Apr 23 17:17:04 GSoC 2015: Accepted student proposals announced on the Google Summer of Code 2015 site. Apr 23 17:17:04 Mon, April 27, 12pm – 1pm Apr 23 17:17:21 ok sugar labs and fossasia have already told me slots but Apr 23 17:17:31 nothing's officially announced until then Apr 23 17:18:12 but unofficially slots could be told as google informs org about it before hand itself Apr 23 17:18:23 if you are willing to tell Apr 23 17:18:34 it would seem that we are not... Apr 23 17:18:39 saying this again, organizational policies vary Apr 23 17:22:34 anyone knows if the image from latest images beagleboard.org has g_ether active ? Apr 23 17:28:26 vvu: no, but if you don't have the image, how would one test that? Apr 23 17:29:14 eg. I can test if for you if you tell me how, just have no idea what g_ether is :) Apr 23 17:29:18 tejas: you asking this everyday is not going to help. Apr 23 17:30:07 nevermind neemo, i will figure it out Apr 23 17:30:38 k Apr 23 17:37:50 no idea, cheap ones are, well, cheap... Apr 23 17:38:14 i would shoot for max Apr 23 17:38:24 vvu: if the question was, is g_multi loaded on the latest image (which is a replacement for g_ether & g_mass_storage I guess?), the answer is yes, at least lsmod says so Apr 23 17:38:56 data sheet *should* tell you that stuff... Apr 23 17:39:11 nerdboy: well, what kind of magnetometers does the overall CubeSat project expect Apr 23 17:39:48 I mean, the datasheet says 8Hz in the power requirements for the compass, so this IMU is not very demanding in that regard Apr 23 17:39:59 so real-time on the PRU isn't really needed Apr 23 17:40:43 if there are other mag. sensors planned to be used, which have a much higher sampling rate, the PRU would be useful to not clog the ARM for simple transformations of incoming data Apr 23 17:50:39 nerdboy: ^, what type of magnetometers should I expect for the cubesat? Should I still try to do the processing on the PRU expecting that people will want to use much better sensors, or should I opt to do it all on the ARM? Apr 23 17:50:41 check the specs on some of the available ones Apr 23 17:51:46 price range? If you have any links to give me an idea what to look for, please do share :) Apr 23 17:57:55 nerdboy: PNI Micromag3 module, $61, 2000 Hz Apr 23 17:57:57 https://www.sparkfun.com/datasheets/Sensors/MicroMag3%20Data%20Sheet.pdf Apr 23 17:58:07 i look at tindie, adafruit, sparkfun, etc Apr 23 17:58:51 details should be in manufacturer data sheet Apr 23 17:58:55 it was used in the RAX cubesat, from the paper I am pulling the research from Apr 23 17:59:15 yeah, search from the papers they used Apr 23 18:00:03 nerdboy alexanderhiam: what sampling rate is the cutoff point to offload it to the PRU, in your opinion Apr 23 18:00:18 it's not really that simple Apr 23 18:00:29 eg. what rate is worth to do the real-time stuff on the pru, not to bugger the ARM core Apr 23 18:00:44 define 'bugger the ARM core' Apr 23 18:00:58 that sounds illegal... Apr 23 18:01:13 well, one of the main points was to offload the real-time stuff from the ARM core Apr 23 18:01:27 since linux can do real-time, but there are limits Apr 23 18:01:42 assume IMU stuff is on arm side Apr 23 18:01:52 and PRUs are meant to be able to handle hard real-time at 5ns easily, as long as you don't fetch outside memory Apr 23 18:01:52 it is not "bugger"ing the ARM core that you need to concern youself with Apr 23 18:01:56 it is slamming the L4 Apr 23 18:02:21 which you would be contributing to by passing data to and from the PRUs Apr 23 18:02:43 you also need to grab data from both magnetometers, most likely spi interface, and "process" Apr 23 18:03:02 alexanderhiam: true, that's why I'm asking about alternative routes to get the data to the PRU Apr 23 18:03:06 prehaps stepping back and asking yourself - how often do you need to update your heading info Apr 23 18:03:16 and how much rotation you are expecting Apr 23 18:03:29 the second one points you toward writings of a guy name mr nyquist Apr 23 18:03:46 the first one can be addressed by augmenting information from other sensors. Apr 23 18:03:54 apart from the userspace driver, the PRU should be able to get the data from the SPI directly (and have a penalty on the memory side), or it can bitbang the data (waiting a lot if not doing processing) Apr 23 18:04:18 I assume you've looked at this? https://github.com/NoelMacwan/Kernel-10.4.1.B.0.101/tree/master/drivers/staging/iio/imu/inv_mpu Apr 23 18:05:51 alexanderhiam: nope, didn't find it before, looking into it now. Apr 23 18:07:30 ds2: the question for how fast you need to sample is based on the application, so for heading I think not so much, for pointing a camera more preciesly, I would say more samples would help based on the speed of the sat Apr 23 18:08:33 ds2: for getting magnetometer data for space weather, maybe even higher? unfortunatelly the research didn't disclose those details, and I'm searching for more pointers to hard numbers Apr 23 18:14:16 If you don't get numbers, generate them (tm) :) Apr 23 18:14:22 <_av500_> 42 Apr 23 18:14:29 <_av500_> I just generated that for you Apr 23 18:15:02 :) Apr 23 18:18:26 ds2 nerdboy: I haven't sent any cubesats to space, but from a data standpoint, 2000 mag. samples in a second at an orbital speed of 7.8km/s (says wikipedia for LEO), do you really need a sample every 3.8 meters some 200-300 km above earth? I have no idea, didn't to magnetosphere science myself. Apr 23 18:19:43 but I'm gueessing 2000hz (every ~4 meters) is better than 8hz (every 950 meters), I could be wrong though, so input from smarter people please :) Apr 23 18:20:15 _av500_: 42Hz, sounds like a sweet spot to me :) Apr 23 18:25:39 so, the question(s) is how much datapoints do you need, and how much is too much for the ARM and should it in that case be ported to the PRU? Apr 23 18:27:54 you have other higher sample rate sensors that you can use to help fill the gaps Apr 23 18:28:17 you cannot just go rambling off low level details without understanding the system Apr 23 18:28:22 correcting your approximation 8 times a second with the mag data Apr 23 18:30:52 alexanderhiam: thx again for the work on pybbio. helped me a lot :) Apr 23 18:31:34 cool! What have you been using it for? Apr 23 18:33:45 alexanderhiam: makes sense, and it will help with imagning with the cubesat Apr 23 18:36:20 some old project...need to do a system for checking some plastic mold machines Apr 23 18:36:44 the workers are turning them off at night and in the morning the boss needs to know when where they working Apr 23 18:37:02 alexanderhiam: don't know if higher sampling with a dedicated magnetometer (eg. PNI one above) would help much in the positioning or other applications. nerdboy comments? Apr 23 18:39:48 vvu: the boss can't just ask them? Apr 23 18:40:12 everybody lies :) Apr 23 18:40:26 the workers say that is the electrical engineers fault and the other way around Apr 23 18:40:37 ah Apr 23 18:40:37 and to look on CCTV footage takes too long Apr 23 18:41:14 well PyBBIO is great for spying on your employees! Apr 23 18:41:27 no, the imu should do that stuff Apr 23 18:41:35 alexanderhiam nerdboy: the other question being, should I pursue doing stuff on the PRU at all? since it has multiple issues with wasting time reading memory and not sure what benefits Apr 23 18:41:50 the other sensor is for data acquisition Apr 23 18:42:22 neemo: the only reason to go to the PRU is if you know something needs to be done there and you know it's a good place to do it Apr 23 18:42:37 nerdboy: how fast should the other sensor run? Should the processing for that one be done on the PRU? Apr 23 18:42:44 the plan was for initial data cleanup to happen there Apr 23 18:43:18 neemo: the any sample rates taht are configurable should be configurable through the API so the user can decide on resolution vs. power consumption Apr 23 18:43:31 nerdboy alexanderhiam: makes sense, but the more I go into the issue, the less it seems to make sense to do it on the PRU Apr 23 18:43:40 dat from both sensors goes to PRU(s), gets denoised, result stored Apr 23 18:43:45 *data even Apr 23 18:43:58 and I'm going from the assumption that the PRU was planned to do it from the ideas page info Apr 23 18:44:50 nerdboy: that's what I was planning to do Apr 23 18:44:52 hard to say until you try it... Apr 23 18:44:58 true Apr 23 18:45:42 well, I can try, even try to get the data bitbanged to the PRU (no memory overhead, less useful PRU cycles) and see how that works Apr 23 18:46:22 neemo: that kernel driver that's already written would be the logical place to start Apr 23 18:47:08 alexanderhiam: yeah...spying like a boss here with this bbb Apr 23 18:47:31 that's why I'm asking so much here though, since I've seen something mentioned or done by other people, but I have no feeling for what the optimal way to do this on the BBB would be Apr 23 18:47:37 there's a good slogan. PyBBIO: Spy Like a Boss Apr 23 18:47:58 just multiple ideas and a lot of testing to do Apr 23 18:48:12 other than the drone side, probably not much ... Apr 23 18:49:00 imu stuff on drones is low-ish overhead, but you'll probably want more samples Apr 23 18:49:30 ds2: sorry if this came of as rambling, just thinking aloud on the ideas I gathered and trying to find the best way to get it done Apr 23 18:50:10 nerdboy: that's what I thought. But how much? What's a ballpark sampling rate I would want on a cubesat? Apr 23 18:50:24 or for this particular project? Apr 23 18:51:19 jkridner: your idea for replacing gist was to use the github rep API,(https://developer.github.com/v3/repos/#create) Question: You're expecting to have a new file each time a tutorial is created on the github rep? Apr 23 18:51:20 try scaling up from drone velocity Apr 23 18:52:37 vvu: that's a very interesting use for a BBB. Was this in a Chinese factory per chance? Apr 23 18:53:29 vvu: any posts about that project pending? Apr 23 19:02:53 neemo: in Romania :) Apr 23 19:03:10 alexanderhiam: don't have anything in plan but i can take some pics of the hardware Apr 23 19:03:26 I've heard too much about Ghost shifts :) Apr 23 19:06:00 * alexanderhiam needs to start posting more PyBBIO stuff Apr 23 19:06:15 demos and tutorials Apr 23 19:06:31 i am doing some basic Flask app to present the results :) Apr 23 19:06:57 nice, Flask + PyBBIO is a fun combo Apr 23 19:07:14 yeah...but i have 20 sensors to watch...kills the bb Apr 23 19:07:23 in a tight while loop Apr 23 19:07:31 yikes Apr 23 19:07:45 just digital inputs? Apr 23 19:07:49 yeah Apr 23 19:08:17 hmm, that shouldn't be much of a problem Apr 23 19:08:35 the actions perform fast and i kinda need a while 1 do magic Apr 23 19:08:39 and sleep a bit at the end Apr 23 19:08:47 not to hang there Apr 23 19:09:02 threads? event loop? Apr 23 19:09:09 is there any way to get an interrupt or smth when the pin state changes ? Apr 23 19:09:36 https://github.com/graycatlabs/PyBBIO/wiki/Interrupts Apr 23 19:09:59 epoll based Apr 23 19:10:25 oh well i did not read all the docs if so :) Apr 23 19:10:55 the docs definitely need to be presented better Apr 23 19:11:19 i feel that on my own BSc thesis Apr 23 19:11:24 i open sourced the code and has no docs :) Apr 23 19:11:44 * Abhishek_ thinks he needs to write some more documentation on BeagleLogic as well Apr 23 19:12:04 and make it like "apt-get install beaglelogic" Apr 23 19:12:59 alexanderhiam: what are the future plans for pybbio ? Apr 23 19:14:17 vvu: mostly just performance enhancements and adding support for cool devices as I happen upon them Apr 23 19:14:55 some day I'd like to start supporting other platforms Apr 23 19:15:18 but no huge cool plans atm Apr 23 19:16:08 i +1 Flask if you want to do some cool things :) Apr 23 19:16:53 I do want to make some demos with Flask Apr 23 19:17:27 alexanderhiam: and when the interrupt is fired the main loop of python is stopped and then resummed ? Apr 23 19:17:34 i assume is like that Apr 23 19:17:47 vvu: seems like factory workers around the world have similar ideas for avoiding work then :), a friend had to do something of that order, but he did it with an RPi Apr 23 19:18:24 oh well...I support the people here, don't go with the other boards :) Apr 23 19:19:00 vvu: yeah, it runs through the GIL Apr 23 19:19:24 vvu: I support your support. with the number of additional boards he ended up using, a BB would have been a better option in my opinion Apr 23 19:19:55 to each their own, I suppose Apr 23 19:20:44 alexanderhiam: ok then...so i need to start stripping down the basic debian image not to run cloud9 and all that other thingies Apr 23 19:27:46 vvu: what exactly is the issue? Apr 23 19:29:44 i am doing things inefficiently :) running 20 while 1 loops in 20 threads Apr 23 19:29:58 oh my! Apr 23 19:29:59 it's my bad Apr 23 19:30:24 with the interrupt thingie i can just remove those things Apr 23 19:30:40 yeah Apr 23 19:31:29 that reminds me, I need to move the interrupt code to a C extension Apr 23 19:33:41 alexanderhiam: i am trying to use GPIO0_13 which is also i2c2_scl Apr 23 19:33:53 but for some reason it does not work...i ahve it input declared Apr 23 19:35:33 do i need to disable something via uEnv, like HDMI ? Apr 23 19:36:08 no, it should work Apr 23 19:37:26 hmm, the config for that pin looks right Apr 23 19:38:19 mhmh let me check the input on another GPIO Apr 23 19:38:27 I2C2 is enabled in the base DT for reading the EEPROMs, but the muxing should still work Apr 23 19:39:22 I wonder why so many examples not use I2C2 right away and load I2C1 overlays Apr 23 19:39:53 seems like people think I2C2 is reserved for EEPROMs only Apr 23 19:40:43 I find it so convenient to plug in stuff and simply do i2cget etc Apr 23 19:45:30 don't some of the cape overlays remap the pins? Apr 23 19:45:48 * nerdboy has seen many different pinout definitions... Apr 23 19:46:29 and default pin mapping depends on kernel/dt/uEnv config? **** ENDING LOGGING AT Fri Apr 24 02:59:59 2015