wolfspraul | nice megahertz myth cartoon http://geekculture.net/joyoftech/joyarchives/243.html | 00:59 |
---|---|---|
wolfspraul | we just wondered about the meaning of milkymist performance over in the #milkymist channel :-) | 00:59 |
wpwrak | cute :) | 01:02 |
wpwrak | the current one is also nice ;-) | 01:02 |
wolfspraul | roh: I will try to use a tp-link mr11u a bit more | 01:58 |
roh | whatfor? packaging to a mm1? | 01:58 |
wolfspraul | roh: I will try to use a mr11u a bit more | 01:58 |
wolfspraul | right now I use my nano as music player mostly | 01:58 |
wolfspraul | right now I use my ben as music player mostly | 01:58 |
wolfspraul | something wrong with my client, urgh | 01:59 |
wolfspraul | so | 01:59 |
wolfspraul | so I use my ben as music player mostly | 01:59 |
wolfspraul | though I want to use other apps more, slow in actually doing it | 01:59 |
wolfspraul | with the mr11u, don't know yet. it's just cheap and maybe I have some ideas for apps/use cases with it. I feel it's like a ben without keyboard and screen. | 02:00 |
wolfspraul | do you know how arduino is doing lately? | 02:01 |
wolfspraul | I am only following the project from the distance, reading news sometimes | 02:01 |
roh | dunno. i am just using it an see people using it. | 02:02 |
roh | i think due to the openness there is no clean 'community' or so. quite cluttered | 02:02 |
wolfspraul | what do you use them for? | 02:04 |
roh | whenever i need a small microcontroller | 02:04 |
roh | most the time i do it as a pde, so others can more easy replicate it. but i havent bought a real board yet. | 02:04 |
roh | mostly i dont even programm their bootloader. just use an avr from the box and flash it via isp in my custom hardware (which often is just some io-driver or so) | 02:05 |
roh | not much documented stuff | 02:05 |
wolfspraul | wow easily 40 books :-) http://en.wikipedia.org/wiki/Arduino | 02:06 |
roh | https://trac.raumfahrtagentur.org/tags?q='arduino' https://trac.raumfahrtagentur.org/tags?q='AVR' | 02:07 |
roh | i got some more, but they never got documented | 02:07 |
roh | one-wire serial interface which reads out ds18b20 temperature sensors and reports to rs232 which a python tool makes into rrd data | 02:08 |
roh | https://trac.raumfahrtagentur.org/wiki/Projekte/EmcArduino thats how most stuff i do 'arduino-esque' end up. | 02:09 |
roh | some box on a wall doing something | 02:09 |
roh | need to build a proper doorbell soon. our second rf doorbell is showing flukes with rain | 02:10 |
roh | i think arduino basically replaced all the '74xxx and cd4xxx' series parts in many of our electronic labs. | 02:11 |
roh | instead of custom complex logic, and a pcb people shoot it with a few lines of code. being done faster is the gain. even if the chips are more expensive. | 02:12 |
wolfspraul | don't you think in a year or two you use cheap routers for that? with usb you can then interface to serial or other i/o, no? | 02:14 |
roh | wolfspraul: nope. too expensive, eats too much power. too big | 02:14 |
roh | i use routers too. no question. but for different stuff | 02:14 |
wolfspraul | the 703n uses something like 180ma including wifi, 100ma without | 02:14 |
roh | our weatherstation is connected to the usb of one of those. running custom binaries to make sense of that | 02:15 |
wolfspraul | the routers have strong momentum and I can see continued investment into that category | 02:15 |
wolfspraul | so they will become smaller, cheaper, more powerful (thouh smaller and cheaper is hard, not sure what you are comparing with when you say big/power hungry/expensive) | 02:15 |
roh | wolfspraul: sure. but thats another usecase scale. avr is 'too small or simple to use a linux os machine' | 02:16 |
wolfspraul | sure, but the router can replace the avr | 02:16 |
roh | not always. | 02:16 |
wolfspraul | and with openwrt the sw is much more flexible and faster/easier to customize | 02:17 |
roh | as i said. its smaller and uses some scalars less power | 02:17 |
wolfspraul | there is a lot of existing solutions around avr, no doubt | 02:17 |
wolfspraul | how much? | 02:17 |
roh | an avr can run for month on battery. no multihundred mhz cpu does that | 02:17 |
wolfspraul | true | 02:17 |
roh | smallest avrs run on picoampere i think | 02:17 |
wolfspraul | but you don't think investment into the router category is, what, several 'scalars' more than into avr? | 02:18 |
roh | i have seen some accesspoints with avrs in there in addition to the arm | 02:18 |
roh | the avr does reset watchdog work ;) | 02:18 |
wolfspraul | they will continue to bring power down, make the chip and electrical design more scalable | 02:18 |
wolfspraul | yes, sure. no doubt. | 02:18 |
roh | making sure the arm gets reset properly and it can do the high-reliability its made for | 02:18 |
wolfspraul | low power, for everybody, has ways to go down | 02:18 |
roh | i think the middle between the routers and the arduinos is more under fire atm | 02:19 |
wolfspraul | I am not saying you should replace anything. just thinking about your "too expensive/big/power hungry" comment | 02:19 |
roh | see the lpc arm9 /arm m0 and m3 cores getting cheaper all the time | 02:19 |
wolfspraul | maybe you have to wrap your mind around how small cheap and low-power the latest routers are :-) | 02:19 |
roh | often they are simply too big | 02:19 |
roh | atleast for what i do. and they take time to boot. | 02:20 |
roh | not using a linux kernel when i dont need it has also features ;) | 02:20 |
wpwrak | roh: so your "arduino" projects are actually just an AVR, nothing arduino :) | 02:23 |
roh | yep. but if possible i release it as a .pde file and use their libs | 02:23 |
wpwrak | wolfspraul: m1 marketing could use that: "contains 72 MHz Arduino softcore" ;) that should impress the hell out of them :) | 02:24 |
wolfspraul | sure | 02:24 |
wolfspraul | sorry to always repeat the same stuff, but I like to get the facts out | 02:24 |
roh | i got another project around, which is a temperature sensor and flow meter for the lasercutter. its not completed yet, but is a pde and a modified arduino lib | 02:24 |
wolfspraul | the 703n I have right here measures at 5.7x5.7x1.8 cm | 02:24 |
wolfspraul | with case | 02:24 |
roh | i basically use arduino as the 'exchange standard for stuff to do with small avrs' | 02:24 |
wolfspraul | 100ma without wifi, 180ma with | 02:24 |
wolfspraul | what, other than inertia of existing knowledge and solutions, would make you not use them more? I think you will slowly use them more | 02:25 |
wolfspraul | and I think they will continue to develop/improve | 02:25 |
roh | so people with less clue about electronics can buy a kit, install the software, add a few buttons and a display and start using | 02:25 |
wolfspraul | I say 'more' | 02:25 |
wolfspraul | and of course the AVR has lots going for them, a totally different class of low-power, microkernel, etc. | 02:25 |
wolfspraul | no kernel | 02:25 |
wolfspraul | I know that | 02:25 |
roh | wolfspraul: writing code which runs on linux even wiggling a wire is more complicated on the wrt than the avr. simple as that. | 02:26 |
wolfspraul | the stronger investment momentum is with the routers though, I'm sure | 02:26 |
roh | people who use arduino usually have very limited knowledge about electronics. much less than any of us | 02:26 |
wolfspraul | yeah | 02:26 |
roh | they wire up stuff, often witout soldering | 02:26 |
roh | its mostly likelythe best c beginners course of the world ;) | 02:27 |
wolfspraul | that's why I think openwrt is important | 02:27 |
wolfspraul | the 703n is just a board for me, then you flash openwrt and that makes the whole thing A LOT more accessible | 02:27 |
roh | no questions. but its like 'the second stage' of learning and hacking embedded electronics. | 02:28 |
roh | much more power (computing), less accessible (needs soldering for gpios) much more networking options. | 02:29 |
roh | i think thats what carambola tried to target (having more pins accessible) | 02:29 |
wolfspraul | weight [703n], including case I measure 35g | 02:29 |
wolfspraul | let's see. my slightly funny formula of 25 USD / kg consumer electronics... | 02:30 |
wolfspraul | that means the 703n can go as low as 87.5 US cents! | 02:31 |
wolfspraul | :-) | 02:31 |
roh | interresting formula | 02:35 |
roh | does it have something like a gain table by product category? | 02:35 |
roh | or are smartphones rated like atx mainboards included cooling? | 02:37 |
wolfspraul | no all the same | 02:50 |
wolfspraul | the only problem is that some vendors like say Apple don't sell their produce by the kg | 02:51 |
wolfspraul | you can't call up Apple to buy 1 kg of iphones for 25 USD + shipping | 02:51 |
wolfspraul | but that's a minor problem, other than that the formula is solid | 02:52 |
wolfspraul | and btw, what do I read in Bunnie's excellent "the end of chumby" interview yesterday? | 02:52 |
wolfspraul | http://blog.makezine.com/2012/04/30/makes-exclusive-interview-with-andrew-bunnie-huang-the-end-of-chumby-new-adventures/ | 02:52 |
wolfspraul | " merchants tend to look at your product not as a whole, but as so many grams of plastic and so many wires, which if you multiply it out by the commodity price of the raw materials sets their expectation for how much they will pay for it to be on their shelf." | 02:53 |
wolfspraul | he speaks from experience, having been part of a device startup that ended up burning 29 million USD before going out in flames | 02:53 |
wolfspraul | I think the formula of 25 USD / kg consumer electronic is not too bad to keep in the back of ones mind | 02:54 |
wolfspraul | if you can sell for more than that, there must be a reason in the software side, marketing, ease of use, some 'platform' or tie-in or network effect. whatever it is. so the iphone is probably more like several thousand USD / kg, or more since Apple probably looks at this from a recurring revenues angle. | 02:55 |
wolfspraul | they get percentages of data revenue, app store percentages, itunes percentages, etc. etc. | 02:55 |
wolfspraul | maybe more like 10,000 USD / kg :-) | 02:56 |
wolfspraul | I feel I'm making my hacker's master thesis here | 03:10 |
wolfspraul | climbing around on a tiny chinese balcony | 03:10 |
wolfspraul | dirty like hell, trying to hookup something to an old & rusty aircon electrical system | 03:11 |
wolfspraul | and I see the other 'pros' on neighboring houses equally fudging around on their stuff | 03:11 |
wolfspraul | at least the sun is shining and blue skies | 03:11 |
wolfspraul | there are estimates of over 1 million (!) worker deaths pear year in Asia | 03:11 |
wolfspraul | nobody counts | 03:12 |
wolfspraul | back to the balcony... | 03:12 |
wolfspraul | I should ('should' use some mountain-climbing gear in case the entire balcony breaks off, foreign made of course. but what to attach it to? nah...) | 03:12 |
wolfspraul | second floor only, I shouldn't complain. werner probably is doing fun stuff up on his 14th floor or whatever it is :-) | 03:14 |
wpwrak | office is on the 15th :) | 03:22 |
kristianpaul | gmenu2x really does underclock xburst clock? | 03:27 |
kristianpaul | cause i been running my nanonote at 80Mhz theorically set by gmenu2x last days.. | 03:28 |
kristianpaul | tought alex4 could get a but jumpy but still work :) | 03:28 |
kristianpaul | s/but/bit | 03:36 |
Ayla | hi guys | 08:13 |
Ayla | do somebody know how I can "boost" a thread from inside an IRQ, to be sure that it will be executed right after the IRQ handler ends? | 08:13 |
wpwrak | Ayla: what exactly do you mean by "thread" ? a user-space thread ? | 11:24 |
Ayla | wpwrak, yes | 11:24 |
wpwrak | you could give it real-time priority. that would make it run as soon as possible | 11:25 |
mth | it would have to be a temporary boost, not a permanent one | 11:26 |
mth | the thread called an ioctl to wait for vsync and then has to update the vertical panning setting before the next frame starts | 11:26 |
wpwrak | once the task is done. the thread could drop the priority. or simply block, waiting for the next event | 11:26 |
mth | but the vblank is only a few milliseconds, so having a different process scheduled would cause the waiting one to miss its time slot | 11:26 |
mth | ah yes, we could handle this in SDL rather than in the kernel | 11:27 |
Ayla | by setting the real-time bit on the thread before waiting for vsync, and removing it after the vertical panning? | 11:31 |
Ayla | (or just a high-priority "nice" number) | 11:33 |
wpwrak | why not have a dedicated thread that only does that ? then you don't even need to change the priority | 11:34 |
roh | in the matrox fbdev driver there is an ioctl to do that | 12:02 |
roh | you can call it and then the userspace thread is getting suspended, and woken up when the retrace came by | 12:02 |
roh | maybe you can replicate that mechanics by adding that ioctl to the jz fbdev | 12:03 |
Ayla | thanks, I'll take a look | 12:05 |
roh | looks dirty on the first view. but its really the simplest way to have fast kernel to userspace response | 12:05 |
mth | roh: we have added the ioctl, but if the userspace thread doesn't get scheduled in time, the vblank will be over before it gets a chance to change the panning | 12:12 |
mth | assuming FBIO_WAITFORVSYNC is the ioctl you're referring to | 12:13 |
roh | i think so | 12:16 |
roh | not every driver has it i think | 12:16 |
roh | can't you set that one thread which does nothing but blit and wait 'realtime' ? | 12:16 |
mth | we don't control the applications, but most applications go through SDL so we could do it there | 12:24 |
mth | it would be simpler in code to take and drop realtime privs around these two ioctl calls (vsync and pan); is there really a need for a separate thread? | 12:25 |
roh | i think changing scheduling parameters constantly will not make it better | 12:28 |
roh | extra thread is easier.. also you do not want to have everything block 60times a sec | 12:28 |
mth | roh: blocking everything 60 times per second is pretty much unavoidable when rendering to the back buffer | 12:46 |
mth | and rendering to a buffer outside of the framebuffer would require an extra copy step, which is an overhead we don't want | 12:46 |
Ayla | I wouldn't mind :) | 12:47 |
mth | in any case, pretty much every game and emulator syncs to 60 Hz anyway, so it might as well be done via vsync | 12:47 |
mth | Ayla: then implement SWSURFACE | DOUBLEBUF in SDL ;) | 12:48 |
Ayla | the SDL app would still have to wait every 1/60s | 12:49 |
mth | not if you make SDL_Flip() do the copy and do the actual flip on a background thread | 12:49 |
mth | which is how SWSURFACE | DOUBLEBUF would work | 12:50 |
Ayla | that's... crude | 12:50 |
mth | it's the only way it makes sense | 12:51 |
Ayla | I think that for the moment, it doesn't really matter | 12:51 |
roh | real pros do tripple buffer ;) | 12:51 |
Ayla | I mean, I don't care if the apps have to wait for vsync, as long as they render perfectly | 12:52 |
mth | ideally we'd do a triple buffer where the buffers are exchanged between kernel and user space, with each buffer belonging only either kernel or userspace at any one time | 12:53 |
mth | afaik v4l2 supports that nowadays, but the framebuffer interface does not | 12:53 |
mth | using vpan for page flipping is not a good interface, but it's what we inherited from old hardware | 12:54 |
mth | well, even with old hardware the kernel could hide the panning and just pretend they are separate buffers | 12:55 |
qi-bot | The build was successful: http://fidelio.qi-hardware.com/~xiangfu/build-nanonote/openwrt-xburst.full_system-20120503-1301 | 19:03 |
--- Sat May 5 2012 | 00:00 |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!