[beagleboard] Waiting for root device ...

Hi all, I am having some trouble getting my root partition to mount. I am a bit new to this and am likely making a simple mistake. If you could take a minute to look and see if you spot a mistake with my setup I would be very thankful. Background: I am working on my senior design project at

[beagleboard] Re: eMMC Reset Line

I think you can also use mmc-utils from linux to enable the reset pin functionality in eMMC. Keep in mind this setting (ECSD byte 162, "RST_n_FUNCTION"), like disturbingly many of the eMMC's settings, is *one-time-programmable*. No margin for mistakes or second thoughts here :P (Unlike the

Re: [beagleboard] Re: eMMC Reset Line

On 1 November 2015 at 09:49, Matthijs van Duin wrote: > Note BTW that as long as you leave mmc_clk alone you can safely use the > remaining pins for other purposes, so unless you really need that last pin > too I would leave reset alone. Or, if you can briefly use

Re: [beagleboard] I2C driver by PRU

Hi Micka, With a few tweaks, you can use the drivers from Staterware[1] and use the PRU C compiler. My advice is to use Starterware on the CortexA8 to get familiar with the examples, utilities and driver code. Next you want to pull out just the driver and utility code you need and put it into

Re: [beagleboard] I2C

On Sun, 1 Nov 2015 18:18:36 -0700, you wrote: >I am curious though. So keep in mind I'm not so much of an EE type when I >ask this. But why would you use I2C over another serial communications type >? I've used SPI on the msp430's before, and know that if one were to use >SPI through the PRU's on

[beagleboard] I2C

Hi Harvey, Yeah, I'm honestly not interested in I2C, at least not yet. I was just trying to express that I know the register in memory layout "ok" and that the OP was not using a driver, really. Thanks for the offer though. -- For more options, visit http://beagleboard.org/discuss --- You

Re: [beagleboard] I2C

Yeah, thanks. I always forget about the distance factor. It's a shame that I2C is so "slow" though. ~400Khz is it's max speed right ? On Sun, Nov 1, 2015 at 8:00 PM, Harvey White wrote: > On Sun, 1 Nov 2015 19:32:56 -0700, you wrote: > > >By the way, that's an honest to

Re: [beagleboard] I2C

By the way, that's an honest to god question. I see people use I2C all the time, and I do not know why. From a software developer's perspective, I'm often in the frame of mind that "faster is better". I kind of feel like I'm missing something though. I do know that some parts only come in I2C,

Re: [beagleboard] I2C

On Sun, 1 Nov 2015 19:32:56 -0700, you wrote: >By the way, that's an honest to god question. I see people use I2C all the >time, and I do not know why. From a software developer's perspective, I'm >often in the frame of mind that "faster is better". I kind of feel like >I'm missing something

[beagleboard] Re: BBK - pwmchip inconsistencies

Cheers Matthijs, that's the answer that I was looking for. It looks like the PRU is a feature that will require my attention shortly. Cheers, PL On Sunday, November 1, 2015 at 4:31:34 PM UTC+8, Matthijs van Duin wrote: > > On Thursday, 22 October 2015 17:42:53 UTC+2, TJF wrote: >> >> So you

Re: [beagleboard] I2C

On Sun, 1 Nov 2015 17:55:19 -0700, you wrote: >Hi Harvey, > >Yeah, I'm honestly not interested in I2C, at least not yet. I was just >trying to express that I know the register in memory layout "ok" and that >the OP was not using a driver, really. > >Thanks for the offer though. You're welcome.

[beagleboard] Seeed BeagleBone Green getting started documentation out of date or plain wrong

I've just received the BeagleBone Green and Grove IoT Starter Kit Powered by AWS. The leaflet in the box of the BeagleBone Green lists a 3 step procedure to getting started, this is appears to be very out of date or completely wrong. After a quite a bit of frustration and Googling I managed to

Re: [beagleboard] Re: BBK - pwmchip inconsistencies

Hello Pierre, I honestly do not know the eCAP / PWM modules at all, but I suspect that you would not necessarily need to use the PRU to access these modules. Pretty much anything that can be accessed via the PRU's can be accessed from a C program through /dev/mem/ + mmap(). Perhaps though, since

Re: [beagleboard] I2C

