Also, I am not sure if this would be useful for your case, but I talked with a person about a year ago about he GPMC on board. Just from memory, I recall this person telling me that 40MB/s throughput would not be much of a problem using this. However, I know less about the GPMC, than I do about the PRUs. Which is to say not a whole lot.
It may however be something worth looking into and as I recall you can access the GPMC through the PRU's . . .which possibly I am remembering wrongly, but still worth a look. On Wed, Jan 7, 2015 at 8:49 PM, William Hermans <[email protected]> wrote: > 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.
