Re: [beagleboard] PRU locking up Beaglebone AI
this topic, visit https://groups.google.com/d/topic/beagleboard/TyaYiVQkscM/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAA9ERVr2u5m%3DJMrUsVAKN7H5TKw3_NvSxXwDGab9%2BmhNFnzC%3DQ%40mail.gmail.com <https://groups.google.com/d/msgid/beagleboard/CAA9ERVr2u5m%3DJMrUsVAKN7H5TKw3_NvSxXwDGab9%2BmhNFnzC%3DQ%40mail.gmail.com?utm_medium=email_source=footer> . -- Charles Steinkuehler char...@steinkuehler.net -- 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/d4ac29b3-77a2-ea27-1019-b9a9ac7ceedb%40steinkuehler.net.
[beagleboard] Re: [Machinekit] Seeed to design and build Machinekit focused Cape for BeagleBone Black/AI
This depends a lot on what sort of machine you're trying to drive. A "standard" CNC machine with step/dir typically needs a DB25 (aka: parallel port) with buffered signals you can connect to external stepper drivers. A 3D printer would more typically have low-powered "Pololu" style drivers either on-board or via sockets along with some high power outputs for the extruder and bed heaters. A more advanced system might provide a control signal (+/- 10V, or perhaps PWM) to drive a motor driver and provide for encoder feedback to close the servo loop. ...so it really depends on what sort of system(s) you want to support, and how much you want to try to be a "one size fits all" solution. On 3/12/2020 8:38 AM, Jason Kridner wrote: Seeed is looking to not only build a Machinekit-focused Cape for BeagleBone Black and BeagleBone AI, but to: * Take in features and feedback from the community * Contribute the design to open source and certify it as such * Manufacture the design under the BeagleBoard.org name to support the BeagleBoard.org Foundation and community * Help assemble and provide software images configured for an open source 3D printer and CNC machine (with BeagleBoard.org and community guidance and support) * Offer a collection of additional accessories which might commonly be needed I am very excited about this because I know Seeed cares about open hardware and also knows how to deliver solutions reliably and cost effectively. So, what are your ideas about where to start on such a cape? -- Charles Steinkuehler char...@steinkuehler.net -- 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/0db7068a-dba9-fe07-8961-d1adc079aed4%40steinkuehler.net.
Re: [beagleboard] Ethernet module in beagle bone black
You might want to take a look at the netcat utility: https://en.wikipedia.org/wiki/Netcat You can use it to send or receive data via Etherenet as easily as using the cat command (hence the name). On 7/23/2019 11:14 PM, Megha Bhirade wrote: > Hi, > > I am using beagle bone black board in Linux ubuntu 16.04LTS, i need to work > on Ethernet . > > requirement is like enabling Ethernet between the Board and PC and i need > to send the data from PC and need to receive the data on beagle bone black > using Ethernet communication and once data collected that data i need to > pass to the other PC using Uart.. > > Uart enabling and transmitting the data i understood... > > please tell me how to configure Ethernet and C program to receive the data > from Ethernet > > please suggest me any related link for this > -- Charles Steinkuehler char...@steinkuehler.net -- 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/6d541652-79b2-3c08-896e-0ac4ad84662a%40steinkuehler.net.
Re: [beagleboard] PRU Communications: Beaglebone Black
On 7/4/2019 2:57 AM, TJF wrote: > Interesting, thanks Charles! > > Am Mittwoch, 3. Juli 2019 17:35:41 UTC+2 schrieb Charles Steinkuehler: >> >> The >> transfer is terminated if either PRU core stalls for more than 1024 >> cycles. > > How to distinguish between a terminated or regular transfer? >From the TRM: "In direct connect mode (device ID 14), any PRU transaction will be terminated if the stall is greater than 1024 cycles. This will generate the event pr<1/0>_xfr_timeout that is connected to INTC." -- Charles Steinkuehler char...@steinkuehler.net -- 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/6e5e75fb-b2a3-a44b-0f2b-a049baf59f7a%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] PRU Communications: Beaglebone Black
As has been discussed, the PRUs have no direct "interrupt" like functionality that interrupts and redirects program execution. In addition to the various methods already discussed, if you are trying to tightly couple program execution between the two PRU cores, I suggest using the transfer instructions (XIN/XOUT). While these instructions are typically used to access the scratchpad and hardware multiplier, you can also specify a direct connection between the two PRU cores. In this case, one PRU core executes an XIN instruction and the other core executes an XOUT. The core that executes the instruction first will stall until the other PRU executes it's transfer instruction, at which point the two PRU cores will continue executing code, synchronized by the transfer instruction. The transfer is terminated if either PRU core stalls for more than 1024 cycles. Details are in the TRM, but you have to have one of the versions with full details on the PRU cores (eg: spruh73c or similar). On 7/2/2019 7:49 AM, Venkatesh Vadde wrote: > We are a group working with a Beaglebone and trying to get more time > determinism between the PRUs. We are trying to get one PRU to respond to a > trigger from the other PRU. The INTC framework seems quite complex, and we > are finding it quite difficult to decipher or understand (but an example > might help us build on it). Does the PRU allow for a timed response like an > interrupt based mechanism? Can someone suggest something for our > requirement of communication between the PRUs? > > Thank you, > -Vadde > -- Charles Steinkuehler char...@steinkuehler.net -- 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/30cf3e82-eae4-07cb-7be8-0bf34137de0d%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Board recovery
On 5/18/2019 10:02 PM, Kevin Krugielki wrote: > > Long story short. I have thses boards but have no access to them. > Is there a way i can login and get the code from these without > having the user info? This is a standard Linux recovery scenario. Hook up a serial console and hit a key to go to the U-Boot menu when the board boots. Add "init=/bin/bash" to the kernel command line. You'll boot into an interactive prompt with root permissions and can do anything you need: reset passwords, copy files, etc. -- Charles Steinkuehler char...@steinkuehler.net -- 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/6fc177b3-7124-b457-3ad4-b40179317331%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] How to restore BeagleBoard-X15 to its default image?
On 5/17/2019 6:14 AM, Felicity Lv wrote: > Hello, > > I recently flashed a new eMMC image to the BeagleBoard-x15, later found out > that it's not an image I want. How do I restore the BeagleBoard-X15 to its > original eMMC image? You can get the official images here: http://beagleboard.org/latest-images Note if you want to flash your eMMC (vs. just run off the uSD card) you will need to edit uEnv.txt as described in the text. -- Charles Steinkuehler char...@steinkuehler.net -- 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/33ba1c6b-df1e-e25d-b3e7-0cda5d581240%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] how to reset PRU ?
On 5/14/2019 5:26 PM, jmelson...@gmail.com wrote: > I am using the pruss software to control a PRU program. I have several > test programs that do one part at a time. Now, when I combined the parts, > the PRU program is not completing properly. After this happens, the PRU > will not respond until I reboot the Bone. > > Is there some way to halt and reset the PRU subsystem back to the idle > state, so it can be reloaded and started? > > I tried to make a "kill PRU" program by executing this at the end : > > prussdrv_pru_clear_event (PRU_EVTOUT_0, PRU0_ARM_INTERRUPT); > /* Disable PRU and close memory mapping*/ > prussdrv_pru_disable (PRU_NUM); > prussdrv_exit (); > > But, it didn't seem to do anything. Try: prussdrv_pru_reset() -- Charles Steinkuehler char...@steinkuehler.net -- 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/61c8dbe8-f85e-9691-6555-166d4437860f%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Using Remoteproc and the scratchpad
On 2/27/2019 3:39 AM, captainlightnin...@gmail.com wrote: > > The problem i am walking in to is that there is next to > no explanation on remoteproc or scratchpad. Are there better resources on > these topics? Remoteproc is a standard Linux kernel feature, so start with the kernel's Documentation/ directory: https://www.kernel.org/doc/Documentation/remoteproc.txt The scratchpad is documented quite well in the PRU reference materials, see section 5.2.4: https://github.com/beagleboard/am335x_pru_package/blob/master/am335xPruReferenceGuide.pdf -- Charles Steinkuehler char...@steinkuehler.net -- 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/edb3b596-a4dd-a5ca-9788-aca53beba9c7%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
[beagleboard] MLX90621 Temperature Sensor
In case it's useful for anyone else, I have ported code for the MLX90621 (4x16 pixel remote IR temperature sensor) from the RPi (talks directly to the BCM hardware) to use standard Linux I2C devices (eg: /dev/i2c1) so it works on the 'Bone and other boards with standard Linux I2C support. Tested on a BBB using I2C2 (/dev/i2c1, the cape EEPROM I2C bus), 5.6K pull-up resistors, and a diode-connected transistor to drop the 3.3V rail to the 2.6V preferred by the MLX. Code is on github: https://github.com/cdsteinkuehler/mlxd/tree/linux-i2c -- Charles Steinkuehler char...@steinkuehler.net -- 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/ec6f20fa-8261-48f9-b9d5-696910767461%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: On BBB - How to use I2C-1 ? It exists but maybe needs pins setup ? BBB Rev C & Debian 9
On 2/18/2019 9:21 PM, brucejs...@gmail.com wrote: > It's unclear to me so far why so many I/O pins are shared, creating > exclusions, yet so many other I/O pins are left as simple GPIO. I mean, > can't we have both two I2C and 2 SPI at the same time, all on different > pins ? Use the I2C1 pins on P9.24 and P9.26 and you won't conflict with any SPI pins. Load the universal cape and use config-pin to set the pins to i2c mode. The core chip on the BBB (and just about _every_ non-trivial SoC) has a lot of pin multiplexing to enable more features. The BBB suffers slightly in addition due to the fact that not all pins are available on the P8/P9 headers, further limiting options. A good reference for the pin multiplexing is this spreadsheet (forked from selsinork, I added details on pin usage for various CNC capes): https://github.com/cdsteinkuehler/beaglebone-black-pinmux/blob/hal_pru_generic/pinmux.ods ...and of course the AM335x data-sheet and TRM from TI. It can be frustrating trying to work through the various pin multiplexing options, but it would be a *LOT* more frustrating not having _any_ pinmux options! :) -- Charles Steinkuehler char...@steinkuehler.net -- 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/f08ea9a4-5597-a5b3-6673-58047153c33a%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] BBB clone bringup - won't boot eMMC
On 2/2/2019 11:50 PM, Dave wrote: > > I am guessing that something is wrong with the bootloader on the eMMC > > Does that sound correct ? > > Doesn;t the flasher copy the bootloader from the SDcard ? > > Any ideas how I get this to boot from eMMC without the SDcard ? The flasher scripts will pull the boot loader from the web under some circumstances (see the http_spl and http_uboot variables). I'd recommend manually copying your MLO and u-boot.img to the eMMC. Alternately, you could try using the init flasher script (boot with init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh and set root to be read only). There's a commented line for this in the default uEnv.txt file already. This script might fail if you don't have an EEPROM on your board but if it does you can pretty easily edit the script and comment the call to check_eeprom(). -- Charles Steinkuehler char...@steinkuehler.net -- 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/f6438a04-6e85-a6ab-6eb7-2873ee731e1c%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] HDMI resolution not supported?
On 2/2/2019 11:38 AM, sam.abb...@gmail.com wrote: > Hi, > > I have a beaglebone with which I am having trouble getting an HDMI output > on a 50 inch tv. I am getting HDMI output on 32 inch TV but not on a 50 > inch. It just says resolution not supported. > I have tried forcing different resolutions through uEnv.txt but that did > not work. > > What changes can I make to get HDMI output? Which resolutions did you try? The BBB has a limited pixel clock frequency. The resolutions most likely to work with your TV are 720p (60 Hz) and 1080i (60 frame/30 hz), since HDMI requires one of these resolutions to be supported by any HDMI device capable of HD (per the HDMI 1.4b spec): "An HDMI Sink that accepts 60Hz video formats, and that supports HDTV capability shall support 1280x720p @ 59.94/60Hz or 1920x1080i @ 59.94/60Hz video format timings." If you're lucky, the TV will support 1080p30, which will typically look better than 1080i, but this isn't an HDMI requirement. -- Charles Steinkuehler char...@steinkuehler.net -- 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/f6853a50-2e9d-1e05-1dd8-f09e380cc0a9%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Question regarding Custom Board based on BeagleBone Blac
Typically you have your distributor or assembly house program the parts for you. For low volumes it's possible to program them yourself prior to assembly if you've got the required equipment (a programmer and the proper package adapter). Otherwise, you would typically program things like the on-board eMMC and EEPROM after assembly as part of the production test and burn-in process, using an alternate boot method (eg: uSD, JTAG, USB, serial) that would get enough software running to be able to perform in-system programming. Note that usually the EEPROM is write-protected, so part of the production test fixture physically enables EEPROM writes, typically using a test point or other pad that will be pulled high or low as required. See the various "flasher" uSD images available for an example of how to program the eMMC. Dig in the archives of this group and you'll find several threads on programming the EEPROM (or customizing U-Boot so you don't need the EEPROM). You'll probably also want some sort of script to program things like a unique serial number and MAC address. There are lots of ways to do this, and typically it's handled by the same scripts that are doing any other in-system programming and test/burn-in. On 2/1/2019 11:36 AM, omair.k...@saikosystems.com wrote: > Hi Graham, > > Thank you for the reply. > > Yes, I figured this out about the TPS65217C, but couldn't find a way to > edit my post to remove that part of the question. > > My initial searches didn't turn up anything regarding the 1st question so I > thought it might be faster to get some pointers from others since I'm > working on a tight deadline. > > > > On Friday, February 1, 2019 at 5:43:15 AM UTC-8, gra...@flex-radio.com > wrote: >> >> I think the answers to 1, 2, and 3 have all been asked and answered before >> on this email reflector. >> A little bit of searching for appropriate keywords will get you the >> answers to those. >> >> >> For number 4, you are confusing survival (non-operating) with operating >> conditions. >> Read the footnotes to the "Absolute Maximum Ratings" chart. they are >> important. >> >> If you go outside of the "Recommended Operating Conditions" chart supply >> voltages of 4.3 to 5.8 Volts, the TPS65217C goes into an emergency shutdown >> to protect itself and the CPU. >> So if you want to run from 10 to 15 Volts power, you will need an external >> buck-converter or other step down power supply ahead of the TPS65217 to >> feed it 5 Volts. >> >> --- Graham >> >> == >> >> On Thursday, January 31, 2019 at 12:32:55 PM UTC-6, >> omair...@saikosystems.com wrote: >>> >>> >>> Hello Everyone, >>> >>> I tried to post this yesterday and got a brief "Your discussion has been >>> posted" message, but then later could not find the post, so sorry if it >>> gets double posted. >>> >>> I'm looking into creating a custom board for a client based on the >>> BeagleBoard Black and had a few questions. I will be creating the hardware >>> design and the client will handle all the software requirements. Almost the >>> whole BBB will get replicated, with the exception of the HDMI and perhaps >>> the Ethernet (both of which are not used in their application). Some of >>> these questions are geared towards software, but I want to make sure that >>> all the bases are covered and I can point the clients down the correct path >>> in bringing up the new board. Any feedback from those who have endeavored >>> on this path before is greatly appreciated. >>> >>> >>>1. I understand the BeagleBoards come pre-programmed with a Linux >>>kernel and U-Boot, however, new chips we purchase from the factory will >>> be >>>black. What is the method for first programming of the blank chips? Can >>> it >>>be done via the USB Client port or MicroSD? >>> >>>2. I understand there's an EEPROM on board that contains board >>>identification information, which is used by the Kernel and U-Boot to >>> setup >>>and boot the board correctly. What areas need to be modified to bring up >>> a >>>board that does not contain the EEPROM, or contains a blank EEPROM? >>> >>>3. The SRM mentioned that some of the TPS65217C power rails had been >>>modified to 1.5V instead of 1.8V. Where is this set? I'm guessing this >>> is >>>done in software and somewhat related to question 2. >>> >>>4. Th
Re: [beagleboard] BBB Clone change UART0 to UART4
On 1/29/2019 12:50 AM, Dave wrote:
> The snippet below is in the common dtsi for all am335x boards.
>
> What I am asking is if that snippet is meaningless, or if it has the actual
> effect of switching standard out at some point to uart0 ?
>
> Also what is the simplest way to rebuild the am335x-bone-uboot-univ.dtb ?
> I am not familiar with compiling dtb's in the linux kernel tree.
> Those have an assortment of includes.
> I am used to compiling standalone dts/dtb's
>
> Is there a
>
> make dtb
>
> that will build the dtb for the current .config device ?
It's "make dtbs", or you can specify the specific dtb you want to build:
https://www.lynxbee.com/how-to-compile-dts-to-dtb-from-linux-kernel-and-manually/
> chosen {
> stdout-path =
> };
That could be causing your problems, and it almost certainly wouldn't
hurt to change it:
https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
--
Charles Steinkuehler
char...@steinkuehler.net
--
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/91d36379-248f-2c51-645b-56ae6fc0633c%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] BBB Clone change UART0 to UART4
On 1/29/2019 12:58 AM, Dave wrote: > I am trapping serial output on BOTH the target board and a BBB booting the > SAME SD card, with the only difference being the setting of init_console. > After each has run as far as it will - in the case of the BBB I get a login > prompt. I don't think this is an "apples to apples" test. I haven't crawled into the low-level differences between the BBB and the Octavo SIP, but I _think_ at least the DRAM settings are different. Do you have a Pocket Beagle or one of the other Octavo boards handy for testing? Are you sure U-Boot is patched to handle your EEPROM-less board? That said, if you were having SDRAM timing issues I'd expect the kernel to crash and I wouldn't expect the failure to be so consistent with USR LEDs still blinking. So I wouldn't chase SDRAM issues right away, but just keep in mind that might be part of your problems. > I vimdiff the serial output captures. > > On the BBB I get alot of console output from the end of all the eqep driver > setup through the login prompt. > On the target all serial output stops with the eqep output - but the LEDS > continue to be active. > As they are soft - something is still executing See if adding a getty for UART4 gets you a login prompt. You don't really need the kernel console if you can login, and with the USR LEDs blinking it sounds like the system is probably still running. -- Charles Steinkuehler char...@steinkuehler.net -- 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/c85e26a1-231a-8d0b-f173-79614a236079%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] BBB Clone change UART0 to UART4
On 1/28/2019 12:33 PM, Dave wrote: > Thank you; > > Changing init_console did the trick. > > I am now getting console output while booting into linux - For a while. > > Unfortunately instantly after the Linux eqep Linux Printk's console IO > ceases. > > It appears the board is still doing something - as the USR0 and USR2 LED's > are active, > > I tried installing a significantly more minimalist kernel in the event that > it was stalled dealing with some sub critical hardware. > > Is it possible that a setting in the Device Tree is re-directing the > console ? The device-tree doesn't affect the kernel console settings AFAIK. Did you change the getty login console in your root filesystem as well as the kernel console setting in U-Boot? You may just be seeing the end of the kernel output and no login prompt (if you're really lucky). > Is there an absolute bare minimum BBB Linux configuration that has pretty > close to nothing critical except the console enabled ? > I can add things back in until I figure out what is failing. I'm not sure if there's a pre-existing config file floating around, but you can definitely disable most of the AM335x specific drivers if you think they're causing problems. Can you provide the whole serial console boot log? Other eyes might spot something wrong. Also, any chance you can try booting your custom uSD on known good hardware (eg: some other Octavo based board)? That might help isolate what's going wrong. ...and then there's always the JTAG cable! :) -- Charles Steinkuehler char...@steinkuehler.net -- 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/3a950a18-1a3c-6fcb-660c-414b929cc4f6%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] BBB Clone change UART0 to UART4
On 1/24/2019 1:10 AM, Dave wrote: > The BBB Clone board I am trying to get working has had sufficient work that > it is now trying to load Linux. > > I have u-boot patched to use UART4 as the console. I have tried to make > changes to pass UART4 to linux as the console, without success. > > I still get > > debug: [console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 > root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M > net.ifnames=0] ... > > from uboot on UART4 just before starting the kernel when I lose output > > Where is the console getting set to ttyO0 ? Probably the U-Boot default environment. Hit a key at the U-Boot "countdown" prompt and dump the environment: > printenv You can follow along from the "boot" entry until you get to the point where the kernel command line is being set. Edit that entry (editenv) to use UART4 and then boot from the prompt. Depending on your U-Boot, the default environment may be compiled in, stored raw on the uSD, or in something like the uEnv.txt file. -- Charles Steinkuehler char...@steinkuehler.net -- 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/e500a060-539b-c968-b919-1808cbbbd24d%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Booting BBB Clone
On 1/17/2019 4:34 AM, 'Mark Lazarewicz' via BeagleBoard wrote: > I'm a retired low level SW engineer mostly for RTOS and barebones. If you are > low level capable/board bring up SW in the interview alarm bells would be > screaming. From your last question I'm confused BBB minimal example why? You > said they expect you to get work done on BB white.This deadline story smells > like you were setup I hope this is a $100 hour contract not some 2 month > permanent job.Don't fight the HW guy but if he isn't willing to help you get > correct DDR timing values for HW if the bonehead didn't use exact HW as > reference you may be working 80 hrs a week free if its not a contract job. > In the year since I last used this on omap 17x Its been deprecated. > http://www.ti.com/tool/STARTERWARE-SITARA > > good luckI have no idea what you plan on doing with this.You say you have > extensive linux experience in what apps? If so I'd plan an exit plan +1 on using starter-ware as a reference for low-level configuration, but with any luck you won't have to dig that deep into the guts of things. The U-Boot code is already doing low-level hardware configuration, you just need to tweak things a bit. There are already functions available to setup the various UARTs and I2C. I think you should be able to modify the SPL code (which is trying to read the EEPROM and properly setup the SDRAM, among other things) to provide some externally visible output. NOTE: Since your board is based on the Octavio part, at least you don't have to worry about the DRAM bus timings or trace routes being messed up. I think if you can get your code running (double-check all boot mode pins) and hard-code the EEPROM auto-detect, you should be able to get running. #FingersCrossed -- Charles Steinkuehler char...@steinkuehler.net -- 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/e713d993-e083-8f85-de4f-cc85e0ae7d2c%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Booting BBB Clone
On 1/15/2019 2:34 AM, Dave wrote: > > I followed these instructions > > and additionally set > CONFIG_CONS_INDEX=4 in the defconfig. > > Held the boot button and cycled the power. > > The USR0 LED did not come up. > > Can I presume there is a more significant issue than that the eeprom is > blank ? > > https://octavosystems.com/forums/topic/osd3358-boot/ I don't know enough about the BBB U-Boot to say for sure, but given the issues you're having, I'd try to isolate what's wrong as early as possible: 1) Verify your boot loader is actually running by toggling a GPIO or perform some other externally visible activity *IMMEDIATELY* after the boot loader code is launched. In other words, in the MLO code, before things like SDRAM are available. 2) Once you know you can actually run code, verify the SDRAM is being properly initialized and can be successfully accessed. You can likely use one of the other UART ports for some diagnostics here, but toggling GPIO pins or LEDs for status is always a fall-back. 3) Make sure the interface to whatever storage you're using (uSD card?) is actually working. 4) At this point, you should be able to proceed with development mostly as normal until you get the boot loader working properly and/or figure out what's wrong with the board (other than the missing EEPROM). ...or you could just try debugging from reset using JTAG, but I'm a hardware guy so I tend to shy away from most of the SW debugging tools. Unless I'm really desperate, they tend to take more time for me to setup than they save in debugging. But if you're already working in an environment that supports the JTAG debugger, this might be easier for you. Also, if you've got schematics, double-check the settings on the boot pins, both in the schematic and on the physical board. There should be pull-up and/or pull-down resistors to set the mode. If there were issues populating the board, that could be messing with your intended boot mode and you'll never get anything to work. Good luck! -- Charles Steinkuehler char...@steinkuehler.net -- 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/8827783b-b5c3-b3aa-5825-efae858be656%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Booting BBB Clone
I design hardware for a living. You need to throw this back at the hardware designer and have him/her present you with a workable board. They took a SIP designed to take all the hard work out of making a BeagleBoard clone and managed to mess things up enough so that it won't boot and you can't even tell how. At the very least, I would insist on having them wire up UART0 so you can have a console. Unless they royally f**ked up the PCB layout, this should be possible by soldering a few "flying wires" to some via pads. If they didn't fanout all the SIP pads to vias, you have my permission to shoot them! :) Best of luck! ...and if you don't want to get confrontational with the HW guys, you should be able to fairly easily compile U-Boot to use a different serial port. That ought to get you any console info printed except for the character(s) printed by the actual ROM boot loader. And once you have console output, debugging gets a *LOT* easier. :) On 1/14/2019 5:06 PM, Dave wrote: > I have been searching arround all day and gathering more information. > > The "Clone" board appears to be an Octavo SIP and is partly patterned after > an PocketBeagle. > There is also a display similar to that of the BB 4.3 Cape. > The SIP eeprom is unlikely programmed, there is no eeprom to tell linux > about the display. UART0 is not accessible, and there is no networking - > beyond g_ether. > > Even if I resolve the SIP eeprom - the display is not going to come up, and > I am not going to have a serial console and I am not going to have network > access to the board. > > And at this point I do not actually know that the board is good. > > To me that means I really need to rebuild u-boot - and assign the console > to one of the other uarts. > I might as well at the same time address the SIP eeprom. > > This board has a USB A and a USB B connector, so I can for development > purposes attach a USB NIC to gain network access to the board. > But I still probably need the serial console until I have the net fully > configured. > > I pulled your "Bootloader-Builder" Github repository as there was a patch > there to address the eeprom issue. > > But just running build.sh ran for hours, failed, and is probably not what I > wanted. > > I commented out most of the builds at the end of build.sh. > > I am guessing that I want am335x_bone_flasher enabled. > But I also want to enable a patch to assume a pocketbeagle > as well as to change UART0. -- Charles Steinkuehler char...@steinkuehler.net -- 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/e79d25e7-b910-e5c3-3f2c-72fa675d617f%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Are PRUs really deterministic, and well documented, ant not obsolete...
You can only do no-jitter bit-banging if you use the PRU direct outputs, and those are unique to each PRU core so there is no possibility for contention between the PRU cores for access. Any access to the standard GPIO registers will always have some jitter, as the write transactions from the PRU have to cross the on-chip interconnect fabric and transition to a separate clock domain. That said, the jitter is typically very low (5-10 nS) and is unlikely to be a significant problem. The very significant jitter seen when accessing the GPIO registers with the ARM core is related more to task scheduling and operating system effects than the low-level bus transactions to the GIPO registers, and does not exist on the PRUs. On 1/9/2019 3:06 AM, ithinu wrote: > So it means that I can do no-jitter bit banging if only one PRU accesses > the GPIO, and if the unit does not use any shared resources? That would be > great. > > On Tuesday, January 8, 2019 at 10:43:36 PM UTC+1, Charles Steinkuehler > wrote: >> >> The PRUs are mostly deterministic when accessing resources within the >> local PRU-ICSS block. The "mostly" comes from potential contentions >> if you have both PRU cores accessing the same resource (eg: PRU0 and >> PRU1 both trying to access the local UART) in which case one of the >> PRU cores will stall briefly. >> >> The PRUs are less deterministic when accessing resources outside the >> PRI-ICSS block (eg: SDRAM or GPIO registers) where the transaction is >> subject to synchronization delays, bus congestion on the L3/L4 >> interconnect, etc. >> >> On 1/8/2019 6:48 AM, daveyj...@gmail.com wrote: >>> Hi, I have read this nice ad for PRUs >>> http://www.staroceans.org/documents/TI-sdk/spry264.pdf which states how >>> deterministic the PRUs are, >>> >>> "*each PRU has its own single-cycle I/O*" etc. Then I wanted details... >>> >>> http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit >> "Content >>> is* no longer maintained and is being kept for reference only!* " >>> >>> http://processors.wiki.ti.com/index.php/PRU-ICSS "Please note as of >>> Wednesday, August 15th, 2018 this wiki *has been set to read only*." >>> >>> http://processors.wiki.ti.com/index.php/PRU_Read_Latencies "The PRU >> write >>> instruction is a fire-and-forget command that executes in *~*1 cycle" >>> >>> *that tilde...* >>> >>> >>> "The read latency values at the following links are *considered* >>> "best-case," accounting for the 2 cycle instruction and interconnect >>> introduced *latency*". >>> >>> *best case* >>> >>> Possibly, there is some doc which states min/max execution times? >>> Deterministic or not? etc, etc. >>> *Not found. Just not found.* >>> >>> --- >>> >>> I do not want to be pessimistic but neither I want to >> reverse-engineer >>> these "deteministic" units, that do not really look that-deterministic. >> And >>> that docs obsolete or missing??? What is it all about? >>> >>> >>> >>> >> >> >> -- >> Charles Steinkuehler >> cha...@steinkuehler.net >> > -- Charles Steinkuehler char...@steinkuehler.net -- 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/67079519-549d-ec77-6e8b-484caf77c6f2%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Are PRUs really deterministic, and well documented, ant not obsolete...
The PRUs are mostly deterministic when accessing resources within the local PRU-ICSS block. The "mostly" comes from potential contentions if you have both PRU cores accessing the same resource (eg: PRU0 and PRU1 both trying to access the local UART) in which case one of the PRU cores will stall briefly. The PRUs are less deterministic when accessing resources outside the PRI-ICSS block (eg: SDRAM or GPIO registers) where the transaction is subject to synchronization delays, bus congestion on the L3/L4 interconnect, etc. On 1/8/2019 6:48 AM, daveyjohn...@gmail.com wrote: > Hi, I have read this nice ad for PRUs > http://www.staroceans.org/documents/TI-sdk/spry264.pdf which states how > deterministic the PRUs are, > > "*each PRU has its own single-cycle I/O*" etc. Then I wanted details... > > http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit "Content > is* no longer maintained and is being kept for reference only!* " > > http://processors.wiki.ti.com/index.php/PRU-ICSS "Please note as of > Wednesday, August 15th, 2018 this wiki *has been set to read only*." > > http://processors.wiki.ti.com/index.php/PRU_Read_Latencies "The PRU write > instruction is a fire-and-forget command that executes in *~*1 cycle" > > *that tilde...* > > > "The read latency values at the following links are *considered* > "best-case," accounting for the 2 cycle instruction and interconnect > introduced *latency*". > > *best case* > > Possibly, there is some doc which states min/max execution times? > Deterministic or not? etc, etc. > *Not found. Just not found.* > > --- > > I do not want to be pessimistic but neither I want to reverse-engineer > these "deteministic" units, that do not really look that-deterministic. And > that docs obsolete or missing??? What is it all about? > > > > -- Charles Steinkuehler char...@steinkuehler.net -- 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/7a070ff0-e452-5181-293f-c6913d750b3d%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Flashing Beaglebone with a custom image problem
On 1/5/2019 11:07 AM, Pablo999 wrote: > > I am using Yocto to generate a customized Linux version for my BeagleBone > board. > > I can flash this image to the internal emmc on the board via an external SD > card and it runs fine. In order to flash it, I hold down the boot button > when the board boots up, which flashes the image from the SD card onto the > internal emmc memory. > > The one problem however I have now is that if I want to re-flash another > custom image after this onto the board the same way, it doesn't work unless > I *first* flash a default Debian image for the BeagleBone (provided on the > BeagleBone site). > > Would anyone know why this is, or have some way to try to solve it? It's probably an issue with the boot loader. Hook up a serial console to see what's going on. Pause U-Boot when prompted (hit a key) and dump the environment (printenv). > My understanding is that the ROM bootlader provided by TI is the very first > thing to get executed when the board starts and this code never changes. > This ROM bootlader checks if the boot button is pressed and decides where > to boot from. > > Why would it make a difference which kernel version is currently flashed on > the board, and why is it only working when a default Debian image is loaded > on there first and not my customized Yocto image? Many thanks in advance > for any help. The kernel version shouldn't matter, but the BBB boot loaders have at various times been setup to look for files like uEnv.txt in various places. I suspect the U-Boot installed on the uSD is seeing something on the programmed eMMC that it doesn't like and/or breaks the boot sequence. -- Charles Steinkuehler char...@steinkuehler.net -- 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/13b2fe1e-e3f5-c21d-3cbb-bb21cdda020e%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Problem with validity of data written to reserved memory by pru
Did you flag the reserved memory as non-cachable? If not, add the "no-map" property to your device tree node, or otherwise manage the cache (which typically requires root permissions and kernel mode code): https://www.kernel.org/doc/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt On 12/28/2018 11:49 PM, dehghania...@gmail.com wrote: > Hello. I have a problem with writing data to reserved memory by PRU in > BeagleBone Black. > Reserving memory is done through device tree "reserved-memory" node. The > memory is reserved correctly and I can see the gap in the System Ram in > "/proc/iomem" file. > I want PRU to write data items to the reserved memory and an user-space C > program running on Linux will read these data items. > The problem is that some of the data items have not written to the reserved > memory correctly. For example, if I write 100 integer numbers to the > reserved memory, the numbers between 39 and 47 will not be written > correctly while the other integers are written correctly. In other words, > when I read the integer numbers from the reserved memory, all the integer > numbers are correct, but numbers in the rage 40 to 62 are not correct. > > [image: reserved_memory_problem.jpg] > In the above picture, numbers in the left column are the indexes of data in > the reserved memory and numbers in the right column are the values of data > items stored in the reserved memory. All values are correct but values in > the range 39 to 47 are not correct. The contents of reserved memory are > read using "devmem2". > > Does anyone know why that chunk of data (39 to 47) is not written correctly > by the PRU? > -- Charles Steinkuehler char...@steinkuehler.net -- 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/13e894b3-47ce-7ced-748c-540402ecb7cb%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Can't get SPI data up to 10 MHz - PRU
As mentioned, you can't really tell what a compiler is going to turn
your C code into. As you discovered, the v2 code that is actually more
suited to the PRU low-level assembly instructions turns into worse
assembly because of the compiler. I suspect you have at least two
problems with your code:
1) You are on the edge of having enough time to capture all the clocks
even with the "better" assembly produced by v1 of the C code.
2) You may be encountering problems with noise or metastability with
your code which looks for the clock edges. It's not at all uncommon to
have an occasional glitch which could be why the v1 code isn't working
reliably.
I *HIGHLY* recommend you code this in assembly, and add a small bit of
filtering to the clock signal (eg: require the clock signal to be the
same for two or more clocks before detecting the edge).
On 12/8/2018 3:11 PM, Fred Gomes wrote:
Hi Charles, thank you very much for your answer,
I followed your advice but something overly odd is happening.
First of all, let me contextualize you: the image sensor is always
sending data through the CS, SCLK, and MOSI pins. The delay between each
frame is about 10 ms. That said, I wrote the code in attachment
"prog_pru_v1". In the first stage, I test it using the another PRU from
beagle bone. So, I send some clocks from PRU 1 and count them on the
PRU1; here I checked that the PRU can get all the pulses up to a
frequency clock of 20 MHz (I only need 10 MHz). The problem comes when I
shortened the delay time between frames, it stops catching all the
clocks (in fact, it catches very few clocks) and I don't understand the
reason since it should be in a loop (between the variation edges from
the CS pin.
The other problem I did (prog_pru_v2.c) seems to work a bit better. It
sometimes catches all the clocks from the sensor and fails another
times. Surprisingly, the assembly code seems to be much uncluttered on
this code.
I can't understand why is this happening, it doesn't seem to have much
sense. I validate the code successfully, but the problem comes when I
start sending much data spaced about 10 ms!
Find attached the code programs mentioned above, both the .c code and
assembly.
Let me know if you have any other suggestion I should test,
Bets regards,
-- Fred Gomes
Charles Steinkuehler <mailto:char...@steinkuehler.net>> escreveu no dia sexta, 7/12/2018 à(s)
13:47:
On 12/7/2018 3:52 AM, Fred Gomes wrote:
>
> Here's the code where I got the better results:
>
> while(__R31); // CS = 1
>
> while(__R31){ //sclk = 1
>
> if(__R31){
> goto END;}
> }
> while(!(__R31)); //SCLK = 0
> var = (__R31)? var |(0x01 << shift): var;
>
> k++;
> shift--;
>
> if(shift == -1){
> *(buffer_shared + cnt) = var;
> cnt++;
> shift=31;
> var = 0;
> }
> END:
> *(buffer_shared+2600) = k; // Here I am storing the value of the
counter,
> to check if all the clocks wre catched.
>
> I have only one small problem though, the sensor is sending data
every
> time, and sometimes it catches more than one frame. I don't
> understand quite well why is it happening since the time between
frames is
> about 10 ms, and in that why it is difficult to have sure that I
haven't
> miss clocks in the frame. So, to have sure I am not missing
clocks I add
> the following line:
>
> LABEL:
> if(k==79184)
> goto END;
>
> And I noticed that sometimes I miss one clock (although here I am
> introducing one extra instruction, which will make the program a
bit slow).
> If you have any suggestion I should implement to tackle this problem,
> please let me know ...
Again, please either write in assembly or post the assembly listing
the compiler is generating. You have 12 lines of C code above, and
that doesn't even look like the entire loop (just the inner loop for
one 32-bit word). As mentioned previously, you have time for about 20
PRU assembly instructions, which isn't many for 12 lines of C.
Without the full code and seeing the assembly your compiler is
generating, I can only make a few suggestions. An optimizing compiler
would probably do much of this for you, but it doesn't sound like your
compiler is doing much optimization (again, let's see some listing
files!):
* Get rid of the count variable and create a dedicated buffer pointer,
then increment that, ie:
*(buffer_shared + cnt) = var;
cnt++;
...turns into:
// Initial setup
uint32_t *buffer_ptr = buffer_shared
// ...other code goes here...
*(buffer_ptr) = var;
buffer_ptr++;
*
Re: [beagleboard] PRU Internal clock
On 12/7/2018 11:16 AM, alanmthomason via BeagleBoard wrote: > I use the BeagleBone Black PRU for a very time critical task. I currently > have registers that increment based on how many instructions I have just > run and their type (SBBO's for instance take more than the usual 1 clock > cycle per instruction) so that I can keep track of time. I have seen > somewhere that you can reset and read an internal clock on the BBB PRUs, > but I just can't seem to find that again. > > Has anyone used this feature, and if so can you guide me on how to go about > reading and resetting? There's the Industrial Ethernet Peripheral, mentioned by Bill which includes support for 8 timers. In addition, there is an ECAP module within the PRU fabric (separate from the other BBB ECAP timer modules). But I think you may be thinking of the Cycle/Stall registers. You can enable the cycle count register in the Ctrl register (CTR_EN bit), and you can clear the cycle count when the counter is disabled, if desired. -- Charles Steinkuehler char...@steinkuehler.net -- 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/47b45a80-72b1-65a1-6eb1-f6db633c69f6%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Can't get SPI data up to 10 MHz - PRU
On 12/7/2018 3:52 AM, Fred Gomes wrote:
>
> Here's the code where I got the better results:
>
> while(__R31); // CS = 1
>
> while(__R31){ //sclk = 1
>
> if(__R31){
> goto END;}
> }
> while(!(__R31)); //SCLK = 0
> var = (__R31)? var |(0x01 << shift): var;
>
> k++;
> shift--;
>
> if(shift == -1){
> *(buffer_shared + cnt) = var;
> cnt++;
> shift=31;
> var = 0;
> }
> END:
> *(buffer_shared+2600) = k; // Here I am storing the value of the counter,
> to check if all the clocks wre catched.
>
> I have only one small problem though, the sensor is sending data every
> time, and sometimes it catches more than one frame. I don't
> understand quite well why is it happening since the time between frames is
> about 10 ms, and in that why it is difficult to have sure that I haven't
> miss clocks in the frame. So, to have sure I am not missing clocks I add
> the following line:
>
> LABEL:
> if(k==79184)
> goto END;
>
> And I noticed that sometimes I miss one clock (although here I am
> introducing one extra instruction, which will make the program a bit slow).
> If you have any suggestion I should implement to tackle this problem,
> please let me know ...
Again, please either write in assembly or post the assembly listing
the compiler is generating. You have 12 lines of C code above, and
that doesn't even look like the entire loop (just the inner loop for
one 32-bit word). As mentioned previously, you have time for about 20
PRU assembly instructions, which isn't many for 12 lines of C.
Without the full code and seeing the assembly your compiler is
generating, I can only make a few suggestions. An optimizing compiler
would probably do much of this for you, but it doesn't sound like your
compiler is doing much optimization (again, let's see some listing
files!):
* Get rid of the count variable and create a dedicated buffer pointer,
then increment that, ie:
*(buffer_shared + cnt) = var;
cnt++;
...turns into:
// Initial setup
uint32_t *buffer_ptr = buffer_shared
// ...other code goes here...
*(buffer_ptr) = var;
buffer_ptr++;
* Review the generated code for the var update. The PRU has lots of
bit test and shift instructions, so changing this calculation slightly
could reduce the number of instructions needed. If I was writing in
assembly I would shift var first then conditionally or in a '1'
depending on the state of the input pin. In C it would look like this
(but I don't know if this will generate the actual assembly I'm
thinking of, it depends on your compiler):
var >>= 1;
if (__R31) var |= 0x8000;
* Review the code generated for the various bit test instructions (eg:
__R31 & ). These should be a single bit test instruction in PRU
assembly, but that may not be what the compiler is generating.
There are other "tricks" you can try (eg: get rid of the shift count
and use a bit in var instead). Without being able to see the
generated assembly you can easily wind up making things much worse,
but you can try it if you like. Make sure to initialize var to 0x8000
and set the buffer_ptr value in your setup code:
while(!(__R31)); //SCLK = 0
k++; // I assume this is needed outside the loop
// 1 in the LSB means this is the last bit of our 32-bit word
if (var & 0x01)
{
// Shift in the last bit
var >>= 1;
if (__R31) var |= 0x8000;
// Store the value
*(buffer_ptr) = var;
// Setup for the next word
buffer_ptr++;
var = 0x8000;
} else {
// Shift in the next bit
var >>= 1;
if (__R31) var |= 0x8000;
}
--
Charles Steinkuehler
char...@steinkuehler.net
--
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/95d14956-6dad-f1c4-fe34-7074cb4e926d%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Compiling Out of Tree Driver with Different Version of Toolchain Than was Used to Compile Kernel
On 12/6/2018 1:59 PM, Jeff Andich wrote: > Hi, > > General question. > > Is it valid to cross compile an out of tree driver with a different version > of the cross compiler/toolchain than the kernel was compiled with? If not, > where do you draw the line? > > Recently we re-compiled an out of tree WiFi driver for the BBB on a PC host > machine, pointing it at the kernel source tree with all of the build > products/generated files in it. The kernel was built with the 6.4.x Linaro > toolchain, however the developer built the WiFi driver with the Linaro 5.4 > toolchain. The developer was able to deploy the WiFi driver to the target, > and it worked just fine. > > I mentioned to the developer that, in general, it's probably safer to use > the same brand and version of the cross toolchain to build the driver and > kernel, but now I'm so sure that this has to be the case. For instance, If > the function call interface is standard for all versions of the Linaro > toolchain, then maybe this doesn't matter. However, if version 4.x uses > one set of registers to pass function parameters to a driver, for instance, > and the driver is compiled with a different version of the compiler which > expects the parameters to be passed in a different set of registers, then > there would be an issue. > > What's the rule of thumb here or what's a good reference to better > understand the interfaces? What you mentioned (register use and parameter passing) is known as calling conventions, which are part of the full ABI (Application Binary Interface) which specifies those and other details of the target platform: https://en.wikipedia.org/wiki/Application_binary_interface As long as the ABI is compatible, you should be able to compile kernel modules using whatever compiler you want. There are lots of different ABIs for the ARM platform because there are a wide range of CPUs with different features (eg: hard floating point, NEON support, thumb instructions, etc). That's why you wind up with long lists of cross-compiler tool chain variants, eg: https://releases.linaro.org/components/toolchain/binaries/latest-7/ -- Charles Steinkuehler char...@steinkuehler.net -- 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/64a4c107-f9e9-56f6-1e8e-acbfaca71677%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Can't get SPI data up to 10 MHz - PRU
Try writing in assembly, or at least providing a listing of the PRU
code your compiler is generating. The C code you've written could
turn into very ugly assembly with a lot of memory reads (which are
*VERY* expensive on the PRU) depending on the compiler.
In general, for speed you only want the PRU to write to your buffer[]
memory region, you should never read from it. So use a local variable
to build a 32-bit word and then write that into the buffer[] memory
instead of bit-wise oring the data piece-meal into your buffer[].
If you need to maintain a rate of 10 MHz, you only have 20 assembly
instructions per bit, which isn't many when you're trying to code in C.
On 12/4/2018 3:30 AM, Fred Gomes wrote:
> I've forgotten to mention. I am sending the clocks from the PRU 1 to PRU 0
> at this time. So I know exactly how many clocks there is and the frequency.
> The objective is to plug the sensor which I want to read the data after
> having this working .
>
> -- Fred Gomes
>
>
> escreveu no dia terça, 4/12/2018 à(s) 09:25:
>
>> Hi, I need your help,
>>
>> I need to read data of an SPI Master device on the BeagleBone. Since the
>> SPI kernel driver doesn't support an SPI slave mode I have to implement it
>> in the PRU (Because the maximum frequency one BeagleBone's GPIO can be
>> toggle is only 15 KHz).
>> From what I have read, the PRU cycle time is 200 MHz, even so, I can't
>> read data up to 10 MHz. I am doing the following:
>>
>>
>>
>> k=0;
>> shift = 0;
>>
>> while((__R31) != cs){ // CS = 0
>> while((__R31) == sclk);
>> while((__R31) == sclk){ //sclk = 1
>>
>> if((__R31) == cs)
>> goto END;
>> }
>> while((__R31) != sclk); //SCLK = 0
>> buffer[cnt] = ((__R31) == miso)? buffer[cnt] | 0x01 << shift:
>> buffer[cnt]; // Here is where my cycle is being stranded!!!
>> k++;
>> shift = (shift==32)? 0 : shift + 1;
>> cnt = ((k%32)==0)? cnt+1 : cnt;
>>
>> If I comment on the reading line, I can't catch clocks at 20 MHz. However,
>> if a uncomment it I only can get all of them at 9 MHz (I need 10 MHz). My
>> question is if it is possible to get it a bit faster. I can't understand
>> why it is so slow (given that the PRU is a real-time processor and has
>> a high speed between instructions).
>>
>> Regards,
>> -- Fred Gomes
>>
>> --
>> 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/Vtw23FneFLk/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/d8ea84f9-cb22-47bd-89ac-328214ded03e%40googlegroups.com
>> <https://groups.google.com/d/msgid/beagleboard/d8ea84f9-cb22-47bd-89ac-328214ded03e%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
--
Charles Steinkuehler
char...@steinkuehler.net
--
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/15bfe150-751b-17a2-da72-2a7ea91d0929%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] How to use "reserved-memory" in device tree to reserve DDR memory?
Glad you got it working! It seems like the beginning and end of the memory region are "special cases", so I usually reserve memory at the middle of the available range. As long as the reserved memory region starts and ends on page boundaries it won'pretty much t matter at all from a performance standpoint what the absolute address is. On 12/2/2018 2:27 PM, Ken Shirriff wrote: > Thanks for the replies, Charles. I figured out the problem. The dts > <https://git.ti.com/apps/tida01555/blobs/master/dts/am335x-boneblack-pruadc.dts> > > I was using tried to reserve 256K at 0x9ffc. However, system RAM ends > at 9fdf, which is earlier, so the reservation never showed up in the > RAM numbers. (I'm unclear what's in that last 2 meg of RAM, and if it's > okay to reserve part of it.) > > I changed the range to start at 0x9000 and now it shows up as a change > when running "free". As well, the reserved memory hole is nicely visible in > /proc/iomem: > # grep RAM /proc/iomem > 8000-8fff : System RAM > 9004-9fdf : System RAM > > So I think everything is working with memory reservation now. > > Ken > > On Sunday, December 2, 2018 at 10:59:09 AM UTC-8, Charles Steinkuehler > wrote: >> >> On 12/2/2018 12:22 PM, Ken Shirriff wrote: >>> >>> I also tried increasing the amount of reserved memory from 256K to 4M >> and >>> didn't see any change. I increased the size way beyond physical memory, >> and >>> didn't get any errors. So I suspect it is being ignored. Do I need a >> kernel >>> flag or something to reserve memory? >> >> No. >> >>> So, is there any way to verify that the memory is getting reserved? (I >>> suspect nothing is reserved, so I would be writing to random memory if I >>> tried to use the buffer.) >> >> Other than noticing the reduced amount of free ram, I don't think the >> reserved memory regions show up until/unless they are requested by a >> kernel driver. >> >>> Ken >>> >>> [1]: I got the reserved-memory to load two ways. I figured out that I >> need >>> to use target-path = "/"; in the dtc file so it gets loaded under the >> root >>> node. Next, in case reserved-memory didn't work as an overlay, I edited >>> am335x-bone-common.dtsi under /opt/source/dtb-4.14-ti. >> >> There's likely an issue in your device tree. Make sure your entries >> are showing up under /sys: >> >> $ find /sys/firmware/devicetree/base/reserved-memory/ -type f >> /sys/firmware/devicetree/base/reserved-memory/ranges >> /sys/firmware/devicetree/base/reserved-memory/#address-cells >> /sys/firmware/devicetree/base/reserved-memory/#size-cells >> /sys/firmware/devicetree/base/reserved-memory/NewTek_Reserved/reg >> /sys/firmware/devicetree/base/reserved-memory/NewTek_Reserved/name >> /sys/firmware/devicetree/base/reserved-memory/NewTek_Video/reg >> /sys/firmware/devicetree/base/reserved-memory/NewTek_Video/name >> /sys/firmware/devicetree/base/reserved-memory/name >> >> ~$ hd /sys/firmware/devicetree/base/reserved-memory/NewTek_Reserved/reg >> 18 00 00 00 08 00 00 00 || >> 0008 >> >> NOTES: >> * This is from a Zynq (not a BBB), but it should match if you're using >> a recent 4.x kernel. >> >> * The names should match whatever you have in device-tree >> >> * The values in the "reg" file are in wacky device-tree byte order, >> the hex dump above corresponds to a "reg = <0x1800 0x0800>;" >> entry in the device-tree. >> >> * You don't need the status="okay"; entries in your node >> >> * Don't use overlays and put the reserved-memory node at the root of >> the device-tree (I think you already figured this out). >> >> * Double (and then triple) check for typos! >> >> * Note that just because something shows up in the "live" device tree >> (under /sys/firmware/devicetree/base/) doesn't mean the kernel did >> anything with it. If you misspell "reserved-memory" for instance, >> your node will show up in the device tree, but you won't have actually >> reserved any memory. The kernel doesn't complain about unknown or >> unexpected elements in the device-tree. >> >> -- >> Charles Steinkuehler >> cha...@steinkuehler.net >> > -- Charles Steinkuehler char...@steinkuehler.net -- 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/4f37bc1b-7918-2f0f-30f3-f68f4a2caa81%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] How to use "reserved-memory" in device tree to reserve DDR memory?
On 12/2/2018 12:22 PM, Ken Shirriff wrote: > > I also tried increasing the amount of reserved memory from 256K to 4M and > didn't see any change. I increased the size way beyond physical memory, and > didn't get any errors. So I suspect it is being ignored. Do I need a kernel > flag or something to reserve memory? No. > So, is there any way to verify that the memory is getting reserved? (I > suspect nothing is reserved, so I would be writing to random memory if I > tried to use the buffer.) Other than noticing the reduced amount of free ram, I don't think the reserved memory regions show up until/unless they are requested by a kernel driver. > Ken > > [1]: I got the reserved-memory to load two ways. I figured out that I need > to use target-path = "/"; in the dtc file so it gets loaded under the root > node. Next, in case reserved-memory didn't work as an overlay, I edited > am335x-bone-common.dtsi under /opt/source/dtb-4.14-ti. There's likely an issue in your device tree. Make sure your entries are showing up under /sys: $ find /sys/firmware/devicetree/base/reserved-memory/ -type f /sys/firmware/devicetree/base/reserved-memory/ranges /sys/firmware/devicetree/base/reserved-memory/#address-cells /sys/firmware/devicetree/base/reserved-memory/#size-cells /sys/firmware/devicetree/base/reserved-memory/NewTek_Reserved/reg /sys/firmware/devicetree/base/reserved-memory/NewTek_Reserved/name /sys/firmware/devicetree/base/reserved-memory/NewTek_Video/reg /sys/firmware/devicetree/base/reserved-memory/NewTek_Video/name /sys/firmware/devicetree/base/reserved-memory/name ~$ hd /sys/firmware/devicetree/base/reserved-memory/NewTek_Reserved/reg 18 00 00 00 08 00 00 00 || 0008 NOTES: * This is from a Zynq (not a BBB), but it should match if you're using a recent 4.x kernel. * The names should match whatever you have in device-tree * The values in the "reg" file are in wacky device-tree byte order, the hex dump above corresponds to a "reg = <0x1800 0x0800>;" entry in the device-tree. * You don't need the status="okay"; entries in your node * Don't use overlays and put the reserved-memory node at the root of the device-tree (I think you already figured this out). * Double (and then triple) check for typos! * Note that just because something shows up in the "live" device tree (under /sys/firmware/devicetree/base/) doesn't mean the kernel did anything with it. If you misspell "reserved-memory" for instance, your node will show up in the device tree, but you won't have actually reserved any memory. The kernel doesn't complain about unknown or unexpected elements in the device-tree. -- Charles Steinkuehler char...@steinkuehler.net -- 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/ec864a51-c521-3622-dbd8-6dd9c41b4b50%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] How to use "reserved-memory" in device tree to reserve DDR memory?
The reserved memory ranges don't really show up in the boot logs.
Check the "Memory:" line early in the kernel boot messages if you've
got a serial console, or you can run "free" to see the amount of
system memory available. It should be reduced by the amount you reserved.
On 12/1/2018 11:56 PM, Ken Shirriff wrote:
> I'm trying to do exactly the same thing as Gaurav and I found this thread.
>
> First, I ran into the same problem as Gaurav that the beaglebone bricked on
> boot with FDT_ERR_BADOVERLAY. The problem was I put the "reserved-memory"
> section in my overlay dts, which the overlay system doesn't like.
>
> I moved that to a fragment, and now it boots and there's a reserved-memory
> section in /sys/firmware, but looking at dmesg and /proc, I don't think it
> actually reserved any memory.
>
> fragment@6 {
> target = <>;
> __overlay__ {
> reserved-memory {
> #address-cells = <1>;
> #size-cells = <1>;
> ranges;
>
> pruadc_reserved: pruadc_reserved@0x9ffc {
> reg = <0x9ffc 0x0004>;
> no-map;
> status = "okay";
> };
> };
> };
> };
>
>
> So, my question is: how do I get this fragment to actually reserve a chunk
> of memory? I just guessed at the target "ocp", so that may be wrong.
>
> (My underlying goal is to allocate a chunk of RAM to share between the ARM
> and the PRU; the built-in shared RAM is a bit too small. It seems that the
> TIDA01555 <https://git.ti.com/apps/tida01555/> project does just what I
> (and presumably Gaurav) want, if I can get it to work.)
>
> Ken
>
> On Tuesday, October 9, 2018 at 6:55:28 PM UTC-7, RobertCNelson wrote:
>>
>> On Tue, Oct 9, 2018 at 5:58 PM GS >
>> wrote:
>>>
>>> Thanks for the suggestion, Robert.
>>> I have attached the complete output. The relevant section is pasted
>> here:
>>>
>>> uboot_overlays: loading /lib/firmware/MEM.dtbo ...
>>> 418 bytes read in 94 ms (3.9 KiB/s)
>>> failed on fdt_overlay_apply(): FDT_ERR_BADOVERLAY
>>>
>>> Not exactly sure what it means.
>>
>> it means, error, bad overlay...
>>
>> Which means it didn't do the overlay syntax..
>>
>> We have lots of examples here:
>>
>> https://github.com/beagleboard/bb.org-overlays/tree/master/src/arm
>>
>> what's your actual overlay dts file look like?
>>
>> You need:
>>
>> /plugin/;
>>
>> fragment@0 {'s
>>
>> target = <>; or target-path="/";
>>
>> and
>>
>> __overlay__ {
>>
>> finally built with "-@"
>>
>> Regards,
>>
>> --
>> Robert Nelson
>> https://rcn-ee.com/
>>
>
--
Charles Steinkuehler
char...@steinkuehler.net
--
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/70fbad3e-dc9c-5477-a70d-7785fa7df5e7%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Trouble in getting started with PRU
On 11/20/2018 6:08 PM, Gerhard Hoffmann wrote: > > Am 20.11.18 um 23:15 schrieb Mark A. Yoder: >> >> Using the PRU interface is faster. I think my students measured >> it as being a couple times faster. Using the PRU interface you can >> toggle a pin every 5ns. >> >> > Yes, R30/R31 is about 3 times as fast and more predictable. Going > through the OCP interface > > has to wait sometimes if there is already CPU or DMA activity. PRU writes to the direct I/O are 8 times faster than writing to a GPIO pin via the OCP (40 ns for the GPIO vs. 5 ns for direct I/O). Note that while the write competes on the PRU side within 40 ns, it takes about another 100 nS until the actual GPIO pin value is updated (this is the time needed for the write transaction to flow through the interconnect fabric and actually update the GPIO register). Reads, however are much worse, since they are not posted by the interconnect fabric and stall the PRU until the read value is returned. Reading from a GPIO pin via the OCP port takes apx. 165 ns vs. 5 ns for a direct I/O read. I did some tests and measurements of this when I was writing the PRU code for Machinekit, and documented the details in some comments: https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_generic.p#L137-L165 -- Charles Steinkuehler char...@steinkuehler.net -- 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/3b658492-eea7-43b5-4c93-2d6f9dd9fdb8%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Pru Reset without BBB reboot?
On 10/24/2018 5:05 AM, true-t...@web.de wrote: > Hello, > > In tests with clpru C programs, the problem arises again and again that the > Pru hangs up. > A simple LED Bink program can then no longer be started. > Is there a way to reset the Pru without rebooting the BBB? > Tips from the network have not worked for me so far. > > thanks to all experts It looks like you're using the UIO bindings for the PRU. If you're also using the prussdrv library, just call the prussdrv_pru_reset() function. Otherwise, there's an enable and reset bit in the PRU control register (PRU_ICSS_PRU_CTRL register 0: CTRL bit 0: SOFT_RST_N and bit 1: EN). See the PRU section of the TRM for details. -- Charles Steinkuehler char...@steinkuehler.net -- 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/4a49cf83-7c58-ebbe-96bb-138d446ca909%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] config-pin default values
You'll have to ask RCN, but it looks to me like all the pins were set to pull-down (except for the I2C pins, anyway). I was careful to match the power-on reset defaults, since I rely on some of those weak bias resistors to help insure hardware powers up in a "safe" state. On 10/19/2018 11:11 AM, TJF wrote: > Thanks for the answer, Charles. In the default overlay it's PULLDOWN: > > https://github.com/beagleboard/bb.org-overlays/blob/master/tools/pinmux-generator/BeagleBone_Black.dts#L691-L693 > > And this is what anybody gets when not installing your cape universal > device tree blob. My question is still why? > > Am Freitag, 19. Oktober 2018 16:58:20 UTC+2 schrieb Charles Steinkuehler: >> >> On 10/19/2018 5:05 AM, TJF wrote: >>> With kernel 4.14.x on Beaglebone Black board (may Green and White as >> well) >>> after boot the pin P9_11 is in muxmode >>> >>> GPIO INPUT PULLUP >>> >>> , while the config-pin default is >>> >>> GPIO INPUT PULLDOWN >>> >>> Why that difference? Shouldn't the boot mode and the default mode be >> equal? >>> 13 further pins show that difference. >> >> The default mode for P9_11 is an input with pull-up enabled: >> >> >> https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/cape-universal-00A0.dts#L392-L393 >> >> >> The default pin modes for cape universal were set to match the reset >> defaults of the AM3358, so loading the universal device-tree overlay >> would not cause any physical change in the pin state. The reset >> default states are listed in the AM3358 data-sheet (which is a >> different document than the AM335x TRM). Most pins are are generally >> GPIO inputs with either a pull-up or pull-down (pin dependent) after >> reset. >> >> -- >> Charles Steinkuehler >> cha...@steinkuehler.net >> > -- Charles Steinkuehler char...@steinkuehler.net -- 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/dc33d104-5fc3-6a43-f3fb-872f65b93b30%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] config-pin default values
On 10/19/2018 5:05 AM, TJF wrote: > With kernel 4.14.x on Beaglebone Black board (may Green and White as well) > after boot the pin P9_11 is in muxmode > > GPIO INPUT PULLUP > > , while the config-pin default is > > GPIO INPUT PULLDOWN > > Why that difference? Shouldn't the boot mode and the default mode be equal? > 13 further pins show that difference. The default mode for P9_11 is an input with pull-up enabled: https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/cape-universal-00A0.dts#L392-L393 The default pin modes for cape universal were set to match the reset defaults of the AM3358, so loading the universal device-tree overlay would not cause any physical change in the pin state. The reset default states are listed in the AM3358 data-sheet (which is a different document than the AM335x TRM). Most pins are are generally GPIO inputs with either a pull-up or pull-down (pin dependent) after reset. -- Charles Steinkuehler char...@steinkuehler.net -- 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/730b8d75-6940-8cd6-345e-29c7b29b07ab%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
[beagleboard] X15 PRU UIO Bindings
Has anyone made a UIO device tree binding for the PRUs on the X15, or is everything remoteproc now? -- Charles Steinkuehler char...@steinkuehler.net -- 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/af98d137-da4e-2606-3220-52412ef0cf18%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] header file for CCSv6 & PRU
On 8/14/2018 6:29 AM, Hugh Frater wrote: > Does anyone know the header file I need to include to get access to the > i2c2 control registers from within the PRU subsystem? Having a hard time > getting any info and my google-foo is usually pretty decent... AFAIK, there are no "standard" headers for accessing physical hardware like the i2c buses from the PRU. Even the Linux kernel generally mixes this sort of thing between header files (for the bit definitions and "structure" of the control registers) and the device tree (for base addresses, IRQ values, etc). Probably the closest you'll find is something from the TI bare-metal code: http://processors.wiki.ti.com/index.php/StarterWare -- Charles Steinkuehler char...@steinkuehler.net -- 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/c5010875-a291-db45-fd6f-a9c9edf13751%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: PRU/DDR Feasibility
If I understand correctly, you are only trying to move 1 MB/s into SDRAM, which should not be a problem. You should do burst writes for efficiency, see the BeagleLogic code for examples. If you don't want to hassle with ring-buffers, you can dedicate a chunk of contiguous physical memory to your application by editing the device-tree and adding a "reserved-memory" stanza: https://www.kernel.org/doc/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt You'll still have to deal with cache coherency issues, however. On 2/8/2018 6:05 AM, Giulio Moro wrote: > Have a look at the BeagleLogic project: they use one PRU for data > acquisition and the other one to write to a portion of DDR allocated > through a kernel driver: > https://github.com/abhishek-kakkar/BeagleLogic/blob/master/firmware/beaglelogic-pru0.c > > On Monday, January 22, 2018 at 3:29:36 PM UTC, David Edwards wrote: >> >> I'm looking at moving away from an FPGA to a PocketBeagle for a new >> project, and I think I can divide up my real-time tasks between the 2 PRU's: >> >>1. Use PRU0 as a SPI master to capture external 16-bit ADC data at >>500kS/s >>2. Store around 30MB of samples in DDR >>3. Change PRU0 firmware to be a SPI slave to transfer these samples to >>an external host with a SPI clock rate in the neighborhood of 40MHz >>(~2.5MB/s) >>4. PRU1 will act as an I2C slave handling stop/start/config requests >>for the two PRU0 activities. >> >> I'm a little concerned about the DDR transfer in step 3 keeping up with >> the SPI clock rate. Will this transfer be subject to possible latencies in >> the non-RTOS core? Or, is there a way to architect this where PRU0 has >> direct access to the 512MB external memory? The linux core does not >> necessarily need to see or even know about this data, I simply need to >> store it and then dump it back out. >> >> >> Thanks, >> >> Dave >> > -- Charles Steinkuehler char...@steinkuehler.net -- 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/181f097c-06df-8449-b3d5-7e7aed81d909%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Is it a bug? control flow instruction of PRU does not make right comparison with negative number
On 10/30/2017 4:53 PM, zlw8...@gmail.com wrote: > I am trying to use QBLT to compare two numbers and found out when one > number is negative, the QBLT logic does not seem make right comparison. In > the following code, before QBLT, r3 =1-4 = -3, and r2 = 10, so r3 < r2, > then the code should execute MOV r3, -1. However, when I run this macro, r3 > is set to 1. > Anyone notices this issue? Any idea how to fix it? This is a known issue, the PRU supports *ONLY* unsigned integers. Write your code properly for unsigned data types and you will not have any problems. -- Charles Steinkuehler char...@steinkuehler.net -- 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/ecf0f332-a2bc-5119-904b-30d5c336f351%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: BeagleBoard, G540, Linux CNC
The BBB has pretty sensitive I/O pins without much drive (most pins are spec'd for 3 mA max). I'd recommend at least a simple buffer (like an 'HCT244/245) on the output lines, and something on the inputs to insure they *NEVER* go over 3.3V (or you will destroy your BBB). As for pinout, there's no real standard. For most signals (step, direction, enable, endstops, etc) it doesn't really matter which pins you use. There are several example configurations for Machinekit which use the pinouts listed in this pinmux.ods spreadsheet: https://github.com/cdsteinkuehler/beaglebone-black-pinmux/blob/hal_pru_generic/pinmux.ods ...but you can move things around by editing the HAL file. I'm not sure what the LinuxCNC folks have for examples or standards, but I do hear they can run on the BeagleBone these days. On 10/29/2017 3:23 PM, mrarmy...@gmail.com wrote: > Thanks I'll take a look. I figured i could just solder some wires from > output pins to a db25 connector. I've found more advanced users setups but > it never explains how they connected the g540 to the beaglebone. > > > On Tuesday, October 24, 2017 at 9:58:58 AM UTC-5, R3DP wrote: >> >> Replicape maybe? >> >> I have one that I'm about to install for 3D Printing. Using PRUS controls. >> All opensource as well. >> >> On Monday, October 23, 2017 at 8:44:49 PM UTC-5, mrar...@gmail.com wrote: >>> >>> >>> Wanting to replace my dead CNC computer with a beagleboard. I have a >>> G540 controller. Everyone says to connect it to the beaglebone but I see >>> no tutorial anywhere on pinning up a db25 connector to the board. This >>> seems so simple... lol. Can anyone point me in the correct direction? >>> >> > -- Charles Steinkuehler char...@steinkuehler.net -- 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/f143e41a-8319-6646-1272-cc8d55a770e8%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] prussdrv.c
On 8/28/2017 3:38 AM, Babak akbari wrote:
> I'm an absolute beginner in the field of pru. I was wondering what actually
> takes place when a bin file is loaded into the instruction memory of a pru. I
> looked through the prussdrv.c in am335x_pru_package file where application
> loader api functions are located.
> https://github.com/beagleboard/am335x_pru_package/blob/master/pru_sw/app_loader/interface/prussdrv.c
>
> My question is in
> int prussdrv_pru_write_memory (unsigned int pru_ram_id, unsigned int
> wordoffset, unsigned int *memarea, unsigned int bytelength);
> function scope
>
>
> wordlength = (bytelength + 3) >> 2; //Adjust length as multiple of 4 bytes
>
> for (i = 0; i < wordlength; i++) {
> *(pruramarea + i + wordoffset) = *(memarea + i);
> }
> return wordlength;
>
> why wordoffset is added to pruramarea which holds the the address of the
> instruction memory.but according to this guide
>
> http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader_API_Guide
>
> wordoffset is the offset from *memarea and I think wordoffset is to be added
> to memarea instead , otherwise we are missing some parts of the instruction
> memory.
It looks like the documentation is unclear (or wrong). The offset is
the offset into the mapped memory region (pruramarea, selected by what
you pass as the pru_ram_id parameter) where the memory buffer
specified by memarea & bytelength will be copied.
When in doubt, trust the code! :)
> My other question is why pru instruction memory is said to be 8kB But
> according to the trm pru global memory section the instruction memory is just
> 4k
Which TRM? The TRMs I have for the AM335x refer to 8KB instruction
memory for each PRU core, but there are several versions of the PRU
floating around in different SoC's.
--
Charles Steinkuehler
char...@steinkuehler.net
--
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/bc13310e-4c4d-460c-357c-65178c5447bc%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Dereferencing an address in memory
On 8/15/2017 8:12 AM, M Pitman wrote:
> I'm trying to get to the values of data stored in memory on the Beaglebone
> Black
> and experiencing a very fundamental problem. I have the following C code
> running in Linux.
>
> int *p;
> int value;
>
> p = (int *)0x4A30;// Start of PRU0 data ram
> printf("p addr: 0x%x\n", p);
> value = *p;
> printf("value: 0x%x\n", value);
>
> p prints fine but trying to print *p or value gives a Segmentation fault.
> Can
> anyone explain to me what is going on and how I can get to the data stored at
> a
> memory location on the BeagleBone?
In your code, p is a pointer to the user memory space, which goes
through virtual address translation before becoming a physical address
which is what you're trying to use.
You need to mmmap() the physical region you want to use from /dev/mem
into your user memory space. This will give you a user-mode pointer
to the physical memory. There are many examples of how to do this
floating around, but since you're trying to use the PRU, you might
want to checkout something like:
prussdrv (C code for accessing the PRU using uio_pruss):
https://github.com/beagleboard/am335x_pru_package/blob/master/pru_sw/app_loader/interface/prussdrv.c#L70
--
Charles Steinkuehler
char...@steinkuehler.net
--
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/1ce459d9-655f-f0b8-8765-a67379b0c3fc%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] File writing from PRU
On 8/8/2017 10:11 AM, Clark Sann wrote: > > But why did TI blather on and on about the printf_support switch and the high > and low level IO drivers in the PRU C Compiler manual? Because you can get printf working if you add a UART or other means to get data out of the system. > What do you do to get diagnostic info while debugging PRU firmware? My typical methods: * "Twiddle" pru output pins at various points in the code. Note that if you've got a good 'scope or logic analyzer (I'm typically using an Agilent MSO with 16 digital channels), you can shift out data values with a single pin, so it can be more useful than just "LED" style debugging. * Dump data into a chunk of shared memory (typically one of the PRU data RAMs) and examine it from the ARM side. * Use a debugger to single-step the PRU code. I typically use the HAL based one provided with Machinekit but there are now several others available. Regardless, debugging on the PRU is much harder than debugging code on the ARM side. -- Charles Steinkuehler char...@steinkuehler.net -- 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/e5397db0-ee22-e884-a2d5-893936dea0df%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] File writing from PRU
On 8/7/2017 10:55 PM, Clark Sann wrote: > I need some help from someone who has succeeded in getting the PRU to write > files onto the host's file system. I have tried two methods: > > 1. Using open, fputs, fprintf, etc. This does not work for me. First of all, > unless I set the printf_support flag to minimal, even a simple program with > only > a single print statement uses more instruction memory than the BeagleBone PRU > has. Even if I set the flag to minimal, I do not find that any files have > been > written. > > 2. Using the low level drivers described starting on page 124 of the PRUC > Compiler V21 User Guide. I also cannot get these functions to write a simple > file. > > If anyone has succeeded in getting either of these methods to write a simple > string to a file, would you please consider posting some sample code? You cannot write to anything like a file directly from the PRU. The best you could do is enable the PRU UART and craft a version of the C library that would let you do printf() or similar to a console. If you need to save data into a file, you will have to pass it from the PRU to the ARM at which point you can do anything available via Linux (print to console, write to file, send via Ethernet, etc). -- Charles Steinkuehler char...@steinkuehler.net -- 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/e57bbb0b-5c9b-0391-74eb-a33627da9da1%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] PRU Hardware UART
It looks to me like you're immediately disabling the UART without waiting for the data you wrote to get transmitted (which will take a *LONG* time, at least from the PRU's 5 ns/clk perspective). Try either not shutting down the UART, or polling the UART to make sure the Tx side is idle before disabling it. On 7/18/2017 4:09 PM, brc...@gmail.com wrote: HI, I'm learning how to use the BBB's PRU's, and I'm writing some assembly to utilize the PRU's integrated UART. I read through the PRU reference manual and used it to write my assembly code, but after running the code in a debugger, I'm getting almost no output. The only reaction from the PRU I could see with my logic analyzer is a small spike when the PRU writes a value to the UART output address, but it is not a valid UART communication. Here's my assembly code <https://gist.github.com/winter-muted/4e4b113fb5767ea31fdae92f334af46a > and cape manager overlay <https://gist.github.com/winter-muted/6aea7bb9d05636a5304c93c202fbbf67> Any thoughts as to what might be going on? 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 beagleboard+unsubscr...@googlegroups.com <mailto:beagleboard+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/7279f8f5-c8ba-4d96-a7fc-4a0a507c5a2f%40googlegroups.com <https://groups.google.com/d/msgid/beagleboard/7279f8f5-c8ba-4d96-a7fc-4a0a507c5a2f%40googlegroups.com?utm_medium=email_source=footer>. For more options, visit https://groups.google.com/d/optout. -- Charles Steinkuehler char...@steinkuehler.net -- 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/3fcaffe0-7d4e-abd2-e08d-f9dec88c76f6%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] PRU help needed....I don't understand pointers well enough to understand them.
On 6/13/2017 7:29 PM, Clark Sann wrote: > Thanks Charles. > > I understand everything except for your last statement. > > I don’t understand the difference between > *(volatile uint32_t *) > and (volatile uint32_t *). Like I said, read up on some basic C tutorials, they'll explain it much better than I can. > Why is the leading * needed? That is why I thought it meant a pointer to a > pointer, which didn’t seem to make sense in this context. No. (uint32_t *) is a pointer (address) to a uint32_t *(uint32_t *) is the value (data) pointed to by (uint32_t *) -- Charles Steinkuehler char...@steinkuehler.net -- 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/cf910aed-bae4-1c43-d5b5-e3aa214774b2%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] PRU help needed....I don't understand pointers well enough to understand them.
On 6/13/2017 6:50 PM, Clark Sann wrote: > > But what I really need to know is how do I interpret this statement: > > #define GPIO0_SETDATAOUT (*(volatile uint32_t *)*(GPIO0_BASE + 0x190)) > > One way I use it is as follows: > > GPIO0_SETDATAOUT = 1u << PWM2A_OFFSET; > > What I don't understand is how I intrepret the first statement, especially > the > bolded part. I understand the meaning of #define and I understand the simple > GPIO0BASE + 0x190 offset math. What I don't understand is the bolded part. It > looks like it is a pointer to a pointer to a uint32_t, but that doesn't make > sense to me. I don't see the need for double indirection. And I'm not too > clear > on the difference between a uint32 and a uint32_t. > > Can someone give me a plain english translation for the #define statement? The #define results in a simple text replacement prior to the C compiler actually running. The actual code that would be compiled is something like: *(volatile uint32_t *)*(GPIO0_BASE + 0x190)) = 1u << PWM2A_OFFSET; Basically this takes the value of GPIO0_BASE + 0x190 (the address of the SETDATAOUT register), casts it to a volatile uint32_t pointer, and stores the result of the right-hand side of the equals to the address being pointed to. This is all very basic C code...just read up on some tutorials regarding the C pre-processor (the #dfine), pointer handling (the *'s) and the volatile keyword. Breaking the first bit down to hopefully help you out a bit: uint32_t : a 32-bit unsigned value uint32_t * : a pointer to a 32-bit unsigned value volatile uint32_t * : a pointer to a 32-bit unsigned value that may change in ways the compiler doesn't expect (ie: don't optimize away all the reads/writes to this value) *(volatile uint32_t *) : The actual 32-bit unsigned data value at the address contained in the following expression -- Charles Steinkuehler char...@steinkuehler.net -- 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/e601ff9c-da92-2cb6-5158-e5b7ac23a42d%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: PRU timing with __delay_cycles()
On Thursday, May 25, 2017 at 10:01:40 AM UTC-5, M Pitman wrote: > > > If anyone can shed any light on what I'm seeing with the __delay_cycles > command I would be interested in hearing about it. Thanks. > Program the PRUs in assembly, especially if you want single cycle accuracy. ...or at least provide us the assembly listing for the C code, as well as the entire C program. There are lots of things that can be happening behind the scenes since you're using C. On the MPS-430, for example, the __delay_cycles() routine actually turns off most of the processor (to save power) and wakes it back up after the delay expires, which could obviously cause unexpected behavior if you didn't realize that's what it was doing. I don't use C compiler so I'm not sure how this routine is implemented for the PRU, but it probably isn't a simple noop loop like you might expect. -- Charles steinkuehlerchar...@steinkuehler.net -- 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/afd7ba5d-929b-446e-92f8-4860ab0dbca0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] PRU timing with __delay_cycles()
On 5/25/2017 9:01 AM, M Pitman wrote: > > If anyone can shed any light on what I'm seeing with the __delay_cycles > command > I would be interested in hearing about it. Thanks. Program the PRUs in assembly, especially if you want single cycle accuracy. ...or at least provide us the assembly listing for the C code, as well as the entire C program. There are lots of things that can be happening behind the scenes since you're using C. On the MPS-430, for example, the __delay_cycles() routine actually turns off most of the processor (to save power) and wakes it back up after the delay expires, which could obviously cause unexpected behavior if you didn't realize that's what it was doing. I don't use C compiler so I'm not sure how this routine is implemented for the PRU, but it probably isn't a simple noop loop like you might expect. -- Charles Steinkuehler char...@steinkuehler.net -- 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/77f3bae9-b5ae-945e-041c-3113bf8c7b8b%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] See if I understand setting up a device tree for the PRU
On 5/17/2017 9:37 PM, Clark Sann wrote: > > Signal Signal name on Mode from Data > Octavo per BB Blue Sheet Table 4-1 > schematic > > MDIR 1A GPIO2_0_T13 7 > MDIR 1B UART4_TX0_U176 > MDIR 2A CP101_16_R137 > MDIR 2B LCD_DATA14_V40 > PWM 1A EHRPWM1A_U14 6 > > The mode setting I have chosen is the mode that causes the pin to have the > signal name shown on the BB Blue schematic. > > Do I have my mode settings correct? Probably not, unless you plan to use the UART, PWM, and LCD hardware to drive your motor coils. You probably want to set all the pins to mode 7 (GPIO). The PRU can write to the GPIO control registers with minimal delay and latency. -- Charles Steinkuehler char...@steinkuehler.net -- 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/bfc90fcf-e962-d70c-615a-185fb683f189%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] How do you enable 24 bits for Beaglebone Black?
The dtbo file should be included in the kernel. The commit RCN linked to was from two days ago. ...so, your issue has been fixed, but you need to update to a kernel that includes the fix (ie: less than two days old). On 4/30/2017 9:20 PM, David Faulkner wrote: That link is for different dts files which I have seen before. So if I took one of them and compiled it to a dtbo file which is the correct way to enable it? I have seen it done 2 ways: 1) Through the uEvt.txt file 2) Using the echo command to write to the slots file Both were done with using older debian builds and I could never get it to work. I am running Kernal 4.4.30 so based on your post that should be ok correct? On Sunday, April 30, 2017 at 8:57:45 PM UTC-5, RobertCNelson wrote: With v4.4.x+ kernels: https://github.com/beagleboard/bb.org-overlays/commit/a20c3a6c8e4ee6760238d52a9d919b4df8aa7436 <https://github.com/beagleboard/bb.org-overlays/commit/a20c3a6c8e4ee6760238d52a9d919b4df8aa7436> Regards, On Sun, Apr 30, 2017 at 8:08 PM, David Faulkner <dvfaul...@gmail.com > wrote: Specs: Beaglebone Black Rev C Image Build 8.6 Jessie Debian LCD- Apollo Display G104X1-L03 So I am using the Beaglebone black and pairing it with a LVDS display. I layed out an interface board and hooked it up and at first it did not work unless I hooked up an HDMI interface. So I went into the uEnv.txt and unconmenteded the cmdline=coherent_pool=1M quiet cape_Universal=enable video=HDMI- A-1 1024x768@60e and now it runs on its own. However the I have the board configured for 24 bit mode so the red and blue colors are swapped (See Picture below) I was aware that when the am335 swaps red and blue in 24 bit mode so it makes sense as the default BSP is configured for 16. But now I am struggling to enable 24 bit mode for the latest Jessie build. For the early Angstrom images all you had to do was go into the X11/xorg.conf and change the color depth from 16 to 24 and it worked. But for jessie if I do that it does the following on bootup: I am assuming this is conflict with TI's tilcdc driver but Im not sure. In any case what is the best way to enable 24 bits outside of the X11 config? 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 beagleboard...@googlegroups.com . To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/b81d8dc1-2a64-4c67-b228-92722e2614f6%40googlegroups.com <https://groups.google.com/d/msgid/beagleboard/b81d8dc1-2a64-4c67-b228-92722e2614f6%40googlegroups.com?utm_medium=email_source=footer>. For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>. -- Robert Nelson https://rcn-ee.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 <mailto:beagleboard+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/0442418d-075c-475a-8e8b-cb391da08684%40googlegroups.com <https://groups.google.com/d/msgid/beagleboard/0442418d-075c-475a-8e8b-cb391da08684%40googlegroups.com?utm_medium=email_source=footer>. For more options, visit https://groups.google.com/d/optout. -- Charles Steinkuehler char...@steinkuehler.net -- 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/89489bf2-c8e8-ab3d-1539-cb0c6a1cb1dc%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: config-pin does not work for all pins on BBBW
On 4/20/2017 8:51 PM, thisboyiscr...@gmail.com wrote: > I am having the same problem with P9_31. > > I think it is because you need to disable the audio but I can not figure out > how > to do that. Disable the HDMI virtual cape in your uEnv.txt file. This leaves the HDMIn (HDMI with no audio) enabled, so you will still have a display. In uEnv.txt: optargs=capemgr.disable_partno=BB-BONELT-HDMI -- Charles Steinkuehler char...@steinkuehler.net -- 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/daf701de-1591-02cd-d0e6-a60a6ad93e3b%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Repeatable bug where beaglebone black loses bytes from it's serial connection.
On 4/21/2017 11:18 AM, David Howlett wrote: > I have spent about two days tracking down an issue in one of my machines. I > am > streaming pressure readings from an i2c pressure sensor to a PC at high > speed. I > have reduced the problem to a small test case. To replicate the fault I > connect > the beaglebone black to a PC, connect to it with serial over the micro USB > port, > login and launch a command that streams data fast. On the PC run a program > that > collects the streamed data more slowly than it is being created. This is expected behavior unless you are using hardware flow control or something like XON/XOFF to throttle the Tx side. Otherwise, if you transmit data faster than a receiver can process it, you will loose data. ...looks like you need a faster PC! ;-) -- Charles Steinkuehler char...@steinkuehler.net -- 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/bd01aa4a-a01f-d4bf-c8e7-3afb2a59676a%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Slow reading speed from DDR allocated for pru (uio_pruss driver)
On 4/18/2017 6:38 AM, letterdotandnum...@gmail.com wrote: > Hello, > I've encountered a problem with very slow reading speed from memory allocated > by > pru kernel driver uio_pruss comparing to reading from usual address spaces. > Here > is an performance tests on my Beagle Bone black: > > Average memcpy from pru DDR start address to application virtual address (300 > kB > of data): 10.4781ms > Average cv::Mat.copyTo (300 kB of data): 11.0681ms > Average memcpy from one virtual address to another (300 kB of data): > 0.510001ms > > Kernel version is 4.4.12-bone11 > > Can somebody explain the issue? May be I should have used new pru rpmesg > rproc > driver? Like William said, we can't really answer your question without more detail, but I'll take a guess. The DRAM that's shared with the PRU is marked as non-cachable memory since the PRU can modify it. That means for a typical memory copy loop *EACH* word read from DRAM is going to turn into a full round-trip CPU to DRAM to CPU read latency rather than the first read triggering a cache-line fill. You probably want to use a memory copy that uses a bunch more registers and does burst reads from the PRU memory region (as big as you can for performance, but at least a cache line long). There are several useful routines from the ARM folks themselves: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka13544.html ...along with the benefits and drawbacks of each. -- Charles Steinkuehler char...@steinkuehler.net -- 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/5c302592-7edc-caa1-2e87-d47250fc5843%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Cramps board FAULT pins
On 4/13/2017 6:18 AM, klemenzivko...@gmail.com wrote: > Hi! > > I have connected closed loop steppers (3 of them) to cramps that resides on > beaglebone that runs machinekit, and this closed loop steper drivers have > FAULT- > and FAULT+ pin. > FAULT + pin goes to GND when closed loop driver cannot push motor in demanded > position. > > Is it possible to connect this fault pin to some fault pin on cramps (or > somehow > connect them to eStop)? I was looking cramps pdf schematics, but cannot find > such pin. I'd recommend just using one of the digital I/O pins unless you need all six limit switches on P502 and the 4 spare/SPI pins on P503. Add a signal to your HAL file and tie it to the amp-fault-in signal(s) of the motion component. If you really want to wire your fault signal into the ESTOP chain, you can use a circuit similar to what I have already on the board instead of a simple jumper (or in series with a physical ESTOP switch if you've got one). Something similar to the R301/Q303 circuit in the ESTOP chain on the CRAMPS board should do what you want: * You probably want a pull-up resistor on the FAULT+ line (similar to R301). The pull-up voltage and the resistance will depend on the characteristics of your FAULT+ output. Make sure you do not exceed the maximum Vgs of the FET (usually 15-20V). * The FET gate should be tied to your FAULT+ signal. The FET will conduct when FAULT+ is high, and will not conduct when FAULT+ is low. * The FET source should be tied to the low side of the ESTOP chain (P302 pin 2) * The FET drain should be tied to the high side of the ESTOP chain (P302 pin 1) -- Charles Steinkuehler char...@steinkuehler.net -- 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/9c73b9a9-a7d0-1bad-4179-130f52d8d5ae%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] How to reliably push data from ARM host to PRU (shared) memory with predictable (low) latency?
On 3/22/2017 12:08 AM, ags wrote: > > I need to provide about 32 KiB to the PRU within 5 milliSec, repeating > every 20 milliSec. That's not much data. I recommend you just make a circular buffer in the PRU data memory, and run a periodic task on the ARM side to keep the buffer filled. Using the 12K shared data ram you can store almost 2 mS worth of data, which ought to be plenty. By way of example, the default Machinekit ARM side thread period is 1 mS and could easily be faster for something simple like this. Note you might need an -rt or -xenomai kernel to achieve reliable operation, I've seen the non-rt kernels occasionally "wander off into the weeds" for several hundred mS at a time. -- Charles Steinkuehler char...@steinkuehler.net -- 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/2eb65170-2666-173f-f5f8-82660e58f5f7%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: How many PRU clock cycles does a LBBO instruction take?
I also don't see any references to VBUS/VBUSP, but based on the context they are internal PRU buses. To answer your original question, access to anything outside the PRU block (the two PRU cores, data memories, and local peripherals) requires communicating over the SoC's internal interconnect fabric. You can perform zero wait state writes to these resources (at least until you saturate the posted write logic), but reads will stall the PRU until data is returned from the far end. I characterized the performance when accessing the GPIO registers from the PRU, and got results similar to your DDR memory timings: https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_generic.p#L137-L165 Note that all timings are approximate. The exact number of PRU cycles it will take to complete a write or read will depend on things like internal bus utilization, various clock crossing latencies (which by nature will have a varying amount of latency) and how quickly the far end can respond. The DDR DRAM controller in particular needs to schedule the read request and there are many factors that can cause the read latency to vary. On 3/14/2017 2:24 PM, ags wrote: > Would someone kindly decode what VBUS and VBUSP are? Searched but could not > find other relevant references. Thanks. > > On Tuesday, May 26, 2015 at 6:39:38 AM UTC-7, marcelo...@gmail.com wrote: >> >> Sorry, just saw that you actually mentioned that the shared memory has the >> same performance as the DRAM. >> Also, I found this: >> http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit#Load_.2F_Store_Instructions >> where it is said that LBBO should take (1+word count) cycles. If that's >> right, an LBBO instruction up to 4 bytes should take 2 cycles for VBUS >> and 3 cycles for VBUSP. For now I need to study more to understand which >> one is the case, but VBUSP matches with your findings. >> >> Em sexta-feira, 3 de janeiro de 2014 23:05:30 UTC-2, Lenny escreveu: >>> >>> Hello, >>> >>> I am using a Beaglebone Black. When i measured the number of PRU clock >>> cycles needed for the execution of various assembler instructions, I found >>> surprisingly large values for memory access. Here follows a list, in which >>> one cycle corresponds to a delay of 5ns as expected: >>> >>> Most operations, such as ADD,SUB,QBxx,MOV,JMP etc.: 1 cycle >>> >>> LBBO 1,2,4 Bytes from PRU DRAM: 3 cycles >>> LBBO 8 Bytes from PRU DRAM: 4 cycles >>> LBBO 12 Bytes from PRU DRAM: 5 cycles >>> LBBO 16 Bytes from PRU DRAM: 6 cycles >>> >>> LBCO 4 Bytes from DDR: 43 cycles >>> LBCO 8 Bytes from DDR: 44 cycles >>> LBCO 12 Bytes from DDR: 45 cycles >>> LBCO 16 Bytes from DDR: 46 cycles >>> >>> With PRU DRAM, i mean any addresses between 0x and 0x4000 and >>> the shared PRU RAM (12 kB starting from 0x0001). Any other address i >>> tried had the delay stated for "DDR". >>> >>> Can anybody confirm the long DDR (and other delays if possible) readout >>> times that I have measured? Does anybody have an explanation for these >>> large delays? >>> >>> Thanks in advance! Lenny >>> >> > -- Charles Steinkuehler char...@steinkuehler.net -- 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/1818edb3-b783-8142-d683-29d51407d387%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Unexpected PRU I/O Delay
..@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/37ece5ec-31b9-4ee6-81b9-b3a732b69184%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/37ece5ec-31b9-4ee6-81b9-b3a732b69184%40googlegroups.com?utm_medium=email_source=footer>. > For more options, visit https://groups.google.com/d/optout. > -- Charles Steinkuehler char...@steinkuehler.net -- 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/e6fa1a63-7f89-206f-5db9-9c234e88d6be%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] why is pinmux-helper needed?
On 3/3/2017 10:04 PM, ags wrote:
>
> 1) pin configuration ultimately boils down to two steps, for every pin (ball
> on
> the SoC): what is it internally connected to (and operationally configured),
> and
> separately, controlling that function once connected.
Yes. The physical pin is connected to a pin multiplexer, which is
generally completely separate from any logical device (gpio, uart,
timer, etc) that might use the pin.
> 2) specifying the function/connection and operation is what the "traditional"
> pinmux ("pinctrl-single") entries do. It is accomplished by setting values in
> GPIO control registers, which is just writing values to locations in the SoC
> memory mapped space (with pinmux child nodes using "pinctrl-single,pins"
> driver
> to specify offset from pinmux base address and mode selection, in 2-tuples
> for
> each pin being configured). It is a bit tricky because this requires
> privilege
> and thus a kernel driver (in kernel space/ring 0). The selection of
> function/connection is done by the "mode" bits (2:0) in the control register,
> and the operation by other bits (pullup/down, pull-enable, receiver enable,
> slew
> rate).
Yes, with the caveat that different systems may have different ways of
specifying the pinmux control. The BBB uses two values, but there are
many different flavors of pinmux control across the various SoC's
available.
> *I haven't tried it (don't want to damage hardware) but does this mean that
> directly poking at the GPIO registers from userspace with /dev/mem & mmap()
> won't work?
> *if this is correct so far, what prevents loading a series of cape overlays
> that
> change the configuration of a pin with this "old" style of pinmux control?
In the "old days", you could do this if you were root. Now I believe
the hardware configuration register space is setup with memory
protections so you have to access it from kernel space or you get an
exception. You can still work around this if you're root by playing
"tricks" (you can use something like the DMA engine or PRU to write
values to the pinmux registers, bypassing the MMU).
> 3) this is where things start being less clear to me: I think I was just
> understanding pinmuxing; now I see devices with properties "pinctrl-0;" with
> no
> value. Is that because the devices no longer "own" their pins, but the
> config-pin driver does?
Not every device need to manage pins. Some devices don't have any
pins (a DMA controller, cryptographic acceleartor, etc) and sometime
the pins are already setup or are controlled by a different driver
(like the pinmux-helper driver).
> 4) the cape-universal node uses the "gpio-of-helper" driver, and apparently
> has
> a node for each header pin, with a 3-tuple. It looks like {mode,?,0} but
> that's
> a guess. I've searched, and found some examples from Pantelis Antoniou, but
> no
> explanation.
The gpio-of-helper exports the GPIO pins so this doesn't have to be
done by the user. The three values you are referring to describe a
particular GPIO pin. The number of values needed, and their meaning
is device specific:
https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt
> Ultimately, I'd like to understand this so that I can create mappings/dts on
> my
> own, rather than just relying on finding something that works offered by
> someone
> else.
Read through the device tree binding documentation in the kernel
source. It is also helpful to view the full working device tree from
your system. You can take the binary device tree from /boot and
convert it into source with dtc. Then instead of a bunch of dangling
references like , you can go to gpio3 and see what it is, which
will help you find it's documentation in the kernel's Documentation
directory.
--
Charles Steinkuehler
char...@steinkuehler.net
--
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/bf93652d-f99d-c0c4-90be-5526a5df9077%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] why is pinmux-helper needed?
On 3/1/2017 11:00 PM, ags wrote: > This may be a rudimentary linux/dt question, but doesn't the pinctrl-single > driver already support this? Couldn't one change the pin configuration by > loading a dtc overlay? pinctrl-single provides a way to set pinmux values, but not a way to switch between various sets of values. And yes, you can change the pinmux values by loading a device tree overlay, but you cannot do this repeatedly (ie: load several device tree overlays in sequence that modify the same pin) and there is no way to control individual pins without having individual device tree overlays for each pin and separating the hardware drivers (ie: timer, uart, etc) from the pinmux overlays. If you do this, you have basically recreated the cape-universal overlays as a series of many small files instead of a single overlay (except you have to load/unload overlays to change the pin muxing rather than just write to a file in sysfs). -- Charles Steinkuehler char...@steinkuehler.net -- 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/1a9ada6a-2543-2cbd-13a2-5a1ec13ede4b%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] why is pinmux-helper needed?
The pinmux helper driver is required because modifying the pinmux settings must be done in the kernel. The helper exports sysfs entries that can be modified by standard user-mode code. Also, the pinmux helper provides a way to support multiple pinmux options, vs. a typical device tree where pins only have a single function. For example: "Typical" Device Tree: A UART driver is enabled, with pinmux entries that set the various pins as required for Rx, Tx, RTS/CTS, etc. These pins are now fixed and cannot be used as anything else (like GPIO or some other special function that also exists on any of those specific pins). "Universal" Device Tree: A UART driver is enabled, but does not include any pinmux settings. The pinmux helper driver is enabled with a large choice of pinmux options for each pin, and a default setting for the desired pinmux mode when the overlay is initially loaded. The user can now switch individual pins between the UART functions, GPIO, and any other functions enabled on the pins. This is far more flexible for the casual hobbyist, and allows things like an Rx or Tx only UART which are not supported with the typically available device tree overlays. Note that I did not write the pinmux helper driver, although I have submitted a few tweaks to the code. On 3/1/2017 5:38 PM, robertsmaria934 via BeagleBoard wrote: > > > On Wed, 3/1/17, John Syne <john3...@gmail.com> wrote: > > Subject: Re: [beagleboard] why is pinmux-helper needed? > To: "Beagle Board" <beagleboard@googlegroups.com> > Date: Wednesday, March 1, 2017, 10:26 PM > > You need to > understand how the pins are configured when defined in the > devicetree. It is the driver that does the pin configuration > as defined in the devicetree. Without an associated driver, > the pins defined in the devicetree won’t do anything. When > using PRU, there is no driver, so the pins don’t get > configured and hence that is why pinmux-helper is > necessary. > > Regards,John > > > > > > > On Feb 28, 2017, at 9:32 PM, ags > <alfred.g.schm...@gmail.com> > wrote: > If there is a better place for this post please > move - after all, pinmux is for more than GPIO, right? > I've been trying to figure out why > pinmux-helper is needed. I've searched and found initial > RFC and followup in the early years (by Charles > Steinkuehler) and I understand the motivation (I think) as > stated, but I don't understand the basics behind the > why. > Before pinmux-helper was provided, > wasn't it possible to use sysfs to change pinmux and > gpio settings for all exported pins? Weren't all pins > exported? (If not, couldn't exporting them all have been > an alternate solution?) And couldn't loading a device > tree fragment be used to change the current state? If > changes to pin state were to be made frequently, I can see > how those methods would be cumbersome; however, isn't > pin state configuration something that is done rather > infrequently, as it implies that the BBB is being repurposed > and connected to different hardware (physically)? > > This question extends to config-pin > utility, as well as the cape-universal (and associated) dtb > files. Wasn't all this possible already? > Let > me be clear that I'm not criticizing the work that has > been done - rather I'm trying to use the evolution of > capes, cape manager, dtb, drivers etc as a way of better > understanding how the underlying drivers, device trees, and > sysfs controls work. > > > -- > > 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/6ae54709-0f14-4a73-a01b-6efd024f4525%40googlegroups.com. > > 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 beagleboard+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/E6A2E452-2FE6-426F-8975-467FACE5415E%40gmail.com. > > For more options, visit https://grou
Re: [beagleboard] Re: eQEP not reading meaningful values
On 2/10/2017 3:54 AM, abhilash h wrote: > Hi hugh, > Can you share the link of universal cape It should be built into the kernel if you are using anything fairly recent and built by Robert C Nelson (basically any of the available Debian uSD images). The original source (for the 3.8.13 kernel) can be found here: https://github.com/cdsteinkuehler/beaglebone-universal-io ...while RCN's versions updated for 4.x kernels live alongside all the other bb.org overlays: https://github.com/RobertCNelson/bb.org-overlays/tree/master/src/arm -- Charles Steinkuehler char...@steinkuehler.net -- 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/e0cb1b20-e8a3-96e0-ffb8-faacd14f34f3%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Why use PRU shared DRAM (12k) over individual core DRAM (8k)?
On 2/9/2017 8:42 PM, William Hermans wrote: > > But the point is really this. If you need to get data out of the PRU's into > userland Linux as quickly as possible. Maybe the way to pull that data ot of > the > PRU's memory is from the ARM(Linux ) side of things ? No, you want to have the PRU doing writes. In modern systems, writes are fast (they can get posted so they complete at the initiator side and can take their time working through the various interconnect fabrics to make their way to their ultimate destination). Reads typically stall the initiator until the data is received. If you need to move data quickly from the PRU to the ARM, reference the BeagleLogic code. That moves data pretty much as quickly as the hardware physically allows (which requires a kernel module): https://github.com/abhishek-kakkar/BeagleLogic -- Charles Steinkuehler char...@steinkuehler.net -- 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/4320e03a-a798-efa4-9be0-2c01f7c8b1ea%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Why use PRU shared DRAM (12k) over individual core DRAM (8k)?
On 2/9/2017 7:37 PM, William Hermans wrote: > However, the 8k memory used by each PRU core, as well as the shared 12k > memory > each PRU has access to is supposed to be single cycle read / write access. In > fact each PRU core as I understand it has the ability to "broadside" all of > it's > 32bit registers in a single cycle over to the 12k shared memory. You cannot "broadside" store the register file into the 8k or 12k data rams, only into one of the three scratch pad locations or directly into the other PRU's register file. Table 4-21 (of the AM335x TRM version spruh73o) lists what happens when you encounter collisions or stalls with the XIN/XOUT commands. -- Charles Steinkuehler char...@steinkuehler.net -- 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/ac968e7e-03be-f91f-e47b-0476c7f777ee%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Why use PRU shared DRAM (12k) over individual core DRAM (8k)?
On 2/7/2017 8:04 PM, ags wrote: > I'm working on using the PRU for critical signal timing, paired with userland > code that loads data into the PRU local memory. > > I've done a lot of research learning about latency wrt local and system > resources, L3/4 fabric delays, etc. In each case, I haven't seen any > difference > in the read/write (load/store from the PRU sense) time (PRU cycles) between > the > PRU core-specific 8k DRAM and the shared 12k DRAM. I also see that PRU0 can > access PRU1's 8k DRAM, and vice versa. So in effect the 8k DRAM is also > shared > between the two PRU cores. So other than providing more memory than the 8k > for > each PRU core, why would one use the 12k DRAM? > > [Note: I haven't seen any posts measuring latency of load/store from one PRU > core to the other PRU core's DRAM. Could that be the advantage of the 12k > shared > DRAM - same timing when being accessed by either PRU core? If both cores are > accessing either the shared 12k or core-specific 8k DRAM concurrently, would > that cause one to stall?] The available TRM is a bit light on specifics, but I would expect the 8K DRAM for each core is single port memory and is highly likely to incur wait states if both PRU cores are trying to read from the same memory bank. I would expect the 12K shared memory to be at least 2-port (so both PRUs could access it simultaneously without incurring wait states) and possibly triple ported (so the ARM core could access the memory without potential wait states). ...and of course 12K is bigger than 8K! :) -- Charles Steinkuehler char...@steinkuehler.net -- 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/5b30675e-b63a-8571-1085-d1ff0b267306%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Trouble using config-pin to config P9.28 pin as spi or gpio
On 1/27/2017 7:43 PM, Drew Fustini wrote: > > Charles / Robert: > Should P9.28 be SPI by default? All pins are GPIO by default, with pull up/down set to match the reset defaults of the processor. To use P9.28 as SPI, in addition to loading cape-universal, it is necessary to run: config-pin P9.28 spi If this does not result in the pinmux being set to spi, it's a bug. -- Charles Steinkuehler char...@steinkuehler.net -- 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/deb8e3c7-15c4-c8fd-0ed4-345e04fd%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: PRU cycle counter overflow
On 12/22/2016 10:45 AM, Justin Pearson wrote: > I have the same question. > > I'm using the PRU's 200 MHz cycle counter to timestamp sensor measurements. > At > 200 MHz, this 32-bit counter overflows in 20 seconds. I would like to notify > a C > program running on the 1GHz host ARM processor as soon as it overflows. > > *Is it possible to configure the PRU cycle counter to trigger an interrupt in > the host ARM when it overflows?* Do you mean the Cycle register (offset 0x0C in the PRU_ICSS_PRU_CTRL register bank)? If so, this counter doesn't even wrap around (it automatically stops when it hits 0x) much less generate an interrupt. > I know how to write PRU code to make the PRU trigger an interrupt in the > host, > but that's not quite what I want, since my PRU will be busy doing other > things. > I would like the cycle counter to trigger an interrupt automatically, without > the PRU having to check if it has overflowed. Try using the IEP timer. It will wrap automatically, and you can even setup a configurable period by using compare register zero and setting the CMP0_RST_CNT_EN bit. You can also route an IEP timer event (pr1_iep_tim_cap_cmp_pend) to the ARM core to generate an interrupt. -- Charles Steinkuehler char...@steinkuehler.net -- 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/3e1b910f-6ec3-06d1-ab1c-fd10dd3c7856%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Pru Timer Capture
On 12/18/2016 5:08 PM, Amr Alanwar wrote: > Hi All > > I would like to use PRU on BBB to capture the time of an event on an external > pin. > In short, how to use PRU timers to do input capture? Exactly the same way you use the timer/capture hardware on the ARM side, you just have to write the code to run on the PRU instead. See section 15.3 of the TRM "Enhanced Capture (eCAP) Module)" for use cases and example setup. Note the latest universal overlays now allow pin multiplexing for the PRU eCAP and UART hardware, and I can verify the PRU eCAP works in PWM mode (which is what I'm using) and it should work fine in capture mode as well. -- Charles Steinkuehler char...@steinkuehler.net -- 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/186275e9-9b60-52c3-9111-940784a48417%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Possible to remove eeprom?
On 12/17/2016 12:12 PM, ferdster wrote: > Hallo TJF, > > I think you are referring to the eMMC. I am talking about the small i2c > eeprom > that is used to identify the board. Like Robert Nelson said, you're going to have to hack on U-Boot to remove all the EEPROM calls. ...but unless you are *REALLY* worried about parts cost, I'd suggest leaving it in the design. It makes a great place to store MAC addresses, serial numbers, and any other board specific settings you might need (DRAM flavor, production calibration values, or whatever). Yes, you can store these in the eMMC or uSD, but that makes it much more likely for these values to get overwritten or lost. ...and at least part of the EEPROM cost is covered by not having to maintain a custom U-Boot branch for your board, and by simplified software management later on if you ever ship similar but not quite identical versions of your board. Imagine if all the BeagleBoard variants didn't have an EEPROM and had to have a custom U-Boot and flasher image for every version (and all the various ways folks in the field would mess this up when upgrading!). -- Charles Steinkuehler char...@steinkuehler.net -- 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/80f8808d-1f85-6421-fb84-f67d0d86a223%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] PRU UART Debian 8.6
On 12/6/2016 4:42 AM, pidders...@gmail.com wrote: > Hi, I have found setting the pru uart pins P9_17 and P9_18 to mode 5 does > not work using config-pins with the latest release Debian 8.6. > The overlays I used in Debian 7.9 no longer work. I have found that the > overlay used to disable the hdmi, univ-emmc-00A0.dtbo does > not include the pru_uart option for P9_17 and P9_18, whereas cape-universal > does. So I copied the entries for P9-17 & -18 over to > univ-emmc, recompiled and copied to /lib/firmware which seems to solve the > problem. Has anyone else had a similar experience? I only recently added support for the PRU peripherals. Your problem stems from the fact that I do not have a univ-emmc cape in my original repo: https://github.com/cdsteinkuehler/beaglebone-universal-io ...so the univ-emmc overlay didn't get updated when the changes were merged into the official BB overlay repo: https://github.com/beagleboard/bb.org-overlays ...and it's likely the other univ-* capes have the same problem (the cape-univ* files exist in my original repo and should be OK). I'm sure Robert Nelson would appreciate a PR! -- Charles Steinkuehler char...@steinkuehler.net -- 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/c4773580-8e6a-17e8-e7a7-f96e00966ddf%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] BeBoPr rev 3 with bridge questions
On 12/6/2016 10:00 PM, John Warren wrote: > Hi all. Ive got me a bebopr rev 3 w/ bridge and a bbb. Ive been > combing through the github wiki and was hoping someone with some > experience could lend me a hand. > > Ive had this board for YEARS now and have not been able to get it to > turn my steppers. I think it may have something to do with dip switch > positions but cant find documentation on what they do or how to set > them. Do you have a manual for your BeBoPr? Bas wrote an excellent manual, but it was never freely available online, so if you didn't buy your board directly from him you might not have a copy. It should list most of the details you need. If you don't have a copy I can send you one off-list. > On top of that i have a hot end with an accelerometer for bed > leveling. It uses i2c. Ive seen in patch notes for the upgrade to > bebopr+++ that it has rerouted the secondary i2c so you dont need to > solder on board anymore. Is there a link to this hack? Am I able to > access this lovely feature of my hot end or am I barking up the wrong > tree? > > If anyone has some useful links or documentation that is hard to find > id really appreciate it. The bridge board schematics and details are on github: https://github.com/modmaker/BeBoPr-Bridge ...as are details for the BeBoPr++: https://github.com/modmaker/BeBoPr-plus-plus You may also find some helpful details in modmaker's other github repositories, depending on the specific hardware you have (decamux, take-5), and there are some hardware specifics in the various BeBoPr pages on elinux.org. Note that Bas Laarhoven (aka: modmaker, the BeBoPr designer) passed away some time ago, so several resources (the BeBoPr forum, aeselectronics.nl, etc.) are no longer online. :( -- Charles Steinkuehler char...@steinkuehler.net -- 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/64164fe6-e9fa-31cb-f11b-06ea07503ded%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] PRU Mem Map - General Registers ,Shared Ram,Data Ram
On 11/27/2016 6:35 PM, Neil Jubinville wrote: > > Description of the program: > > An LED toggles on and off from a set delay time in R2. > > A separate C program loads the PRU program, starts the core and then prompts > the > user for a Time to do a delay. Upon the user entering a time, the c program > writes that value to dataram and reads back the mapped memory from the PRU to > show. > > The PRU loop does a SBBO each time as well as a LBBO for a single R2 . My > LBBO > call however is not returning the proper value, I am likely using the wrong > pointer value. > > Here is where I believe the problem is, how I interpret what register address > to > start at by setting an arbitrary r9 to the start. > > *ldir9, 9 // offset to the start of the third 32 bit value * > *lbbo r2, r9, 0 ,4 // read 4 bytes from there and store it into r2* First, 9 is not the proper offset for the third 32-bit value (that would be 12, or 3 values * 4 bytes/value). Second, you are reading *AND* writing the memory location you are trying to monitor in your PRU code. That means a new value will *ONLY* be picked up if the ARM side updates the value in between the write and the read. You should structure your code so that for any given memory location, only one side (ARM or PRU) writes the values. -- Charles Steinkuehler char...@steinkuehler.net -- 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/e9c69c98-f487-45c2-7412-3f657fe14d70%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] PRU Mem Map - General Registers ,Shared Ram,Data Ram
On 11/26/2016 1:33 PM, Neil Jubinville wrote:
>
> Here is my basic understanding - Focusing on PRU0:
>
> Each PRU has 8K of 'dataram' - This is where I expect R1,R2,R3 R31 to
> be
> stored. *Is this true? I see many people changing the reference at
> *0x_0n00,
> n = c24_blk_index[3:0], do I need to set where the Rn's lay down in memory?
NO
The data ram is what it says...data ram. The registers are what they
say...registers. Registers are *NOT* data ram. If you want the
register values to appear in memory, you have to write them out using
the SBBO instruction.
> Docs also state that the PRU 0 Data ram starts at *0x4a30*;
>
> int registerStart;
> registerStart = *(int*)0x4a30;
> printf("--> R0 = %d" + registerStart);
>
> However I get a seg fault trying to print what is in R0 that way. That was
> more
> to just do a direct look see if possible and go around all the interfaces.
0x4a30 is a physical address. You can use that if you are
directly accessing memory (via /dev/mem, bus-mastering DMA, or
something that doesn't use an MMU like the PRU core). If you try to
access a physical address from a standard application that has not
been mapped into your process memory space, the MMU will forbid access
and your program seg-faults.
To access the PRU memory in your application, use the address provided
to you by the prussdrv_map_prumem function.
--
Charles Steinkuehler
char...@steinkuehler.net
--
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/c86ac4d1-9d7e-ce4d-9f90-e6701561a431%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Use PWM and UART at the same time
On 11/7/2016 2:38 PM, Theodosis Ntegiannakis wrote: > > On Monday, November 7, 2016 at 3:29:07 PM UTC+2, Charles Steinkuehler wrote: > > You have to set the pins to the proper pinmux values for UART and PWM, > not just load the overlay. > > How do you suggest i should enable all the pins needed? > If i try to enable BB-PWM0,1,2 overlays pwm still doesn't work from > Adafruit_BBIO library... Use the universal overlay. I created it specifically because it is difficult or impossible to load several of the individual overlays for various functions (like PWM and UART) because they conflict. ...or craft your own custom overlay with exactly what you want, but that is a fairly high barrier to entry for most users. The universal overlay allows selecting specific pin functions on a per-pin basis, while enabling most of the commonly used special hardware features. -- Charles Steinkuehler char...@steinkuehler.net -- 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/b971cec1-c629-74c9-078d-db6e41f5b52e%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Use PWM and UART at the same time
On 11/6/2016 4:46 PM, Theodosis Ntegiannakis wrote: > > With the above settings ADC and PWM works fine, but not UART... > Although /dev/ttyO2 and /dev/ttyO4 are present it doesn't work. You have to set the pins to the proper pinmux values for UART and PWM, not just load the overlay. > I am having trouble understanding dts files in order to create my own overlay. > Also when i tried to run config-pin i get command not found You are running a non-standard distribution. The universal overlays are part of the BBB kernels, but the config-pin utility is probably not getting installed. Just grab it from github: https://github.com/cdsteinkuehler/beaglebone-universal-io ...or you can directly play with the sysfs entries created by the overlay. > and with sudo sh -c "echo 'BB-UART2' > > /sys/devices/platform/bone_capemgr/slots" > i get sh: echo: I/O-error This generally means the cape couldn't be loaded. You can sometimes find more detail at the end of dmesg output, but failures when trying to load capes are usually pretty cryptic. -- Charles Steinkuehler char...@steinkuehler.net -- 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/db971a2d-a086-ddc1-2d15-bbfd9958ff77%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: No MLO-file on newer BBG's?
On 11/4/2016 7:50 AM, Paul Plankton wrote: > OK just to understand this: > > To clarify, the 512 bytes is just for the first sector of the MBR that has > the partition table in it. We actually skip by that to an offset of 128k. > Based on Robert's instructions, 256 *k*bytes (384-128) is reserved for the > MLO. Of course, MLO needs to fit in the internal RAM of the processor > since > this is the first place the DDR is configured, so your MLO would never get > to be that large. > > First 512 Bytes are the MBR including the partition table and some other > "magic" > things. Then the MLO-file is appended (directly at 512 bytes or with an > offset > of 128k?). > > But: who is responsible to jump into the MLO-"file" at it's position in > flash? > Isn't there a special MBR-code needed that knows where to continue? This is not an x86 system that runs code from the MBR to boot-strap the system. The code that loads and executes MLO is in the on-chip ROM, details are in chapter 26 "Initialization" of the TRM. Read through section 26.1.7.5 "MMC / SD Cards". -- Charles Steinkuehler char...@steinkuehler.net -- 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/9a454233-eadb-78f0-8a95-94f9e347097a%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] How susceptible is BeagleBone to the Mirai software?
On 10/27/2016 1:12 PM, Josiah Yoder wrote: > I teach a real-time systems class where students use Beaglebone over the > network. Generally, we are behind a protected firewall, but sometimes the > students want to debug on other parts of the campus. > > By default, one can access the root account without a password. If my > students > put such a BeagleBone on a network where the IP is externally visible, is it > likely that the BeagleBone will become infected by the open-source botnet > software Mirai? > > I guess it's a moot point -- the root password should be changed before > attaching the BeagleBone to a public network anyway! At the very least, you need to set a root password, set a password for the default user, and disable the "no password" sudo access. I would also recommend reviewing the open network ports and disabling anything you don't need to use or that isn't secure. You probably don't want things like xrdp and xvnc visible on the raw internet. -- Charles Steinkuehler char...@steinkuehler.net -- 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/898a16f2-324e-d6f1-8934-8e59a4bbbea5%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] cannot set P9.42 as INPUT MODE6 0x26
On 10/25/2016 1:12 PM, malkowki wrote: > In fact I want to check the PRU memory register when the pin is set > as input and forced to 3.3V. I know that from user space we use > sysfs to export the pin. I have some doubt if it the same mechanism > for the PRU GPIO? Leave the PRU input (P9.42B) alone. Export the other pin (P9.42) as GPIO and set it to drive high. Since the pins are wired together on the BBB, the PRU should see the input as '1'. Make sure you switch P9.42 back to input before hooking it to whatever signal source you're planning on using. -- Charles Steinkuehler char...@steinkuehler.net -- 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/ab2d17b4-6c8a-8231-51c3-04a4b09b1c8c%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] cannot set P9.42 as INPUT MODE6 0x26
On 10/25/2016 11:01 AM, Beninio Mbila wrote: > Hello Charles, > > Thanks for this remark, I have changed the dts file now it is ok. > > I want to force 3.3V to the PIN9.42 and check in the memory register that the > value is "1", do you know how I can check this? Since you are not claiming the pin in your device-tree overlay (you should, and force it to be an input), you ought to be able to simply export the GPIO via the kernel and set it to output a '1' like any other GPIO pin. -- Charles Steinkuehler char...@steinkuehler.net -- 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/5ccab5c4-7e93-152e-5d8d-0c9d6f404e5d%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] cannot set P9.42 as INPUT MODE6 0x26
On 10/25/2016 9:48 AM, malkowki wrote: > > Why pin 89 is set as 0x27 (GPIO MODE) instead of |0x1a0 0x26// P9_42B > pr1_pru0_pru_r31_4, MODE6 | INPUT | PRU 00100110=0x26?? > > Any Idea what could be the reason??? Because you are not setting the pinmux at 0x964 (P9_42), just the one at 0x9a0 (P9_42B). The pinmux at 0x9a0 should be set for PRU in, and the pinmux at 0x964 should be set for GPIO input to avoid potentially conflicting with whatever is driving the signal. -- Charles Steinkuehler char...@steinkuehler.net -- 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/bb686cad-189b-b79b-6a06-e925d7a28099%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Time beween pulses
On 10/20/2016 12:44 PM, TJF wrote: > > eCAP is the right module to use. > > Am Donnerstag, 20. Oktober 2016 12:22:36 UTC+2 schrieb Charles Steinkuehler: > > ... record the time it happened with up to 5 nS resolution. > > The resolution is up to 10 nS (100 MHz clock), so the maximum frequency is 50 > MHz. Oops...I've been using the eCAP in the PRU sub-system, which does have 5 nS resolution (200 MHz clock). I forgot the normal system timers have a slower 100 MHz clock, so only 10 nS resolution. Still *WAY* better than anything a software loop can mange! ;-) -- Charles Steinkuehler char...@steinkuehler.net -- 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/f305e34a-d571-8078-776f-34451555999b%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Time beween pulses
On 10/19/2016 6:50 PM, Arthur Caio wrote: > Hello you all! > > I need to calculate hot much time it takes for an input to go from LOW to > HIGH > and then to LOW again. Basically, I want to know the period of a square wave > generated by the LM555 timer. Use an eCAP timer input pin. That's what the eCAP capture-compare timers are for...they capture the rising and/or falling edges of signals and record the time it happened with up to 5 nS resolution. -- Charles Steinkuehler char...@steinkuehler.net -- 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/26356533-2770-59e7-f925-8421d4716428%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] SGX on 4.4.*-ti-rt kernel
On 10/17/2016 10:42 AM, Robert Nelson wrote: > > The libraries are built for egl/wayland, so remember no x.. What's the status of wayland on the BBB with Debian Jessie? ...or is that more "build from source" fun, like the SGX drivers themselves? -- Charles Steinkuehler char...@steinkuehler.net -- 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/deb402c8-baf9-0b31-b4da-cca2cc469cd9%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] ARM->PRU->ARM interrupts for data transfer from ARM->PRU
All of the examples are "shared memory", including the initial code
(which used shared memory and interrupts). "Shared memory" in this
case meaning memory that both the ARM core and the PRU core have
read/write access to.
If the links William provided aren't what you are looking for, be a
bit more specific about your question and it will be easier to help you.
On 10/14/2016 11:10 AM, William Hermans wrote:
> My mistake, I think the second link I gave is an explanation of the PRU
> shared
> memory and not DDR shared memory. So, if you do a google search for
> "beaglebone
> pru shared ddr memory" there are lots of hits out there. You're bound to find
> something that makes things understandable.
>
> On Fri, Oct 14, 2016 at 8:48 AM, William Hermans <yyrk...@gmail.com
> <mailto:yyrk...@gmail.com>> wrote:
>
> awesome! Thank you! Do you know where I can find a good example of
> using shared memory? I am wondering if I might be better off using
> shared memory instead. Does shared memory work both ways so that ARM
> can access the PRU memory and PRU access the ARM memory?
>
>
> There is a DDR example here:
>
> https://github.com/beagleboard/am335x_pru_package/tree/master/pru_sw/example_apps/PRU_memAccess_DDR_PRUsharedRAM
>
> <https://github.com/beagleboard/am335x_pru_package/tree/master/pru_sw/example_apps/PRU_memAccess_DDR_PRUsharedRAM>
>
>
> Then if you need a better explanation of the code( Like I would ). You can
> read this:
>
> http://www.embedded-things.com/bbb/understanding-bbb-pru-shared-memory-access/
>
> <http://www.embedded-things.com/bbb/understanding-bbb-pru-shared-memory-access/>
>
> On Fri, Oct 14, 2016 at 4:36 AM, Jay Doobie <doobi...@gmail.com
> <mailto:doobi...@gmail.com>> wrote:
>
> awesome! Thank you! Do you know where I can find a good example of
> using shared memory? I am wondering if I might be better off using
> shared memory instead. Does shared memory work both ways so that ARM
> can access the PRU memory and PRU access the ARM memory?
>
>
> On Thursday, October 13, 2016 at 10:59:26 PM UTC-4, Charles
> Steinkuehler
> wrote:
>
> On 10/13/2016 5:48 PM, Jay Doobie wrote:
> > Hi,
> >
> > I'm trying to send some data from ARM to the PRU for the PRU to
> execute upon it,
> > but I'm having some issues where it tends to miss some of the
> data on the PRU,
> > so I assume I am not synchronizing the interrupts properly,
> here
> is basically
> > what I am doing:
> >
> > C code:
> >
> > for (i = 0; i < 10; i++) {
> > prussdrv_pru_write_memory(PRUSS0_PRU0_DATARAM,
> SHARED_MEMORY, (unsigned
> > int*)pkts[i], memSize);
> >//if I put a sleep here it generally works:
> usleep(50);
>
> The ARM has a weak memory model. You need a memory fence
> instruction
> here to insure that all writes before the fence (your write to
> the PRU
> memory, above) have completed before any writes after the fence
> (generating the PRU interrupt) take effect.
>
> It's a bit ham-fisted, but you can use a __sync_synchronize() here
> (assuming you're using gcc...it's a full memory barrier). Or you
> can
> use the C++11 memory fence semantics (more complicated). Either
> is
> way better than the "old school" full cache flush and invalidate!
> :)
>
> >//printf("sending intc...\n");
> >// here are the packets!
> >prussdrv_pru_send_event(ARM_PRU0_INTERRUPT);
> >// wait for PRU response
> >//printf("waiting intc...\n");
> >prussdrv_pru_wait_event (PRU_EVTOUT_0);
> >// clear PRU response
> >//printf("clr intc from PRU0...\n");
> >prussdrv_pru_clear_event (PRU_EVTOUT_0,
> PRU0_ARM_INTERRUPT);
> >
> > }
> >
> > PRU:
> >
> > HANDLE_DATA:
> > // wait for interrupt
> > WBS r31, #30
> > // reset interrupt
>
Re: [beagleboard] ARM->PRU->ARM interrupts for data transfer from ARM->PRU
On 10/13/2016 5:48 PM, Jay Doobie wrote:
> Hi,
>
> I'm trying to send some data from ARM to the PRU for the PRU to execute upon
> it,
> but I'm having some issues where it tends to miss some of the data on the
> PRU,
> so I assume I am not synchronizing the interrupts properly, here is basically
> what I am doing:
>
> C code:
>
> for (i = 0; i < 10; i++) {
> prussdrv_pru_write_memory(PRUSS0_PRU0_DATARAM, SHARED_MEMORY, (unsigned
> int*)pkts[i], memSize);
>//if I put a sleep here it generally works: usleep(50);
The ARM has a weak memory model. You need a memory fence instruction
here to insure that all writes before the fence (your write to the PRU
memory, above) have completed before any writes after the fence
(generating the PRU interrupt) take effect.
It's a bit ham-fisted, but you can use a __sync_synchronize() here
(assuming you're using gcc...it's a full memory barrier). Or you can
use the C++11 memory fence semantics (more complicated). Either is
way better than the "old school" full cache flush and invalidate! :)
>//printf("sending intc...\n");
>// here are the packets!
>prussdrv_pru_send_event(ARM_PRU0_INTERRUPT);
>// wait for PRU response
>//printf("waiting intc...\n");
>prussdrv_pru_wait_event (PRU_EVTOUT_0);
>// clear PRU response
>//printf("clr intc from PRU0...\n");
>prussdrv_pru_clear_event (PRU_EVTOUT_0, PRU0_ARM_INTERRUPT);
>
> }
>
> PRU:
>
> HANDLE_DATA:
> // wait for interrupt
> WBS r31, #30
> // reset interrupt
> LBCOr20, CONST_IEP, 0x44, 4 // Load CMP_STATUS register
> sbco rResetInterrupt, CONST_PRUSSINTC, SICR_OFFSET, 4
> // handle data
> MOV R31.b0, PRU0_R31_VEC_VALID | PRU_EVTOUT_0
> sub rCounter, rCounter, rCounter
> qbne HANDLE_DATA, rCounter, 0
>
>
> Kernel: Linux beaglebone 3.8.13-bone79 #1 SMP Tue Oct 13 20:44:55 UTC 2015
> armv7l GNU/Linux
>
> Thanks!
--
Charles Steinkuehler
char...@steinkuehler.net
--
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/976503b9-3eb1-1d9c-d5c7-6ae719180872%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: problems with static ip address on eth0
You need to configure connman, not /etc/network/interfaces: https://groups.google.com/forum/#!topic/beagleboard/yfNwIk_dWlg On 10/6/2016 11:02 PM, yang13...@gmail.com wrote: Hi, Have you solve the problem? I have the same problem as you, could you please advise? On Monday, July 18, 2016 at 9:52:08 PM UTC+8, bart.van...@gmail.com wrote: I downloaded the newest image (bone-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb) and I am now trying to configure the eth0 to be able to use the BBB on our network. I can connect to it over USB link. I changed the /etc/network/interfaces file to the content shown below, but after reboot the BBB gets address 169.254.129.50 (an address assigned after failed DHCP assignment attempt?) After some searching, I have the impression that this is because the usb0 link uses dhcp, and the BBB is also using this on eth0, although I tell it to use 'static' in the interfaces file. If I restart the eth0 link using 'ifdown eth0' and 'ifup eth0' then it does get the right ip address, and I can ssh to it over the eth0 interface. But this is not really a good solution, and I have the impression that some other network settings, (dns, ...) are still misconfigured. I tried deleting the usb0 link from /etc/interfaces, and disabling the /opt/scripts/boot/autoconfigure_usb0.sh script, but that didn't help either. Is there any way I can force it to use a static IP address on eth0? Thanks for any help Bart root@beaglebone:/etc/network# cat interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet static dns-nameservers 8.8.8.8 8.8.4.4 address 30.0.0.39 netmask 255.0.0.0 network 30.0.0.0 gateway 30.0.0.1 # Example to keep MAC address between reboots #hwaddress ether DE:AD:BE:EF:CA:FE # The secondary network interface #auto eth1 #iface eth1 inet dhcp # WiFi use: -> connmanctl # Ethernet/RNDIS gadget (g_ether) # Used by: /opt/scripts/boot/autoconfigure_usb0.sh iface usb0 inet static address 192.168.7.2 netmask 255.255.255.252 network 192.168.7.0 gateway 192.168.7.1 -- 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 <mailto:beagleboard+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/601f2ca4-d3f3-4700-9ac7-d7c591cf5a8a%40googlegroups.com <https://groups.google.com/d/msgid/beagleboard/601f2ca4-d3f3-4700-9ac7-d7c591cf5a8a%40googlegroups.com?utm_medium=email_source=footer>. For more options, visit https://groups.google.com/d/optout. -- Charles Steinkuehler char...@steinkuehler.net -- 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/3c9681e6-5e33-0f01-9763-2263b7d0cb5e%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Pinmux Problems
On 9/25/2016 9:23 AM, Charles Steinkuehler wrote: > I'm trying to add some new pinmux modes to the universal overlay, but > something fundamental seems to be wrong. I'm using the RCN built > machinekit image with the 3.8.13-xenomai-r79 kernel. I started with > the existing dts > (/opt/source/beaglebone-universal-io/cape-universal-00A0.dts), gave it > a new name and compiled it. When I try to load it, however, I get > *TONS* of errors, pretty much all of them looking like this: > >> [ 2758.176552] bone-pinmux-helper P8_07_pinmux.14: could not find pctldev >> for node /ocp/interrupt-controller@4820, deferring probe >> [ 2758.176578] bone-pinmux-helper P8_07_pinmux.14: Failed to get pinctrl >> [ 2758.183378] platform P8_07_pinmux.14: Driver bone-pinmux-helper requests >> probe deferral >> [ 2758.183812] bone-pinmux-helper P8_08_pinmux.15: could not find pctldev >> for node /ocp/edma@4900, deferring probe >> [ 2758.183834] bone-pinmux-helper P8_08_pinmux.15: Failed to get pinctrl >> [ 2758.190601] platform P8_08_pinmux.15: Driver bone-pinmux-helper requests >> probe deferral >> [ 2758.190934] bone-pinmux-helper P8_09_pinmux.16: could not find pctldev >> for node /fixedregulator@0, deferring probe >> [ 2758.190948] bone-pinmux-helper P8_09_pinmux.16: Failed to get pinctrl > > ...and most of the pinmux control files don't get created in sysfs. > > If I just load the cape-universal overlay that's built-in to the > kernel, it works fine. > > I'm pulling the 3.8.13-xenomai-r79 kernel source, but it's going to > take a while (my local kernel git repo is very stale). Are there some > recent changes that would cause "legacy" universal capes to suddenly > stop working properly? Problem solved...it's not an issue with the overlay, it's the device-tree-compiler. The dtc version on recent images is 1.4.1, but the version used by the 3.8.13 kernel is 1.2.0-g37c0b6a0. If I use the dtc from the kernel source I can happily load a freshly compiled overlay. Robert: Any idea exactly what's going on? Both versions report that they generate version 17 dtb blobs by default, but something is obviously different in the results. Also, I didn't see a package for the older dtc available in the repos (just 1.4.0 and 1.4.1). Is there a way to get 1.4.x to make a dtb the 3.8.13 kernel will like or a suggested way to install the appropriate dtc on the Machinekit images when built? I just copied the dtc binary from the 3.8.13 kernel tree, but that's probably not a desired end-user experience. :) -- Charles Steinkuehler char...@steinkuehler.net -- 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/00c1e50c-80f7-eee5-c835-e10dbb3a6fa1%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Pinmux Problems
I'm trying to add some new pinmux modes to the universal overlay, but something fundamental seems to be wrong. I'm using the RCN built machinekit image with the 3.8.13-xenomai-r79 kernel. I started with the existing dts (/opt/source/beaglebone-universal-io/cape-universal-00A0.dts), gave it a new name and compiled it. When I try to load it, however, I get *TONS* of errors, pretty much all of them looking like this: > [ 2758.176552] bone-pinmux-helper P8_07_pinmux.14: could not find pctldev for > node /ocp/interrupt-controller@4820, deferring probe > [ 2758.176578] bone-pinmux-helper P8_07_pinmux.14: Failed to get pinctrl > [ 2758.183378] platform P8_07_pinmux.14: Driver bone-pinmux-helper requests > probe deferral > [ 2758.183812] bone-pinmux-helper P8_08_pinmux.15: could not find pctldev for > node /ocp/edma@4900, deferring probe > [ 2758.183834] bone-pinmux-helper P8_08_pinmux.15: Failed to get pinctrl > [ 2758.190601] platform P8_08_pinmux.15: Driver bone-pinmux-helper requests > probe deferral > [ 2758.190934] bone-pinmux-helper P8_09_pinmux.16: could not find pctldev for > node /fixedregulator@0, deferring probe > [ 2758.190948] bone-pinmux-helper P8_09_pinmux.16: Failed to get pinctrl ...and most of the pinmux control files don't get created in sysfs. If I just load the cape-universal overlay that's built-in to the kernel, it works fine. I'm pulling the 3.8.13-xenomai-r79 kernel source, but it's going to take a while (my local kernel git repo is very stale). Are there some recent changes that would cause "legacy" universal capes to suddenly stop working properly? -- Charles Steinkuehler char...@steinkuehler.net -- 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/27466936-db6f-f64f-6c0b-966f488d968a%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] High speed encoder input capability of BBB?
On 9/11/2016 3:27 PM, beezerlm wrote: > I guess I wouldn't consider myself proficient with the Linux HAL seeing as I > have only used it one time to set up a machine. Wouldn't latency and jitter > be > lower going direct through the PRU instead of utilizing the HAL assuming the > PRU > was capable of handling my logic loop? Yes, latency and jitter for anything running on the PRU will probably be in the uS time-scale. A typical real-time HAL processes running on the ARM core will have millisecond scale cycle rates with ~75 uS of jitter. So the PRU is definitely much faster, but it will probably require custom programming for your application The HAL solution could be implemented with existing HAL components, so no programming required (just HAL netlist wiring). -- Charles Steinkuehler char...@steinkuehler.net -- 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/46cbb85a-072b-7bcc-40f9-6ee8f46dd38b%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] High speed encoder input capability of BBB?
On 9/11/2016 9:14 AM, beezerlm wrote: > I think my project would be simple enough to run through the PRU. My current > PLC loop I am running in the motion control software is just a few ifElse > statements that monitor position and change direction. Does the PRU have > access > to the eQEP without adding latency? No and yes. :) No: Everything adds latency, even reading the PRU's direct inputs (although that only takes one clock cycle or 5 nS). Yes: Reading the eQEP from the PRU will only take a few hundred nS (during which time the PRU will be stalled), and the timing jitter will be fairly low. Unless you have particularly critical timing issues you didn't mention, the PRU can easily perform a few reads of the eQEP module while running whatever other control routines you need. > It's been a long time since I worked with a linux real time kernel and HAL. > I > did a similar project a long time ago using linuxCNC to control a Moog > hydraulic > servo-valve on an old Heald ID grinding machine. That was pretty cool to see > linux handle a Hydraulic cylinder on a PID loop. Here is a quick vid of it: > > https://www.youtube.com/watch?v=NMkNCSUJBvs > > The machinekit distro looks very similar but more streamlined and with better > hardware than what I had. I will have to dig into that a little more. If you're already somewhat familiar with HAL, this could be a good way to go. As I mentioned there are already eQEP and I/O drivers available, as well as building blocks like PID controllers, comparators, and even a classic ladder-logic control if you want to just port your PLC application. You can test things easily with the pre-built Machinekit uSD card image...just pop out the uSD if you decide you don't like using Machinekit: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#BBW.2FBBB_.28All_Revs.29_Machinekit -- Charles Steinkuehler char...@steinkuehler.net -- 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/3d26a443-4916-9408-e59e-a8692e2f7dbc%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] High speed encoder input capability of BBB?
On 9/10/2016 5:04 PM, beezerlm wrote: > > I have a fairly simple motion control project I was planning on using > an > Arduino for, but my understanding is that the arduino's 16Mhz clock won't > keep > up with my encoder pulses. I will need to process a max of 10,000 pulses per > second. The project is to control 1 reciprocating pneumatic cylinder and to > simply monitor the position and change direction at a programmable in/out > position. Is this within the capabilities of the BBB? The hardware eCAP encoder inputs on the BBB can easily keep up with this rate and much faster. The main issue you are likely to run into is latency and jitter on the ARM side running the control software. If your application is simple enough, you can write PRU code to run it and not have to worry about any ARM side system latency with Linux. If your application is more complex and you need easy access to system resources, you might consider using the Machinekit distribution. It's already setup with a hard-real-time kernel and HAL layer that has drivers for the BBB's eQEP hardware encoders. It should be fairly simple to craft a HAL file (which is basically a netlist or text version of a schematic design) using stock components that will twiddle pins based on the current encoder position. -- Charles Steinkuehler char...@steinkuehler.net -- 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/62465c16-d3da-3d4d-cd6f-8019c7da3fb9%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Header files for non PRU peripherals
On 9/8/2016 3:35 PM, Charles Steinkuehler wrote:
> On 9/8/2016 12:41 PM, William Hermans wrote:
>>
>> It has long been programing technique to use DATAOUT |= BITx to set a
>> register
>> bit DATAOUT &= (~BITx) to clear a register bit, or something like if(DATAOUT
>> &
>> BITx){} or if((DATAOUT ) == 0 or 1) to read a bit from a register.
>
> Yes, it has. But those short-hand snippits of C code are hiding an
> implicit read-modify-write cycle:
>
> DATAOUT |= BITx
>
> ...turns into:
>
> Read : = DATAOUT
> Modify: = | BITx
> Write : DATAOUT =
>
> ...where is probably a CPU register (unless your C compiler is
> _really_ bad!). But if you use the set/clear registers it's just:
>
> Write : SETDATAOUT = BITx
Oh...while we're on the subject, there's one more significant reason
the set/clear registers are helpful even if you're not worried about
multi-threaded operation: They're *FAST*
The ARM core on the BBB is running at 1 GHz, but the I/O is only
running at about 100 MHz. So that simple DATAOUT |= BITx stalls the
CPU until the system can provide the current value of DATAOUT to the
processor core, which likely takes a couple hundred nanoseconds (based
on the time it takes for the PRU to read a GPIO register).
The write, however, is very fast (for both the set/clear case and for
writing directly to DATAOUT). Writes are posted and the ARM has weak
memory ordering, so as long as you're not saturating the on-chip
interconnect fabric, the write will appear to complete instantly, the
ARM core will carry on executing instructions, and about 100 nS later
the GPIO register will update with the new value once the write
transaction has worked it's way through the on-chip interconnect fabric.
--
Charles Steinkuehler
char...@steinkuehler.net
--
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/66e45786-85b9-2302-bef4-3213f6848a8d%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Header files for non PRU peripherals
On 9/7/2016 7:50 PM, William Hermans wrote: > > SETDATAOUT -> |= BITx > CLEARDATAOUT -> &=(~BITx) > > I gues I'll have to reread the TRM again. The set/clear registers only affect the bits that are written with a '1' value, all other bits remain unchanged, while writing directly to the DATAOUT register affects the value of all 32 bits in the GPIO bank. Using the set/clear registers allows a single atomic write operation to affect the specific bit(s) you want to change without having to perform a non-atomic read-modify-write cycle. Since the write to the set or clear register is atomic, if both the ARM and the PRU both use this method, no locks or other hand-shaking is required to prevent corruption. -- Charles Steinkuehler char...@steinkuehler.net -- 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/4db8f6f0-f70a-0d28-29f9-3d0aba8dd690%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Header files for non PRU peripherals
On 9/7/2016 5:18 PM, William Hermans wrote: > > I agree with Charles with one exception. I personally prefer to use DATAOUT > directly instead of using SETDATAOUT / CLEARDATAOUT. If you write directly to DATAOUT from either the PRU or the ARM side, you risk data corruption. Example access patterns causing data corruption: 1: * PRU reads DATAOUT * ARM modifies DATAOUT * PRU writes DATAOUT * ARM Update is *LOST* 2: * ARM reads DATAOUT * PRU modifies DATAOUT * ARM writes DATAOUT * PRU update is *LOST* Both the PRU and the ARM need to use the set/clear registers for updates or some updtes can get *LOST* (which can be *REALLY* hard to debug in the RealWorld). -- Charles Steinkuehler char...@steinkuehler.net -- 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/c7da32a4-e33f-3c60-eafd-66fc188595f5%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Header files for non PRU peripherals
On 9/7/2016 1:02 PM, Kirk wrote: > > What is the recommended way to access NON PRU GPIO pins? > > I'm asking because I'm working with a custom cape board on the Beaglebone > Black > that has already been built. > And I'm trying to move some time critical code to the PRU. > I don't think all the GPIO pins that are used are in the group of PRU GPIO > pins. IMHO it works best if you setup the GPIO banks with Linux, then use the PRU to twiddle the output bits using the set and clear registers in the GPIO bank. That way you don't have to worry about any sort of locking to insure consistent updates. Note the Linux side also needs to use the set/clear registers for output updates (and not a read-modify-write sequence) to insure no updates get lost. -- Charles Steinkuehler char...@steinkuehler.net -- 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/a43516b8-e0f1-d8f0-8850-505077dc9689%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] small linux distribution working with ROS
On 8/10/2016 3:33 PM, Robert Nelson wrote: > On Wed, Aug 10, 2016 at 3:30 PM, David Kraus <davidkrau...@gmail.com> wrote: >> Hi, by ROS mean Robot Operation system (www.ROS.org), it can run on >> different distributions of linux. I want to ask if someone have good >> results, with some combination small linux and ROS. > > ROS, is in the process of being integrated into debian: > > https://wiki.debian.org/DebianScience/Robotics/ROS/Packages > > I've backported most of the packages from unstable into our default > jessie repo.. > > Grab a jessie image from here: > > http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots > > and give it a goo... I'd recommend just using a uSD card for more space. 8G and 16G class 10 (or faster) uSD cards are readily available and inexpensive. You will spend far more time and effort trying to squeeze everything into the 4G eMMC (at least when developing...once you figure out exactly what you need the 4G eMMC might be fine). In addition to Robert's stock Debian images, over at the Machinekit we're also working with ROS, trying to get it integrated to our hard-real-time motion control foundation. We're targeting the BeagleBone and some SoC+FPGA platforms (both Altera and Xilinx), and our base system is going to be built on top of RCN's Debian images with ROS either installed from the Debian package stream or built from source. -- Charles Steinkuehler char...@steinkuehler.net -- 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/bdb02dce-f9a7-b7d3-dfa4-0b114e2d7e31%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Beaglebone Black on PocketNC - Monitor conection
On 8/8/2016 2:01 PM, rs3...@gmail.com wrote: > It was the HDMI to HDMI micro that is attached to the Beaglebone for the > PocketNC. > I opened the PocketNC to see if that cable was loose or had come out. > It was in, so I pushed it in harder and it didnt seem to move. > > But that fixed it. Glad to hear it's working! I don't like the typically large and heavy HDMI to micro-HDMI connector hanging off of the BeagleBone. I'm always afraid I'm going to yank the HDMI connector off the 'Bone by accident (I'm clumsy!) and the size can interfere with the uSD slot and USB connector. I keep a few of these on-hand in various lengths instead: https://amzn.com/B0060AU5MW ...but now I see they've got an even cheaper Amazon Basics version: https://amzn.com/B014I8TVLI -- Charles Steinkuehler char...@steinkuehler.net -- 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/a22d919d-bb8e-443d-c328-c5ecab9db5f1%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Beaglebone Black on PocketNC - Monitor conection
On 8/8/2016 11:31 AM, rs3a...@gmail.com wrote: > > Mouse and keyboard work fine thru a USB 2.0 hub, but the Monitor doesnt > display > correctly. > I am using an older Dell 2001FP (which Beagle Support says "should" work) and > the display resolution of 1280x1024@60 is supposedly supported by Beaglebone > Black. > > Beagle support pages mention that there are HDMI cable problems. > > I am connecting the Dell via DVI_D to HDMI (not micro). > Is this the wrong choice? I typically use a micro-HDMI to HDMI cable, then an HDMI to DVI-D adapter, but as long as you've got micro-HDMI on one end and DVI-D (or HDMI, whichever your monitor supports) on the other you should be OK. > Should I be using a Sub-D to HDMI Micro? No, the BeagleBone doesn't output analog video, so it won't hook to a 15-pin VGA D-Sub connector. > DVI-D to HDMI Micro? Should work. > Does this image give anybody any hints as to where I might look to solve > problem? It looks like maybe a bad cable or connection, or possibly a video format the monitor doesn't like. I'd try forcing something really common, like 1024x768 or even plain VGA 640x480 using the uEnv.txt file. Since the BeagleBone isn't connecting, you can edit this file on another Linux system (probably even your Mac) if use an SD card reader. Personally, I never like connecting to the 'Bone via USB and always run either stand-alone with a KB/Monitor connected, or connect via the wir`ed Ethernet port. Worst case, you can hook a serial cable up to the console port on the BBB and assign it a fixed IP address. -- Charles Steinkuehler char...@steinkuehler.net -- 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/e7c6a5fd-1088-5064-6123-8cbbaa97a031%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
