2011-07-28 00:01 hmm, Mr Drillux triggers a reboot 2011-07-28 00:02 some minutes ago, my dingoo rebooted while I was coding 2011-07-28 00:02 and USB wasn't even plugged 2011-07-28 00:02 it was idleing at gmenu2x 2011-07-28 00:02 this one was not random though, I can reproduce it 2011-07-28 00:03 let me guess 2011-07-28 00:03 you have USB plugged in 2011-07-28 00:04 without USB, does it powers off instead of rebooting? 2011-07-28 00:06 no, it also reboots then 2011-07-28 00:06 ah 2011-07-28 00:06 snes9x does poweroff when entering the in-game menu 2011-07-28 00:07 just because /proc/jz does not exist, then it can't read the battery 2011-07-28 00:07 the guy did code a poweroff-when-low-battery function :) 2011-07-28 00:11 can the disabling of the fb console be added at a later moment than previously? 2011-07-28 00:11 for example, in the gmenu2x startup script 2011-07-28 00:12 or maybe even in the same place that sets the SDL-don't-clear flag? 2011-07-28 00:12 I'd like to get logging if the frontend startup fails 2011-07-28 00:14 by the way, console apps are broken for me now, is there a way to fix that? 2011-07-28 00:14 by adding a flag to the ini file if needed 2011-07-28 00:14 they are broken even if bind is not set to 0 2011-07-28 00:16 ah, it was about redirecting to a log file, iirc 2011-07-28 00:17 there is no log viewer menu item anymore though 2011-07-28 00:17 mth: I don't really know where to put that command 2011-07-28 00:19 I guess the first step would be to have an per-app flag whether the app is graphical or text-based 2011-07-28 00:19 and remove the global log flag 2011-07-28 00:20 well, we could omit logging of graphical apps, but does that ever make sense? 2011-07-28 00:20 and we could log text apps using "tee", but again, does it make sense? 2011-07-28 00:24 I don't understand, you want to remove the log feature? 2011-07-28 00:25 no, I want to auto-enable it when it makes sense 2011-07-28 00:25 then I was thinking about the contrary, log the graphical apps and not the text apps 2011-07-28 00:25 I guess with a text-based app that is not (n)curses based, logging might be useful 2011-07-28 00:26 Ayla: yes, that was my original idea as well 2011-07-28 00:26 I'm wondering though whether there are exceptions to that rule 2011-07-28 00:27 on the NN, the full keyboard means a lot more text-based applications are useful 2011-07-28 00:28 yes 2011-07-28 00:28 something like a telnet/ssh session might be useful to log 2011-07-28 00:28 while an (n)curses application would not be useful to log 2011-07-28 00:29 maybe I'm overcomplicating things though for an initial version 2011-07-28 00:29 I think the log is fine as it is right now 2011-07-28 00:29 the log makes apps like alsamixer unusable 2011-07-28 00:32 is the sysfs "bind" file really only changeable when the console is visible? 2011-07-28 00:34 no, you can change it when gmenu2x is running for instance 2011-07-28 00:35 if I try that, the value stays 1 2011-07-28 00:36 re-activating the console works, I didn't test the other way 2011-07-28 00:37 re-activating works during the loading screen, not while gmenu2x is still running 2011-07-28 00:37 not here, anyway 2011-07-28 00:37 weird 2011-07-28 00:47 I'm off now 2011-07-28 00:47 I'll see that tomorrow 2011-07-28 00:47 bye 2011-07-28 01:13 marcan: hi there and welcome! 2011-07-28 01:14 hello :) 2011-07-28 01:14 fyi - marcan is the guy behind the OpenLase project http://marcansoft.com/blog/2010/11/openlase-open-realtime-laser-graphics/ 2011-07-28 01:14 http://git.marcansoft.com/?p=openlase.git;a=summary 2011-07-28 01:15 I'm about to catch some sleep, but we should have some overlap during my morning/your afternoon :) 2011-07-28 01:15 which is a laser projector, thanks to Tuxbrain for digging it up... 2011-07-28 01:15 marcan: sure :-) I'm here all day long, just sipping my morning coffee :-) 2011-07-28 01:20 sigh..... http://blog.slyon.de/2011/07/26/openmoko-gta04-is-getting-reality/ 2011-07-28 01:35 marcan: just asked rejon who confirmed that you cannot put the laser rendition of the bad apple clip under a cc license 2011-07-28 01:37 right, I figured 2011-07-28 01:37 I like the fact that it's scanned from a video 2011-07-28 01:37 maybe once I learn japanese I'll be able to ask for permission :) 2011-07-28 01:38 maybe we can scan another video that is already cc licensed? 2011-07-28 01:38 it's not super important though, just that I think that's a capability worth talking about 2011-07-28 01:38 yeah, but it's going to be hard to find something that works that well 2011-07-28 01:38 well, technically, an early prototype of the tracer is in the LASE demo video - used for metaballs and fire, which are first rendered as bitmaps 2011-07-28 01:38 understand, needs to be pulled through some black&white naturalization or high-contrast or whatever filter 2011-07-28 01:39 (after that was when I had the idea of plugging in ffmpeg and the whole video tracing thing took off) 2011-07-28 01:39 oh, it doesn't require that 2011-07-28 01:39 I have a Canny edge tracer that looks for edges, regardless of whether the video is black/white 2011-07-28 01:39 and does a pretty good job 2011-07-28 01:39 but of course it can't magically turn a normal video into a perfect stylized shadow art thing like that bad apple video 2011-07-28 01:40 understood 2011-07-28 01:40 real life problems :-) 2011-07-28 01:40 but the idea is still cool! 2011-07-28 01:41 I've been meaning to apply it to a realtime depth image lifted from a Kinect 2011-07-28 01:41 that is pretty cool marcan 2011-07-28 01:41 that should give us something very similar to the Bad Apple video, but from a live feed :) 2011-07-28 01:41 marcan: can use some images from http://openclipart.org and animate them 2011-07-28 01:41 or make something similar 2011-07-28 01:41 marcan: ah yes, I think rejon is openclipart founder :-) 2011-07-28 01:42 rejon: is that right Jon? 2011-07-28 01:42 there's an svg2ild in there for static images (that can be embedded in openlase apps), though it doesn't (yet) do animation 2011-07-28 01:42 (that's how the LASE title and the Euskal Encounter outro were done for LASE) 2011-07-28 01:43 so since marcan has not gone to sleep yet, just for the record the idea being discussed here is to manufacture his laser projector as copyleft hardware 2011-07-28 01:43 tuxbrain was so super excited about it and said it had to be combined with milkymist one - SOMEHOW 2011-07-28 01:43 :-) 2011-07-28 01:43 (fwiw, it was always meant to be open hardware ;) 2011-07-28 01:43 sure, we know 2011-07-28 01:44 it will take some time for more people to understand how it's built, how it could be used with our video synthesizer, and so on 2011-07-28 01:44 marcan: it would be awesome if you could do the electrical design in KiCad, we've done a lot of work with KiCad and come to like it 2011-07-28 01:45 that's what I was thinking about using 2011-07-28 01:45 I've never used it but it's been on my TODO list for a while 2011-07-28 01:45 rejon: (marcan correct me if I'm wrong) my understanding of the design is that at the core it's a cheap laser pointer, then some mirrors and electro motors for positioning, and a microcontroller/circuit to integrate the whole thing 2011-07-28 01:45 Eagle freeware being closed source and limited, and gEDA, well, can be a bit annoying at times 2011-07-28 01:45 kicad looks good, I've just been waiting for an excuse to try it :) 2011-07-28 01:46 marcan: you are in the right place here, we've done _A LOT_ of KiCad work 2011-07-28 01:46 cool 2011-07-28 01:46 as for the hardware, it's even simpler 2011-07-28 01:46 data is fed to the projector mainly in the form of audio channels, on M1 (Milkymist One), maybe we can hook it up over USB... 2011-07-28 01:46 there's a tiny micro but it's just there for some power/safety stuff 2011-07-28 01:46 the core is just a USB sound card feeding straight into the motor drivers 2011-07-28 01:47 marcan: if you don't have a repository yet, feel free to use the projects.qi-hardware.com server 2011-07-28 01:47 for the KiCad files 2011-07-28 01:47 but I think you have a repo already, then it's more important to keep it all in one place... 2011-07-28 01:47 yeah, I have an OpenLase Git on git.marcansoft.com 2011-07-28 01:47 I'll put the hardware stuff on a repo next to that 2011-07-28 01:48 we've done quite a bit of work for server-side KiCad automation, like schematics history for example http://projects.qi-hardware.com/schhist/m1-jtag-serial/ 2011-07-28 01:48 ha, is sounded like like jean michel jarre, and it is :-), great stuff 2011-07-28 01:48 but yes, keep it in one place 2011-07-28 01:48 yeah, I saw that on the tuxbrain talk 2011-07-28 01:48 that definitely convinced me to try it :) 2011-07-28 01:48 s/is/it 2011-07-28 01:48 try what? 2011-07-28 01:48 KiCad 2011-07-28 01:49 ah yes, definitely 2011-07-28 01:49 the motors are off the shelf chinese galvos (they come with the mirrors and all that) with their drivers and whatnot 2011-07-28 01:49 I can dismiss any concerns about 'not ready for professionals' today, easily. we've done enough work in the last years to know it's not true. 2011-07-28 01:49 the current design is a patchwork of stuff (hacked USB sound card, hacked laser pointer, galvos, etc.) 2011-07-28 01:49 but I want to unify all the electronics into one or a few boards designed from scratch as all-digital controllers, at least up until the galvos 2011-07-28 01:50 our goal should be to integrate everything as much as possible, and to make it as cheap and robust as possible 2011-07-28 01:50 easier said than done :-) 2011-07-28 01:50 so I wouldn't use the original galvo controllers (the galvos can be sourced standalone, I've asked for them once) 2011-07-28 01:50 I think I can get huge advantages in performance and features that way :) 2011-07-28 01:51 for sourcing, I suggest digi-key as a first orientation on availability 2011-07-28 01:51 for electronics, of course 2011-07-28 01:51 but you won't find galvos on digi-key ;) 2011-07-28 01:51 if you need stuff that is not on digikey, like modules or those galvos, please bring it up as early as possible and I do some reasearch in China 2011-07-28 01:52 100% of our vendors and supply chain are documented 2011-07-28 01:52 I am not holding _any_ information back when I manufacture something 2011-07-28 01:52 for example this is the inventory I currently have, various leftovers mostly :-) http://en.qi-hardware.com/wiki/Sharism_inventory 2011-07-28 01:53 and vendors we buy from http://en.qi-hardware.com/wiki/Vendor_Code 2011-07-28 01:53 http://www.phenixtechnology.com/en/products_view.asp?id=135&dl_id=1001&lb_id=10010001 2011-07-28 01:53 those are the ones I'm using right now 2011-07-28 01:53 (took me a while to track down those guys, since I originally got them through a reseller on eBay) 2011-07-28 01:53 I had to find them because the reseller vanished and I blew one of my galvos 2011-07-28 01:54 marcan: what other parts do you believe exist anywhere in the laser projector that are not 'common' 2011-07-28 01:54 let's define 'common' as 'not on digikey' for now 2011-07-28 01:55 can you project in water vapour? 2011-07-28 01:55 first the galvos, and anything else? 2011-07-28 01:55 just the laser(s) themselves I guess 2011-07-28 01:55 yes, on openclipart 2011-07-28 01:56 (and the two dichro mirrors if we do RGB) 2011-07-28 01:56 (dichros are used to mix the lasers into one beam) 2011-07-28 01:56 another idea is to just rerender something like http://bigbuckbunny.com with only the black and white, remove background 2011-07-28 01:56 marcan: I need more technical information on those parts 2011-07-28 01:56 or what is their new film, http://sintel.com 2011-07-28 01:56 as much as you know about them, hard specs 2011-07-28 01:56 wolfspraul: the galvos, or the other stuff? 2011-07-28 01:56 everything that is not on digikey :-) 2011-07-28 01:57 so I think now we have: 2011-07-28 01:57 1) galvos 2011-07-28 01:57 2) laser 2011-07-28 01:57 3) dichros 2011-07-28 01:57 if we call these things 'modules', we need to be careful with those modules 2011-07-28 01:57 I don't want to depend on completely opaque ebay sources 2011-07-28 01:57 of course 2011-07-28 01:58 the spot market in Shenzhen is a heaven for modules, but I need to spend a little time to see which is the best way to source 'standardized' modules 2011-07-28 01:58 for example for LCM, or touch panels, or many others types I'm very clear nowadays 2011-07-28 01:58 but of course for those 3 - no idea now :-) 2011-07-28 01:58 I think we want to do two things, 1) make the board as generic as possible so people can use their own modules, 2) find some "reference" sources for complete kits or whatever if we do that 2011-07-28 01:59 oh I want to make a full product, including mechanical design, everything 2011-07-28 01:59 sure, but I think we also want to be able to sell the board to someone who wants to use it to build their own projector 2011-07-28 01:59 not me, you can do that :-) 2011-07-28 01:59 since everyone seems to want different colors/powers/galvo quality :) 2011-07-28 01:59 or Tuxbrain :-) 2011-07-28 01:59 sure :) 2011-07-28 02:00 fine, but I am interested in making those decisions towards what _we_ consider is 'good' quality 2011-07-28 02:00 so the end user can just buy the thing and it will work 2011-07-28 02:00 agreed 2011-07-28 02:00 since everything is open, opportunities for branching out in a new direction are always there 2011-07-28 02:00 in fact making that easy is a key goal 2011-07-28 02:00 which means I need to experiment still :) 2011-07-28 02:00 but because that is easy, I can solely focus on what I believe is a good integrated product 2011-07-28 02:01 definitely, this will take months 2011-07-28 02:01 what would help me now is to understand more about the galvos, laser and dichros we need 2011-07-28 02:01 their specs 2011-07-28 02:01 for 1) I only know of those galvos, 2) I'm just using DealExtreme pointers, but thankfully diode laser modules aren't rocket science and are fairly interchangeable; 3) no clue about dichros yet (I haven't done RGB yet), but I understand it's a pretty generic item 2011-07-28 02:02 with 'now' I don't mean right now (you need to go sleep), but I mean in next days/weeks 2011-07-28 02:02 i.e. a hunk of glass passing one wavelength and reflecting another, it doesn't really matter who you get it from 2011-07-28 02:02 dealextreme is not bad 2011-07-28 02:02 it's like a remote version of digging through shenzhen spot markets 2011-07-28 02:02 of course super inefficient compared with a trip there 2011-07-28 02:02 yeah 2011-07-28 02:03 their lasers are a bit hit and miss at times though :P 2011-07-28 02:03 everything there is :-) 2011-07-28 02:03 but if you would spend a week with me walking around the markets, you would realize the inability to build a reproducible online shop out of this :-) 2011-07-28 02:03 http://en.qi-hardware.com/wiki/Shenzhen_markets 2011-07-28 02:04 that's the work I can contribute to your project actually 2011-07-28 02:04 haha :) 2011-07-28 02:04 find cheap ways to integrate everything 2011-07-28 02:04 cleanup the sources 2011-07-28 02:04 find some hard-to-source modules 2011-07-28 02:04 yeah, having someone who knows his way around Chinese markets is a huge bonus 2011-07-28 02:04 especially since that's the only way to get affordable laser parts (particularly the galvos) 2011-07-28 02:04 (and the lasers) 2011-07-28 02:04 well we need to dig out the facts, specs etc. 2011-07-28 02:05 I'd say we need to decide on them first :) 2011-07-28 02:05 once we dig this out, we can do sourcing anywhere, in the end it is quite possible that many parts actually come from Japan/Korea/Taiwan 2011-07-28 02:05 basically I want to start working on the new hardware soonish and see where that gets me, I don't think I'll be able to start deciding on hard specs until I have some prototypes for the electronics and I can actually test stuff 2011-07-28 02:06 but if you want to know what my _current_ hacky projector looks like, well, the basic specs are 30kpps galvos, and a 200mW (currently) DPSS green laser diode 2011-07-28 02:06 you have a much clearer idea on specs than me right now, so it helps if you write up what type of laser/galvo/dichro _might_ work 2011-07-28 02:06 ah there you go :-) 2011-07-28 02:07 s/diode/module/ 2011-07-28 02:07 sorry interrupt again but, i'm confuse, where are the schematics here  git.marcansoft.com ? 2011-07-28 02:07 (there's no such thing as a green laser diode) 2011-07-28 02:07 kristianpaul: the schematics aren't on the git, I just wrote a quick blog post about the hardware some time ago 2011-07-28 02:07 since the current version is very much DIY/adapt-as-you-go, not really a 100% reproducible product 2011-07-28 02:08 [commit] Xiangfu Liu: new package for keep milkymist config files (master) http://qi-hw.com/p/openwrt-packages/787a430 2011-07-28 02:08 but the two parts I built from scratch (the main controller board and the laser driver) have their respective schematics 2011-07-28 02:08 http://marcansoft.com/blog/openlase/hardware-mark-1/ 2011-07-28 02:08 there's the writeup on the hardware 2011-07-28 02:09 marcan: anything other than galvo/laser/dichro that's not on digikey? 2011-07-28 02:10 check out my qi-hw project: http://en.qi-hardware.com/wiki/Laoban_Soundsystem 2011-07-28 02:10 other than mechanical stuff (case, heatsinks, mounts, that kind of stuff), not that I can think of 2011-07-28 02:10 the final design is very much up in the air, but I don't intend to use anything exotic 2011-07-28 02:11 the only mildly weird thing is I want to use an XMOS micro, which is a newfangled multicore event-driven thing that I think is a good match, but that's on digi-key too 2011-07-28 02:11 marcan: I am not an electrical engineer, I can barely read a circuit 2011-07-28 02:11 just clarifying my role 2011-07-28 02:11 so what I can help with is sourcing, manufacturability 2011-07-28 02:12 rejon: wow, 6000W :) 2011-07-28 02:12 so you will see me following your project very much from a sourcing side. asking questions about specs of parts etc. 2011-07-28 02:12 if you use KiCad, you can follow some of the naming conventions we've come up with, if you like 2011-07-28 02:12 and hopefully safety ;) 2011-07-28 02:13 the new design will be much safer (laser-wise) than what I have now 2011-07-28 02:13 since I'll do the galvo driving loop in the micro, if the galvos break/stop moving I can turn off the laser 2011-07-28 02:13 marcan: Werner Almesberger (wpwrak) may have feedback for you once your KiCad project is up. Stuff is also written up and you can look at the KiCad projects on projects.qi-hardware.com 2011-07-28 02:13 right now that can't be detected since the galvo drivers give no feedback :) 2011-07-28 02:14 (the #1 unsafe situation for a laser scanner is that the laser stops and delivers full power to one point, then if someone gets hit in the eye you've got a problem) 2011-07-28 02:14 wolfspraul: will do 2011-07-28 02:14 (feedback) yeah, was about to point that.. 2011-07-28 02:15 this is super alpha, but still http://en.qi-hardware.com/wiki/Copyleft_Hardware_Style_Guide 2011-07-28 02:15 feel free to use if it makes sense for you, we are all learning and debating what's best... 2011-07-28 02:16 hey, i missed that page, looks interesting 2011-07-28 02:16 duly noted 2011-07-28 02:16 updated 2011-07-28 02:16 can you replace laser by some sort of hihg power LED or something? 2011-07-28 02:17 well, just barelly asking 2011-07-28 02:17 I've had a crazy year (moves, conferences, stuff to organize, jobs etc), but as soon as I get more "stable" in the coming months I want to start seriously cleaning up OpenLase and working on the hardware 2011-07-28 02:17 since I've had several interested people, and just not enough time to really start documenting things properly :/ 2011-07-28 02:18 kristianpaul: not really, it needs to be a laser to be collimated 2011-07-28 02:18 I'm interested too, it allows me to dig into parts I haven't digged in before (galvos/dichros/laser), and out of that we can build good products in the future, maybe :-) 2011-07-28 02:18 you can't really focus an LED down to a line 2011-07-28 02:18 yeah.. 2011-07-28 02:18 one of the cool things about the laser projector is you can project on uneven of way off-angle surfaces 2011-07-28 02:19 well, be safe ! i'll follow your blog for now as well :) 2011-07-28 02:19 and there are no focus issues, you just adjust the transform 2011-07-28 02:19 wolfspraul: btw the point of laoban soundsystem always was to make copyleft/open soundsystems 2011-07-28 02:19 ears are super sensitive 2011-07-28 02:19 and bass/sound is all around 2011-07-28 02:19 vision you have to get heads pointed at 2011-07-28 02:19 marcan: so that's my wishlist - more documentation about the desired/required/best specs for those 3 parts 2011-07-28 02:20 wolfspraul: will do, just don't expect it "real soon" because I'm still very much unclear about it still, I need to start doing some prototyping first :) 2011-07-28 02:21 marcan: do you have a picture of the innards of your current projector? 2011-07-28 02:21 http://www.teledynelighting.com/products/PhotonEngine/default.asp may be? 2011-07-28 02:21 it doesn't have a case, so more like the outards ;) 2011-07-28 02:21 http://marcansoft.com/uploads/laser/hardware/overall.jpg 2011-07-28 02:21 marcan: oh sure, keep us posted about the prototyping. I'm sure those are exactly the points that will come up there. 2011-07-28 02:22 as you can see, veery hacky construction ;) 2011-07-28 02:22 but works very well ! 2011-07-28 02:22 thanks :) 2011-07-28 02:22 and no injuries so far, right? :) 2011-07-28 02:22 not that I know of anyway :) 2011-07-28 02:23 :-) 2011-07-28 02:23 I'm pretty careful, and I've got my safety goggles 2011-07-28 02:23 the rule at 100mW or so, as far as I can calculate, is that it should be safe as long as it's drawing something nontrivial (though you don't want to get hit deliberately, of course) 2011-07-28 02:23 marcan: are all pictures/videos on your blog or posted by you cc-by? 2011-07-28 02:23 so the danger is while you're adjusting or messing with the projector itself, and that's when you use goggles :) 2011-07-28 02:24 wolfspraul: consider all the pictures cc-by, as for the videos, if they don't contain third-party source video or audio, same thing 2011-07-28 02:24 got it, great! 2011-07-28 02:26 marcan: can the projector be passively cooled? 2011-07-28 02:26 currently it's all passive, though if we put it in a case it might be a good idea to get some airflow 2011-07-28 02:26 but with some clever engineering (using the case as a heatsink...) it can probably be done entirely passive 2011-07-28 02:27 on that picture, where are the galvos? 2011-07-28 02:27 the power supply is bottom left 2011-07-28 02:27 top center/rightish 2011-07-28 02:27 ah ok 2011-07-28 02:27 what's the top left part? 2011-07-28 02:27 http://marcansoft.com/uploads/laser/hardware/galvos.jpg 2011-07-28 02:27 where is the laser output? 2011-07-28 02:27 top left is the laser 2011-07-28 02:28 mounted on a heatsink and with a black cover on top to catch any stray reflections, if any 2011-07-28 02:28 yes, you should definitely try to avoid a fan 2011-07-28 02:28 my one interesting unknown re: cooling right now is cooling the lasers themselves 2011-07-28 02:28 "pro" stuff tends to use TEC cooling (peltier) as far as I know, for temperature stability 2011-07-28 02:29 I'm not using any of that yet, but I do notice some instability with the laser module 2011-07-28 02:29 so I might experiment with that 2011-07-28 02:29 yes, good 2011-07-28 02:29 [commit] Xiangfu Liu: m1: add busybox EXTRA_CFLAGS option (master) http://qi-hw.com/p/openwrt-packages/6226524 2011-07-28 02:30 ok, I should be getting some sleep :) 2011-07-28 02:32 night marcan cool stuff! 2011-07-28 02:33 great to see you join us in here 2011-07-28 02:33 things are moving 2011-07-28 02:33 n8 2011-07-28 02:50 ahh outw_p is from the outb familly 2011-07-28 02:54 i guess i can just re-use the mmio functions from milkymist rtems bsp 2011-07-28 03:06 kristianpaul: how's the gps stuff coming along btw? 2011-07-28 03:07 this a nice doc svn.psas.pdx.edu/svn/psas/trunk/gps/documentation/adg_thesis_final.pdf 2011-07-28 03:07 wolfspraul: working on osgps porting 2011-07-28 03:07 well, for now verifying code compatiblity 2011-07-28 03:07 seems write/read not big deal 2011-07-28 03:08 now remains, registers compatibillity check, and intterupt handling 2011-07-28 06:03 (openlase) neat stuff ! 2011-07-28 06:05 marcan: (safety) how fast can you switch the laser on/off ? e.g., could you control its power with a PWM without getting the beam visibly chopped ? and when the beam hits an eye, how long do you have before it does damage ? 2011-07-28 06:08 (hw guide) makes me realize just how much we still have to document :-) complete naming conventions, sizing conventions for schematics (text, symbols), idem for footprint/layout (a lot more parameters), tables of parameters per component types, ... then there are a few things at the extreme end of the range, like caps with merely fF (and tolerances in % or F) that deviate from the usual rules 2011-07-28 06:12 (hw guide) next, package naming conventions, footprint style conventions/recommendations, workflow (e.g., how do i add a symmbol or a footprint; how do i generate gerbers from my project), recommended mechanical parameters, footprint dimensioning rules and recommendations (these are my favourite - remember all those long posts full of obscure numbers and more references than the average PhD thesis, with all the sources violently contra 2011-07-28 06:12 dicting themselves ? :) 2011-07-28 06:12 hopefully we will pick up some phds too wpwrak 2011-07-28 06:13 (hw guide) sourcing best practices, etc. etc. 2011-07-28 06:13 a PhD in copyleft hw would be sweet ;-) 2011-07-28 06:16 another option 2011-07-28 06:16 :) 2011-07-28 06:17 well, sebastien should be about halfway there. llhdl should also satisfy the prerequisite theoretical work. write a few conference papers and find a university where they're not too picky about form, and voila :) 2011-07-28 06:18 halfway, phew. i'm halfdead. even just working on sourcing makes me feel there's still 1000 things I cannot even spell right. 2011-07-28 06:19 Adam's testing is slowly making progress btw 2011-07-28 06:19 http://en.qi-hardware.com/wiki/Milkymist_One_run_3_schedule#Test_Results 2011-07-28 06:19 we have to wait for full data for all 90 pcbas first 2011-07-28 06:20 7 in 100% pass condition now, I hope this goes up! :-) 2011-07-28 06:20 93% yield isn't half bad 2011-07-28 06:21 no I have 7 boards that pass 100% 2011-07-28 06:21 after testing 27 :-) 2011-07-28 06:21 but we need a full data set first... 2011-07-28 06:21 oh :) 2011-07-28 06:22 first priority - make as many boards 100% pass as quickly as possible 2011-07-28 06:22 second priority - understand systematic problems of this run so that the next run has better yield/less problems 2011-07-28 06:23 third priority - fix boards one by one, starting with the easiest, moving towards the harder ones, and stopping when it's so hard (per board) that it makes no economic sense to continue, and instead start the next run 2011-07-28 06:23 we are in #1 now 2011-07-28 06:24 yes, makes sense 2011-07-28 06:25 good logik 2011-07-28 06:26 #1 has actually to parts: #1.1 make a few work 100%, so you know that there's no common fatal flaw. #1.2 get boards ready for distribution/selling. #1.2. may or may not be in you critical path, depending on what other things you need (e.g., case parts, accessories, box, ...) 2011-07-28 06:27 rejon, hi 2011-07-28 06:27 wpwrak: #1.1 is what the very first board is for, that is taken off the smt line before the rest is pushed through. A bit risky maybe to only take 1, but that's how it's done normally. 2011-07-28 06:27 i am still testing..rc3 though 2011-07-28 06:28 I guess the assumption is that the smt/reflow process is so deterministic that if there are no problems with the first board, the rest can be pushed through safely 2011-07-28 06:28 too much data in that situation wouldn't help you either, because the line is waiting... 2011-07-28 06:28 (just one) yeah, one is hard enough work and you have just one adam :) 2011-07-28 06:28 rejon, so my apartment/office here now is messy a little, after testing all boards firstly maybe we can meet at somewhere. ;-) 2011-07-28 06:29 in theory, >1 board would be good to spot very bad variations or exceeded tolerances. but the value of adding boards quickly diminishes. and your smt line will only have so much patience ;-) 2011-07-28 06:34 yay. glueing done. solvent jar closed (i hope i can let it be closed for some time now) 2011-07-28 06:34 aw: cool man 2011-07-28 06:34 don't want to distract you 2011-07-28 06:34 i'm here near taipei 101 2011-07-28 06:35 now letting it rest a few hours.. will do qc on the remaining sheets now and then check the yesterday-glued 75 (qc) and package them 2011-07-28 06:35 rejon: youre in tpe? nice. 2011-07-28 06:36 roh: does the solvent at least smell "nice" ? ;-) 2011-07-28 06:36 i havent smelled it yet. i guess thats a good sign 2011-07-28 06:36 how boring ;-) 2011-07-28 06:36 a chemist i know warned me about it, but commented that its 'a nice turn when it happens' 2011-07-28 06:37 *grin* 2011-07-28 06:37 i guess he must know. (/me likes physics but chemicals are still something i consult people on a default basis) 2011-07-28 06:38 rejon, ;-) 2011-07-28 06:39 roh: you should once try pcb speed etching. mix ~30% HCl and ~30% Peroxide in equal parts, then insert the PCB and agitate it a bit. make sure spills and fumes will be contained :) 2011-07-28 06:40 aw: there is something brewing for next tues. then you can meet a few people working on parts of the puzzle :) 2011-07-28 06:40 roh: if you're really good, you will even be able to get the board out before it's completely ruined :) 2011-07-28 06:40 might be better 2011-07-28 06:40 wpwrak: "may the yield be with you" :-) 2011-07-28 06:42 wpwrak: i am really happy we got a ventillation system here 2011-07-28 06:42 wpwrak: used it a lot lately for making sure nobody gets harmed. 2011-07-28 06:43 sigh, what happened to the mad scientists of the good old days ? 2011-07-28 06:44 it has 3 power levels and was built for the former useage as solarium. i only use stage1 on outtake air usually. sometimes also stage1 intake 2011-07-28 06:44 every stage eats about 3kW. so its 18 kW max power. 2011-07-28 06:45 also kinda funny: stage 3 out and no in active makes the inner front door open by itself (against a spring loaded closer) because of the air getting sucked out. 2011-07-28 06:45 hmm. are you sure it's designed to work with chemicals ? some stuff can be quite corrosive. without an appropriate filter, you won't enjoy that ventilation for long ... 2011-07-28 06:46 afaik all filters are gone already. its mostly consisting of tubing made from fire-zinked metal and some aluminium parts 2011-07-28 06:47 also it was for free (well.. eats electricity for breakfast) 2011-07-28 06:48 well, you may want to check its condition every once in a while :) 2011-07-28 06:48 and avoid experiments with quicksilver :) 2011-07-28 06:50 http://yamato.hyte.de/tmp/vent.jpg 2011-07-28 06:50 hrhr. sure.. no nasty stuff 2011-07-28 06:52 nice control panel :) 2011-07-28 06:52 wpwrak: btw.. i heard you met elekta 2011-07-28 06:54 roh: yeah, she was at fisl 2011-07-28 06:54 didn't spot anything obviously wrong with my wpan boards. that was encouraging :) 2011-07-28 06:54 :) 2011-07-28 07:19 that "bad apple" song seems to have inspired quite a lot of creative adaptations. various laser shows, ASCII art, minesweeper art, one even hand-carving real apples ! http://www.youtube.com/watch?v=Ol2LDUcoVhk 2011-07-28 07:25 or here, with the original video on the side: http://www.youtube.com/watch?v=Qo6HzavOfbI 2011-07-28 07:33 wow, yes. that must be thousands of pictures with the apples... 2011-07-28 07:38 btw.. i hope you all ordered your camp tickets ;) 2011-07-28 07:39 how many did you sell so far? 2011-07-28 07:40 wpwrak: after the laser projector, we work on the automated apple peel cutter 2011-07-28 07:40 wolfspraul: not sure. i dont have the numbers. but its not sure there will be a on-site sale at all 2011-07-28 07:42 wolfspraul: yeah, when i saw this, i started to wonder how hard it would be to cnc-mill an apple ;-) 2011-07-28 07:49 the artist is also in there, very humble at 2:38 2011-07-28 07:49 a real fan 2011-07-28 07:54 yeah, this must take quite some dedication 2011-07-28 07:56 and the cool thing is: THEY'RE ALL CRIMINALS ! they're blatantly violating the copyright. lock them away ! now ! :) 2011-07-28 09:03 xiangfu: question: what would you think i moved fped's "home" over to qi-hw, and take over the fped project you've already created here ? i think all your things are under debian/, so it should be easy to have the main repository and your debian work coexist 2011-07-28 09:04 wpwrak, yes. that will be great. 2011-07-28 09:05 yes. all debian package stuff is under debian/ 2011-07-28 09:05 xiangfu: i'll make myself project admin then, okay ? 2011-07-28 09:05 yes. sure. 2011-07-28 09:06 and shall we merge debian/ into the main branch ? or would you prefer to keep it in a separate branch ? 2011-07-28 09:07 if you don't mind put 'debian/' in your source code, just do it. 2011-07-28 09:07 I just put the 'debian/' in xburst-tools 'master' branch 2011-07-28 09:08 perfect. i'll merge it then. 2011-07-28 09:09 then we can just remove the 'debian' branch 2011-07-28 09:12 [commit] Xiangfu Liu: add debian package stuff (master) http://qi-hw.com/p/fped/b6807a7 2011-07-28 09:12 [commit] Xiangfu Liu: clean up the Build-Depends. (master) http://qi-hw.com/p/fped/e394af8 2011-07-28 09:12 [commit] Xiangfu Liu: use the new version rules. (master) http://qi-hw.com/p/fped/b17ed1a 2011-07-28 09:12 [commit] Xiangfu Liu: add debian/fped.manpages  for install manpage (master) http://qi-hw.com/p/fped/b9a6369 2011-07-28 09:12 [commit] Xiangfu Liu: update to svn rev 5982, enable dh_auto_test (master) http://qi-hw.com/p/fped/17dc8ff 2011-07-28 09:12 [commit] Xiangfu Liu: use usual name for orig tarball top-level directory (master) http://qi-hw.com/p/fped/069e82f 2011-07-28 09:12 [commit] Xiangfu Liu: update take svn rev: 5983 (master) http://qi-hw.com/p/fped/a6d21bb 2011-07-28 09:12 [commit] Xiangfu Liu: remove the Build-Depends ttf-liberation (master) http://qi-hw.com/p/fped/21f2ae2 2011-07-28 09:12 [commit] Xiangfu Liu: update to svn rev 5986 (master) http://qi-hw.com/p/fped/5fa6038 2011-07-28 09:12 [commit] Xiangfu Liu: override dh_auto_clean, use make spotless instread (master) http://qi-hw.com/p/fped/5ac0cb5 2011-07-28 09:12 [commit] Xiangfu Liu: add ghostscript to Build-Depends (master) http://qi-hw.com/p/fped/ced96bb 2011-07-28 09:12 [commit] Xiangfu Liu: update the homepage to help webpage (master) http://qi-hw.com/p/fped/4a68274 2011-07-28 09:12 [commit] Xiangfu Liu: update to r5997 (master) http://qi-hw.com/p/fped/ceaa519 2011-07-28 09:12 [commit] Xiangfu Liu: debian package update to 5999 (master) http://qi-hw.com/p/fped/a49bbd2 2011-07-28 09:12 [commit] Xiangfu Liu: update to r6005 (master) http://qi-hw.com/p/fped/acccaee 2011-07-28 09:12 [commit] Xiangfu Liu: update to r6006 (master) http://qi-hw.com/p/fped/6396ca8 2011-07-28 09:13 O_o 2011-07-28 09:41 [commit] Werner Almesberger: Makefile: switched from SVN to git (master) http://qi-hw.com/p/fped/6cadac8 2011-07-28 09:41 [commit] Werner Almesberger: xxx (master) http://qi-hw.com/p/fped/9465776 2011-07-28 09:41 [commit] Werner Almesberger: changed GUI page location, checkout instructions, and e-mail address (master) http://qi-hw.com/p/fped/f0c0ae7 2011-07-28 10:25 wpwrak: i re-used your code from ubb-vga to disable/enable interrupts (i think it works because if i disable interrupts and then don't enable them, the system looks pretty much halted) 2011-07-28 10:26 my intention is to disable interrupts in the beginning of each iteration (calculation step) and then enable them again; and so forth 2011-07-28 10:26 probably this way i can achieve real-time, who knows :) 2011-07-28 10:26 but the question is now, how (where?) to get the timer source? 2011-07-28 10:27 i need to have some timer running, and trigger my calculations in defined time steps 2011-07-28 10:30 suddenly i understood that this code is also in ubb-vga.. 2011-07-28 10:32 i'm not sure how it works, but it seems that you are using the hardware timer provided by 4740 2011-07-28 10:34 what is the resolution of this timer? is it a reliable source of time? 2011-07-28 10:37 it's a little bit of a magic for me, how you interact with CPU registers from your application.. Is is the linux kernel that provides such interface? Or how does it work? 2011-07-28 10:38 probably it has soemthing to do with /dev/mem where these registers are mapped into specific region.. But how do you know where? 2011-07-28 10:43 2011-07-28 10:43 :) 2011-07-28 10:50 i think there is a RTC driver... 2011-07-28 10:50 s/think/remenber 2011-07-28 10:53 there is a /dev/rtc, i'm not sure how it can be used, bur Werner is using something else.. 2011-07-28 10:59 the rtc timer has a resolution of 1 second... 2011-07-28 11:13 so the rtc timer is not sufficient for this task.. 2011-07-28 11:28 wpwrak: PWM with green lasers is tricky because they're not diode lasers, they use a diode laser to pump a crystal laser and the latter has issues turning on and off really fast 2011-07-28 11:28 though maybe it'll all smooth out in the end as long as you PWM the pump diode fast enough 2011-07-28 11:29 I think few people do PWM though, it's mostly analog current control 2011-07-28 11:29 as for safety, that depends on the laser power, of course 2011-07-28 11:30 there are exposure limits that vary by wavelength, power, and time (Maximum Permissible Exposure) 2011-07-28 11:32 but as a rule of thumb, <5mW is safe under all conditions, ~100mW or so is safe as long as it's actively moving and the target isn't too close, and once you start going into the W range then you really need to avoid hitting people at all, moving or not 2011-07-28 11:33 I intend to program MPE limits into the DSP so that it accumulates exposure into a grid of buckets across the screen, and limits power once it exceeds a threshold per bucket 2011-07-28 12:12 kyak: the clock frequency is 112 MHz 2011-07-28 12:13 kyak: the code is indeed a little unusual ;-) i don't wait for a timer interrupt. instead, i busy loop until the timer reaches its limit 2011-07-28 12:14 kyak: if you want timer interrupts (or any other interrupts), you need to go into the kernel. 2011-07-28 12:16 marcan: (exposure) yeah, i was thinking that your MCU could perhaps lower the duty cycle of the laser if it stays too long in the same area/bucket 2011-07-28 12:17 marcan: but if the later isn't easy to control with a PWM, then that wouldn't quite fly 2011-07-28 12:18 marcan: i any case, you'd need the exposure limit in something like J/m^2. then you could translate this to J/degrees^2, etc. 2011-07-28 12:18 well, most drivers use analog power control instead of PWM, which is mostly equivalent (just less efficient) 2011-07-28 12:18 that's what I have right now (just a simple current driver) 2011-07-28 12:18 ah, efficiency could also be a consideration. get rid of those bulky heat spreaders ;-) 2011-07-28 12:19 and yeah, of course the exposure limits are heavily dependent on how far you are, beam divergence, etc... 2011-07-28 12:20 I'm just doing some educated guesstimating, but you definitely need a real laser safety engineer and an exposure meter, *especially* if you plan on deliberately aiming at people (audience scanning) 2011-07-28 12:20 me, I just project onto a wall, so I just roll with some basic MPE calculations and making sure I avoid hitting anyone in the first place 2011-07-28 12:23 bbl, food and stuff :) 2011-07-28 12:24 with a really powerful laser, you could add a "cook lunch" mode ;-) 2011-07-28 12:25 well.. its easier to cook with the exhaust-air of the laser cooling subsystem of a decent sized lasertube than by heating something up with the light coming out ;) 2011-07-28 12:28 roh: how lame ;-) 2011-07-28 12:29 can we build an expansion cable, say, from the m1 expansion connector, and directly drive the laser or galvos? 2011-07-28 12:29 or from UBB :-) it's universal after all... 2011-07-28 12:30 what kind of processing power or input is needed to drive the projector? (without MCU or XMOS I mean) 2011-07-28 12:31 wpwrak: do i understand it correctly that you read the timer value from within your application and act when it reaches according value? 2011-07-28 12:32 kyak: yes. well, what i actually poll is the flag that indicates a timer overrun, see ubb-vga.c (delay) 2011-07-28 12:33 roh: will you do the first logo test today? please send me a picture asap then I can sign it off and we are good to go... (is this the planned procedure?) 2011-07-28 12:33 kyak: the polling is in the first while loop 2011-07-28 12:33 i guess so 2011-07-28 12:33 i just finished cleaning the shields 2011-07-28 12:34 kyak: after that, i read the timer value and add some more loops based on the difference to the expected value. this is to compensate for cycles i may have missed when polling. 2011-07-28 12:34 wpwrak: i see. What if you enabled interupts while you are in a waiting loop? 2011-07-28 12:34 kyak: (delay loop) that way, my contraption gets a little more accurate, reducing pixel noise 2011-07-28 12:35 dunno if its a good idea to laser today.. kinda tired and lasering the sheets should be error-free (or i would have to cut some more lids) 2011-07-28 12:35 (interrupts) then an unknown (and variable) amount of latency would get added 2011-07-28 12:36 wpwrak: ok, thanks :) i will need some time to think it over 2011-07-28 12:37 kyak: and you'd have to disable interrupts at the end again. also, the code running while interrupts are enabled would change the cache. so cache refills would add some latency as well. but your application may not need such high timer precision. 2011-07-28 12:40 roh: ok sure tomorrow is also fine. just send me a photo of 1 top acrylic first, then do the rest. 2011-07-28 12:40 is that ok? 2011-07-28 12:48 i'll do a test on some leftover material first 2011-07-28 12:52 wpwrak: you said, that enabling interrupts during delay loop would add unknown (and variable) latency. But if you poll the timer continously during this delay loop, and disable interrupts again just in the moment when you see that the timer is "full" (i.e. it is time to calculate the next step), would it solve the problem? 2011-07-28 12:54 kyak: no, because you may not be scheduled when the timer reaches the critical value 2011-07-28 12:54 right.. 2011-07-28 12:54 you could compensate this, of course: first loop/sleep until you're "close", then disable interrupts and loop 2011-07-28 12:54 but that may be too coarse to be useful 2011-07-28 12:55 ha 2011-07-28 12:55 would be a nice trick 2011-07-28 12:55 in the kernel, you'd only have to worry about timer interrupt latency, which should usually be small 2011-07-28 12:56 should i consider running an application as a kernel module? 2011-07-28 12:57 kyak: depending on what you want to do hrtimers might be an option 2011-07-28 12:58 if you need strict timing and have a low duty cycle, yes 2011-07-28 12:58 [commit] Ayla: Dingux port: added a "power off" icon on the "settings" tab. (master) http://qi-hw.com/p/gmenu2x/e066050 2011-07-28 12:58 if you ned strict timing and have a high duty cycle (i.e., if there's no point in letting anything else run), then you could use the ubb-vga approach 2011-07-28 12:58 larsc: i'm not yet sure what i want to do, for now i'm just exploring :) 2011-07-28 12:59 if you have extremely strict timing, you'd even combine both approaches 2011-07-28 12:59 and there is also uio which can be used to deliver irqs to userspacce 2011-07-28 12:59 if you have loose timing and only need high CPU priority, you could increase your task's scheduling priority 2011-07-28 12:59 wpwrak: i see. Could you explain how does it work that you disable interrupts, but you are still able to poll the timer? Where is it coming from? 2011-07-28 13:00 larsc: yeah. may actually be nice to have a generic uio driver :) 2011-07-28 13:01 larsc: btw, are hr timers disabled in Ben;s kernel for a reason? 2011-07-28 13:01 kyak: the timer has a register bit it sets when it overflows 2011-07-28 13:01 wpwrak: so you read the register from userspace? How? 2011-07-28 13:02 kyak: do you have the 4720 or 4740 programmer's manual ? (from ingenic) 2011-07-28 13:02 wpwrak: i don't 2011-07-28 13:02 larsc: (generic) im gpio -> uio 2011-07-28 13:05 i guess i should get the manual and ask less questions :) 2011-07-28 13:06 the manual will answer some questions. and probably create a lot more ;-) 2011-07-28 13:09 kyak: what you don't? 2011-07-28 13:09 really? 2011-07-28 13:09 wolfspraul: got it now :) 2011-07-28 13:10 ah perfect, I would have emailed otherwise 2011-07-28 13:13 and UIO also seems like a good way to get timer interrupts in userspace 2011-07-28 13:57 wolfspraul: http://yamato.hyte.de/tmp/logotest/ 2011-07-28 13:58 i didnt want to waste a full lid sheet for the test 2011-07-28 13:59 logo is 50x55 mm now. the 'frame' is 80x80mm (only to make it a 'piece' for me now, not for later lasering on the lid) 2011-07-28 14:01 oh, nice. would have almost missed me. wait looking now 2011-07-28 14:02 i can upload the fullsized images as well if needed 2011-07-28 15:42 hi guys 2011-07-28 15:44 I'm about to push a very huge commit for gmenu2x, can somebody test my diff on a nanonote to see if I didn't break anything? :) 2011-07-28 15:50 I think there is an autoamted build that can spot posible problems 2011-07-28 15:51 ah, you mean, test the binaries? 2011-07-28 15:51 yes 2011-07-28 15:53 drop it, i'm not doing to much at work today, so i can try some misterious bianries by quick :-) 2011-07-28 15:55 ok 2011-07-28 15:55 I don't know how you create your packages, so you'll have to install it by hand 2011-07-28 15:56 make isntall i guess? :-) 2011-07-28 15:57 I'm uploading an archive 2011-07-28 15:57 good, i already disabled my gmenu2x from the initab 2011-07-28 15:57 http://marvin.crapouillou.net/~paul/gmenu2x.tar.bz2 2011-07-28 15:57 the binary can be anywhere on the filesystem, but the data has to be on /usr/share/gmenu2x 2011-07-28 15:58 got it 2011-07-28 16:05 okay i'll reboot and see 2011-07-28 16:06 ahhh loop 2011-07-28 16:06 if you read this messages in the logs, check http://.. 2011-07-28 16:07 so no start Ayla 2011-07-28 16:07 wolfspraul: if there are FPGA pins available on the expansion connector, it should be easy to add a, say, modified I2S interface to drive the laser (with HDL changes) 2011-07-28 16:08 you could have that connect to the XMOS for high-level data, or shift all the laser duties over to the MM, but in the latter case then you wouldn't be able to have a standalone projector and that's no fun 2011-07-28 16:08 there are 10 pins i think 2011-07-28 16:08 if we're talking about mm1 :) 2011-07-28 16:08 yeah 2011-07-28 16:11 wolfspraul: re: FPGA on the laser, it'd work I'm sure, but I think implementing a softcore is overkill 2011-07-28 16:11 I've looked into XMOS and I like what I've seen, they're trying to step into FPGA territory while remaining a micro, so it's fairly flexible and powerful 2011-07-28 16:11 ot you can run a soft* over a 8bits mcu if you need flexibillity beyond HDL logic 2011-07-28 16:12 and they do lots of audio stuff, which is extremely similar to laser processing, so there's examples available for that 2011-07-28 16:12 but at the cost of theri licenses :) 2011-07-28 16:12 i mean for the examples 2011-07-28 16:13 I think they have decent licenses (and if they don't I can probably get them to, I have a friend who is a friend of the company founder ;) 2011-07-28 16:13 and I also have people working on completely open development tools, so I'm not concerned about lock-in to their SDK either 2011-07-28 16:14 well, last time iremeber some parts of the llvmm port where not floss, anywa i never used that xmos kit at much 2011-07-28 16:14 anyway, if you need help integrating that I2S in the milkymist soc, jsut let me now, i'll do my best :) 2011-07-28 16:14 yeah, they also have the XC language stuff, which is a proprietary hack (though convenient), but I'll avoid it unless there are open dev tools 2011-07-28 16:14 will do :) 2011-07-28 16:14 ah, good, (avoid XC) 2011-07-28 16:15 you're gonna belive me but i get the kit because was alsmot free and i tought was an FPGA xD 2011-07-28 16:15 I think the best plan here is to have the laser have its own standalone MCU for processing/safety/etc, and have it take both USB 2.0 (for PC usage) and something like I2S for the MM or similar standalone hardware 2011-07-28 16:15 later i discover tht truth.. 2011-07-28 16:15 you're not* 2011-07-28 16:15 haha, yeah, it's definitely not an FPGA 2011-07-28 16:16 but it can do some things that used to require an FPGA to do sanely before (without hard macros), which is nice 2011-07-28 16:17 so xmos is a bit like the propeller ? 2011-07-28 16:18 yup, but a lot more powerful 2011-07-28 16:18 it's a similar concept 2011-07-28 16:18 but instead of just independent cores, they also have multithreading 2011-07-28 16:18 yeah, the prop is a bit on the sluggish side 2011-07-28 16:19 so you have a 400MIPS core that can run 4x100MIPS threads (but not 1x400MIPS thread) 2011-07-28 16:19 I believe they do that because of pipeline advantages 2011-07-28 16:19 the 4-core versions do up to 1600MIPS total 2011-07-28 16:20 I'll use an L1 (single low-power core, 4x100MIPS through 8x50MIPS) or two of them if I have to (there's an L2, which is two L1s in a single package, but it's a horrid dual-row QFN that I've already had a bad prototyping episode with) 2011-07-28 16:20 looks as if the 400 MIPS code does 8 x 50 MIPS, no ? that would be similar to the prop 2011-07-28 16:21 ah no, they claim 100 MIPS 2011-07-28 16:22 okay, so the threads share something beyond just global memory. so there's a difference to the prop. looks more flexible, though. 2011-07-28 16:22 they have communication channels, internal and external 2011-07-28 16:22 and the threads don't have dedicated memory, and shared memory isn't slow like on the prop 2011-07-28 16:24 yeah, and you avoid the weird memory model 2011-07-28 16:24 wolfspraul: the prop is 160MIPS total, the xmos is 400MIPS total (for an L1), or I think 500MIPS recently? 2011-07-28 16:24 and yeah, it's a more classical architecture 2011-07-28 16:24 I meant wpwrak, tab completion fail :) 2011-07-28 16:25 kristianpaul: you did put the data in /usr/share/gmenu2x? Does it fail with an error message? 2011-07-28 16:25 ah, i had something like 48 MHz/MIPS per .. duh, thingy, in the back of my head. but anyway, when i looked at it, it seemed a bit too slow to do interesting things. 2011-07-28 16:25 also, the xmos has single-cycle multiply-accumulate iirc 2011-07-28 16:26 while the prop doesn't do mul at all 2011-07-28 16:26 heh. time to undust those DSP books ;-) 2011-07-28 16:26 yup :) 2011-07-28 16:26 the prop has many weird things. starting with the ROM ... 2011-07-28 16:26 I really need to read up on PID loops and the like to work out a reasonably optimal galvo control loop 2011-07-28 16:26 but I think it'll totally be worth being able to compensate hardware oddities in software 2011-07-28 16:27 a few opamps can't really compete with a DSP :) 2011-07-28 16:27 everything is moving towards software. so the approach sounds very reasonable to me 2011-07-28 16:28 I know there are veeeery expensive pro galvos that do the same thing, but still have an analog input 2011-07-28 16:28 but we're talking ridiculous prices 2011-07-28 16:28 cheap is better (as long as it works) :) 2011-07-28 16:29 I don't know of any system that uses a single chip to do the whole shebang, including host interface, "DAC", and galvo loops 2011-07-28 16:29 the idea here is to integrate everything to simplify and make it cheap :) 2011-07-28 16:29 Ayla: yes i did 2011-07-28 16:30 (and kick ILDA's ass - I mean, ILDA is cool and everything, but it's about time we ditch the decades old +/-12V analog differential standard) 2011-07-28 16:30 ;-)) 2011-07-28 16:32 Ayla: i jsut moved old gmenu2x and copied the tarball you agve me from / 2011-07-28 16:34 kristianpaul: and is there any error message? 2011-07-28 16:34 Ayla: root@BenNanoNote:~# /usr/bin/gmenu2x 2011-07-28 16:34 ---- 2011-07-28 16:34 GMenu2X starting: If you read this message in the logs, check http://gmenu2x.sourceforge.net/page/Troubleshooting for a solution 2011-07-28 16:35 that's all? 2011-07-28 16:35 afaik 2011-07-28 16:41 hmm, that's weird 2011-07-28 16:41 I'm going to give you a binary of the latest GIT revision, to be sure that it's my patch's fault 2011-07-28 16:41 sure 2011-07-28 16:42 or i can try old binary with your /usr/share/gme 2011-07-28 16:42 mom 2011-07-28 16:43 ./gmenu2x.sh: line 11: /usr/bin/gmenu2x.bin: not found 2011-07-28 16:43 humm 2011-07-28 16:44 ah, maybe you have to rename the binary? 2011-07-28 16:49 ahh in old gmenu2x /usr/share/gmenu2x.1/gmenu2x 2011-07-28 16:50 yours is /usr/share/gmenu2x/gmenu2x.sh 2011-07-28 16:51 but gmenu2x is actually a bin 2011-07-28 16:52 root@BenNanoNote:/usr/bin# ./gmenu2x 2011-07-28 16:52 ---- 2011-07-28 16:52 GMenu2X starting: If you read this message in the logs, check http://gmenu2x.sourceforge.net/page/Troubleshooting for a solution 2011-07-28 16:52 :/ 2011-07-28 16:53 kristianpaul: for galvanometer mirror control you don't need a loop nowadays I'd say. you need a proper hw bridge driver, and a sw that models the hw with all the inertia, feeds the original signal to the model and derive the driver signal from it. As this is a calculation that doesn't have to be done in realtime, you can calculate the mangled driver signal with all the overshots and whatnot on a 4bit cpu, then store it to e.g. a .wav 2011-07-28 16:53 and simply playback that .wav to the hw power driver 2011-07-28 16:54 I.E. use your audio card plus a 10..50W audio stereo amp to drive the galvos 2011-07-28 16:56 DocScrutinizer: okay but i think you talk, with wrong person i jsut discover what a galvanometer is from  cxadams work 2011-07-28 16:56 but yeah, a good hbridge is enought 2011-07-28 16:57 hw* 2011-07-28 16:57 but wait, you stilll need fedback unless you want to blind somobody.. 2011-07-28 16:58 what kind of feedback? 2011-07-28 16:58 a rotary magnnetic enconder or soemthing less fancy 2011-07-28 16:58 cause the point for safety as i understand is poweroff laser if galvanometer get stuck.. 2011-07-28 16:59 useless. you calibrate your model once. After that you know what your mirror is doing right now, even without feedback 2011-07-28 17:00 well, such a safety circuit has to work completely independently from the regular controller anyway 2011-07-28 17:00 yeah, sure, as i said, is just for safety not control 2011-07-28 17:17 you could do that with a microphone and voice recognition. "turn off on ARRRGH!!! I AM BLIND !!" (chances are that you're not quite ... yet :) 2011-07-28 17:21 kristianpaul: about the gmenu2x debugging 2011-07-28 17:21 strace is *incredibly* useful (together with sources) 2011-07-28 17:22 it's the tool i've used to make gmenu2x work 2011-07-28 17:30 Ayla: whitequark http://paste.debian.net/124387/ 2011-07-28 17:35 here is the patch I want to commit: http://pastebin.com/YZFTykiy 2011-07-28 17:36 currently, gmenu2x is compiled with TARGET_GP2X, even when compiling for dingoo or nanonote 2011-07-28 17:36 that's only cleanups 2011-07-28 17:40 i think issue is about how you linked this gmenu2x.. 2011-07-28 17:41 there are plenty of No such file or directory in the strace log 2011-07-28 17:42 maybe I should commit it then, and see if it works with the automated build 2011-07-28 17:42 yeah :) 2011-07-28 18:29 Ayla: if you put the implementation of Touchscreen::initialized() in the header, the compiler can determine at compile time that it always returns false and therefore the code it guards is unreachable 2011-07-28 20:31 mth: I wasn't aware of that, it concerns only C++? 2011-07-28 20:41 ah no, I didn't understand what you said 2011-07-28 22:11 The build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/compile-log/openwrt-xburst.full_system-07272011-1848/ 2011-07-28 23:19 [commit] Ayla: Cleaned GP2X-specific code that was built on all platforms. (master) http://qi-hw.com/p/gmenu2x/5f77e3b