Re: [beagleboard] Re: BeagleBone Black QNX 6.5.0 SP1

2021-03-03 Thread Lucas SOLDA 
Yes I entered these commands in u-boot, I could have automated them but I 
prefer to write them for the moment.

"In theory if you have a license BUT 
some RTOS companies dont supply BSP source code unless you paid fees 

So do you need to modify BSP" 

Yes in theory I agree. I will need to modify the BSP because I want Isagraf 
so I have to install the drivers (to make the beaglebone black a target I 
can load through IsaGraf)

In fact I'm very lost with all of these things
Le mercredi 3 mars 2021 à 19:50:58 UTC+1, lazarman a écrit :

> These commands you entered  are where? uboot?
>
> --> fatload mmc 0 0x8100 prebuilt-bsp-ti-beaglebone.ifs
> --> go 0x8100
>
> Why not automate these commands ?
>
> << prebuilt image, right ?
>
> In theory if you have a license BUT 
> some RTOS companies dont supply BSP source code unless you paid fees 
>
> So do you need to modify BSP>
>
>
>
> On Wednesday, March 3, 2021, 09:03:22 AM CST, Lucas SOLDA <
> lucas...@gmail.com> wrote: 
>
>
> Mark,
>
> I have a BeagleBone Black REV C.
> There was nothing on the SD before. I did not touch to the EMC so I think 
> there is nothing inside.
> My company has a QNX 6.5.0 SP1 licence and here is the list of the tools 
> installed on my computer: 
>
> [image: 1.png]
> [image: 2.jpg]
>
> First, I formated my SD card in FAT32, I made it active by using diskpart 
> and I copied the MLO and then the u-boot files. I took them from here : 
> https://community.qnx.com/sf/wiki/do/viewPage/projects.bsp/wiki/TiAm335Beaglebone
> Bootloader modules# 
> 
>  --> 
> *"Click here 
> 
>  to 
> download the MLO and u-boot binaries for the new Beaglebone Black platform. 
> "*
>
> After that, I downloaded the BSP files: QNX Neutrino 6.5.0 SP1# 
> 
>  -->  *Download *Project Downloads 
> 
>  --> bsp-nto650-ti-beaglebone-sp1-trunk-201209071340.zip 
> 
> (I attach MLO, u-boot and BSP to this mail)
> After extracting, I copied the file "prebuilt-bsp-ti-beaglebone.ifs" in 
> the "image" folder to my sdcard and I could succesfully launch QNX on my 
> BBB by typing these commands :
> --> fatload mmc 0 0x8100 prebuilt-bsp-ti-beaglebone.ifs
> --> go 0x8100
>
> That worked perfectly. 
>
> When I try to compile the image by myself it gets complicated.
>
> if I compile the BSP without modifying anything, I should get the prebuilt 
> image, right ?
> The problem is that, when I do that, I have the message I gave in the 
> first post and it says that I compile with QNX 6.5.0 and not with QNX 6.5.0 
> SP1 (whereas it is installed).
>
> *"I'm guessing you have no support forum or no ones replying at QNX?" *I 
> don't have support anymore and the only thing the told me is that I don't 
> use QNX 6.5.0 SP1
>
> I don't know what to do anymore and the QNX SDP is not on my computer so I 
> can't use it whenever I want
>
> Le mercredi 3 mars 2021 à 15:03:47 UTC+1, lazarman a écrit :
>
> Let's start with some history about what rev board you have , what was on 
> SD before and whats in  the emc now and details about tools you installed 
> to build BSP and QNX and exactly the BSP file's you are compiling as well 
> as your goals. Are you trying to eventually modify the BSP source?
> I'm guessing you have no support forum or no ones replying at QNX?
> I need a clear picture of what you did exactly installing tools as in did 
> you install multiple times etc etc 
>
> I'll look at the pdf you supplied and ponder whether it worthwhile and 
> practical to find my Beagleboard,Whites,blacks or even Pandaboard.
> power supplies may be hard to match I've moved a lot. I guess a black 
> would be easy for me to find but may be in storage.
>
>  Also maybe they will let me reeducate myself as I'm not working on a 
> commercial product and give me access otherwise it's harder to help.
>
> Hopefully I can get you on the right path 
>
> Mark
>
>
> Sent from Yahoo Mail on Android 
> 
>
> On Wed, Mar 3, 2021 at 1:15 AM, Lucas SOLDA
>  wrote:
> I can send you the files if you don't have an account.
>
> I use the MLO and u-boot files for beaglebone black from this link : 
> "Click *here 
> *
>  to 
> download the MLO and u-boot binaries for the new

