Hi board,
I'm working on a project and there are some comms traditionally done by
RS232. The cape already has a FTDI chip connected to J1 for convenience.
So I thought that might just be the easiest solution, tell C to latch onto
ttyO0 and call it a day. Well it worked alright but the open
Also if I sudo echo to ttyO0 it doesn't show on the terminal monitoring it
on the other side.
On Tuesday, November 25, 2014 3:35:18 PM UTC-6, foreverska wrote:
Hi board,
I'm working on a project and there are some comms traditionally done by
RS232. The cape already has a FTDI chip
It does.
On Tuesday, November 25, 2014 7:06:48 PM UTC-6, William Hermans wrote:
Does the file */etc/inittab*
Contain a line similar to this - *T0:23:respawn:/sbin/getty -L ttyO0
115200 vt102*
??
On Tue, Nov 25, 2014 at 2:41 PM, foreverska chezz...@gmail.com
javascript: wrote:
Also
a line similar to this - *T0:23:respawn:/sbin/getty -L ttyO0
115200 vt102*
??
On Tue, Nov 25, 2014 at 2:41 PM, foreverska chezz...@gmail.com
javascript: wrote:
Also if I sudo echo to ttyO0 it doesn't show on the terminal monitoring
it on the other side.
On Tuesday, November 25, 2014 3
/etc/initab does have that line
the output of cat /proc/cmdline is
console=tty0 console=/dev/ttyO0,115200n8
capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G
root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc quiet
init=/lib/systemd/systemd
I got the program working I
Alright so I've been going in circles with this for hours,
I'm using debian sid and I'm trying to compile a kernel for my BBB and I
keep stumbling over this error:
sudo apt-get install gcc-4.4-arm-linux-gnueabi
Reading package lists... Done
Building dependency tree
Reading state
Steinkuehler wrote:
Well it's straight-forward to craft a device tree overlay for just the
pins you need. I'll try to get the missing HDMI overlay added soon, but
no guarantees. I've got a bunch of other stuff I'm working on right now.
On 5/23/2014 9:54 PM, foreverska wrote:
Oh... I'm barely
I could definitely use that.
On Friday, May 23, 2014 6:27:12 AM UTC-5, Charles Steinkuehler wrote:
On 5/22/2014 11:14 PM, foreverska wrote:
There we are. I got it working using C24. That's incredibly confusing.
What's config pin's deal here:
debian@beaglebone:~/Desktop/riot_bin
stages but very cramped.
On Friday, May 23, 2014 3:45:42 PM UTC-5, Charles Steinkuehler wrote:
On 5/23/2014 3:29 PM, foreverska wrote:
I thought we disabled the HDM in the first place... it's disabled in
my uENv.
Yes, recall I said:
If you want to use P8.45 you need to disable the HDMI
cores are upgraded in the AM335x parts vs. the AM18xx.
On 5/21/2014 10:57 AM, foreverska wrote:
I got C3 from TI's website:
http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit#PRU_Internal_Constants_Table_Entry_Register_n_.280x0480_.2B_4.2An.29
On Wednesday, May
I'm not 100% that the driver for that exists in ArmHF. What's dmesg say
after you plug it in?
At any rate why not a crossover cable? or through your home router?
On Thursday, May 22, 2014 7:38:09 AM UTC-5, Rasmus Prentow wrote:
Hi
I'm trying to connect two beagle bones, such that they
Code never seems to work out of the box for me on these things. Now that I
have operational code looking at R31 I have issues putting the results int
datamemory which is just absurd. Here's the code:
#define CONST_PRUDRAM C3
#define TOOTH_COUNTER R5
lpe:
ADD
That did it.
Helpful as always Charles.
On Monday, May 19, 2014 11:58:55 PM UTC-5, Charles Steinkuehler wrote:
On 5/19/2014 6:53 PM, foreverska wrote:
debian@beaglebone:~/Desktop/riot/pru_test$ cat
/sys/devices/bone_capemgr.9/slots
0: 54:PF---
1: 55:PF---
2: 56:PF
On 19.05.2014 07:08, foreverska wrote:
Has anyone used the Pin Mux Utility? I'm trying to enable R30 and R31
on my PRUs. I've had a rough time enabling device trees so I decided
to try and use the Pin Mux Utility. It seems relatively easy to use
and it produces nice .h files
/blog/2013/07/18/disabling-the-beaglebone-black-hdmi-cape/
I tested all pins with my oscilloscope, they appear to work in this
configuration.
Florian
On 19.05.2014 07:08, foreverska wrote:
Has anyone used the Pin Mux Utility? I'm trying to enable R30 and R31
on my PRUs
that
off if need be but I'm not 100% on where to do that.
On Monday, May 19, 2014 5:38:54 PM UTC-5, Charles Steinkuehler wrote:
On 5/19/2014 5:26 PM, foreverska wrote:
I tried running this and:
debian@beaglebone:~/Desktop/riot/pru_test$ config-pin -a P8.15
pruincape-universal overlay
Not the entire thing but I definitely didn't know about a SOC bridge. That
section of code is a derivation on:
http://boxysean.com/blog/2012/08/12/first-steps-with-the-beaglebone-pru/
Nothing is ever said about that and it worked for quite a few runs before
becoming lost. However, I'm more
:
// Clear syscfg[standby_init] to enable ocp master port
LBCO r0, CONST_PRUCFG, 4, 4
CLR r0, r0, 4
SBCO r0, CONST_PRUCFG, 4, 4
On 5/16/2014 5:05 PM, foreverska wrote:
Not the entire thing but I definitely didn't know about a SOC bridge.
That
section of code
and then
reset. Anyone seen this?
the code is very standard
#define GPIO1 0x4804c000
#define GPIO_CLEARDATAOUT 0x190
MOV r2, 121
MOV r3, GPIO1 | GPIO_CLEARDATAOUT
SBBO r2, r3, 0, 4
On Wednesday, May 14, 2014 11:39:03 PM UTC-5, foreverska wrote:
Okay so this is weird. It's been working fine
UTC-5, foreverska wrote:
You have responded to this at a fortuitous time. I JUST got it working on
an example code.
- I edited the device tree turning on the PRUSS system and turning off the
status lights
- modprobe uio_pruss
- sudo ./[program name]
and boom it started blinking just
You have responded to this at a fortuitous time. I JUST got it working on
an example code.
- I edited the device tree turning on the PRUSS system and turning off the
status lights
- modprobe uio_pruss
- sudo ./[program name]
and boom it started blinking just as it should. Now it doesn't exit
I'm trying to get the hang of the pru and all the examples segfault out of
the gate. So I grabbed TI's skeleton code and tried compiling and running
that, segfault. I reduced it down to the first line, fine. First 3,
segfault. Comment out prussdrv_open, fine. Thow -g at the compiler and
,
wh
Am 10.03.2014 03:34, schrieb foreverska:
Well I got it to go finally by:
using gparted to format the 73mb boot partition as FAT
rewriting the flasher SD card
Still no luck with TTYLinux though
--
For more options, visit http://beagleboard.org/discuss
---
You
Well I got it to go finally by:
using gparted to format the 73mb boot partition as FAT
rewriting the flasher SD card
Still no luck with TTYLinux though
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
24 matches
Mail list logo
