Well, I know of nothing that you could not find via a search engine and "beaglebone black PRU" as I've done myself in the semi recent past. I'd shoot you some bookmarks, but I just got a new laptop in today that is a fresh install, and I'm trying to get that running . . . Everything I found though was by googling the above mentioned keywords. SO you should not find it too hard to find it all yourself.
On Wed, Jan 7, 2015 at 1:12 PM, Vasilis Iliadis <[email protected]> wrote: > First of all thank you very much for your valuable input. I think that > your suggested method using the PRUs is what I need. In my application I > need high speed data transfers using the gpios. I have to read/write a nand > flash chip that are several Gbits of memory. For the same reason I need to > utilize 8 pins as bidirectional input and output ( most nand flash chips > use 8 pins for both address,command and data transfer). Now I just have to > understand how PRUs work...:) I will check the net but if you have any > tutorials on this please do tell. Again thank you very much. > On Jan 7, 2015 3:31 AM, "William Hermans" <[email protected]> wrote: > >> *or by using pin(s) the PRU's can switch modes for fast. For something >>> like say a buffer<->external memory. This way would also be far more >>> complex, but should be vastly faster than using universal-io.* >>> >> >> SO what I mean by being far more complex. Is that you would have to write >> an external Linux binary, that would communicate with the PRU(s). Then, >> you would also need to write code for the PRU(s), so the programmable real >> time unit(s) could communicate with your Linux binary. >> >> Typically, I would think this would be fairly useless, unless done for >> demonstration purposes. As the PRUs are really meant for high speed >> "applications", where speed is paramount - to a point ( 200Mhz ). Adding >> Linux to the mix alone would slow things down considerably, let alone >> Nodejs. As non real time Linux flavors only have around a 10ms timing >> resolution, and sometimes it can be far higher ( 100ms + ). >> >> Anyway, probably moot for your case anyhow . . . >> >> On Tue, Jan 6, 2015 at 6:07 PM, William Hermans <[email protected]> >> wrote: >> >>> *The function digitalRead returns the value of the pin does it not?* >>>> >>> >>> This I do not know first hand as I have never used bonescript. What I >>> can say is that typically, when calling an executable directly from Nodejs >>> ( which is what bonescript uses - Nodejs ), you need to use a callback to >>> capture the output of that executable *if* you wish to use that value from >>> within the script. >>> >>> What I do imagine, as far as how bonescript works. Is that it directly >>> calls an executable of some sort ( custom, or Linux command ), which then >>> returns a value depending on which mode the pin is set as. Jason Kridner >>> should know for sure since he wrote the library, and I could be wrong. I >>> never really examined his code all that well, before I decided it was not >>> for me. >>> >>> *Basically what I ask is, if reading the return value of the digitalRead >>>> is enough, of should I capture the value of the pin via a callback >>>> function.* >>>> >>> >>> Ok, so if bonescript does in fact return a value, and if correct ( >>> without a callback ), then there should be no problem. You could / should >>> test the value to make sure it is correct though. >>> >>> *I am writing a small program where I interchange the mode of a pin as >>>> input and output. I am having difficulties doing that. I am a newbie in >>>> javascript, but I am wondering if that is possible at all.* >>>> * Thanks in advance* >>>> >>> >>> I have read on these groups from various people that using a single pin >>> ( GPIO - read / write ) is possible. However, I am left wondering in which >>> case that would be useful. Whatever the case, digitalRead would only work >>> when the pin is configured as GPIO -> IN. >>> >>> Two ways I *think* you may be able to do this is using . . . >>> >>> https://github.com/cdsteinkuehler/beaglebone-universal-io - This would >>> be slow-ish, but you could call config-pin directly from Nodejs. >>> >>> or by using pin(s) the PRU's can switch modes for fast. For something >>> like say a buffer<->external memory. This way would also be far more >>> complex, but should be vastly faster than using universal-io. >>> >>> >>> >>> On Tue, Jan 6, 2015 at 3:29 PM, Vasilis Iliadis < >>> [email protected]> wrote: >>> >>>> The function digitalRead returns the value of the pin does it not? >>>> Basically what I ask is, if reading the return value of the digitalRead is >>>> enough, of should I capture the value of the pin via a callback function. >>>> I am writing a small program where I interchange the mode of a pin as >>>> input and output. I am having difficulties doing that. I am a newbie in >>>> javascript, but I am wondering if that is possible at all. >>>> Thanks in advance >>>> >>>> On Jan 6, 2015 2:44 AM, "William Hermans" <[email protected]> wrote: >>>> > >>>> > How would you plan on getting the information back from digitalRead >>>> if not by using a javascript callback ? >>>> > >>>> > Also, more information is needed. e.g. what is your program goal ? >>>> > >>>> > On Mon, Jan 5, 2015 at 2:38 PM, 'Vasilis Iliadis' via BeagleBoard < >>>> [email protected]> wrote: >>>> >> >>>> >> I am playing with GPIO and digitalRead in bonescript. I noticed that >>>> although digitalRead is fairly fast the callback function takes a while. I >>>> am asking the group if I should wait for the callback to be triggered or >>>> just calling digitalRead is enough!. >>>> >> >>>> >> Thanks >>>> >> >>>> >> -- >>>> >> For more options, visit http://beagleboard.org/discuss >>>> >> --- >>>> >> You received this message because you are subscribed to the Google >>>> Groups "BeagleBoard" group. >>>> >> To unsubscribe from this group and stop receiving emails from it, >>>> send an email to [email protected]. >>>> >> >>>> >> For more options, visit https://groups.google.com/d/optout. >>>> > >>>> > >>>> > -- >>>> > For more options, visit http://beagleboard.org/discuss >>>> > --- >>>> > You received this message because you are subscribed to a topic in >>>> the Google Groups "BeagleBoard" group. >>>> > To unsubscribe from this topic, visit >>>> https://groups.google.com/d/topic/beagleboard/ro7_iOAKamM/unsubscribe. >>>> > To unsubscribe from this group and all its topics, send an email to >>>> [email protected]. >>>> > For more options, visit https://groups.google.com/d/optout. >>>> >>>> -- >>>> For more options, visit http://beagleboard.org/discuss >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "BeagleBoard" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "BeagleBoard" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/beagleboard/ro7_iOAKamM/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
