| qi-bot | [commit] Werner Almesberger: libubb/Makefile: build also a shared version of libubb; better cleanup (master) http://qi-hw.com/p/ben-blinkenlights/64c14fb | 11:25 |
|---|---|---|
| qi-bot | [commit] Werner Almesberger: ubbctl/Makefile: make default build shared; add target "static" (master) http://qi-hw.com/p/ben-blinkenlights/7b8a2e1 | 11:25 |
| qi-bot | [commit] Werner Almesberger: ubbctl/Makefile: add copyright header (master) http://qi-hw.com/p/ben-blinkenlights/b557adf | 11:25 |
| wpwrak | kyak: i added the shared library build process for libubb. does it look good ? been a while since i did that the last time. | 11:26 |
| qi-bot | [commit] Werner Almesberger: ubblib/Makefile: don't generate the versioned shared library (master) http://qi-hw.com/p/ben-blinkenlights/2004d8c | 14:48 |
| wpwrak | git rewrite-history s/ubblib/libubb/ | 14:49 |
| LunaVorax | Hello | 15:48 |
| LunaVorax | I realized that Qi-Hw had no news for over a year | 15:48 |
| LunaVorax | No on-going projects? | 15:48 |
| kyak | wpwrak: lemme check | 16:21 |
| kyak | wpwrak: make[3]: *** No rule to make target `mmcclk.o', needed by `libubb.a'. Stop. | 16:24 |
| kyak | i don't see mmcclk.c either | 16:24 |
| kyak | ubb/mmclk.h is also not there | 16:25 |
| kyak | hey, it seems we revealed your next secret project :) | 16:26 |
| kyak | btw, you probably already noticed, but naming of source and header (mmcclk.c/mmclk.h) is not consistent | 16:32 |
| whitequark | kyak: how did you make that letter bold, you wizard?! | 16:33 |
| kyak | heh :) depends on your client, in irssi it's ^B | 16:34 |
| whitequark | foobarfoo | 16:34 |
| whitequark | oh cool. | 16:34 |
| kyak | oh, wonder how it looks like in your web logs :) | 16:34 |
| kyak | does it support formatting? | 16:35 |
| whitequark | like *this*, yes it does | 16:35 |
| larsc | 4,3foobar | 16:35 |
| whitequark | blargh | 16:35 |
| whitequark | my eyes | 16:35 |
| larsc | :) | 16:36 |
| whitequark | well I never knew about this formatting, so it doesn't | 16:36 |
| whitequark | plus larsc's colored text breaks the underlying library I use | 16:36 |
| larsc | yea! | 16:37 |
| -kyak:#qi-hardware- just a stupid test | 16:37 | |
| kyak | ah, this one appears as message | 16:37 |
| whitequark | what was that? | 16:38 |
| kyak | it's called notice :) | 16:38 |
| kristianpaul | purple :) | 16:54 |
| wpwrak | (mmcclk.c) oh crap. that's WIP. lemme unleak it ... | 17:19 |
| wpwrak | kyak: not very secret, though :) | 17:20 |
| qi-bot | [commit] Werner Almesberger: libubb/Makefile: unleak mmcclk.o and mis-typed mmclk.h (master) http://qi-hw.com/p/ben-blinkenlights/a593da0 | 17:21 |
| wpwrak | wolfspraul: btw, each push still produces "ssh: Could not resolve hostname fidelio.qi-hardware.com: No address associated with hostname" | 17:21 |
| wpwrak | followed by "error: hooks/post-receive exited with error code 255" | 17:21 |
| wpwrak | sooner or later someone will overlook a real error after getting used to not paying attention to git push complaints | 17:22 |
| wolfspraul | ok great, I finally found the old hostname in a script file | 18:18 |
| wolfspraul | let's see whether the problem is gone now, after your next commit we know... | 18:18 |
| wpwrak | let's see ... | 18:20 |
| qi-bot | [commit] Werner Almesberger: libubb/mmcclk.c: helper functions for selecting and configuring the MMC bus clock (master) http://qi-hw.com/p/ben-blinkenlights/1eb8e64 | 18:20 |
| wpwrak | hmm, the error changed :) | 18:21 |
| wpwrak | http://paste.ie/view/c5034aa1 | 18:21 |
| kyak | wpwrak: we are almost there. Openwrt is too smart, and complains that ubbctl is missing dependency for libubb.so.0.0.0. This is because libubb package only provides libubb.so. I can install the symlink from package, but probably it's better done in Makefile | 18:33 |
| kyak | wpwrak: perhaps another option would be to use the soname without $(LIBVERSION) | 18:43 |
| wpwrak | hmm, you mean call the file libubb.so.0.0.0 (instead of libubb.so) and change the soname from ibubb.so.0.0.0 to libubb.so ? | 18:52 |
| wpwrak | or eliminate the version entirely ? in this case, how would ldconfig know what to do ? | 18:52 |
| wolfspraul | argh :-) | 18:52 |
| wolfspraul | wpwrak: made another change, let's see :-) | 18:52 |
| wpwrak | preparing another commit ... | 18:55 |
| qi-bot | [commit] Werner Almesberger: libubb/include/ubb/regs4740.h: add CPCCR (clock control register) (master) http://qi-hw.com/p/ben-blinkenlights/2f4e1bd | 19:15 |
| wpwrak | victory ! no errors | 19:16 |
| wpwrak | wolfspraul: thanks a lot ! | 19:16 |
| wpwrak | did CPCCR.PCS change from 1 to 0 in the last year or so ? (i.e., that the clock that drives MSC and such is now PLL/2 instead of PLL/1) | 19:19 |
| wpwrak | either that, or i always got the UBB-VGA clock calculations wrong | 19:20 |
| kyak | wpwrak: name the file libubb.so and set soname to libubb.so, or provide libubb.so and libubb.so.0.0.0 (symlink) and change soname to libubb.so.0.0.0 | 19:21 |
| kyak | currently soname is libubb.so.0.0.0, but libubb.so.0.0.0 is not provided | 19:22 |
| kyak | just the libubb.so is provided | 19:22 |
| wpwrak | how does ldconfig know the version if neither file nor soname has it ? | 19:23 |
| wpwrak | or are you saying i can just omit the version completely ? | 19:23 |
| kyak | hmm, dunno, i'm not sure if it possible to omit the version completely :) | 19:24 |
| kyak | i'm just guessing it should work | 19:24 |
| kyak | and yeah, that's what i meant - omit the version completely | 19:25 |
| wpwrak | seems to work. kewl. less bureaucracy ;-) | 19:26 |
| kyak | yeah, just tried it, too.. And you don't need ldconfig in this case | 19:26 |
| wpwrak | even better :) | 19:27 |
| wpwrak | what do i put into "suggested by ..." ? your real name doesn't seem to be on record :) | 19:30 |
| kyak | don't bother :) | 19:31 |
| qi-bot | [commit] Werner Almesberger: libubb/mmcclk.c (mmcclk_first): base clock calculation on state of CPCCR.PCS (master) http://qi-hw.com/p/ben-blinkenlights/b18d688 | 19:33 |
| qi-bot | [commit] Werner Almesberger: libubb/Makefile: get rid of version bureaucracy (suggested by Kyak) (master) http://qi-hw.com/p/ben-blinkenlights/127e18d | 19:33 |
| wpwrak | "kyak" it is then | 19:33 |
| wolfspraul | no problem, thanks for insisting on the bug report | 19:34 |
| wolfspraul | sometimes I do hope bugs go away 'by themselves', but then most of the time it's not like that :-) | 19:34 |
| wpwrak | yeah, that could have been a lazy DNS | 19:36 |
| qi-bot | [commit] kyak: libubb: initial package (master) http://qi-hw.com/p/openwrt-packages/971cadb | 19:38 |
| qi-bot | [commit] kyak: ubbctl: initial package (master) http://qi-hw.com/p/openwrt-packages/66d3d0f | 19:38 |
| kyak | wpwrak: you can download built packages from http://downloads.qi-hardware.com/people/kyak/tmp/libubb_20130107-1_xburst.ipk and http://downloads.qi-hardware.com/people/kyak/tmp/ubbctl_20130107-1_xburst.ipk | 19:38 |
| kyak | they should work, if you have the latest image (2012-10-24) | 19:40 |
| wpwrak | great, thanks a lot ! let's see what installs ... | 19:43 |
| wpwrak | kewl. works like a charm | 19:45 |
| kyak | nice! and thank you | 19:45 |
| kyak | wpwrak: what does "keep" argument do for ubb_open and ubb_close? | 19:51 |
| wpwrak | for ubb_open it specified which GPIOs should be left in the state they have. e.g., don't change them to GPIO, etc. | 19:52 |
| kyak | also, just wondering, why do use well-defined datatypes (like uint32_t), but sometimes use ill-defined (like int)? | 19:53 |
| wpwrak | for ubb_close it specifies which GPIOs should not be reset to the state before calling ubb_open | 19:53 |
| wpwrak | i use uint32_t when it's machine registers and such | 19:53 |
| kyak | ah, ok, so it's like an exception mask.. | 19:53 |
| wpwrak | int/unsigned for all the rest ;-) | 19:53 |
| kyak | keep = 0 means "act upon all pins" | 19:54 |
| wpwrak | yes | 19:54 |
| kyak | ok, thanks for explanation :) | 19:55 |
| kyak | ..also, i should read README more carefully.. | 19:59 |
| wpwrak | yeah, it's all there ;-) | 20:02 |
| qi-bot | [commit] Werner Almesberger: ubb-patgen/hw/: schematics of a pattern generator based on UBB (master) http://qi-hw.com/p/ben-blinkenlights/ed91f62 | 20:02 |
| qi-bot | [commit] Werner Almesberger: ubb-patgen/hw/labels.fig: cut-out labels for the wires (master) http://qi-hw.com/p/ben-blinkenlights/7c1f065 | 20:02 |
| qi-bot | [commit] Werner Almesberger: ubb-patgen/: UBB-based pattern generator (WIP) (master) http://qi-hw.com/p/ben-blinkenlights/52ce194 | 20:02 |
| kyak | wpwrak: what happens if i try to SET pin that is IN? | 20:02 |
| wpwrak | and this is the secret new project :) | 20:02 |
| wpwrak | it'll remember the "1" until you turn it into an output | 20:03 |
| wpwrak | important for avoiding glitches | 20:03 |
| larsc | not so secret anymore ;) | 20:03 |
| kyak | wpwrak: just a suggestion, what if we could pass an argument to ubb_open to initiailize chosen pins as outputs (the rest are initialized as inputs)? | 20:07 |
| wpwrak | would there be a problem in your application if the pin transitions first to input ? | 20:10 |
| wpwrak | btw, you can set any number of pins at the same time with IN, OUT, SET, CLR. you don't have to do it one by one. | 20:10 |
| kyak | well, i believe that it's unlikely someone will change the pin from input to output or vice versa at runtime, so it makes sense to do that once during initialization | 20:11 |
| kyak | yeah, these macros accept masks, that's great | 20:12 |
| kyak | also i was thinking about ubb_write function, that would accept mask of pins to write and a value to write and call SET or CLR under the hood | 20:13 |
| wpwrak | there are many protocols that switch the direction of pins. not everything is SPI or UART ;-) | 20:15 |
| kyak | ok thne :) | 20:16 |
| wpwrak | ubb_write would be tricky because it would be non-atomic | 20:16 |
| wpwrak | that is, unless you set them all to the same value | 20:16 |
| kyak | indeed.. why is it a problem? | 20:17 |
| wpwrak | being non-atomic ? well, people may assume operations are atomic. and if they aren't, you get races | 20:17 |
| kyak | hm, right.. | 20:18 |
| kyak | wpwrak: does PIN accept mask as well? | 20:26 |
| kyak | i can't decrypt the (!!(PDPIN & (mask))) --) | 20:26 |
| wpwrak | it says so, doesn't it ? ;-) | 20:26 |
| wpwrak | what happens is that you get 0 if ALL pins in the mask are 0. else, you get 1. | 20:27 |
| kyak | that's what i thought | 20:27 |
| kyak | but what if i want individual statuses of all pins? | 20:27 |
| wpwrak | !! is simply a normalization. 0 stays 0, everything else becomes 1 | 20:27 |
| wpwrak | that's why the registers are available as well :) | 20:28 |
| wpwrak | SET, PIN, etc. are just simplifications for basic tasks | 20:28 |
| wpwrak | if you need something more complicated, you use PDxxx | 20:28 |
| wpwrak | if you still want more, there's a bunch of additional registers to play with | 20:29 |
| kyak | yeah, i understand, but i'm trying to think from a library point of view :) | 20:29 |
| kyak | if i have a function that does (PDPIN & (mask)) and returns the result as a mask, would it be atomic? | 20:30 |
| wpwrak | yes | 20:31 |
| kyak | ok, then it is ubb_read :) | 20:32 |
| viric | !0 is 1 ? | 20:39 |
| wpwrak | viric: yup | 20:45 |
| --- Tue Jan 8 2013 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!