**** BEGIN LOGGING AT Wed Mar 15 03:00:03 2017 Mar 15 07:16:53 Hohum. Arrow currently throwing in a raspberrypi3 with every beagleboard blue. Odd. Mar 15 07:17:50 Well odd if, rather than selecting a load of accessories for the pi, one meets their giveaway value with a blue :) Mar 15 07:26:24 bah.... Arrow's jumped the shark Mar 15 07:56:21 Ds2? Mar 15 07:57:05 Ah, not come across that phrase before. Mar 15 07:59:00 they are actually giving up rpi3 with every order above $77 Mar 15 08:01:45 Yup. I and a blue is 79 :) Mar 15 08:02:29 Not sure where that i came from... Mar 15 08:14:00 ravikp7:hi, did you test packet.createParser()? Mar 15 08:14:25 uka_in: It's not working Mar 15 08:14:28 It's giving an error for me Mar 15 08:14:30 yup Mar 15 08:14:51 should we look for any other serial parser Mar 15 08:15:02 ravikp7: yup Mar 15 08:15:15 uka_in: yeah Mar 15 08:15:32 also, what about compatiblity with mac? Mar 15 08:16:17 i tried to test it on virtual box, but it didn't worked Mar 15 08:16:43 uka_in: libusb can't claim interface of BBB on OSX Mar 15 08:16:57 *node-usb Mar 15 08:17:04 maybe a kext is needed to be implemented to fix this Mar 15 08:17:06 have a look at node-hid Mar 15 08:17:24 it claims to work on osx Mar 15 08:19:36 uka_in: did you test it in virtual box? Mar 15 08:19:51 node-hid? Mar 15 08:20:29 not yet, will try it Mar 15 08:25:35 ordsen: Hi there ? Mar 15 08:30:31 uka_in: node-hid doesn't have any api for interfaces, endpoints and transfer types, I doubt if it fits the requirement here Mar 15 08:41:42 zeekhuge: Sorry my laptop spontaneously disconnected me :D Mar 15 08:41:49 Hi Mar 15 08:42:17 No problem. Just wanted to tell you related to questions you asked yesterday. Mar 15 08:42:42 So, AFAIK , UART has DMA triggers in BBB Mar 15 08:43:04 and .. I am not sure, but I think there must be support for that in the drivers too. Mar 15 08:43:26 so you do not need to use A8 to get data from UART port Mar 15 08:44:00 the triggers work something like - whenever the FIFO is full, it triggers DMA and asks it to get the data from it. Mar 15 08:44:25 DMA does that on the behalf of A8 and puts that data in the driver buffer. Mar 15 08:46:31 OK, so we do not depend on 'when' the driver is scheduled; DMA takes care that no data is lost Mar 15 08:47:07 I havent used it ever. But I think that is how it works. Mar 15 08:51:22 I will do some research on this, thanks :) Mar 15 08:51:47 ordsen: BTW, take a look at ser2net Mar 15 08:52:09 it exposes serial connections to network, could be useful for the project Mar 15 08:52:40 zeekhuge: I have been thinking of a solution which would not use the PRU.. The project description says that the software should be generic for Linux based teminal server, so not relying on the PRU seems like a good idea to reach that goal Mar 15 08:55:02 Yeah so DMA makes complete sense. Mar 15 08:59:10 maciejjo: Just looked it up. It really does look useful, thanks! Mar 15 10:52:10 hi Mar 15 10:52:16 Os amyone here Mar 15 10:53:35 NP95: might be ? you never know ! Therefore, its a better practice to ask your question/query straight away .... Mar 15 10:54:07 Ok I am exploring the synchronous data collection idea using PRu Mar 15 10:54:18 I have seen the past PRU projects Mar 15 10:54:56 and 10 days back I did discuss here about the advantages of synchronous capture as in error correction and faster. Mar 15 10:55:18 But I still can't come up with a practical application for this Mar 15 10:55:47 Any pointers to what I should be looking at for ideas? Mar 15 10:57:26 Have you tried putting up your questions on the mailing list ? Mar 15 10:58:47 Umm not really I wasn't sure whether it was worth asking it in mailing list Mar 15 10:58:52 I will do that Mar 15 10:58:59 Still any pointers? Mar 15 10:59:09 and cc ds2 on it too. Mar 15 11:00:10 his email is hy-gsoc@hy-research.com Mar 15 11:00:17 ok Mar 15 13:17:44 maciejjo: How will ser2net come in handy in ordsen 's project? Mar 15 13:28:51 I think it could be used as an alternative to screen or minicom to access the serial devices from a terminal. Right maciejjo ? Mar 15 13:30:56 Why would you need an alternative? Mar 15 13:36:08 it is more straight forward Mar 15 13:36:54 you can expose serial connections to network ports and connect with telnet to them Mar 15 13:38:01 it is just alternative to using ssh + any app supporting serial Mar 15 13:38:46 I'm not saying it should be used, just another tool for consideration Mar 15 13:39:25 oh...okay. I'm not able to get why this would be straightforward. Mar 15 13:46:47 tokencolour: just my opinion ;p telnet is much simpler than ssh Mar 15 13:47:27 okay :) **** BEGIN LOGGING AT Wed Mar 15 16:23:06 2017 Mar 15 16:23:24 mostly security, plus lack of attention Mar 15 16:25:38 yeah...thought so. Mar 15 16:26:18 telnet's greatest strength is it's simplicity..which now is its biggest weakness Mar 15 16:32:15 I dont understand this so asking, why does the serial terminal project needs to worry about telnet or ssh ? shouldnt that be the choice of the user only. In any way he wants, the user just needs to connect to bbb remotely. isnt that so ? Mar 15 16:33:33 oh ! okay got it ! so the user wont be handling the BBB completely. Mar 15 16:34:05 he should just be able to see the Serial devices the bbb is connected to. Mar 15 16:35:01 so it would be like a server that would listen on one of the ports of bbb. And therefore the project needs to worry about ssh or telnet. Mar 15 16:35:30 and once connected to the port. the user will be presented with just those devices. and nothing else. Mar 15 16:35:40 uhm is that right ? Mar 15 16:37:28 only then it will be a project. otherwise the you can already connect a serial device to bbb and once inside bbb (using ssh) you can interface the serial device. Mar 15 16:55:42 <_av500_> aloo Mar 15 17:03:17 jkridner Mar 15 17:03:22 ds2 Mar 15 17:06:14 <_av500_> hi Mar 15 17:06:16 <_av500_> everybody Mar 15 17:06:27 <_av500_> jkridner is busy at the embedded world fair Mar 15 17:09:34 dealing with black and blue issues? Mar 15 17:09:51 <_av500_> dealing with people at the booth Mar 15 17:09:58 <_av500_> like me yesterday :) Mar 15 17:10:29 trying to prevent damage from monocle drops? Mar 15 17:15:16 Umm ds2 Could you help me out with synchronous data Mar 15 17:15:21 collection Mar 15 17:15:48 I have posted in the mailing list for reference Mar 15 17:44:49 NP95: what about it? Mar 15 17:45:44 NP95: if you mean the deliverables - PRU code and docs on how to use it would be a start... Mar 15 17:48:56 What would be a good reference signal as a synchronization standard Mar 15 17:49:20 depends on what you have available Mar 15 17:50:11 for test purposes, the output of the LCDC from anther bone, a SPI master signal, etc Mar 15 17:50:29 a camera would be nice but donno if you can source that easily Mar 15 17:50:53 What is the LCDC? Mar 15 17:51:07 LCD Controller Mar 15 17:51:11 ok Mar 15 17:51:21 it has a clock (either PCLK, VSYNC, HSYNC) and data Mar 15 17:51:58 Also is my understanding correct that the PRU are treated as periperhals by the OS Mar 15 17:52:22 yes Mar 15 17:52:30 Plus am I going in the right direction in understanding of the PRU Mar 15 17:53:06 sort of... the PRU is just another processor on there Mar 15 17:53:54 one way of going about all this is to keep the interfaces the same as BeagleLogic and just generate a different PRU code Mar 15 17:54:23 interesting bits are - how fast of a signal can you capture Mar 15 17:55:14 in the past I have bursted up to about 26MHz and probally sustained around 24MHz (range); this is a BT565 signal with synchronization to VBLANK, etc Mar 15 18:00:52 Abhishek managed to get around 100 Mhz with Beaglelogic Mar 15 18:01:10 async Mar 15 18:01:17 Yeah Mar 15 18:01:21 with sync, you need to track the clock Mar 15 18:01:32 I know that Mar 15 18:02:21 In theory shouldn't you be able to capture relatively higher frequency signals compared to async? Mar 15 18:02:34 Or have I messed up in my understanding some where Mar 15 18:02:56 Or is it that the implementation is tricky? Mar 15 18:09:01 AFAICT, there is no HW to do the sync Mar 15 18:09:13 so you have to do it in the SW... the SW is clocked at 200MHz Mar 15 18:09:29 instructions are 1 clock each so.... Mar 15 18:11:21 So in theory a 170-180 Mhz signal is the max freq which you can cpture using the PRU? Mar 15 18:11:45 Also could I get insight in how you synced with the VBLANK? Mar 15 18:15:16 no... 100MHz is about the best you can do Mar 15 18:15:26 READ PIN, SAVE DATA and repeat Mar 15 18:15:53 so you can burst at 100MHz but... Mar 15 18:16:08 yes, wait for a high to low transition Mar 15 18:16:30 something like QBBS r30,4,WAIT_FOR_VSYNC Mar 15 18:17:45 VSYNC is "easy"... it comes at about 60Hz Mar 15 18:17:49 PCLK is the tight one Mar 15 18:19:52 Could you explain the QBBS r40,4,WAIT_FOR_VSYNC Mar 15 18:20:00 It looks like assembly Mar 15 18:22:09 And these signals the explantion for these are present in the PRU reference document , right? Mar 15 18:24:40 it is... see PRU docs Mar 15 18:24:50 yes Mar 15 18:25:38 in short - Quick Branch if Bit Set = QBBS; r30 (I think it is r30) is how GPIOs on the PRU are mapped, bit 4, label to branch if it is still set Mar 15 18:25:46 this takes 1 cycle to evaluate Mar 15 18:25:57 Ok I get it now Mar 15 18:26:23 the PRU has very nice instructions Mar 15 18:27:13 Could you explain why the max freq is 100 Mhz , I am making an educated guess that it is due to the latency Mar 15 18:32:01 READ PIN, SAVE DATA and repeat Mar 15 18:32:22 that basic unit takes 2 instructions; it can run 1 instruction per clock so for a 200MHz PRU.... Mar 15 18:35:32 Ok Last q will I need a beaglebone at hand to get better understanding or will the docs suffice Mar 15 18:38:28 docs should be fine Mar 15 18:38:53 u need to figure a strategy first... the Bone is more for testing Mar 15 18:41:52 thanks a lot ds2 you have clarified a lot of the basic stuff and now I am off for some more reading Mar 15 19:25:28 zeekhuge: To come back to your guess again: actually thats something I have been wondering for days now, too.. I doubt that the I/O buffering is the only 'real' work here, so what you wrote makes sense Mar 15 19:32:05 I haven't seen m_w on irc yet; His clarification of the project would be pretty helpful. Mar 15 19:34:09 Hi _av500_, yeah, Embedded World is taking a ton of cycles. Mar 15 20:25:49 jkridner, there? Mar 15 23:12:01 Greetins Mar 15 23:26:33 \help Mar 15 23:26:43 \HELP Mar 15 23:44:02 ard001: this a student/mentor channel, it's okay to say it out loud... Mar 15 23:45:05 the references should be pretty clear, since we're making a remote device assume begalebone green wireless Mar 15 23:45:44 there he goes... Mar 16 00:16:46 $ERROR: Help restricted to non guest users.$ Mar 16 01:02:14 i think i should write a general post **** ENDING LOGGING AT Thu Mar 16 03:00:01 2017