I am curious though. So keep in mind I'm not so much of an EE type when I ask this. But why would you use I2C over another serial communications type ? I've used SPI on the msp430's before, and know that if one were to use SPI through the PRU's on the BBB, it would / could be amazingly fast. Is

Re: [beagleboard] Re: BBK - pwmchip inconsistencies

On 2 November 2015 at 04:33, William Hermans wrote: > I honestly do not know the eCAP / PWM modules at all, but I suspect that > you would not necessarily need to use the PRU to access these modules. Although I haven't yet tried to use the eCAP in PRUSS, I don't think

Re: [beagleboard] Re: ADC & PRU?

> > *Or 4024 * 1.8 / 4096?* > Ok, so let us put this another way. Do you think that is clear when written in code ? What if 1.8 were actually assigned to a constant pointer ? On Sat, Oct 31, 2015 at 5:01 AM, Chad Baker wrote: > Or 4024 * 1.8 / 4096? > > > On 10/30/2015

Re: [beagleboard] Re: I2C driver by PRU

Hi, I'm interested by what you have done. I want to use i2c to read analog value from a component. The first solution that I found was to bitbang the i2c. But you, you use the i2c driver which is nice. Could you give us the peace of asm code that you use to interface with the MCP23017. And if

Re: [beagleboard] Re: I2C driver by PRU

Ah, ok got it. Page 25 of the PRU reference manual table 9 2 I2C1 0x4802_A000 == base address for i2c1 On Sun, Nov 1, 2015 at 5:06 PM, William Hermans wrote: > By the way, I keep seeing stuff like "C2" in PASM assembly in regard to > the PRU's. Wish I could figure out what

Re: [beagleboard] Re: I2C driver by PRU

By the way, I keep seeing stuff like "C2" in PASM assembly in regard to the PRU's. Wish I could figure out what it is . . . Seems to be some sort of constant "register" ? And there is more than just C2, but I have not found any reference to those yet :/ On Sun, Nov 1, 2015 at 5:01 PM, William

Re: [beagleboard] Re: I2C driver by PRU

Hi Micka, I do not think he is using and driver. When speaking of the I2C module, I believe hes speaking of the physical on chip module. But this . . . #define I2C1_BASEC2//base registri I2C1 nella tabella translated from Italian to English . . . *I2C1 base

Re: [beagleboard] Re: I2C driver by PRU

On Sun, 1 Nov 2015 17:06:02 -0700, you wrote: >By the way, I keep seeing stuff like "C2" in PASM assembly in regard to the >PRU's. Wish I could figure out what it is . . . Seems to be some sort of >constant "register" ? And there is more than just C2, but I have not found >any reference to those

Re: [beagleboard] Re: BBK - pwmchip inconsistencies

> > *Why? Using PRUs to access peripherals makes no sense to me either, unless > you need *really* tight timing.* > Determinism. I do agree with what you're saying, but sometimes, you need things to happen at exactly . In userland, you may be able to achieve that most of the time, but you will

Re: [beagleboard] Re: BBK - pwmchip inconsistencies

> > *Correct, pretty much anything can be used from userspace like that, > although some people will frown at you for bypassing the kernel if you do.* > So maybe to you, and others this seems like an argument. But it's not. Just a point I feel the need to put out there. Using /dev/mem/ + mmap()

Re: [beagleboard] Re: BBK - pwmchip inconsistencies

> > *I'll check out that pastbin of yours, so see if I can glean what I've > been missing thus far.* > Ah, perhaps information and things I had not considered yet. But not what I was hoping for ;) config files, and device tree files I can usually figure out fairly easily. Was hoping to "spot"

Re: [beagleboard] Re: BBK - pwmchip inconsistencies

On 2 November 2015 at 07:52, William Hermans wrote: > Determinism. I do agree with what you're saying, but sometimes, you need > things to happen at exactly . In userland, you may be > able to achieve that most of the time, but you will not be able to achieve > that all of the

Re: [beagleboard] Re: BBK - pwmchip inconsistencies

On 2 November 2015 at 06:22, William Hermans wrote: > *Correct, pretty much anything can be used from userspace like that, >> although some people will frown at you for bypassing the kernel if you do.* >> > > So maybe to you, and others this seems like an argument. > No, I