RE: [beagleboard] Re: ioctl messages to Beagle SPI port.

> From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On > Behalf Of Dennis Lee Bieber > On Tue, 25 May 2021 19:44:55 -0700, in gmane.comp.hardware.beagleboard.user > "John Dammeyer" wrote: > > > > > >OK. Hadn't noticed until I tried it on the Beagle that it uses >

RE: [beagleboard] Re: ioctl messages to Beagle SPI port.

Hi Dennis, I will investigate that further. Wanted to get the SPI bus Type K Thermocouple module working first. Baby steps. The code is slightly different from the Pi but not radically so. I used '/dev/spi/0.0' since there is no '/dev/spidev0.0' on my Beagle. > > My concern was that

RE: [beagleboard] Re: ioctl messages to Beagle SPI port.

And yet more progress using the pxl library and Lazarus with the rewritten code from the pxl Blinky.pas example and adafruit_max31855.py. SPI bus operation. Source code attached. debian@ebb:~/lazarus/TC$ ./TC Reading temperature, press any key to exit... Temperature: 21.25C 70.25F

[beagleboard] Re: ioctl messages to Beagle SPI port.

On Tue, 25 May 2021 19:44:55 -0700, in gmane.comp.hardware.beagleboard.user "John Dammeyer" wrote: > >OK. Hadn't noticed until I tried it on the Beagle that it uses >PXL.Boards.RPi.pas which has the definitions for the high speed I/O. The >Beagle doesn't appear to have that feature as there

[beagleboard] Re: ioctl messages to Beagle SPI port.

On Tue, 25 May 2021 19:16:51 -0700, in gmane.comp.hardware.beagleboard.user "John Dammeyer" wrote: >Hi Dennis, >I tried on the groups site to edit this post and change what I wrote. While the master copy appears to be a Google Groups entry, it seems to be propagated outward since gmane

RE: [beagleboard] Re: ioctl messages to Beagle SPI port.

> Because this example program uses the high speed gpio the fault happens much > sooner on the Pi without the sudo. > > pi@raspberrypi:~/projects/lazarus/TC $ ./TC > An unhandled exception occurred at $00084EE4: > ERPiOpenFile: Cannot not open > file

RE: [beagleboard] Re: ioctl messages to Beagle SPI port.

Hi Dennis, I tried on the groups site to edit this post and change what I wrote. I meant to say both systems _do_not_ place local variables on the heap. In fact I'm not sure that static are placed on the heap since that could cause all sorts of fragmentation issues. The advantage of static is

[beagleboard] Re: ioctl messages to Beagle SPI port.

On Tue, 25 May 2021 12:55:32 -0700, in gmane.comp.hardware.beagleboard.user "John Dammeyer" wrote: >My understanding is both systems place the variables on the heap. Only the >small micro-controllers with limited stack space (recall some of the PIC16 >series had a 2 word call stack). Other

RE: [beagleboard] Re: ioctl messages to Beagle SPI port.

I agree, the C code uses the equivalent of the WITH statement in Pascal to assign parameters during structure declaration. Once you 'get' how it works it's fairly readable. My understanding is both systems place the variables on the heap. Only the small micro-controllers with limited stack

Re: [beagleboard] Re: PRU Messaging

Bruce  Make sure any approach you choose meets your requirement of using more RAM than the PRUS have available if this is still a requirement. Mark On Tuesday, May 25, 2021, 01:41:27 PM CDT, Darren Freed wrote: Bruce, I feel your frustration with getting familiar with PRU.  What I

Re: [beagleboard] Re: PRU Messaging