[beagleboard] Re: PWM wave in pocketbeagle

2021-03-03 Thread Dennis Lee Bieber 
On Wed, 3 Mar 2021 06:18:40 -0800 (PST), in
gmane.comp.hardware.beagleboard.user Rafael Meyer

wrote:

>
>I would like to know how to generate a PWM wave with code in python3. 
>

https://adafruit-bbio.readthedocs.io/en/latest/PWM.html

Based upon
https://raw.githubusercontent.com/wiki/beagleboard/pocketbeagle/images/PocketBeagle_pinout.png
there are four pins that support PWM output. P1_33 (defaults to PRU), P1_36
(PWM), P2_1 (PWM), P2_3 (default GPIO).

If Adafruit_BBIO.PWM can't change the pin mode, you may have to play
with config-pin external to the program first.

It looks like PWM has also been added to the blinka/circuitpython
adapter.




-- 
Dennis L Bieber

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/sdp04g50hhjhfbs5f57la9h1v1orub8dla%404ax.com.

[beagleboard] Re: GPIO, libpruio & dtbo Question

2021-03-03 Thread Dennis Lee Bieber 
On Wed, 3 Mar 2021 18:11:27 -0500, in gmane.comp.hardware.beagleboard.user
Don Pancoe  wrote:


>The PCBA test program is a long series of while loops, if statements and
>timeout counters that wait for inputs and evaluate them, or move on if
>they're taking too long. I was thinking of using an AdafruitBB_IO edge
>detect to watch for an abort button press, then having that trigger a
>function that handles any wrap-up tasks and calls a *break* function to pop
>out of the main test loop to another outer loop so that it returns to the
>top of the test. I'm actually doing this now to halt the test if the
>in-circuit programmer reports a flashing failure. The difference is: the
>programmer failure happens at a known point where I know to look for it,
>but the abort button should be able to be used at any time.
>
>One idea I've had but not tested yet is to replace the *sleep()* functions
>I judiciously use for timing throughout the test with a custom function
>that breaks the sleep period (anywhere from 10 ms to 10 s) into smaller
>chunks interspersed with checking of the abort button GPIO. This I could do
>just with libpruio as suggested by TJF. Theoretically, I could wait for
>every subsequent while loop to time out at 60 seconds each, but that's not
>practical for test throughput, or when you are billed for testing by the
>minute.
>

If using Adafruit_BBIO edge detect with a call-back function, that
call-back probably should do nothing more than set a "global" flag.

Your sleep() and loops would then include something like "while not
abortFlag".  

