X-Git-Url: https://git.ucc.asn.au/?a=blobdiff_plain;f=irc%2Flog;h=c9821f872fd6ba09d0641993e51b23b8cbac2c24;hb=0e8bd70f3cbeaf8e1e1e5ec305770c4224c67a5f;hp=135d20d78a1b69fe96130325c9d1fdd09ae6e998;hpb=69520c934c13a0f2a4fed5604d3c9694da48cb34;p=matches%2FMCTX3420.git

diff --git a/irc/log b/irc/log
index 135d20d..c9821f8 100644
--- a/irc/log
+++ b/irc/log
@@ -2940,3 +2940,504 @@
 21:43 < jtanx> ok
 21:43 < jtanx> bye
 23:20 -!- jtanx [~asfa@220-253-203-242.dyn.iinet.net.au] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+--- Day changed Sat Sep 21 2013
+08:42 -!- jtanx [~asfa@220-253-203-242.dyn.iinet.net.au] has joined #mctxuwa_softdev
+11:23 < sam_moore> http://hipstercircuits.com/enable-pwm-on-beaglebone-with-device-tree-overlays/
+11:23 < sam_moore> So... according to this I should add pwm_test as a kernel module
+11:24 < sam_moore> "This is it. It is now three o’clock in the morning and I have not slept or eaten in two days. My neck is sore, my ass has fallen asleep and my organs are screaming “slow down, man”. I no longer see [CC]s, [LD]s and [AS]s, I only see blondes, brunettes and redheads flashing before my eyes. With my last ounce of energy I barely manage to type in “reboot” as my face hits the keyboard. And that is when it happens.."
+11:25 < sam_moore> Ummm
+11:25 < sam_moore> It's awesome that this guy has solved the problem (I think)
+11:26 < sam_moore> But a bit depressing that it still isn't in the official kernel
+11:29 < sam_moore> I think most people just give up and use Angstrom, which is tempting
+11:30 < sam_moore> I still have that HTTP server code... :P
+11:45 < sam_moore> Looks like Robert C Nelson's 3.8 kernel does have a pwm_test module
+11:45 < sam_moore> Maybe the image you used just had an out of date kernel?
+11:45 -!- Irssi: #mctxuwa_softdev: Total of 3 nicks [0 ops, 0 halfops, 0 voices, 3 normal]
+11:51 < jtanx> hmm
+11:51 < jtanx> no idea
+11:51 < jtanx> it was made in july I think and it uses those rcn kernels
+11:51 < jtanx> We could always use lighttp
+11:51 < jtanx> lighttpd on angstrom if necessary
+11:52 < jtanx> lighttpd and install mod_fastcgi
+11:55 < jtanx> ok so the image uses 3.8.13-bone20, so maybe it wasn't enabled in that version, but it now is in 3.8.13-bone28?
+12:02 < sam_moore> I've just built 3.8.13-bone28 and the module pwm_test exists
+12:03 < sam_moore> ... I also copied the code from that guy's blog as pwm_test2 just in case :P
+12:03 < sam_moore> I'll have to test it later, but at least we have the kernel module
+12:08 < jtanx> nice
+12:39 < jtanx> ohhhhh I know why it didn't work from one bbb to the next, using the same image
+12:39 < jtanx> When you boot for the first time, it assigns the ethernet port eth0
+12:39 < jtanx> when you then take it out and boot it on a different BBB
+12:40 < jtanx> because the ethernet device has a different id, it gets assigned to say eth1
+12:40 < jtanx> and because you don't have any config for eth1 in your network config, there's no internet access
+12:40 < jtanx> http://www.eewiki.net/display/linuxonarm/BeagleBone#BeagleBone-Networking:UsingasharedSDcardwithMultipleBeagleBone
+12:41 < jtanx> should fix that
+13:21 -!- jtanx [~asfa@220-253-203-242.dyn.iinet.net.au] has left #mctxuwa_softdev []
+13:21 -!- jtanx [~asfa@220-253-203-242.dyn.iinet.net.au] has joined #mctxuwa_softdev
+15:10 < jtanx> Eh, you know what I'll just stop the threads when you want to pause it
+15:10 < jtanx> instead of conditionals
+15:11 < jtanx> it's not like you're pausing the experiment that often
+15:18 < sam_moore> That's fine
+15:19 < sam_moore> The conditional approach is only really necessary if you're constantly pausing the threads
+15:19 < sam_moore> I used it for an nbody simulator, so the computation of force and position was split up between threads
+15:19 < sam_moore> It's really slow if you have to stop and then recreate the threads on every step
+15:22 < sam_moore> Although still actually faster than the single threaded program
+15:22 < sam_moore> Well, depending on how many objects you simulated
+15:23 < sam_moore> Anyway, just stop the threads, it's simpler to code and the performance effect in our case is probably negligable
+15:30 < jtanx> yeah
+15:30 < jtanx> say you had an actuator that was being controlled at that instant when an 'emergency stop' was issued
+15:31 < jtanx> since an 'emergency stop' is the same as just pausing (eg stopping the thread but keep DataFile open)
+15:31 < jtanx> you'd have to wait for that action to be completed before the 'emergency stop' would be propagated
+15:34 < jtanx> welp I guess that's why there's hardware safety interlocks
+15:38 < jtanx> Also, technically wouldn't it be possible to try to set the actuator value before the current value has been set
+15:38 < jtanx> Since there's no queue
+15:39 < jtanx> a->control could be overwritten by a new request as Actuator_SetValue operates
+16:12 < sam_moore> We want that right?
+16:13 < sam_moore> I'll look at it later if I get time
+16:14 < jtanx> I don't know if we want that or not
+16:15 < jtanx> wait want as in the current behaviour or the behaviour with a queue?
+16:16 < sam_moore> The current behaviour
+16:16 < sam_moore> I don't think you need a queue
+16:16 < sam_moore> You can extend the critical section in Actuator_Loop to stop the current control getting overwritten
+16:17 < sam_moore> Move the pthread_mutex_unlock on line 121 to below line 127 (Actuator_SetValue)
+16:17 < sam_moore> That way if Actuator_SetControl is called before the value has been successfully set, it will just wait
+16:17 < sam_moore> Mutexes actually implement a queue
+16:18 < sam_moore> If one thread has a lock on the mutex, subsequent threads that try to access the mutex will queue up; whenever the mutex is unlocked the next thread (if any) which was waiting will get it
+16:18 < jtanx> ok
+16:23 < jtanx> I'll leave it as is for now
+16:23 < sam_moore> Sure
+16:49 < sam_moore> PWM working
+16:49 < jtanx> nice
+16:50 < jtanx> I still don't really understand - did you compile the kernel from scratch
+16:50 < jtanx> or did you figure out how to use the install-me.sh script
+16:50 < sam_moore> I did, but I didn't need to modify it
+16:50 < jtanx> huh
+16:50 < jtanx> ok
+16:51 < sam_moore> http://www.eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-LinuxKernel
+16:52 < jtanx> so if we do this: http://www.eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Networking:UsingasharedSDcardwithMultipleBeagleBone
+16:52 < jtanx> We should be able to just copy our image
+16:52 < jtanx> and stick it on the electronics' BBB
+16:53 < sam_moore> Sounds good
+16:53 < sam_moore> I'm glad that worked
+16:53 < jtanx> yeah
+16:54 < jtanx> I wonder if it also enabled the usb0 stuff (ethernet over usb)
+16:58 < sam_moore> PWM appears to have picosecond resolution? Or at least the arguments are in ps
+17:02 < jtanx> oO
+17:11 < sam_moore> ADC can sample at ~4KHz
+17:11 < sam_moore> But... that's using bash
+17:11 < sam_moore> It will probably be massively fast when done in C
+17:11 < jtanx> um
+17:11 < jtanx> is there any need to have it sample at a consistent rate
+17:11 < jtanx> as in, with threads there's no guarantee
+17:12 < jtanx> of a consistent sampling rate
+17:12 < sam_moore> Yes, you're right
+17:13 < sam_moore> I don't think we can achieve a consistent sampling rate, but I don't think it's critical that we do
+17:14 < sam_moore> As soon as we make our software run in an operating system with a kernel and other processes that can run as well, it gets pretty unfeasable to have a constant sample rate
+17:14 < sam_moore> We can have it constant to within an uncertainty I guess
+17:15 < jtanx> yeah, true
+17:18 < sam_moore> If you wanted a really high constant sample rate (say much faster than 1us which is probably the best case we could get) you'd have to use a more low level embedded device
+17:18 < sam_moore> Well I guess you could compile your own kernel for the BBB
+17:19 < sam_moore> But either way you'd have to physically run the webserver/GUI interface stuff on a seperate device
+17:19 < sam_moore> At this stage my feeling is what we have is good enough given the complexity of all the requirements we were given
+17:23 < jtanx> yeah
+17:25 < sam_moore> Hmm, I can set some GPIO pins to toggle whenever Sensor_Read is called and get an idea of sample rates and to what degree of accuracy we can quote the time stamps
+17:26 < sam_moore> I think I'll write some pin control code
+17:26 < sam_moore> I don't trust any of these custom libraries
+17:29 < jtanx> custom libraries?
+17:36 < sam_moore> Well they aren't really libraries
+17:36 < sam_moore> http://www.avrfreaks.net/wiki/index.php/Documentation:Linux/GPIO#Example_of_GPIO_access_from_within_a_C_program
+17:37 < sam_moore> Eg: That one has an fopen and fclose each time the value is changed
+17:38 < sam_moore> I could google until I find someone that has already written a C library, but chances are it will be slow or broken
+17:38 < sam_moore> Since I've worked out how to control the pins I may as well just write the C code to do it
+17:39 < jtanx> yep
+17:49 < sam_moore> I wonder if I can do this with a macro...
+18:30 < sam_moore> Ergh, screw that
+18:31 < sam_moore> Ok, I'm going to implement things like: GPIO/ADC/PWM_Export/Unexport to initialise or deinitialise all pins
+18:31 < jtanx> Ok
+18:31 < jtanx> too much effort with macros?
+18:31 < sam_moore> Yeah, 
+18:32 < sam_moore> I was thinking of having something like "GPIOX_Set()" instead of GPIO_Set(int x)"
+18:32 < sam_moore> But that's probably not as nice as I thought it was
+18:32 < sam_moore> Anyway, there's an enum in the header file that contains the id of all pins used
+18:32 < sam_moore> The implementation defines some structs that wrap around the file descriptors
+18:33 < sam_moore> But to use the module you just give it an ID as defined in the enums
+18:33 < jtanx> Makes sense
+18:33 < jtanx> designing the gui is actually not too bad
+18:33 < sam_moore> That's good
+18:34 < jtanx> looks ok in ie8 too
+18:34 < sam_moore> Nice
+18:35 < jtanx> gotta go, dinner
+18:35 < sam_moore> Ok
+18:35 < sam_moore> Hmm, it would be nice if C had value checking on enums
+18:35 < sam_moore> You can define a function that takes an enum type as an argument
+18:36 < sam_moore> But people can still just pass any old integer
+18:36 < sam_moore> As far as I know
+18:36 < sam_moore> eg: typedef enum {FIRST=1, SECOND=10, THIRD=100} EnumType
+18:36 < sam_moore> void Foo(EnumType e);
+18:37 < sam_moore> If you go Foo(2) it won't complain
+18:38 < sam_moore> Annoying
+18:38 < sam_moore> That seems like something the compiler would be able to pick up
+19:31 < sam_moore> Ergh, I'm getting too obsessive compulsive with this pin thing
+19:35 < sam_moore> It's annoying because ADC, GPIO and PWM are treated completely differently
+19:35 < sam_moore> You write one thing and it enables *all* the ADCs
+19:35 < sam_moore> You have to enable each GPIO pin individually
+19:36 < sam_moore> And to enable PWM pins you give a string (not just an integer)
+19:37 < sam_moore> Also the location of the pin files is not guaranteed (though it probably doesn't change for a given system configuration)
+19:39 < sam_moore> Ah, I found a way to enable pwm with /sys/class/ instead of that cape manager thing
+19:39 < sam_moore> I think I'll use that, since at least it's consistent with the GPIO stuff
+19:41 < sam_moore> Ooh!
+19:41 < sam_moore> http://beagleboard-gsoc13.blogspot.com.au/2013/07/sampling-analogue-signals-using-adc-on.html
+19:41 < sam_moore> Provides a driver for continuously sampling with the ADC
+19:41 < sam_moore> Oh wait
+19:41 < sam_moore> Crap in a bucket
+19:42 < sam_moore> Because we're using those multiplexers we can't do that
+19:42 < sam_moore> We have to set the multiplexer before each sample
+19:42 < sam_moore> Oh well, never mind
+19:44 < sam_moore> I suppose we could write our own kernel module :S
+19:45 < sam_moore> I think I understand this enough to talk to Adam next time he tries to talk about sample rate
+19:46 < sam_moore> 1. It's not actually constant, but we can probably have it constant to within a few us
+19:46 < sam_moore> 2. To make it constant would require writing a kernel module
+19:47 < sam_moore> Unless electronics stops being stingy and gets one amplifier per channel :P
+20:22 < jtanx> hehehe
+20:22 < jtanx> next week's adrian though
+20:22 < sam_moore> Ah
+20:23 < jtanx> grilling time
+20:23 < sam_moore> He'll probably ask us the same things :P
+20:23 < jtanx> yeah
+20:23 < jtanx> but man, so much stuff to go through just to get some readings from a few pins
+20:24 < jtanx> so good job with that :P
+20:54 < sam_moore> Thanks
+22:45 -!- jtanx [~asfa@220-253-203-242.dyn.iinet.net.au] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+--- Day changed Sun Sep 22 2013
+00:51 < sam_moore> Hell yes
+00:51 < sam_moore> PWM controlled through web browser
+00:51 < sam_moore> GPIO controlled through web browser
+01:19 < sam_moore> .... And ADC read through web browser
+01:19 < sam_moore> Blergh
+01:28 < sam_moore> I think I'll take the rest of today off from MCTX3420 :S
+08:21 -!- jtanx [~asfa@220-253-203-242.dyn.iinet.net.au] has joined #mctxuwa_softdev
+09:32 -!- jtanx [~asfa@220-253-203-242.dyn.iinet.net.au] has quit [Ping timeout]
+11:36 -!- jtanx [~asfa@220-253-203-242.dyn.iinet.net.au] has joined #mctxuwa_softdev
+11:53 < sam_moore> I've analysed the crap out of sampling rates for this ADC
+11:53 < sam_moore> At least as much as I can just using the timestamps according to gettimeofday
+11:54 < sam_moore> Contrary to my first email, reading the ADC is actually really slow. And also probably the greatest source of variation in sampling rate.
+11:56 < jtanx> wow
+11:56 < jtanx> only 100Hz?
+11:56 < sam_moore> Well it looks more like 1KHz on the oscilloscope, but there's a lot of variation, it has trouble getting a trigger
+11:57 < jtanx> the cpu datasheet rates it at 200kSPS
+11:57 < sam_moore> Hmm
+11:58 < sam_moore> Well judging by the control it is something about the ADC reading that makes it really slow
+11:58 < jtanx> That's annoyng
+11:58 < sam_moore> Yeah
+11:58 < sam_moore> Also annoying is that the ADC file is generally in a different place each time they're enabled
+11:59 < sam_moore> I ended up modifying the program to take the path to the ADC file as an argument
+11:59 < sam_moore> And making run.sh do the initialisation
+11:59 < sam_moore> I figured that was better than calling system()
+11:59 < jtanx> that makes sense
+11:59 < sam_moore> Yep, we might want to set other options that run.sh can pass to it anyway
+12:00 < sam_moore> Ok, I have to stop now, I'm spending way to much time on this
+12:00 < jtanx> Haha
+12:00 < sam_moore> It's getting to the point where I'm considering writing an ADC kernel module that doesn't suck :S
+12:01 < jtanx> :S let's hope it doesn't get to that stage
+14:08 -!- jtanx [~asfa@220-253-203-242.dyn.iinet.net.au] has quit [Connection reset by peer]
+14:25 -!- jtanx [~asfa@220-253-203-242.dyn.iinet.net.au] has joined #mctxuwa_softdev
+14:37 -!- MctxBot [~twang@220-253-203-242.dyn.iinet.net.au] has quit [Ping timeout]
+15:21 -!- MctxBot [~twang@220-253-203-242.dyn.iinet.net.au] has joined #mctxuwa_softdev
+20:12 < jtanx> the pressure regulator has a 1-5vdc analogue output
+20:12 < jtanx> is this considered one of the pressure sensors?
+20:14 < jtanx> or maybe it's just not used
+21:50 -!- jtanx [~asfa@220-253-203-242.dyn.iinet.net.au] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+--- Day changed Mon Sep 23 2013
+07:56 -!- jtanx [~asfa@220-253-203-242.dyn.iinet.net.au] has joined #mctxuwa_softdev
+08:51 -!- jtanx [~asfa@220-253-203-242.dyn.iinet.net.au] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+19:38 -!- jtanx [~asfa@220-253-203-242.dyn.iinet.net.au] has joined #mctxuwa_softdev
+19:41 -!- MctxBot [~twang@220-253-203-242.dyn.iinet.net.au] has quit [Ping timeout]
+20:55 -!- jtanx [~asfa@220-253-203-242.dyn.iinet.net.au] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+21:02 -!- MctxBot [~twang@220-253-203-242.dyn.iinet.net.au] has joined #mctxuwa_softdev
+22:33 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
+--- Day changed Tue Sep 24 2013
+13:56 -!- jtanx [~asfa@220-253-203-242.dyn.iinet.net.au] has joined #mctxuwa_softdev
+14:18 < jtanx> with kernel 3.8 they decided to make life hard with device tree overlays
+14:19 < jtanx> http://e2e.ti.com/support/arm/sitara_arm/f/791/t/277811.aspx
+14:19 < jtanx> https://docs.google.com/a/beagleboard.org/document/d/17P54kZkZO_-JtTjrFuVz-Cp_RMMg7GB_8W9JK9sLKfA/pub
+14:47 < jtanx> huh
+14:47 < jtanx> http://www.youtube.com/watch?v=6gv3gWtoBWQ
+14:47 < jtanx> http://digital-drive.com/?p=146
+15:39 < sam_moore> I wonder if I can write a module that just uses /dev/adcX /dev/gpioX and /dev/pwmX
+15:40 < jtanx> that would make life simple
+15:40 < jtanx> but no
+15:42 < sam_moore> http://www.tldp.org/LDP/lkmpg/2.6/html/x569.html
+15:42 < sam_moore> Probably out of date (2.6?)
+15:45 < sam_moore> Also rt.wiki.kernel.org - realtime linux supposedly gives you better timing accuracy, although it would possibly break with our setup involving nginx
+15:46 < sam_moore> Actually it looks like there are quite a few ways for it to not work
+15:48 < jtanx> I think trying to write a kernel module would cause more grief than it's worth
+15:50 < jtanx> http://saadahmad.ca/using-pwm-on-the-beaglebone-black/
+15:51 < jtanx> I have no idea what's been updated and what hasn't
+15:51 < jtanx> as in, do we have that fix in our kernel
+15:53 < sam_moore> I don't know
+15:54 < sam_moore> We only need 1 PWM though
+16:00 < sam_moore> Or at least, last we heard there was only one. Doesn't make the system very expandable though.
+19:07 < jtanx> you know what I'll try loading an Ubuntu image from rcn to my sd card
+19:08 < jtanx> instead of from armhf
+19:08 < jtanx> armhf.com*
+19:17 < jtanx> ah screw it
+19:17 < jtanx> i'll stick with debian (but do the same thing)
+21:07 -!- jtanx [~asfa@220-253-203-242.dyn.iinet.net.au] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+21:34 -!- MctxBot [~twang@220-253-203-242.dyn.iinet.net.au] has quit [Ping timeout]
+--- Day changed Wed Sep 25 2013
+08:41 -!- MctxBot [~twang@220-253-203-242.dyn.iinet.net.au] has joined #mctxuwa_softdev
+11:31 -!- jtanx [~asfa@130.95.54.13] has joined #mctxuwa_softdev
+12:15 < jtanx> I think I know why we were having issues with pwm yesterday
+12:16 < jtanx> if you do this command
+12:16 < jtanx> echo bone_pwm_P8_13 > /sys/devices/bone_capemgr.8/slots
+12:16 < jtanx> you make it unavailable from /sys/class/pwm
+12:16 < jtanx> so in the run.sh script it was exporting all the pwm devices via the first method
+12:16 < jtanx> and then it becomes unavailable via sysfs
+12:17 < jtanx> anyway... I tried booting from the rcn image
+12:17 < jtanx> it comes with pwm enabled already
+12:17 < jtanx> and via that capemgr I got pwm to work
+12:17 < jtanx> I don't know what /sys/class/pwm/pwm0 corresponds to (which pin)
+12:19 < jtanx> the electronics teams' bbb wasn't done properly when we tried to upgrade the kernel
+12:19 < jtanx> probably something to do with the device tree stuff
+12:19 < jtanx> so I flashed it with the rcn image (which runs 3.8.13-bone26
+12:20 < jtanx> (demo image from here)
+12:20 < jtanx> elinux.org/BeagleBoardDebian
+12:47 -!- jtanx [~asfa@130.95.54.13] has quit [Ping timeout]
+13:09 -!- jtanx_ [~asfa@130.95.54.13] has joined #mctxuwa_softdev
+13:09 -!- jtanx_ is now known as jtanx
+13:16 < jtanx> oh
+13:16 < jtanx> so it now works
+13:16 < jtanx>  echo bone_pwm_P9_22 > slots
+13:16 < jtanx> if I do that line for pwm0
+13:26 < jtanx> oh right
+13:26 < jtanx> echo bone_pwm_P9_21 >slots 
+13:26 < jtanx> for pwm1
+13:30 < jtanx> ahhhhhh
+13:30 < jtanx> if you comment out the line
+13:30 < jtanx> modprobe pwm_test
+13:30 < jtanx> from run.sh
+13:30 < jtanx> it works
+13:43 < jtanx> geeze kernel 3.8 has issues with usb hotplugging 
+13:43 < jtanx> https://groups.google.com/forum/?fromgroups#!searchin/beagleboard/usb/beagleboard/8aalvyWwaig/MUXAPuMTSOYJ
+13:43 < jtanx> which explains why we're having issues with cameras
+13:43 < jtanx> (partly at least)
+13:47 < jtanx> and now pwms not working again
+13:48 < jtanx> via sysfs
+13:50 < jtanx> oh
+13:50 < jtanx> I know why
+13:51 < jtanx> you have to export it /sys/class/pwm
+13:51 < jtanx> first
+13:51 < jtanx> *before* you do stuff like 	echo bone_pwm_P9_21 >slots 
+13:52 < jtanx> yep 
+13:53 < jtanx> so the order is: echo 0/1 > /sys/class/pwm/export
+13:53 < jtanx> then do that other stuff
+13:57 < jtanx> egh
+13:57 < jtanx> finnicky
+13:57 < jtanx> ok I have to stop now
+14:14 -!- jtanx [~asfa@130.95.54.13] has quit [Ping timeout]
+14:15 -!- jtanx [~asfa@130.95.218.72] has joined #mctxuwa_softdev
+15:46 -!- jtanx [~asfa@130.95.218.72] has quit [Ping timeout]
+16:03 -!- jtanx [~asfa@130.95.218.72] has joined #mctxuwa_softdev
+16:04 < jtanx> well that was an interesting experience
+16:04 < jtanx> it's most reliable when you work directly with /sys/devices/ocp2.helper/PWM9_22*
+16:05 < jtanx> I think if you echo am33xx_pwm to the slots thing when it's already loaded
+16:05 < jtanx> weird shit can happen
+16:05 < jtanx> too
+16:07 < jtanx> setting the period via sysfs (eg /sys/class/pwm) didn't work most of the time either
+16:07 < jtanx> you could change duty but not period
+16:07 < jtanx> although I swear I had it working at one point
+16:07 < jtanx> via the other way I think it works ok
+16:08 < jtanx> oh yeah, and I was doing this using the demo image from http://elinux.org/BeagleBoardDebian
+16:09 < jtanx> the electrical group's one has been reflashed with that version as well
+16:09 < jtanx> (for ours I worked off my sd card)
+16:10 < jtanx> that image also enables the ethernet-over-usb 
+16:36 < jtanx> I think we have to be careful which pins we export/enable
+16:37 < jtanx> https://github.com/CircuitCo/BeagleBone-Black/blob/master/BBB_SRM.pdf?raw=true
+16:37 < jtanx> pages 80-82
+16:37 < jtanx> the pins have different meanings based on what mode they're in
+16:41 -!- jtanx [~asfa@130.95.218.72] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+17:59 -!- jtanx [~asfa@220-253-203-242.dyn.iinet.net.au] has joined #mctxuwa_softdev
+18:05 < jtanx> ...so I brought the BBB home, even though I should be studying for 2402 :S
+18:05 < jtanx> the microphone came in today too
+18:19 < jtanx> ok
+18:19 < jtanx> so these documents: https://github.com/derekmolloy/boneDeviceTree/tree/master/docs
+18:19 < jtanx> describes what the pins are  used for by default
+19:00 < sam_moore> Ah... they already got the microphone
+19:00 < sam_moore> Welp. Guess we're stuck with it.
+19:00 < sam_moore> So... we can record <50Hz sounds reliably, maybe
+19:00 < sam_moore> How useful
+19:01 < sam_moore> Have I been missing out on an email stream where the sensors team actually clears things with us?
+19:04 < jtanx> not that I know of
+19:04 < jtanx> haha
+19:04 < jtanx> in other news
+19:04 < jtanx> the sensors team ordered a pressure sensor with no mount
+19:04 < jtanx> adrian had a spat because it'd cost something like $200 to make the mount
+19:05 < jtanx> for a $10 part
+19:05 < jtanx> so he said, order it from online , I don't care if it's from overseas
+19:05 < sam_moore> Oh boy
+19:06 < sam_moore> If there's an issue with the camera and/or microphone they'll blame us
+19:06 < jtanx> yeah
+19:06 < jtanx> about that camera
+19:06 < sam_moore> Oh dear...
+19:06 < sam_moore> Go ahead?
+19:06 < jtanx> still couldn't get it to work today
+19:06 < sam_moore> God dammit
+19:06 < jtanx> although I didn't spend much time on it
+19:06 < jtanx> I got pwm to work
+19:06 < jtanx> mostly
+19:06 < sam_moore> I thought it might be something like adding the user to the "video" group
+19:06 < sam_moore> That's good!
+19:07 < sam_moore> What was happening?
+19:07 < jtanx> yeah, the problem is it doesn't show up at all (the camera)
+19:07 < sam_moore> Hmm
+19:07 < jtanx> and partly because 3.8 has an issue with usb hotplugging
+19:07 < sam_moore> Haha
+19:07 < jtanx> about pwm
+19:07 < jtanx> it seems that the sysfs method is not so reliable
+19:07 < jtanx> you can get it to work
+19:07 < jtanx> you have to export those first
+19:07 < jtanx> so echo 0 > /sys/class/pwm/export
+19:08 < jtanx> then (and only then)
+19:08 < jtanx> can you do
+19:08 < jtanx> that echo to the slots
+19:08 < jtanx> for those pins
+19:08 < jtanx> then it seems to be happy
+19:08 < jtanx> if you echo am33xx_pwm to the slots when it's already enabled
+19:08 < jtanx> that also screws things up
+19:08 < sam_moore> Ok
+19:09 < sam_moore> Thanks for working that out
+19:09 < jtanx> yeah
+19:09 < sam_moore> If you want to change from sysfs to the other method that's fine
+19:09 < sam_moore> But sysfs was much simpler to code
+19:09 < jtanx> should have spent that time studying for mech2402 though :P
+19:09 < sam_moore> Because you just sprintf an integer to the path
+19:09 < jtanx> yeah
+19:09 < jtanx> witht he other way it's all that dynamic path crap
+19:09 < sam_moore> Rather than keeping track of "bone_pwm_test_P9_22.15.arbitrary_string" crap
+19:09 < sam_moore> Exactly :P
+19:09 < jtanx> but
+19:10 < jtanx> you can enable pwm and analogue on boot
+19:10 < jtanx> if I can find the link
+19:10 < sam_moore> Sure, if that's easy
+19:10 < sam_moore> I figured if we put them in the /etc/init.d script that'd be fine too
+19:10 < sam_moore> Actually... maybe we should put it in the /etc/init.d script
+19:11 < jtanx> oh yeah
+19:11 < jtanx> and the demo image from that rcn image
+19:11 < sam_moore> Because if someone gets a different beaglebone then they'd have to reenable it on boot
+19:11 < jtanx> is better than screwing around with recompiling kernels
+19:11 < sam_moore> Can you give a link?
+19:11 < jtanx> I think it's the first image that you had originally
+19:11 < jtanx> http://elinux.org/BeagleBoardDebian
+19:12 < jtanx> there's this script in /boot
+19:12 < sam_moore> Oh
+19:12 < jtanx> that allows you to copy the sd card to flash
+19:12 < jtanx> it also enables the usb over ethernet
+19:12 < sam_moore> Oh right, the image I downloaded before we used yours
+19:12 < sam_moore> Cool
+19:12 < jtanx> yeah
+19:12 < jtanx> I flashed electronics' one with that
+19:12 < sam_moore> Does PWM and stuff work on it?
+19:13 < jtanx> probably
+19:13 < jtanx> I was using the same image
+19:13 < jtanx> on ours
+19:13 < jtanx> you run this script and it copies exatly what's on the sd card to the internal flash
+19:13 < jtanx> resizes the partition as necessary
+19:13 < jtanx> http://digital-drive.com/?p=146
+19:13 < jtanx> that page shows how to enable on boot
+19:13 < jtanx> it's just a change to uEnv.txt in the boot partition
+19:18 < sam_moore> Good work
+19:19 < sam_moore> While I remember, for multiple logins and crap... can you just try to login as a local user account?
+19:19 < sam_moore> Then we could make a wrapper around adduser and deluser for the "administrator" account
+19:19 < jtanx> wow
+19:20 < jtanx> I don't know
+19:20 < sam_moore> I was just thinking
+19:20 < sam_moore> Linux has a user account system already
+19:20 < jtanx> yep, but is it a good idea to be making ~300 on a BBB?
+19:21 < sam_moore> Well... putting LDAP on the BBB probably won't be less intense
+19:21 < sam_moore> I know it's called "Lightweight"
+19:21 < sam_moore> But that's in comparison to "DAP"
+19:21 < jtanx> well to be perfectly honest, adrian is asking way too much
+19:21 < sam_moore> Which was designed in the 1980s by a telephone directory company and used the original OSI networking model
+19:21 < jtanx> you simply can't support a 300-odd user base on something like a BBB
+19:21 < sam_moore> Yeah
+19:22 < sam_moore> But maybe something like 30 users would work?
+19:22 < jtanx> yeah
+19:22 < jtanx> let's just keep it at that limit
+19:22 < sam_moore> Another thing regarding the crazy requirements...
+19:22 < sam_moore> If we have multiple Beaglebones running FastCGI
+19:23 < sam_moore> We can design our GUI so that it has links to the appropriate Beaglebone for each function
+19:23 < sam_moore> I don't think we actually need to do anything in nginx or the Beaglebone software
+19:24 < jtanx> hmm
+19:24 < sam_moore> At least in terms of displaying sensor data
+19:24 < sam_moore> For actuator control, we would need to introduce networking between individual beaglebones
+19:24 < jtanx> it actually depends on what he means by 'extensible' and/or distributed
+19:24 < jtanx> like
+19:24 < jtanx> you could say this BBB is for this experiement
+19:25 < jtanx> this other BBB is for this other experiment
+19:25 < sam_moore> But quite frankly you'd be mad to trust a distributed system with networking delays to coordinate control over hardware
+19:25 < jtanx> well yeah
+19:25 < sam_moore> Well at least something like this where we care about safety
+19:25 < sam_moore> But if you keep the actual control over hardware independent and on seperate devices
+19:25 < jtanx> but I mean
+19:26 < jtanx> wait 
+19:26 < jtanx> if we interpret it as meaning
+19:26 < jtanx> that each BBB runs an instance of the software
+19:26 < jtanx> then they would still be separate
+19:26 < jtanx> as in each BBB controls one 'experiment'
+19:26 < jtanx> you customise each BBB based on the experiment that needs to be done
+19:26 < sam_moore> Yes, that would work
+19:26 < sam_moore> Yep
+19:26 < jtanx> then there's no interaction between BBBS
+19:27 < jtanx> the only thing is you have some sort of control at the front
+19:27 < jtanx> that determines which BBB you connect to
+19:27 < sam_moore> Yes, if there's interaction between BBBs it gets problematic
+19:27 < jtanx> yeah
+19:27 < sam_moore> Yes, you have one BBB which gives the user the "main menu" part of the GUI
+19:27 < jtanx> I reckon that's a stupid requirement to ask
+19:27 < jtanx> yeah
+19:27 < sam_moore> Then the others just have customised GUIs or whatever
+19:28 < jtanx> once you have to get them to talk to each other, you're then having to try and invent a whole new protocol
+19:28 < jtanx> for that
+19:28 < sam_moore> Yeah, and it depends on exactly what the hardware is
+19:29 < sam_moore> You might be able to hack it onto the web protocol (eg: BeagleBone #1 sends http://beaglebone2/api/actuators?id=X?set=Y)
+19:29 < sam_moore> But... let's not think about that
+19:30 < sam_moore> It's clearly beyond the scope of this project
+19:31 < sam_moore> So, after all that, I reckon if we use snoopy for ADC/GPIO/PWM and spike for the dilatometer then that would be cool (probably not actually necessary though)
+19:31 < jtanx> yeah
+19:32 < sam_moore> The dilatomter... it's going to cause headaches if Kieren really wants to "return" an array of points
+19:33 < sam_moore> If the goal is to provide the user with a demonstration of what the dilatometer is doing, then you can just edit an image
+19:33 < sam_moore> If the goal is to provide more data... I don't see the point really
+19:34 < sam_moore> It's going to be the same sort of distribution every time
+19:34 < sam_moore> Realistically all anyone would do is average it
+19:34 < sam_moore> Maybe take a standard deviation
+19:36 < jtanx> I really don't know why a dilatometer's even needed
+19:36 < sam_moore> Educational reasons? :P
+19:37 < jtanx> haha sure
+19:37 < sam_moore> Anyway, hopefully Callum will deal with the dilatometer stuff
+19:37 < sam_moore> The interferometer code is a good starting point
+19:39 < jtanx> Yeah
+19:39 < jtanx> hopefully
+19:42 < sam_moore> We should arrange some meetings next week
+19:42 < sam_moore> Also I'd like to see more of the other group members committing to git and talking in this channel
+19:45 < sam_moore> People are missing a lot of design decisions here :S
+19:45 < jtanx> Yeah
+19:51 < jtanx> Ok
+19:51 < jtanx> so I made a LUT from pin number on the board to GPIO pin number
+19:52 < jtanx> so if you wanted to use P8_13
+19:52 < jtanx> you can use the lut to figure out what gpio number that corresponds to
+19:53 < jtanx> we should probably restrict which pins can be used
+19:53 < jtanx> because quite a few are reserved
+19:53 < sam_moore> Sure
+19:53 < sam_moore> Remove the #defines in bbb_pin_defines.h ?
+19:54 < sam_moore> Don't export those pins in pin_test.c
+19:54 < sam_moore> It is only really for testing anyway
+19:54 < jtanx> yeah
+19:55 < sam_moore> Although... I predict if we leave it in the software, *someone* at some point will try and control hardware directly through it :P
+19:55 < sam_moore> For all the educational stuff it's nice though
+19:56 < sam_moore> Oh, we could have an image of the pinout diagram
+19:56 < sam_moore> And when someone clicks on a part of the image they get to control that pin
+19:57 < sam_moore> Anyway... I really should study for MECH2402 or I will fail it
+19:57 < sam_moore> So bye
+19:57 < jtanx> yeah
+19:57 < jtanx> bye
+20:50 -!- jtanx [~asfa@220-253-203-242.dyn.iinet.net.au] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+21:50 -!- MctxBot [~twang@220-253-203-242.dyn.iinet.net.au] has quit [Ping timeout]