Thanks for the reference...everything helps. I will digest it as well. On Tuesday, May 25, 2021 at 1:41:32 PM UTC-5 darre...@gmail.com wrote: > Bruce, > > I feel your frustration with getting familiar with PRU. What I did, > working with the standard Debian that BB ships with (including

Re: [beagleboard] Re: PRU Messaging

Bruce, I feel your frustration with getting familiar with PRU. What I did, working with the standard Debian that BB ships with (including updates), was to start with Professor Yoder's PRUCookbook . That at least should get you going. He has

Re: [beagleboard] Re: PRU Messaging

Bruce  I agree with your assessment.There is no one way to do this I mentioned two.PRU cookbook and SDK Perhaps GitHub works as well.I know one method works doesn't mean others won't. I now understand better what you tried and where you got it from. Thanks . My parting comment is only an

Re: [beagleboard] Re: PRU Messaging

Other? (OK) When I mean others, I mean other people's post on this topic seems to get the message in dmesg, and looks like everyone else seems to get them fine. I however do not. The "other" I refer to, for example, is at: https://github.com/beagleboard/linux/issues/185 Laserman, I think

Re: [beagleboard] Re: PRU Messaging

Bruce What do " The Others" say is wrong? I have seen that PRU support package. In my reply last week it appears to me you have adopted what I call the apple  and oranges approach. I'm trying to say serious but I think "the other's" were a mysterious cult on star trek. These instructions look

[beagleboard] Re: ioctl messages to Beagle SPI port.

On Tue, 25 May 2021 09:45:39 -0700, in gmane.comp.hardware.beagleboard.user "John Dammeyer" wrote: > >Here's the BBB version from and you can see the code is identical for both the >Pi and the Beagle.

[beagleboard] Re: Reducing Boottime in Beaglebone Black

On Mon, 24 May 2021 20:47:42 -0700 (PDT), in gmane.comp.hardware.beagleboard.user Karishma Jaiswal wrote: > not getting the exact reason why * 51.048s dev-mmcblk1p1.device *this is >taking too much time and is there any way that we can reduce it? > Part of that may be tied to the

RE: [beagleboard] Re: Reducing Boottime in Beaglebone Black

Let's do the math. One million users running WIN-10 software waiting say 2 minutes for usable desktop ready to perform. That's 2 million minutes. Or 33,333..333 hours or 4,166.666 days or 11.4 man-years of wasted time. Do you think we can send an invoice to Bill Gates? John >

RE: [beagleboard] Re: ioctl messages to Beagle SPI port.

So I've solved the problem with the ESysfsSPITransfer: Cannot transfer <1> data byte(s) through SPI bus. The C versions with the spi_ioc_transfer structure declared inside the transfer() function work on both the Beagle and Pi3. Here's the BBB version from and you can see the code is

[beagleboard] Re: PRU Messaging

I have a new image with 10.9 installed with an apt update; apt upgrade I wonder if my issue is around /dev/rpmsg_pru* Others suggest that after the following steps, the device shows up, but mine does not. cd /tmp git clone

[beagleboard] Re: PRU Messaging

Dennis, I have made a flasher and have flashed 10.9 image that you referred to me earlier. Re-adding everything on the system now and re-testing. Also processing the requests from Lazarman about the lab and quick start guide. Really appreciate the help On Tuesday, May 25, 2021 at 11:20:45

[beagleboard] Re: PRU Messaging

On Tue, 25 May 2021 07:40:20 -0700 (PDT), in gmane.comp.hardware.beagleboard.user Bruce Chidester wrote: >*It is asking you to confirm which Beagle you are using.:* >I am using Beaglebone Black Revision C > > >*It will be much quicker to do an apt update/aptupgrade.:* >I performed the

[beagleboard] Re: Reducing Boottime in Beaglebone Black

On Mon, 24 May 2021 15:36:54 -0700, in gmane.comp.hardware.beagleboard.user "John Dammeyer" wrote: >I will state that waiting over two minutes for a Beagle to boot into Linux >desktop mouse/keyboard/screen is unacceptable. Windows with a 640K 8088 or a >Pentium-33MHz could create a

[beagleboard] Re: PRU Messaging

*It is asking you to confirm which Beagle you are using.:* I am using Beaglebone Black Revision C *It will be much quicker to do an apt update/aptupgrade.:* I performed the update/upgrade and /etc/dogtag still reports the same info. Should I get a newer image? Is the issue my distro? On Monday,