2014-11-07 02:05 atommann has joined #qi-hardware 2014-11-07 02:18 valhalla1 has joined #qi-hardware 2014-11-07 02:20 valhalla has quit [Ping timeout: 244 seconds] 2014-11-07 02:26 xiangfu has joined #qi-hardware 2014-11-07 02:46 wpwrak: If you live alone, you can talk to someone when you get bored :-P 2014-11-07 02:46 wpwrak: Talk to the cloud.... 2014-11-07 02:50 rejon has joined #qi-hardware 2014-11-07 03:19 funny, a while ago I showed the clip to a friend and she said pretty much the same thing ;-) 2014-11-07 04:21 Textmode has joined #qi-hardware 2014-11-07 05:07 xiangfu has quit [Ping timeout: 245 seconds] 2014-11-07 05:17 xiangfu has joined #qi-hardware 2014-11-07 05:22 wolfspraul has joined #qi-hardware 2014-11-07 06:10 "... and much more" - people volunteeraly equip their houses with spy equipment, how convenient :) 2014-11-07 06:11 web camera/microphone in laptop? that's last generation 2014-11-07 06:13 after several days "alexa, shut up and kill yourself already, you all-knowing, intruding bitch!" :) 2014-11-07 06:34 the "permanent" listening is indeed a not so likeable feature there. i also wonder whether the cloud is really necessary for the pattern matching that happens when recognizing sentences. 2014-11-07 06:34 but i must say that the concept looks very attractive 2014-11-07 06:45 of course, with something that star trek-ish, one has to wonder whether it can also handle this: "alexa, self-destruct, authorization alpha-alpha-three-zero-five." 2014-11-07 06:54 well, with almost everyone nowadays having smartphone with "ok google" feature, this tower looks unnecessary 2014-11-07 06:54 I want to say "computer" instead "ok google" 2014-11-07 06:55 kyak: for the matlab thing, I need to modelling a inverted pendelum control 2014-11-07 06:56 http://www.iforce2d.net/blog/2014-04-22 - something like this. This guy programmed a PID controller inside a physic engine 2014-11-07 06:58 eintopf: that's been done many times, search pendulum control on FEX 2014-11-07 06:59 there are several interesting submissions, including Lego Segway examples 2014-11-07 07:00 http://www.mathworks.com/matlabcentral/fileexchange/19147-nxtway-gs--self-balancing-two-wheeled-robot--controller-design 2014-11-07 07:01 this might be the most complete example of MBD 2014-11-07 07:01 ("computer") exactly ! that's the whole point. "computer ! put milk on the shopping list. how many fathoms in a parsec ? and, um, eject the warp core." 2014-11-07 07:03 (nxt lego) - yea we know these lego nxt things... but we have a real segway and other sensors for measurement some angles 2014-11-07 07:04 but okay, maybe I need to begin really to start the working on this project 2014-11-07 07:04 http://www.mathworks.com/company/user_stories/segway-llc-delivers-innovative-transporter.html 2014-11-07 07:05 how's this for a real segway? :) 2014-11-07 07:05 no we have some from china 2014-11-07 07:05 http://www.ewee-pt.com/ 2014-11-07 07:06 hmm, "we have a segway for measuring angles". i suppose google should hurry and get a few sr-71 for better google maps pictures, or you'll easily out-overkill 'em :) 2014-11-07 07:06 wpwrak: no there are other sensors 2014-11-07 07:06 for nxt lego they used the ultrasonic distance sensore and making pythagoras magic 2014-11-07 07:07 (ewee-pt) I have also the source code for the controller logic... this is visual basic code 2014-11-07 07:07 oh god.. 2014-11-07 07:07 but the device is hackable 2014-11-07 07:08 interesting is that there exist some visual basic compiler to generate avr code 2014-11-07 07:09 :D 2014-11-07 07:10 kyak: do you have also some skills for scilab? 2014-11-07 07:10 these open source matlab thing 2014-11-07 07:14 nope 2014-11-07 07:14 ok 2014-11-07 07:15 my prof. put me in the theory mathematical group. He knows that I am more a practical guy. 2014-11-07 07:16 when I am done I will publish my results somewhere... open source for everyone 2014-11-07 07:17 your aim is to develop segway controller that replaces one from ewee-pt? 2014-11-07 07:18 yes, but we not really replace the logic 2014-11-07 07:18 no time for that 2014-11-07 07:19 then what do you do? 2014-11-07 07:19 put the logic in some physic engine 2014-11-07 07:19 with sensor parameter contstraints from ewee-pt 2014-11-07 07:20 you mean, you only want to model the logic with physical plant model? 2014-11-07 07:20 with the plant model representing the real ewee-pt device? 2014-11-07 07:20 we only don't replace the logic because stupid laws in germany and because we don't have time 2014-11-07 07:20 yea, something like that 2014-11-07 07:22 kyak: this sounds realistic? 2014-11-07 07:22 of course! 2014-11-07 07:23 in fact, Simulink is made just for this kind tasks.. dynamic systems and controls simulation 2014-11-07 07:26 has already a builtin physics engine? 2014-11-07 07:34 i'm not sure what you mean by that. It has physical modeling tools 2014-11-07 07:48 atommann has quit [Ping timeout: 265 seconds] 2014-11-07 07:55 xiangfu has quit [Ping timeout: 255 seconds] 2014-11-07 07:55 ok 2014-11-07 07:56 xiangfu has joined #qi-hardware 2014-11-07 07:56 apelete: yes, good to hear from you. Already though you got lost on your way home 2014-11-07 08:05 atommann has joined #qi-hardware 2014-11-07 08:07 wpwrak: This is how the "echo" concept will probably evolve. https://www.kickstarter.com/projects/keecker/keecker-the-worlds-first-homepod/ Imagine this one with good speech recognition / IA. 2014-11-07 08:09 (keecker) this looks like a driving toilet 2014-11-07 08:09 mhhh, would be a great feature 2014-11-07 08:10 larsc: been silently busy indeed, but I'm fine :) 2014-11-07 08:10 got a minute or are you busy with work right now ? 2014-11-07 08:11 5 minutes even 2014-11-07 08:15 'kay 2014-11-07 08:15 larsc: I resumed porting dma-jz4740.c to jz4770 2014-11-07 08:15 testing with the dmatest driver currently 2014-11-07 08:16 I noticed that dmatest does not request slave channels from dma: http://lxr.free-electrons.com/source/drivers/dma/dmatest.c#L877 2014-11-07 08:17 and that didn't worked with dma-jz4740 until I harcoded "request_channels(info, DMA_SLAVE);" in dmatest.c 2014-11-07 08:18 larsc: is that normal ? what capabilities is dma-jz4740 compatible with exactly ? 2014-11-07 08:18 I think it only test mem-to-mem 2014-11-07 08:18 nice. and i also like their realistic reward structure: all "mainstream" options that actually require them to make something are capped. so they're not at risk of waking up one morning with 10 MUSD on their account and the obligation to scale by 100x within weeks. 2014-11-07 08:18 anyway, 5 minutes are up, I have to go 2014-11-07 08:19 larsc: 'kay, no problem, we'll talk later then 2014-11-07 08:19 thanks for you time ;) 2014-11-07 08:33 jluis has quit [Remote host closed the connection] 2014-11-07 08:35 rejon has quit [Ping timeout: 240 seconds] 2014-11-07 08:35 viric has quit [Read error: Connection reset by peer] 2014-11-07 08:44 viric has joined #qi-hardware 2014-11-07 08:46 pcercuei has joined #qi-hardware 2014-11-07 08:47 jluis has joined #qi-hardware 2014-11-07 08:49 I'm back now 2014-11-07 08:53 I think it only test mem-to-mem 2014-11-07 08:53 at least it can be sued to know if the driver is working properly, right ? 2014-11-07 08:53 s/sued/used/ :) 2014-11-07 08:53 apelete meant: "at least it can be used to know if the driver is working properly, right ?" 2014-11-07 08:53 sue him! 2014-11-07 08:54 :D 2014-11-07 08:55 if the driver implements mem-to-mem 2014-11-07 08:58 oops, looks like dma-jz4740.c only implements mem-to-dev and dev-to-mem :( 2014-11-07 08:59 so dmatest will ultimately be useless to test it 2014-11-07 09:01 larsc: yesterday I was wondering why it didn't started any transfer at all -> http://paste.debian.net/130647/ 2014-11-07 09:01 (lines 154 and 226) 2014-11-07 09:03 there are obviously a few things wrong with my changes (the number of channels declared in dma-jz4740.c is wrong for instance) 2014-11-07 09:04 larsc: but if I get you right, then I'll be forced to test against the actual mmc driver it seems... 2014-11-07 09:05 which I've been avoiding since I don't know to which extent I'm messing things up here :) 2014-11-07 09:05 you can try read-only for now 2014-11-07 09:05 that should be pretty save 2014-11-07 09:06 safe 2014-11-07 09:06 larsc: you mean putting the sd card in read only mode while booting ? 2014-11-07 09:07 only use DMA for read operations 2014-11-07 09:07 but not for write operations 2014-11-07 09:07 ok 2014-11-07 09:07 mmc-jz4740 already uses DMA, no? 2014-11-07 09:08 yes it does, for read and write 2014-11-07 09:09 but I wanted to get the dma driver right before testing against the mmc driver 2014-11-07 09:09 ok; so it does not use the standard DMA API then? 2014-11-07 09:11 on jz4740 it does 2014-11-07 09:16 you're working on jz4770 now? 2014-11-07 09:24 yes, porting the mmc driver from jz4740 to jz4770 2014-11-07 09:24 and the mmc driver pulls in the dma driver 2014-11-07 09:26 ok, great 2014-11-07 09:26 so I guess you can use the old driver for the internal card, and your new driver for the external SD card 2014-11-07 09:26 if that makes things easier to test, that is 2014-11-07 09:29 didn't think about that, may be a good idea indeed 2014-11-07 09:32 once you have something to test, I can use my proto 2014-11-07 09:32 with the current driver, I reach ~250 KiB/s maximum 2014-11-07 09:32 write speed 2014-11-07 09:38 rejon has joined #qi-hardware 2014-11-07 09:51 Textmode has quit [Quit: "It was one dev, naked in a room with a carton of cigarettes, a thermos full of coffee and bourbon, and all his summoned angels."] 2014-11-07 09:56 'kay 2014-11-07 09:59 kyak has quit [Ping timeout: 244 seconds] 2014-11-07 09:59 kyak has joined #qi-hardware 2014-11-07 10:08 xiangfu has quit [Remote host closed the connection] 2014-11-07 10:43 atommann has quit [Ping timeout: 265 seconds] 2014-11-07 10:52 rejon has quit [Ping timeout: 244 seconds] 2014-11-07 11:55 apelete, larsc: from the docs (section 4.4.1), it seems auto-request mode (8) can be used for memory-to-memory transfers 2014-11-07 11:55 so it might be an option to add that feature to the DMA engine driver 2014-11-07 11:55 to make it easier to test and perhaps to do useful work in the future 2014-11-07 11:56 yes 2014-11-07 11:57 the peripheral supports it, the driver does not 2014-11-07 12:36 rejon has joined #qi-hardware 2014-11-07 13:10 jluis has quit [Quit: Me'n vaig] 2014-11-07 14:22 mth: good to know, added to the todo list just in case I get too much free time ;-) 2014-11-07 14:23 does that ever happen? 2014-11-07 14:27 loads and loads of free time during my sleep actually 2014-11-07 14:27 I was thinking of it not just as a nice-to-have feature, but a way to save time on testing, since if you have mem-to-mem transfers, I think you can use the existing test code 2014-11-07 14:27 but then I wake up and it's all gone :-( 2014-11-07 14:28 I usually debug when I sleep 2014-11-07 14:29 happens quite often that I get ideas about my various projects, in my sleep 2014-11-07 14:29 mth: that's what I thought too, don't know how long it would took to implement though 2014-11-07 14:31 pcercuei: completely agree, debugging while sleeping seems to work really well 2014-11-07 14:33 dma_cap_set of DMA_MEMCPY and implement a device_prep_dma_memcpy handler, I think 2014-11-07 14:37 and jz4740_dma_slave_config would probably have to handle DMA_MEM_TO_DEV 2014-11-07 14:37 eh, DMA_MEM_TO_MEM 2014-11-07 14:39 :b1 2014-11-07 14:39 oops 2014-11-07 14:39 the memcpy interfact doesn't use sg lists, so it's probably a bit easier to set up then a slave transfer 2014-11-07 14:42 ah, there is also device_prep_dma_sg which has sg for both source and destination 2014-11-07 14:43 supporting that would be a bit tricky, since the hw has DMA descriptors which contain both source and dest, so you'd have to weave the two sg lists together somehow 2014-11-07 14:47 the DMA test seems to check DMA_MEMCPY, DMA_XOR and DMA_PQ capabilties, so double sg is probably not needed for testing 2014-11-07 14:55 mth: it's either implement a new device_prep_dma_memcpy handler from scratch OR modify jz4740_dma_slave_config to handle DMA_MEM_TO_MEM, but not both right ? 2014-11-07 15:01 device_prep_dma_memcpy is called explicitly by dmatest.c, so you certainly need that 2014-11-07 15:02 dma_slave_config is not called explicitly, but a DMA_MEM_TO_MEM direction does exist, so I don't know if it might be called indirectly 2014-11-07 15:03 or maybe that's only needed for sg-to-sg transfers then? 2014-11-07 15:03 I know very little about DMA engines, just had a quick look at the code 2014-11-07 15:04 mth: in dma-jz4740.c device_prep_dma_* are callbacks to be registered -> http://lxr.free-electrons.com/source/drivers/dma/dma-jz4740.c#L562 2014-11-07 15:04 so I guess device_prep_dma_memcpy would be added there 2014-11-07 15:05 the question is, would it be used to register a modified version of jz4740_dma_slave_config that can handle mem-to-mem transfer 2014-11-07 15:06 s/jz4740_dma_slave_config/jz4740_dma_prep_slave_sg/ 2014-11-07 15:06 apelete meant: "the question is, would it be used to register a modified version of jz4740_dma_prep_slave_sg that can handle mem-to-mem transfer" 2014-11-07 15:07 or to register a new jz4740_dma_prep_memcpy handler ? 2014-11-07 15:08 jz4740_dma_prep_slave_sg and jz4740_dma_prep_dma_cyclic are mostly the same, so I think a modified variant of those can be used as jz4740_dma_prep_memcpy 2014-11-07 15:09 since there is no sg input, it would have to build only a single entry descriptor list 2014-11-07 15:10 ah, jz4740_dma_start_transfer should support MEM_TO_MEM direction as well 2014-11-07 15:10 maybe instead of jz4740_dma_slave_config 2014-11-07 15:11 'kay 2014-11-07 15:12 maybe I'll look into that then. if it's quick enough to do it might be save testing time indeed 2014-11-07 15:12 s/be// 2014-11-07 15:12 apelete meant: "may I'll look into that then. if it's quick enough to do it might save testing time indeed" 2014-11-07 15:13 (I love that qi-bot) 2014-11-07 15:13 eh, does dma-jz4740 use DMA descriptors at all? 2014-11-07 15:14 it seems it pokes directly into DMA registers and then starts the next transfer on the completion IRQ 2014-11-07 15:15 which works, but is not the most efficient approach if the sg list contains many small segments 2014-11-07 15:15 it seems it pokes directly into DMA registers and then starts the next transfer on the completion IRQ 2014-11-07 15:15 where in the code do you read that ? 2014-11-07 15:16 jz4740_dma_start_transfer and jz4740_dma_chan_irq 2014-11-07 15:16 in particular, the fact that chan->next_sg exists 2014-11-07 15:17 with chained DMA descriptors, the "next" would be a pointer in the descriptor itself 2014-11-07 15:18 anyway, that's a possible optimization for later; for now being able to use a DMA engine at all is already an improvement over separate DMA implementations in the MMC and audio drivers 2014-11-07 15:18 and fb too 2014-11-07 15:19 in jz4740_dma_start_transfer, it looks to me like it's just using an sg list 2014-11-07 15:20 in fact, I don't know the difference between using an sg list and DMA descriptors 2014-11-07 15:20 never used DMA descriptors this far, so sg is all I know 2014-11-07 15:21 sg list is the Linux side of things, DMA descriptors is what the hw uses 2014-11-07 15:21 they are similar in intent but not bitwise compatible 2014-11-07 15:21 I also don't know if addresses in sg lists are virtual or physical 2014-11-07 15:22 in hw descriptors they must be physical 2014-11-07 15:22 do you have an example of DMA descriptors in use ? 2014-11-07 15:22 just so that I can get a sense of what we're talking about :) 2014-11-07 15:23 the jz4770 fb driver uses them, but that's a dedicated DMA controller for the LCDC iirc, it might not be exactly the same as the generic DMAC 2014-11-07 15:23 'kay, will look at that later, thanks 2014-11-07 15:23 in the 4740 docs, it speaks of descriptor or no-descriptor transfer 2014-11-07 15:24 and if I understand dma-jz4740.c correctly, it uses no-descriptor transfer at the moment 2014-11-07 15:24 probably because there are a lot less complications with that 2014-11-07 15:25 yes, I read that part of 4740 docs, but didn't know how it would actually affect the code 2014-11-07 15:25 section 4.3.1 describes a descriptor transfer 2014-11-07 15:27 roughly: with no-descriptor transfer, each sg item gets poked into the hw regs one at a time: the completion of item N is a trigger for the CPU to poke item N+1 and then start it 2014-11-07 15:28 with descriptor transfer, a linked list of descriptors, one per sg item, is made in memory 2014-11-07 15:28 then the CPU starts the transfer by poking the start address of that list into thw hw regs 2014-11-07 15:28 so no interrupts are needed to go from one sg entry to the next 2014-11-07 15:29 I don't know though how many entries sg lists contain in practice 2014-11-07 15:29 if it's nearly always 1, there is no advantage to descriptor transfers 2014-11-07 15:30 oh, I see... thanks for the translation ;-) 2014-11-07 17:27 rejon has quit [Ping timeout: 260 seconds] 2014-11-07 17:31 pcercuei has quit [Ping timeout: 250 seconds] 2014-11-07 18:14 pcercuei has joined #qi-hardware 2014-11-07 20:25 pcercuei has quit [Ping timeout: 264 seconds] 2014-11-07 21:04 wolfspraul has quit [Quit: leaving] 2014-11-07 22:17 dandon has quit [Quit: buzz] 2014-11-07 22:54 dandon has joined #qi-hardware 2014-11-07 23:23 nicksydney has joined #qi-hardware