There is no easy way in Python to back out of multiple levels of loops
except via an exception (so something like "if abortFlag: raise
customAbortException"). You'd catch that exception at the outermost level,
and the handler does the clean-up. A one-level loop can be exited with
"break".


-- 
Dennis L Bieber

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/ikm04gtkhni4rvnvbon1nfffuk76nmkf6l%404ax.com.

Re: [beagleboard] Re: GPIO, libpruio & dtbo Question

2021-03-03 Thread set_ 
Hello Sir,

Look at this! 


   - https://github.com/beagleboard/BeagleBoard-DeviceTrees 
   - Specifications - DeviceTree 
   
   - https://github.com/beagleboard/bb.org-overlays
   - https://github.com/u-boot/u-boot
   
Those should get you updated on ideas. 

Seth

P.S. The first bullet point is the DeviceTrees for the am335x, 
cape-universal, am5729, and so on... The second bullet point is the actual 
spec. w/ related info. Get one! The third bullet point is the overlay 
section and there is juicy info. in those files for adding support for the 
am335x and so on. Also, last but not least, uboot. I am sure there is 
something about uboot that needs to be incorporated in DeviceTree specs. 
So, I placed that in too. If you get bored, look here 
too: https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black .

On Wednesday, March 3, 2021 at 5:11:50 PM UTC-6 donp...@gmail.com wrote:

> Hello everyone,
>
> Thank you for all the input. It's been a busy few days so I'm just getting 
> back to it.
>
> First, I was talking about AdafruitBB_IO. I was just being lazy and/or 
> confused in typing BBB_IO, but I now see that BBBIO 
>  is a different C library for the 
> Beaglebone Black. I do write C code for microcontrollers, so I don't know 
> why I felt like a program on an SBC should be in Python, but I don't want 
> to start over from scratch now.
>
> The PCBA test program is a long series of while loops, if statements and 
> timeout counters that wait for inputs and evaluate them, or move on if 
> they're taking too long. I was thinking of using an AdafruitBB_IO edge 
> detect to watch for an abort button press, then having that trigger a 
> function that handles any wrap-up tasks and calls a *break* function to 
> pop out of the main test loop to another outer loop so that it returns to 
> the top of the test. I'm actually doing this now to halt the test if the 
> in-circuit programmer reports a flashing failure. The difference is: the 
> programmer failure happens at a known point where I know to look for it, 
> but the abort button should be able to be used at any time.
>
> One idea I've had but not tested yet is to replace the *sleep()* 
> functions I judiciously use for timing throughout the test with a custom 
> function that breaks the sleep period (anywhere from 10 ms to 10 s) into 
> smaller chunks interspersed with checking of the abort button GPIO. This I 
> could do just with libpruio as suggested by TJF. Theoretically, I could 
> wait for every subsequent while loop to time out at 60 seconds each, but 
> that's not practical for test throughput, or when you are billed for 
> testing by the minute.
>
> Somewhat separate from all this, though: I've been finding the device 
> tree, overlays and pinmuxes to be some of the more difficult BBB/Linux 
> topics to wrap my head around, so I would appreciate any recommended 
> tutorials on the subject. There are tutorials that come up in Google 
> searches, but with the changes to both Linux and Beaglebone over the years, 
> it's hard to know if they are pertinent to the state of my system right now 
> (I've not updated to the latest kernel etc. because I don't want to break 
> any of my past work).
>
> Thanks,
> --
> Don Pancoe, P.E.
> Industrial Designer, Electrical Engineer
> DonPancoe.com 
>
> On Wed, Mar 3, 2021 at 4:09 AM TJF  wrote:
>
>> Hello Don Pancoe!
>>
>> Why do you think you'll need an IRQ for the "abort" button?
>>
>> Drop Adafruit_BBIO! Just setup the GPIO in libpruio and poll the state in 
>> your main loop (or in a timered thread).
>>
>> Regards
>> donp...@gmail.com schrieb am Montag, 1. März 2021 um 19:27:01 UTC+1:
>>
>>> Hello all,
>>>
>>> I have a BBB Python application (PCBA test fixture) where I am using 
>>> libpruio, specifically for access to the eCAP pins. Libpruio requires that 
>>> the universal cape be disabled, but when I needed a UART and I2C, I was 
>>> able to add those back in using the existing dtbo files from /lib/firmware 
>>> (shown below) in my uEnv.txt.
>>>
>>> uboot_overlay_addr0=/lib/firmware/BB-I2C1-00A0.dtbo
>>> uboot_overlay_addr1=/lib/firmware/BB-UART4-00A0.dtbo
>>> uboot_overlay_addr2=/lib/firmware/DP-GPIO-PCBATest-00A0.dtbo (I talk 
>>> about this below)
>>>
>>>
>>> Now I want to add an "abort" button to the test fixture since the 
>>> technicians have reported it takes a lot of time to reset if the board 
>>> under test locks up. I expect that wiring a pushbutton to a GPIO with an 
>>> interrupt is the way to handle this, and I've been thinking that there are 
>>> two ways to get there.
>>>
>>>1. Include another dtbo file to add a single GPIO that I can then 
>>>access with Adafruit_BBIO (this is where my efforts have focused so 
>>> far), or
>>>2. Figure out how to work with the hardware-based IRQ of the PRU  
>>>with libpruio (which I've been avoiding because it looks even more

Re: [beagleboard] Re: GPIO, libpruio & dtbo Question

2021-03-03 Thread Don Pancoe 
Hello everyone,

Thank you for all the input. It's been a busy few days so I'm just getting
back to it.

First, I was talking about AdafruitBB_IO. I was just being lazy and/or
confused in typing BBB_IO, but I now see that BBBIO
 is a different C library for the
Beaglebone Black. I do write C code for microcontrollers, so I don't know
why I felt like a program on an SBC should be in Python, but I don't want
to start over from scratch now.

The PCBA test program is a long series of while loops, if statements and
timeout counters that wait for inputs and evaluate them, or move on if
they're taking too long. I was thinking of using an AdafruitBB_IO edge
detect to watch for an abort button press, then having that trigger a
function that handles any wrap-up tasks and calls a *break* function to pop
out of the main test loop to another outer loop so that it returns to the
top of the test. I'm actually doing this now to halt the test if the
in-circuit programmer reports a flashing failure. The difference is: the
programmer failure happens at a known point where I know to look for it,
but the abort button should be able to be used at any time.

One idea I've had but not tested yet is to replace the *sleep()* functions
I judiciously use for timing throughout the test with a custom function
that breaks the sleep period (anywhere from 10 ms to 10 s) into smaller
chunks interspersed with checking of the abort button GPIO. This I could do
just with libpruio as suggested by TJF. Theoretically, I could wait for
every subsequent while loop to time out at 60 seconds each, but that's not
practical for test throughput, or when you are billed for testing by the
minute.

Somewhat separate from all this, though: I've been finding the device tree,
overlays and pinmuxes to be some of the more difficult BBB/Linux topics to
wrap my head around, so I would appreciate any recommended tutorials on the
subject. There are tutorials that come up in Google searches, but with the
changes to both Linux and Beaglebone over the years, it's hard to know if
they are pertinent to the state of my system right now (I've not updated to
the latest kernel etc. because I don't want to break any of my past work).

Thanks,
--
Don Pancoe, P.E.
Industrial Designer, Electrical Engineer
DonPancoe.com 


On Wed, Mar 3, 2021 at 4:09 AM TJF  wrote:

> Hello Don Pancoe!
>
> Why do you think you'll need an IRQ for the "abort" button?
>
> Drop Adafruit_BBIO! Just setup the GPIO in libpruio and poll the state in
> your main loop (or in a timered thread).
>
> Regards
> donp...@gmail.com schrieb am Montag, 1. März 2021 um 19:27:01 UTC+1:
>
>> Hello all,
>>
>> I have a BBB Python application (PCBA test fixture) where I am using
>> libpruio, specifically for access to the eCAP pins. Libpruio requires that
>> the universal cape be disabled, but when I needed a UART and I2C, I was
>> able to add those back in using the existing dtbo files from /lib/firmware
>> (shown below) in my uEnv.txt.
>>
>> uboot_overlay_addr0=/lib/firmware/BB-I2C1-00A0.dtbo
>> uboot_overlay_addr1=/lib/firmware/BB-UART4-00A0.dtbo
>> uboot_overlay_addr2=/lib/firmware/DP-GPIO-PCBATest-00A0.dtbo (I talk
>> about this below)
>>
>>
>> Now I want to add an "abort" button to the test fixture since the
>> technicians have reported it takes a lot of time to reset if the board
>> under test locks up. I expect that wiring a pushbutton to a GPIO with an
>> interrupt is the way to handle this, and I've been thinking that there are
>> two ways to get there.
>>
>>1. Include another dtbo file to add a single GPIO that I can then
>>access with Adafruit_BBIO (this is where my efforts have focused so far), 
>> or
>>2. Figure out how to work with the hardware-based IRQ of the PRU
>>with libpruio (which I've been avoiding because it looks even more scary)
>>
>> I've tried to make a custom dtbo by following an example from Derek
>> Molloy (github.com/derekmolloy/boneDeviceTree) and while it compiled and
>> booted OK, I still get the following error when I run a simple test
>> program. The same error as when I tried running the program before I
>> created the dtbo.
>>
>> kapsul@beaglebone:~/pyDev$ sudo python3 abortTest.py
>> Traceback (most recent call last):
>>   File "abortTest.py", line 6, in 
>> GPIO.setup("P9_12", GPIO.IN)
>> ValueError: Set gpio mode failed, missing file or invalid permissions.
>>
>>
>> Further, when I do the following (with or without the dtbo), I get the
>> following...
>>
>> kapsul@beaglebone:~/pyDev$ config-pin -q p9.12
>> P9_12 pinmux file not found!
>> Cannot read pinmux file: /sys/devices/platform/ocp/ocp*P9_12_pinmux/state
>>
>>
>> Any input would be appreciated, whether it is correcting me on path 1 or
>> steering me towards path 2. I will happily provide any additional info, but
>> I didn't want to start uploading stuff until I know what, exactly, will be
>> helpful.
>>
>> Thanks,
>> --
>> Don Pancoe, P.E.
>>

[beagleboard] Re: BBAI PRU-I2C driver

2021-03-03 Thread Fred Frey 
Hey, can I flip it around? Becuase I have a question for *you.*

Have you managed to get this working on a normal BBB? I'm also trying to 
develop an i2c driver for the PRU. It almost looks like we started with the 
same codebase (https://github.com/LinuxDroneLab/pru-i2c-lib), but you have 
obviously modified yours a lot more than I have mine to get it working with 
the 527.

There is definitely some piece missing here. Mine gets to the point of 
setting the I2C_CON register, but then XRDY never comes, and if I read back 
the I2C_CON register, it has lost its master bit. If you look at the TRM, 
it says that the bit is automatically cleared "at the end of a transfer on 
a dedicated stop condition, in case of arbitration lost or when the module 
is configured as a master but addressed as a slave by an external master." 
When I read back the IRQSTATUS register, it just gives back 0.

I've tried trawling through e2e support threads, but the most promising 
ones always link to the TI Processors wiki, which TI decided wasn't worth 
maintaining and shut down about 2 months ago :( 

I made another thread begging people for their stash of these old articles (
https://groups.google.com/u/0/g/beagleboard/c/w6Nd1WmPoSU), so that may be 
of interest to you as well.

I'm sorry if it feels like I'm hijacking your thread, but maybe we can help 
each other out here?

Thanks,
Fred





On Tuesday, 2 March 2021 at 14:58:18 UTC-5 pierric...@gadz.org wrote:

> Hi All,
>
> I am trying to develop a PRU driver for I2C on the Beaglebone AI 
> (Ti-am5729). I have some questions about the setup procedure using 
> Interrupt and polling (I am not using DMA). I am not quite sure about the 
> differences between the setup described between section *24.1.5.1.1.1.1 
> and 24.1.5.1.1.1.2)* and the figure (24.19) of the TRM 
> 
> . 
>
> 1- I am not sure about the value to put for I2C_IRQENABLE_SET (referenced 
> in figure 24.19) I have tried with 0x1f (enable XRDY, RRDY, ARDY, NACK, and 
> AL as they are used later). However, I receive a Kernel Oops when I try to 
> run my code " [Feb26 14:54] Unable to handle kernel NULL pointer 
> dereference at virtual address 
>
> [ +0.003725] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
>
> genirq: exiting task "irq/114-4807a00" (110) is an active IRQ thread (irq 
> 114)" 
>
>  What value should be used to configure the I2C_IRQENABLE_SET?
>
> 2- I have tried to write in the I2C_DATA register but reading the register 
> after always gives 0xD. I have checked the value of I2C_IRQSTATUS_RAW, and 
> it always read 0x10 (XRDY). Am I missing something to write the data? 
>
> If you want to have a look at my code, it is under this repository 
> https://github.com/PierrickRauby/BBAI-PRU-I2C/blob/main/am572x_pru_i2c_driver.pru1_1.c
>
> Thanks for any help you can provide! 
>
> Pierrick 
>
>
> PS: I have posted this same question on the Ti e2e forum a few days ago 
> but I have not solved my issue yet. 
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/65d1a4f9-2b90-43a7-a0e5-d7753c8d2c2bn%40googlegroups.com.

[beagleboard] TI Processors Wiki Archive

2021-03-03 Thread Fred Frey 
Hi all,

This isn't strictly related to beagle(board|bone) SOCs, but more about TI's 
recently taken-down Processor Wiki, which had all sorts of goodies for 
getting into the lower levels of the AM335x. I foolishly failed to archive 
the things that I wanted before it was taken down.

There is a rather large scrape of it up on archive.org (
https://archive.org/details/wiki-processorswikiticom), but it's lacking 
some articles that I see linked on old e2e support forum threads.

I'm going to give up hope now of ever finding those specific articles, but 
if anyone has a stash that they'd be willing to share, I'm looking for 
pretty much anything to do with AM335x, and especially the PRUs, and the 
i2c subsystem.

Thanks,
Fred

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8e6e663a-3291-4da0-b2d5-15977f631d7bn%40googlegroups.com.

[beagleboard] PWM wave in pocketbeagle

2021-03-03 Thread Rafael Meyer 
Hello,

I am a beginner in programming and acquired a pocketbeagle card.
 
So far I have just configured the pocketbeagle to communicate with the 
internet and updated the software. I used a simple code from the internet 
to test the board's leds but I still don't know how to configure the pins.

I would like to know how to generate a PWM wave with code in python3. 

 Thanks! 

 Rafael G. Meyer

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/c84cbb31-587b-427e-9462-881be7bb19c6n%40googlegroups.com.

Re: [beagleboard] Re: BeagleBone Black QNX 6.5.0 SP1

2021-03-03 Thread 'Mark Lazarewicz' via BeagleBoard 
Let's start with some history about what rev board you have , what was on SD 
before and whats in  the emc now and details about tools you installed to build 
BSP and QNX and exactly the BSP file's you are compiling as well as your goals. 
Are you trying to eventually modify the BSP source?I'm guessing you have no 
support forum or no ones replying at QNX?I need a clear picture of what you did 
exactly installing tools as in did you install multiple times etc etc 
I'll look at the pdf you supplied and ponder whether it worthwhile and 
practical to find my Beagleboard,Whites,blacks or even Pandaboard.power 
supplies may be hard to match I've moved a lot. I guess a black would be easy 
for me to find but may be in storage.
 Also maybe they will let me reeducate myself as I'm not working on a 
commercial product and give me access otherwise it's harder to help.
Hopefully I can get you on the right path 
Mark

Sent from Yahoo Mail on Android 
 
  On Wed, Mar 3, 2021 at 1:15 AM, Lucas SOLDA wrote:   I 
can send you the files if you don't have an account.
I use the MLO and u-boot files for beaglebone black from this link : "Click 
here to download the MLO and u-boot binaries for the new Beaglebone Black 
platform.".
The fact you pointed is troubling. I don't understand why the BSP is unchanged  
between beagleboard and BBB.
"Perhaps if you disassemble the binary and look at the bone memory map and the 
linker map and the u boot load address for QNX there's a mismatch do you have 
access to BSP users guide? " 

I will try to do that but I'm not an expert. I have access to the user guide 
yes... Le mercredi 3 mars 2021 à 08:09:38 UTC+1, Lucas SOLDA a écrit :

@lazarman, in fact I'm not a student and I have a company account with a QNX 
6.5.0 SP1 licence. I have also already registered to the" QNX Software 
Development Platform 6.5.x (registration)" link that you gave me. The problem 
is not the fact that I can't download and install the SDP but the fact that 
when I build the image thanks to the BSP, I don't have the same result as the 
prebuilt image

Le mercredi 3 mars 2021 à 00:24:34 UTC+1, lazarman a écrit :

Hi Robert I think Lucas is saying he's only trying to build the BSP not QNX.
I did this 10 years ago and I also had the latest  BSP guides I tried getting 
these and you need a customer login. It says it's free for education but again 
BlackBerry bought this.
What's funny is this link below takes you to another page which says we support 
these processors. It also says you should lose the latest version's 
QNX SDP 7.0 BSP for Texas Instruments AM335x (Beaglebone Black)




 https://blackberry.qnx.com/en/support/qnx-board-support-packages
Clicking on the above link  next to the BSP you see another page saying 

The QNX Software Center enables you to download and manage QNX Software 
Development Platform version 7.x and related products. PDF documentation and 
Licensing information relating to QNX SDP 7 and related products can also be 
found here. IMPORTANT: SDP 7.x licenses are initially delivered within the 
myQNX License Manager and MUST be assigned to users via the license manager in 
order for them to access the product.

And no code just a login.
That BSP Lucas references is over 6 year's old.
Even 10 year's ago you needed a valid company domain and email address for QNX 
I know GreenHills and  maybe WindRiver as well wouldn't even reply to a free 
email domain and definitely won't give you a 30 day level  license key that the 
license manager needed 
Lucas is this for education ?? I know it's frustrating you might have to reach 
out them about



  

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1278493211.71215.1614780213005%40mail.yahoo.com.

[beagleboard] Re: latest machinekit image isn't loading uio dtb

2021-03-03 Thread TJF 
In debian LTS-5_4 (20-05-18) there is no uio_pruss driver. See

https://groups.google.com/g/beagleboard/c/WhS8mHDWY58/m/1Ip8wMO9AQAJ

No answer yet.

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/bd1965d5-a942-4106-bd38-0568fc061f28n%40googlegroups.com.

[beagleboard] Re: GPIO, libpruio & dtbo Question

2021-03-03 Thread TJF 
Hello Don Pancoe!

Why do you think you'll need an IRQ for the "abort" button?

Drop Adafruit_BBIO! Just setup the GPIO in libpruio and poll the state in 
your main loop (or in a timered thread).

Regards
donp...@gmail.com schrieb am Montag, 1. März 2021 um 19:27:01 UTC+1:

> Hello all,
>
> I have a BBB Python application (PCBA test fixture) where I am using 
> libpruio, specifically for access to the eCAP pins. Libpruio requires that 
> the universal cape be disabled, but when I needed a UART and I2C, I was 
> able to add those back in using the existing dtbo files from /lib/firmware 
> (shown below) in my uEnv.txt.
>
> uboot_overlay_addr0=/lib/firmware/BB-I2C1-00A0.dtbo
> uboot_overlay_addr1=/lib/firmware/BB-UART4-00A0.dtbo
> uboot_overlay_addr2=/lib/firmware/DP-GPIO-PCBATest-00A0.dtbo (I talk 
> about this below)
>
>
> Now I want to add an "abort" button to the test fixture since the 
> technicians have reported it takes a lot of time to reset if the board 
> under test locks up. I expect that wiring a pushbutton to a GPIO with an 
> interrupt is the way to handle this, and I've been thinking that there are 
> two ways to get there.
>
>1. Include another dtbo file to add a single GPIO that I can then 
>access with Adafruit_BBIO (this is where my efforts have focused so far), 
> or
>2. Figure out how to work with the hardware-based IRQ of the PRU  with 
>libpruio (which I've been avoiding because it looks even more scary)
>
> I've tried to make a custom dtbo by following an example from Derek Molloy 
> (github.com/derekmolloy/boneDeviceTree) and while it compiled and booted 
> OK, I still get the following error when I run a simple test program. The 
> same error as when I tried running the program before I created the dtbo.
>
> kapsul@beaglebone:~/pyDev$ sudo python3 abortTest.py
> Traceback (most recent call last):
>   File "abortTest.py", line 6, in 
> GPIO.setup("P9_12", GPIO.IN)
> ValueError: Set gpio mode failed, missing file or invalid permissions.
>
>
> Further, when I do the following (with or without the dtbo), I get the 
> following...
>
> kapsul@beaglebone:~/pyDev$ config-pin -q p9.12
> P9_12 pinmux file not found!
> Cannot read pinmux file: /sys/devices/platform/ocp/ocp*P9_12_pinmux/state
>
>
> Any input would be appreciated, whether it is correcting me on path 1 or 
> steering me towards path 2. I will happily provide any additional info, but 
> I didn't want to start uploading stuff until I know what, exactly, will be 
> helpful.
>
> Thanks,
> --
> Don Pancoe, P.E.
> Industrial Designer, Electrical Engineer
> DonPancoe.com 
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e16d3e52-0239-4df2-bb47-8aac7776728dn%40googlegroups.com.