date:20151102

Hi Micka,

Follow this tutorial:

http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs 


Regards,
John




> On Nov 2, 2015, at 1:26 AM, Micka  wrote:
> 
> Ok, the problem is that in a PRU project you don't have access to the I2C 
> function that you have in the starterware :'( .
> 
> 
> I guess that I need to code in ASM then ^^ .
> 
> Le lun. 2 nov. 2015 à 10:01, Micka  > a écrit :
> I found that : 
> 
> http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone//blog/2014/04/30/bbb--pru-c-compiler
>  
> 
> 
> 
> Le lun. 2 nov. 2015 à 09:48, Micka  > a écrit :
> Ok, thx for the tips.
> 
> I've CCS & starterware installed. I found the I2C driver. But how do you 
> create a PRU project for the beaglebone black ? 
> 
> In the CCS App center, the PRU compiler is installed, but I can't find how to 
> create a PRU project ?
> 
> 
> Micka,
> 
> 
> Le lun. 2 nov. 2015 à 01:30, John Syne  > a écrit :
> 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 one file, compile with 
> the PRU C compiler and fix errors and warnings. Don’t forget to add 
> CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;[2] to the start of main().
> 
> I do this all with a JTAG emulator. Not sure how you will be able to debug 
> this code otherwise. 
> 
> [1] http://www.ti.com/tool/starterware-sitara 
> 
> [2] https://git.ti.com/pru-software-support-package 
> 
> 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Nov 1, 2015, at 4: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 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 Hermans > > wrote:
>> 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 registers in the table  
>> which seems to me he is setting up the I2C hardware module directly through 
>> it's registers in memory. But the other link, he pasted I do not know if you 
>> saw it or not 
>> http://beagleboard.org/Community/Forums/?place=msg%2Fbeagleboard%2FDAXyYJOrDIc%2FDZ8WKkRWaC0J
>>  
>> 
>>  he talks about the problem being solved and he was not bringing the 
>> hardware module out of reset, which is similar to how the ADC module works. 
>> 
>> Wish I could help you more, but I know nearly nothing about I2C. I know what 
>> it is, and vaguely how it's done, but have never used I2C . . .
>> 
>> On Sun, Nov 1, 2015 at 2:45 PM, Micka > > wrote:
>> 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 you have the c code also it would be great.
>> 
>> ( if possible, also the part of you managed to activate the module by 
>> writing MODULEMODE field into register CM_PER_I2C1_CLKCTRL register and also 
>> the code that wait for IDLEST field to confirm that module is ready).
>> 
>> Micka,
>> 
>> 
>> Le dim. 19 juil. 2015 21:45, Gianfranco Rosso > > a écrit :
>> 
>> I've also posted this in I2C topic, the solution is there:
>> 
>> http://beagleboard.org/Community/Forums/?place=msg%2Fbeagleboard%2FDAXyYJOrDIc%2FDZ8WKkRWaC0J
>>  
>> 
>> 
>> 
>> Il giorno lunedì 13 luglio 2015 09:49:20 UTC+2, Gianfranco Rosso ha scritto:
>> 
>> I want to manage the I2C1 module by the PRU, in order to interface some

Re: [beagleboard] Re: ADC & PRU?

really now. Prey tell, enlighten us then with your logic.

On Mon, Nov 2, 2015 at 5:10 AM, Chad Baker  wrote:

> No, I don't, but having taught programming for over 40 years, I know that
> students would take your equation and plug it in and then be surprised that
> they get 0 for an answer.
>
> On 11/1/2015 6:13 PM, William Hermans wrote:
>
> *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 12:18 PM, William Hermans wrote:
>>
>> By the way, the ADC gives out a value of 0-4095. So scaling voltage is
>> really simple. Say you get a value of 4024 for a reading. In order to get a
>> reading from 0-1.8v from this  . . .
>>
>> ((4024 / 4096) * 1.8) or 1.768359375v
>>
>> The max voltage on the pins still can not exceed 1.8v, this is why one
>> needs an opamp, or similar device to keep the input scaled down. But, in
>> this manner you could even track large voltages. Hundreds or even thousands
>> of volts, at the cost of resolution. Which unfortunately can not be
>> avoided. So going by the above example . . .
>>
>> ((4024 / 4096) * 300) or 294.7265625v
>>
>> Does this make sense ?
>>
>>
>> On Fri, Oct 30, 2015 at 9:59 AM, William Hermans < 
>> yyrk...@gmail.com> wrote:
>>
>>> *BBB and Linux are new to me.  One of the things I would like to do is
 compute a ratio between two voltages, each of which might exceed 1.8 VDC.
 One solution might be to use DACs to sent feedback voltages to operational
 amplifiers that are supplied by 1.8 VDC.  The goal is to determine the
 ratio as quickly as possible and without waiting for Linux to get around to
 it (waiting for the ADC to happen).*

>>>
>>>
>>> What sample rate do you need ? If something around only a few thousand
>>> samples a second. This can be done from userspace without using the PRU's.
>>> You can even use mmap() with /dev/mem/ and directly manipulate the ADC's
>>> registers, which can sample the ADC faster than 200ksps. However, the
>>> sample rate would not be as deterministic as using the PRU's.
>>>
>>> You can use a PRU to read the ADC's for sure. If you search the web for
>>> Beaglebone PRU + ADC
>>> , you will find many ways. People have been doing this for a long time(
>>> since the beaglebone white ), and if you search this google group, you'll
>>> even find full code for something someone called "ADCcollector". It's C,
>>> and PASM assembly, but is a very short / easy read / understanding.
>>>
>>> As for how to physically connect to the ADC, I'd listen to evilwulfile.
>>> He's been an EE for longer than many people on this group have been alive,
>>> and he knows his stuff ( I know him personally ). Don't risk burning up
>>> your board, as I've seen several people on these groups do . . .
>>>
>>> On Fri, Oct 30, 2015 at 9:43 AM, TJF < 
>>> jeli.freih...@gmail.com> wrote:
>>>
 Hi John!

 As Przemek mentioned, a simple voltage divider can scale the input
 voltage. Additionaly I use a LED (orange color) between the ADC input and
 ground in order to block overvoltage. (The LED starts to light up at 1V5
 and consumes full power at 1V8. 1 / 6 of the ADC resolution get lost (is
 less accurate), but the burning LED as indicatior is a nice side effect.)

 Regarding software you should have a look at libpruio
 
 .

 BR
 --
 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.
 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> Chad Baker Memphis, TN
>> --
>> 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.
>>

[beagleboard] Re: CAN bus speed issue on Beaglebone Black

2015-11-02 Thread mickeyf

We have only used the one speed which our other devices expect, but that 
has worked correctly with a couple of dozen BBBs, "since forever".

On Friday, October 30, 2015 at 11:48:28 AM UTC-7, Glenn Cutler wrote:
>
> I'm using DCAN0 on the Beaglebone Black to communicate with other devices 
> on a CAN bus at 125 Kbps. Everything is working well but in order to get 
> 125 Kbps from the BBB I actually had to command 135 Kbps ("ip link set can0 
> up type can bitrate 135000") - I've verified this with a scope. In fact, in 
> order to get any desired speed, I have to command a speed 8% higher. I 
> initially thought it might be a problem with the Rev.A5A BBB I was using 
> but I've since experienced the problem with a Rev.C board as well. I've 
> also tried different images to no avail. Has anyone else encountered this 
> problem?
>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Power button and /dev/input/event0 on 4.1.10-bone16

2015-11-02 Thread toni incog


iirc power button input event is routed to acpid. See the /etc/acpi for the 
actual shutdown script.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] WL1835mod not working with latest TI kernel?

2015-11-02 Thread e_mag

Hello,

I have a wl1835mod cape and am trying to run the latest TI kernel so I can 
have sleep mode too (4.1.12-ti-rt-r26).

The problem is that the WL1835mod cape no longer works, all I get is:

dmesg | grep wl
[4.160681] wlan-en-regulator: disabling
[   13.628431] wl1271_sdio: probe of mmc1:0001:1 failed with error -16
[   13.628584] wl1271_sdio: probe of mmc1:0001:2 failed with error -16

...makes sense if it's looking for a WL1271 and I have a WL1835, but how 
can I get it to load the correct driver?

My uEnv.txt:

uname_r=4.1.12-ti-rt-r26
uuid=09597df5-a634-419c-b9cb-3315c5284ec1
dtb=am335x-boneblack-wl1835mod.dtb

cmdline=coherent pool=1M quiet


Thank you.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] WL1835mod with kernel 4.2.5-bone2

2015-11-02 Thread e_mag

Hi,

I'm trying to get the WL1835mod cape working with kernel version 
4.2.5-bone2, so I can have sleep mode enabled as well. 

I'm using the ./wl8-build.sh script from here: 
http://processors.wiki.ti.com/index.php/WL1835_Cape_on_BeagleBone_with_MainLine_Kernel_Debian_Filesystem.

I've obviously modified the script to download 4.2.5-bone2, as well as a 
minimalist Ubuntu build instead of Debian.

Everything boots and works well, except the wl1835mod cape is not 
recognized. dmesg simply shows the following:

ubuntu@arm:~$ dmesg | grep wl
[5.319992] wlan-en-regulator: disabling
[8.778535] wl1271_sdio: probe of mmc1:0001:2 failed with error -12

...which kinda makes sense, if it's trying to find a wl1271mod instead of a 
wl1835mod. 

How do I make it search for the wl1835mod on mmc1 instead? Is it something 
in am335x-boneblack-wl1835mod-cape.dtsi or uEnv.txt that I have to modify?

Here is my uEnv.txt:

ubuntu@arm:/boot$ cat uEnv.txt
uname_r=4.2.5-bone2
uuid=09597df5-a634-419c-b9cb-3315c5284ec1
dtb=am335x-boneblack-wl1835mod.dtb

cmdline=coherent pool=1M quiet

Thank you,

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] I2C driver by PRU

Yeah that link John gave out seems good. I've been meaning to follow it
myself for a couple weeks now. But I've been doing other things waiting for
remoteproc / rpmsg to settle down.

I really like the idea of remoteproc / rpmsg, it seems very intuitive /
natural.

Also Micka, there is *some* github project that uses starterware too . . .
demonstrating how to use starterware inside a ti_cgt C compiler project . .
. I do not remember which it is, so may not be able to find a link to it .
. .

On Mon, Nov 2, 2015 at 8:37 AM, John Syne  wrote:

> Hi Micka,
>
> Follow this tutorial:
>
> http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs
>
> Regards,
> John
>
>
>
>
> On Nov 2, 2015, at 1:26 AM, Micka  wrote:
>
> Ok, the problem is that in a PRU project you don't have access to the I2C
> function that you have in the starterware :'( .
>
>
> I guess that I need to code in ASM then ^^ .
>
> Le lun. 2 nov. 2015 à 10:01, Micka  a écrit :
>
>> I found that :
>>
>>
>> http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone//blog/2014/04/30/bbb--pru-c-compiler
>>
>>
>> Le lun. 2 nov. 2015 à 09:48, Micka  a écrit :
>>
>>> Ok, thx for the tips.
>>>
>>> I've CCS & starterware installed. I found the I2C driver. But how do you
>>> create a PRU project for the beaglebone black ?
>>>
>>> In the CCS App center, the PRU compiler is installed, but I can't find
>>> how to create a PRU project ?
>>>
>>>
>>> Micka,
>>>
>>>
>>> Le lun. 2 nov. 2015 à 01:30, John Syne  a écrit :
>>>
 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 one
 file, compile with the PRU C compiler and fix errors and warnings. Don’t
 forget to add CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;[2] to the start of
 main().

 I do this all with a JTAG emulator. Not sure how you will be able to
 debug this code otherwise.

 [1] http://www.ti.com/tool/starterware-sitara
 [2] https://git.ti.com/pru-software-support-package

 Regards,
 John

 On Nov 1, 2015, at 4: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 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 Hermans 
 wrote:

> 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 registers in the
> table  *which seems to me he is setting up the I2C hardware module
> directly through it's registers in memory. But the other link, he pasted I
> do not know if you saw it or not
> http://beagleboard.org/Community/Forums/?place=msg%2Fbeagleboard%2FDAXyYJOrDIc%2FDZ8WKkRWaC0J
> he talks about the problem being solved and he was not bringing the
> hardware module out of reset, which is similar to how the ADC module 
> works.
>
> Wish I could help you more, but I know nearly nothing about I2C. I
> know what it is, and vaguely how it's done, but have never used I2C . . .
>
> On Sun, Nov 1, 2015 at 2:45 PM, Micka  wrote:
>
>> 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 you have the c code also it would be great.
>>
>> ( if possible, also the part of you managed to activate the module by
>> writing MODULEMODE field into register CM_PER_I2C1_CLKCTRL register and
>> also the code that wait for IDLEST field to confirm that module is 
>> ready).
>>
>> Micka,
>>
>> Le dim. 19 juil. 2015 21:45, Gianfranco Rosso <
>> gianfranco.ro...@tiscali.it> a écrit :
>>
>> I've also posted this in I2C topic, the solution is there:
>>
>>
>> http://beagleboard.org/Community/Forums/?place=msg%2Fbeagleboard%2FDAXyYJOrDIc%2FDZ8WKkRWaC0J
>>
>>
>> Il giorno lunedì 13 luglio 2015 09:49:20 UTC+2,

Re: [beagleboard] I2C driver by PRU

Ah ! Since John is mentioning starterware + bare metal, I must mention that
it is not necessary to run bare metal in order to use the starterware
driver files. The github project above that I linked to is an example of
how to do that(also).

This is not to say that you can not , or should not run bare metal. I'm
just putting it out there that it is not a requirement.

On Mon, Nov 2, 2015 at 10:49 AM, John Syne  wrote:

> A few pieces of advise on how to get these examples to work. Make sure to
> boot with the custom MLO provided with Starterware as this sets up memory
> and clocks required by Starterware. Also don’t forget to use the GEL file
> when launching CCSV6. I also had to add a watchdog disable to the GEL file
> or else BBB just keeps on rebooting. I have attached my custom GEL file.
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> Regards,
> John
>
>
>
>
> On Nov 2, 2015, at 9:29 AM, William Hermans  wrote:
>
> Here is one such project, although I'm not sure this is the one I was
> thinking of
>
> https://github.com/BeaglePilot/PRUSS-C
>
> the starterware stuff is located in the PRUSS_LIB sub directory.
>
> On Mon, Nov 2, 2015 at 10:21 AM, William Hermans 
> wrote:
>
>> Yeah that link John gave out seems good. I've been meaning to follow it
>> myself for a couple weeks now. But I've been doing other things waiting for
>> remoteproc / rpmsg to settle down.
>>
>> I really like the idea of remoteproc / rpmsg, it seems very intuitive /
>> natural.
>>
>> Also Micka, there is *some* github project that uses starterware too . .
>> . demonstrating how to use starterware inside a ti_cgt C compiler project .
>> . . I do not remember which it is, so may not be able to find a link to it
>> . . .
>>
>> On Mon, Nov 2, 2015 at 8:37 AM, John Syne  wrote:
>>
>>> Hi Micka,
>>>
>>> Follow this tutorial:
>>>
>>> http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs
>>>
>>> Regards,
>>> John
>>>
>>>
>>>
>>>
>>> On Nov 2, 2015, at 1:26 AM, Micka  wrote:
>>>
>>> Ok, the problem is that in a PRU project you don't have access to the
>>> I2C function that you have in the starterware :'( .
>>>
>>>
>>> I guess that I need to code in ASM then ^^ .
>>>
>>> Le lun. 2 nov. 2015 à 10:01, Micka  a écrit :
>>>
 I found that :


 http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone//blog/2014/04/30/bbb--pru-c-compiler


 Le lun. 2 nov. 2015 à 09:48, Micka  a écrit :

> Ok, thx for the tips.
>
> I've CCS & starterware installed. I found the I2C driver. But how do
> you create a PRU project for the beaglebone black ?
>
> In the CCS App center, the PRU compiler is installed, but I can't find
> how to create a PRU project ?
>
>
> Micka,
>
>
> Le lun. 2 nov. 2015 à 01:30, John Syne  a écrit :
>
>> 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 one
>> file, compile with the PRU C compiler and fix errors and warnings. Don’t
>> forget to add CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;[2] to the start of
>> main().
>>
>> I do this all with a JTAG emulator. Not sure how you will be able to
>> debug this code otherwise.
>>
>> [1] http://www.ti.com/tool/starterware-sitara
>> [2] https://git.ti.com/pru-software-support-package
>>
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Nov 1, 2015, at 4: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 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 Hermans 
>> wrote:
>>
>>> 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

Re: [beagleboard] I2C driver by PRU

BTW, I believe the BeaglePilot project is running those drivers on the PRU, so 
this is the same as running on the Cortex-A8 bare-metal. 

Regards,
John




> On Nov 2, 2015, at 9:29 AM, William Hermans  wrote:
> 
> Here is one such project, although I'm not sure this is the one I was 
> thinking of 
> 
> https://github.com/BeaglePilot/PRUSS-C 
> 
> 
> the starterware stuff is located in the PRUSS_LIB sub directory.
> 
> On Mon, Nov 2, 2015 at 10:21 AM, William Hermans  > wrote:
> Yeah that link John gave out seems good. I've been meaning to follow it 
> myself for a couple weeks now. But I've been doing other things waiting for 
> remoteproc / rpmsg to settle down.
> 
> I really like the idea of remoteproc / rpmsg, it seems very intuitive / 
> natural.
> 
> Also Micka, there is *some* github project that uses starterware too . . . 
> demonstrating how to use starterware inside a ti_cgt C compiler project . . . 
> I do not remember which it is, so may not be able to find a link to it . . .
> 
> On Mon, Nov 2, 2015 at 8:37 AM, John Syne  > wrote:
> Hi Micka,
> 
> Follow this tutorial:
> 
> http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs 
> 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Nov 2, 2015, at 1:26 AM, Micka > > wrote:
>> 
>> Ok, the problem is that in a PRU project you don't have access to the I2C 
>> function that you have in the starterware :'( .
>> 
>> 
>> I guess that I need to code in ASM then ^^ .
>> 
>> Le lun. 2 nov. 2015 à 10:01, Micka > > a écrit :
>> I found that : 
>> 
>> http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone//blog/2014/04/30/bbb--pru-c-compiler
>>  
>> 
>> 
>> 
>> Le lun. 2 nov. 2015 à 09:48, Micka > > a écrit :
>> Ok, thx for the tips.
>> 
>> I've CCS & starterware installed. I found the I2C driver. But how do you 
>> create a PRU project for the beaglebone black ? 
>> 
>> In the CCS App center, the PRU compiler is installed, but I can't find how 
>> to create a PRU project ?
>> 
>> 
>> Micka,
>> 
>> 
>> Le lun. 2 nov. 2015 à 01:30, John Syne > > a écrit :
>> 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 one file, 
>> compile with the PRU C compiler and fix errors and warnings. Don’t forget to 
>> add CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;[2] to the start of main().
>> 
>> I do this all with a JTAG emulator. Not sure how you will be able to debug 
>> this code otherwise. 
>> 
>> [1] http://www.ti.com/tool/starterware-sitara 
>> 
>> [2] https://git.ti.com/pru-software-support-package 
>> 
>> 
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Nov 1, 2015, at 4: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 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 Hermans >> > wrote:
>>> 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 registers in the table  
>>> which seems to me he is setting up the I2C hardware module directly through 
>>> it's registers in memory. But the other link, he pasted I do not know if 
>>> you saw it or not 
>>> http://beagleboard.org/Community/Forums/?place=msg%2Fbeagleboard%2FDAXyYJOrDIc%2FDZ8WKkRWaC0J
>>>  
>>> 
>>>  he talks about the problem being solved and he was not bringing the 
>>> hardware module out of reset, which is similar to how the ADC module works. 
>>> 
>>> Wish I could help you more, but I know nearly nothing about I2C. I know 
>>> what it is,

Re: [beagleboard] WL1835mod not working with latest TI kernel?

2015-11-02 Thread E Mag

So I tried apt-get install'ing all the way back to 4.1.1-ti-r1, and I still 
get the same error =/ It must be something else, since I imagine this was 
tested with kernel 4.1.x at some point.

I get the same issue with the prebuilt image here  
https://rcn-ee.com/rootfs/2015-10-09/elinux/ubuntu-14.04.3-console-armhf-2015-10-09.tar.xz,
 
so definitely not an issue with the compilation...


On Monday, November 2, 2015 at 11:07:46 AM UTC-5, RobertCNelson wrote:
>
> On Mon, Nov 2, 2015 at 9:46 AM,   wrote: 
> > Hello, 
> > 
> > I have a wl1835mod cape and am trying to run the latest TI kernel so I 
> can 
> > have sleep mode too (4.1.12-ti-rt-r26). 
> > 
> > The problem is that the WL1835mod cape no longer works, all I get is: 
> > 
> > dmesg | grep wl 
> > [4.160681] wlan-en-regulator: disabling 
> > [   13.628431] wl1271_sdio: probe of mmc1:0001:1 failed with error -16 
> > [   13.628584] wl1271_sdio: probe of mmc1:0001:2 failed with error -16 
> > 
> > ...makes sense if it's looking for a WL1271 and I have a WL1835, but how 
> can 
> > I get it to load the correct driver? 
> > 
> > My uEnv.txt: 
> > 
> > uname_r=4.1.12-ti-rt-r26 
> > uuid=09597df5-a634-419c-b9cb-3315c5284ec1 
> > dtb=am335x-boneblack-wl1835mod.dtb 
> > 
> > cmdline=coherent pool=1M quiet 
>
> Please help use by apt-get'ing previous kernel's till it worksl: 
>
> sudo apt-cache search linux-image-4.1 | grep ti 
>
> Regards, 
>
> -- 
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] I2C driver by PRU

>
> *BTW, I believe the BeaglePilot project is running those drivers on the
> PRU, so this is the same as running on the Cortex-A8 bare-metal. *
>

I'll take your word on that, as I have not really done much with that git
project. Initially, I found it a waste of my time. Perhaps later I'll
revisit it and see what I missed.

But I also initially started learning how to use the ti-cgt PRU C compiler,
but without CCS ( I prefer to stay as close to gcc as possible ), and found
it rather difficult to proceed passed getting basic stuff working. So, I
went back to attempting to "relearn" asm, and in the process learn PASM,
and the PRU instruction set. Which of course initially I had a hard time
with too, but I'm starting to understand more now.

Now I remember why I gave up on assembly so many years ago . . . the syntax
is enough to make anyone "choke" . . .

On Mon, Nov 2, 2015 at 11:47 AM, 'Mark Lazarewicz' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> I'd use Starterware as intended with a real RTOS like  TI RTOS
>
> Sent from Yahoo Mail on Android
> 
> --
> *From*:"John Syne" 
> *Date*:Mon, Nov 2, 2015 at 1:12 PM
> *Subject*:Re: [beagleboard] I2C driver by PRU
>
> Yeah, I agree. Running Starterware as bare metal is a real pain because so
> many subsystems have to be configured correctly before anything works. If
> you can run this from within Linux, then you have the added benefits of
> knowing that clocks, memory, etc have already been setup for you. Be
> careful when running the drivers, because they do try to setup
> clocks/memory/bus and that may interfere with the Linux kernel. I haven’t
> tried this so I have no idea. One other complication is Linux uses an MMU
> so the peripherals memory map will not match the TRM. For example, MCSPI0
> is located at 0xFA03, not 0x4803 and EDMA is located at 0xFB00,
> not 0x4900
>
> Regards,
> John
>
>
>
>
> On Nov 2, 2015, at 9:54 AM, William Hermans  wrote:
>
> Ah ! Since John is mentioning starterware + bare metal, I must mention
> that it is not necessary to run bare metal in order to use the starterware
> driver files. The github project above that I linked to is an example of
> how to do that(also).
>
> This is not to say that you can not , or should not run bare metal. I'm
> just putting it out there that it is not a requirement.
>
> On Mon, Nov 2, 2015 at 10:49 AM, John Syne  wrote:
>
>> A few pieces of advise on how to get these examples to work. Make sure to
>> boot with the custom MLO provided with Starterware as this sets up memory
>> and clocks required by Starterware. Also don’t forget to use the GEL file
>> when launching CCSV6. I also had to add a watchdog disable to the GEL file
>> or else BBB just keeps on rebooting. I have attached my custom GEL file.
>>
>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Nov 2, 2015, at 9:29 AM, William Hermans  wrote:
>>
>> Here is one such project, although I'm not sure this is the one I was
>> thinking of
>>
>> https://github.com/BeaglePilot/PRUSS-C
>>
>> the starterware stuff is located in the PRUSS_LIB sub directory.
>>
>> On Mon, Nov 2, 2015 at 10:21 AM, William Hermans 
>> wrote:
>>
>>> Yeah that link John gave out seems good. I've been meaning to follow it
>>> myself for a couple weeks now. But I've been doing other things waiting for
>>> remoteproc / rpmsg to settle down.
>>>
>>> I really like the idea of remoteproc / rpmsg, it seems very intuitive /
>>> natural.
>>>
>>> Also Micka, there is *some* github project that uses starterware too . .
>>> . demonstrating how to use starterware inside a ti_cgt C compiler project .
>>> . . I do not remember which it is, so may not be able to find a link to it
>>> . . .
>>>
>>> On Mon, Nov 2, 2015 at 8:37 AM, John Syne  wrote:
>>>
 Hi Micka,

 Follow this tutorial:

 http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs

 Regards,
 John




 On Nov 2, 2015, at 1:26 AM, Micka  wrote:

 Ok, the problem is that in a PRU project you don't have access to the
 I2C function that you have in the starterware :'( .


 I guess that I need to code in ASM then ^^ .

 Le lun. 2 nov. 2015 à 10:01, Micka  a écrit :

> I found that :
>
>
>

Re: [beagleboard] I2C driver by PRU

Yeah, I agree. Running Starterware as bare metal is a real pain because so many 
subsystems have to be configured correctly before anything works. If you can 
run this from within Linux, then you have the added benefits of knowing that 
clocks, memory, etc have already been setup for you. Be careful when running 
the drivers, because they do try to setup clocks/memory/bus and that may 
interfere with the Linux kernel. I haven’t tried this so I have no idea. One 
other complication is Linux uses an MMU so the peripherals memory map will not 
match the TRM. For example, MCSPI0 is located at 0xFA03, not 0x4803 and 
EDMA is located at 0xFB00, not 0x4900

Regards,
John




> On Nov 2, 2015, at 9:54 AM, William Hermans  wrote:
> 
> Ah ! Since John is mentioning starterware + bare metal, I must mention that 
> it is not necessary to run bare metal in order to use the starterware driver 
> files. The github project above that I linked to is an example of how to do 
> that(also).
> 
> This is not to say that you can not , or should not run bare metal. I'm just 
> putting it out there that it is not a requirement. 
> 
> On Mon, Nov 2, 2015 at 10:49 AM, John Syne  > wrote:
> A few pieces of advise on how to get these examples to work. Make sure to 
> boot with the custom MLO provided with Starterware as this sets up memory and 
> clocks required by Starterware. Also don’t forget to use the GEL file when 
> launching CCSV6. I also had to add a watchdog disable to the GEL file or else 
> BBB just keeps on rebooting. I have attached my custom GEL file. 
> 
> 
> -- 
> 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 
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Nov 2, 2015, at 9:29 AM, William Hermans > > wrote:
>> 
>> Here is one such project, although I'm not sure this is the one I was 
>> thinking of 
>> 
>> https://github.com/BeaglePilot/PRUSS-C 
>> 
>> 
>> the starterware stuff is located in the PRUSS_LIB sub directory.
>> 
>> On Mon, Nov 2, 2015 at 10:21 AM, William Hermans > > wrote:
>> Yeah that link John gave out seems good. I've been meaning to follow it 
>> myself for a couple weeks now. But I've been doing other things waiting for 
>> remoteproc / rpmsg to settle down.
>> 
>> I really like the idea of remoteproc / rpmsg, it seems very intuitive / 
>> natural.
>> 
>> Also Micka, there is *some* github project that uses starterware too . . . 
>> demonstrating how to use starterware inside a ti_cgt C compiler project . . 
>> . I do not remember which it is, so may not be able to find a link to it . . 
>> .
>> 
>> On Mon, Nov 2, 2015 at 8:37 AM, John Syne > > wrote:
>> Hi Micka,
>> 
>> Follow this tutorial:
>> 
>> http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs 
>> 
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Nov 2, 2015, at 1:26 AM, Micka >> > wrote:
>>> 
>>> Ok, the problem is that in a PRU project you don't have access to the I2C 
>>> function that you have in the starterware :'( .
>>> 
>>> 
>>> I guess that I need to code in ASM then ^^ .
>>> 
>>> Le lun. 2 nov. 2015 à 10:01, Micka >> > a écrit :
>>> I found that : 
>>> 
>>> http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone//blog/2014/04/30/bbb--pru-c-compiler
>>>  
>>> 
>>> 
>>> 
>>> Le lun. 2 nov. 2015 à 09:48, Micka >> > a écrit :
>>> Ok, thx for the tips.
>>> 
>>> I've CCS & starterware installed. I found the I2C driver. But how do you 
>>> create a PRU project for the beaglebone black ? 
>>> 
>>> In the CCS App center, the PRU compiler is installed, but I can't find how 
>>> to create a PRU project ?
>>> 
>>> 
>>> Micka,
>>> 
>>> 
>>> Le lun. 2 nov. 2015 à 01:30, John Syne >> > a écrit :
>>> 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

Re: [beagleboard] I2C driver by PRU

A few pieces of advise on how to get these examples to work. Make sure to boot with the custom MLO provided with Starterware as this sets up memory and clocks required by Starterware. Also don’t forget to use the GEL file when launching CCSV6. I also had to add a watchdog disable to the GEL file or else BBB just keeps on rebooting. I have attached my custom GEL file. 



-- 
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.
For more options, visit https://groups.google.com/d/optout.


AM335X_beagleboneblack.gel
Description: Binary data

Regards,John


On Nov 2, 2015, at 9:29 AM, William Hermans  wrote:Here is one such project, although I'm not sure this is the one I was thinking of https://github.com/BeaglePilot/PRUSS-Cthe starterware stuff is located in the PRUSS_LIB sub directory.On Mon, Nov 2, 2015 at 10:21 AM, William Hermans  wrote:Yeah that link John gave out seems good. I've been meaning to follow it myself for a couple weeks now. But I've been doing other things waiting for remoteproc / rpmsg to settle down.I really like the idea of remoteproc / rpmsg, it seems very intuitive / natural.Also Micka, there is *some* github project that uses starterware too . . . demonstrating how to use starterware inside a ti_cgt C compiler project . . . I do not remember which it is, so may not be able to find a link to it . . .On Mon, Nov 2, 2015 at 8:37 AM, John Syne  wrote:Hi Micka,Follow this tutorial:http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs
Regards,John


On Nov 2, 2015, at 1:26 AM, Micka  wrote:Ok, the problem is that in a PRU project you don't have access to the I2C function that you have in the starterware :'( .I guess that I need to code in ASM then ^^ .Le lun. 2 nov. 2015 à 10:01, Micka  a écrit :I found that : http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone//blog/2014/04/30/bbb--pru-c-compilerLe lun. 2 nov. 2015 à 09:48, Micka  a écrit :Ok, thx for the tips.I've CCS & starterware installed. I found the I2C driver. But how do you create a PRU project for the beaglebone black ? In the CCS App center, the PRU compiler is installed, but I can't find how to create a PRU project ?Micka,Le lun. 2 nov. 2015 à 01:30, John Syne  a écrit :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 one file, compile with the PRU C compiler and fix errors and warnings. Don’t forget to add CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;[2] to the start of main().I do this all with a JTAG emulator. Not sure how you will be able to debug this code otherwise. [1] http://www.ti.com/tool/starterware-sitara[2] https://git.ti.com/pru-software-support-package
Regards,John


On Nov 1, 2015, at 4: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 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 Hermans  wrote: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_BASE            C2                //base registri I2C1 nella tabella translated from Italian to English  . . . I2C1 base registers in the table  which seems to me he is setting up the I2C hardware module directly through it's registers in memory. But the other link, he pasted I do not know if you saw it or not http://beagleboard.org/Community/Forums/?place=msg%2Fbeagleboard%2FDAXyYJOrDIc%2FDZ8WKkRWaC0J he talks about the problem being solved and he was not bringing the hardware module out of reset, which is similar to how the ADC module works. Wish I could help you more, but I know nearly nothing about I2C. I know what it is, and vaguely how it's done, but have never used I2C . . .On Sun, Nov 1, 2015 at 2:45 PM, Micka  wrote: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 you have the c code also it would be great.  ( if possible, also the part of you managed to activate the

Re: [beagleboard] Re: ADC & PRU?

2015-11-02 Thread Chad Baker

William,
I sincerely apologize to you and to this forum.
Best regards
Chad

On 11/2/2015 10:34 AM, William Hermans wrote:
Anyway Chad, it is not my responsibility to teach basic C skills. So 
hopefully your Students were taught to understand why something like 
this would / could fail. And how to figure out why. Honestly though. 
Any 6 year old with a browser + know how to use google could figure 
this out in 2 minutes.

On Mon, Nov 2, 2015 at 9:00 AM, William Hermans > wrote:

#include 

int main(void)
{
const float max_val = 4096;

float test = ((4024 / max_val) * 1.8);
printf("%f\n",  test);

return 0;
}

$ gcc test.c -Wall -o test
$ ./test
1.768359

On Mon, Nov 2, 2015 at 8:59 AM, William Hermans > wrote:

Anyway, since you do not seem to know why that does not work.

Math on two integer values can not give out a float value.
This is not a math problem, but a compiler behavior issue.
Intentional or no, one value in the equation brackets *has* to
be forced to a float value as such.

1) ((4024 / 4096.0) * 1.8)
*OR*
2) const float max_value = 4096; ((4024 / max_value) * 1.8)

It's also why I suggested using a const above.

On Mon, Nov 2, 2015 at 8:16 AM, William Hermans
> wrote:

really now. Prey tell, enlighten us then with your logic.

On Mon, Nov 2, 2015 at 5:10 AM, Chad Baker
> wrote:

No, I don't, but having taught programming for over 40
years, I know that students would take your equation
and plug it in and then be surprised that they get 0
for an answer.

On 11/1/2015 6:13 PM, William Hermans wrote:

/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 12:18 PM, William Hermans wrote:

By the way, the ADC gives out a value of 0-4095.
So scaling voltage is really simple. Say you get
a value of 4024 for a reading. In order to get a
reading from 0-1.8v from this  . . .

((4024 / 4096) * 1.8) or 1.768359375v

The max voltage on the pins still can not exceed
1.8v, this is why one needs an opamp, or similar
device to keep the input scaled down. But, in
this manner you could even track large voltages.
Hundreds or even thousands of volts, at the cost
of resolution. Which unfortunately can not be
avoided. So going by the above example . . .

((4024 / 4096) * 300) or 294.7265625v

Does this make sense ?

On Fri, Oct 30, 2015 at 9:59 AM, William Hermans
>
wrote:

/BBB and Linux are new to me.  One of
the things I would like to do is compute
a ratio between two voltages, each of
which might exceed 1.8 VDC.  One
solution might be to use DACs to sent
feedback voltages to operational
amplifiers that are supplied by 1.8
VDC.  The goal is to determine the ratio
as quickly as possible and without
waiting for Linux to get around to it
(waiting for the ADC to happen)./

What sample rate do you need ? If something
around only a few thousand samples a second.
This can be done from userspace without
using the PRU's. You can even use mmap()
with /dev/mem/ and directly manipulate the
ADC's registers, which can sample the ADC
faster than 200ksps. However, the sample
rate would not be as deterministic as using
the PRU's.

You can use a PRU to read the ADC's for
sure. If you search the web for Beaglebone
PRU + ADC

Re: [beagleboard] I2C driver by PRU

2015-11-02 Thread 'Mark Lazarewicz' via BeagleBoard

I'd use Starterware as intended with a real RTOS like TI RTOS

Sent from Yahoo Mail on Android

From:"John Syne"
Date:Mon, Nov 2, 2015 at 1:12 PM
Subject:Re: [beagleboard] I2C driver by PRU

Yeah, I agree. Running Starterware as bare metal is a real pain because so many
subsystems have to be configured correctly before anything works. If you can
run this from within Linux, then you have the added benefits of knowing that
clocks, memory, etc have already been setup for you. Be careful when running
the drivers, because they do try to setup clocks/memory/bus and that may
interfere with the Linux kernel. I haven’t tried this so I have no idea. One
other complication is Linux uses an MMU so the peripherals memory map will not
match the TRM. For example, MCSPI0 is located at 0xFA03, not 0x4803 and
EDMA is located at 0xFB00, not 0x4900

Regards,

John

On Nov 2, 2015, at 9:54 AM, William Hermans wrote:

Ah ! Since John is mentioning starterware + bare metal, I must mention that it
is not necessary to run bare metal in order to use the starterware driver
files. The github project above that I linked to is an example of how to do
that(also).

This is not to say that you can not , or should not run bare metal. I'm just
putting it out there that it is not a requirement.

On Mon, Nov 2, 2015 at 10:49 AM, John Syne wrote:

A few pieces of advise on how to get these examples to work. Make sure to boot
with the custom MLO provided with Starterware as this sets up memory and clocks
required by Starterware. Also don’t forget to use the GEL file when launching
CCSV6. I also had to add a watchdog disable to the GEL file or else BBB just
keeps on rebooting. I have attached my custom GEL file.

--
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.
For more options, visit https://groups.google.com/d/optout.

Regards,

John

On Nov 2, 2015, at 9:29 AM, William Hermans wrote:

Here is one such project, although I'm not sure this is the one I was thinking
of

https://github.com/BeaglePilot/PRUSS-C

the starterware stuff is located in the PRUSS_LIB sub directory.

On Mon, Nov 2, 2015 at 10:21 AM, William Hermans wrote:

Yeah that link John gave out seems good. I've been meaning to follow it myself
for a couple weeks now. But I've been doing other things waiting for remoteproc
/ rpmsg to settle down.

I really like the idea of remoteproc / rpmsg, it seems very intuitive / natural.

Also Micka, there is *some* github project that uses starterware too . . .
demonstrating how to use starterware inside a ti_cgt C compiler project . . . I
do not remember which it is, so may not be able to find a link to it . . .

On Mon, Nov 2, 2015 at 8:37 AM, John Syne wrote:

Hi Micka,

Follow this tutorial:

http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs

Regards,

John

On Nov 2, 2015, at 1:26 AM, Micka wrote:

Ok, the problem is that in a PRU project you don't have access to the I2C
function that you have in the starterware :'( .

I guess that I need to code in ASM then ^^ .

Le lun. 2 nov. 2015 à 10:01, Micka a écrit :

I found that :

http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone//blog/2014/04/30/bbb--pru-c-compiler

Le lun. 2 nov. 2015 à 09:48, Micka a écrit :

Ok, thx for the tips.

I've CCS & starterware installed. I found the I2C driver. But how do you create
a PRU project for the beaglebone black ?

In the CCS App center, the PRU compiler is installed, but I can't find how to
create a PRU project ?

Micka,

Le lun. 2 nov. 2015 à 01:30, John Syne a écrit :

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 one file, compile with the PRU
C compiler and fix errors and warnings. Don’t forget to add
CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;[2] to the start of main().

I do this all with a JTAG emulator. Not sure how you will be able to debug this
code otherwise.

[1] http://www.ti.com/tool/starterware-sitara

[2] https://git.ti.com/pru-software-support-package

Regards,

John

On Nov 1, 2015, at 4: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 it is . . . Seems to be some sort of

Re: [beagleboard] Signed BBB drivers for Windows 10

2015-11-02 Thread Maxim Podbereznyy

You need a lawyer to have a call back from GoDaddy? It's a cruel capitalism
world :)
3 Ноя 2015 г. 5:22 пользователь "Jason Kridner" <
jason.krid...@hangerhead.com> написал:

> Already found an issue. Try
> https://github.com/beagleboard/beaglebone-getting-started/releases/tag/1.1.3
>
> On Mon, Nov 2, 2015 at 9:02 PM, Jason Kridner <
> jason.krid...@hangerhead.com> wrote:
>
>> Finally, here are the drivers signed for Windows 10 to try:
>> https://github.com/beagleboard/beaglebone-getting-started/releases/tag/1.1.2
>>
>>
>> Please let me know how it goes, good or bad. I don't have a Windows 10
>> machine.
>>
>> On Mon, Oct 12, 2015 at 11:48 AM, Jason Kridner <
>> jason.krid...@hangerhead.com> wrote:
>>
>>> Just an update. Had to get a lawyer involved because the old letter had
>>> a phone number that wasn't getting answer. Still waiting on Godaddy to call
>>> me to verify.
>>>
>>> On Thu, Oct 1, 2015 at 9:53 PM, William Hermans 
>>> wrote:
>>>
 *The drivers are signed for 10, but the certificate expired. I got
> paperwork to GoDaddy 2 days ago to get it renewed. Waiting for them to 
> call
> to verify. They had been calling the wrong number for weeks. Might still
> need to get them a note from a lawyer that will cost pointless money, but
> we'll see. *
>

 Yikes ! And my bad I had not realized. Too bad so many of us suckers
 feel compelled to use Windows in the first place. I've been using MS OSes
 since DOS 5, and now . . . I couldn't say what OS I'll be using passed
 Windows 8. For the desktop that is.

>
 On Thu, Oct 1, 2015 at 6:32 PM, Jason Kridner 
 wrote:

> The drivers are signed for 10, but the certificate expired. I got
> paperwork to GoDaddy 2 days ago to get it renewed. Waiting for them to 
> call
> to verify. They had been calling the wrong number for weeks. Might still
> need to get them a note from a lawyer that will cost pointless money, but
> we'll see.
>
> On Oct 1, 2015, at 5:54 PM, William Hermans  wrote:
>
> I do not believe there are any signed drivers for Win10 yet. I also
> would not expect any for a while either. Due to MS's dodgy EULA for 
> Windows
> 10.
>
> You can disable driver signing though.
>
> On Thu, Oct 1, 2015 at 2:50 PM, Manish Shakya <
> manishshakya...@gmail.com> wrote:
>
>> Hi Everyone,
>>
>> Where can I find signed drivers for Windows 10?
>>
>> Thanks
>>
>> Manish
>>
>> --
>> 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.
>> 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.
> 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.
> 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.
 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] kernel updates thread

4.1.12-ti-r26
We've re-enabled the shutdown button, works best with "systemd"...

John Syne got the remoteproc_pruss working

Grab the firmware:

cd /opt/scripts/tools/
git pull
sudo cp /opt/scripts/device/bone/pru-rpmsg_client_sample/am335x* /lib/firmware/
sudo reboot

sudo modprobe rpmsg_client_sample


kernel updater:

cd /opt/scripts/tools/
git pull
sudo ./update_kernel.sh 

"--bone-kernel --testing" is now "4.3.0-bone1"  vs "4.2.5-bone2"

Consider v4.2.x now retired, yet still buildable via:

https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.2

Regards,

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] potential toolchains for building for BBB

2015-11-02 Thread Robert P. J. Day


  scenario: next week, i'm teaching an embedded linux course using the
beaglebone black as a test vehicle, so i'm trying to enumerate all the
possible S/W tools i might use for that class, just for the sake of
variety.

  for the sake of cross-compiling u-boot, the kernel and the rootfs,
what are the best choices in ARM toolchain that people would
recommend?

  for now, i'm going to have the following available:

* based on robert nelson's eewiki.net page, i'll have linaro's
gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz

* i'll also have linaro's much newer
gcc-linaro-5.1-2015.08-x86_64_arm-linux-gnueabihf.tar.xz, which i
admit i haven't tested as much

* finally, i'll have the toolchain built by the yocto project:
poky-glibc-x86_64-meta-toolchain-cortexa8hf-vfp-neon-toolchain-2.0.sh

  that should be more than enough, but is there anything else i can
throw into the mix, just for completeness?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: ADC & PRU?

Anyway, since you do not seem to know why that does not work.

Math on two integer values can not give out a float value. This is not a
math problem, but a compiler behavior issue. Intentional or no, one value
in the equation brackets *has* to be forced to a float value as such.

1) ((4024 / 4096.0) * 1.8)
*OR*
2) const float max_value = 4096; ((4024 / max_value) * 1.8)

It's also why I suggested using a const above.

On Mon, Nov 2, 2015 at 8:16 AM, William Hermans  wrote:

> really now. Prey tell, enlighten us then with your logic.
>
> On Mon, Nov 2, 2015 at 5:10 AM, Chad Baker  wrote:
>
>> No, I don't, but having taught programming for over 40 years, I know that
>> students would take your equation and plug it in and then be surprised that
>> they get 0 for an answer.
>>
>> On 11/1/2015 6:13 PM, William Hermans wrote:
>>
>> *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 12:18 PM, William Hermans wrote:
>>>
>>> By the way, the ADC gives out a value of 0-4095. So scaling voltage is
>>> really simple. Say you get a value of 4024 for a reading. In order to get a
>>> reading from 0-1.8v from this  . . .
>>>
>>> ((4024 / 4096) * 1.8) or 1.768359375v
>>>
>>> The max voltage on the pins still can not exceed 1.8v, this is why one
>>> needs an opamp, or similar device to keep the input scaled down. But, in
>>> this manner you could even track large voltages. Hundreds or even thousands
>>> of volts, at the cost of resolution. Which unfortunately can not be
>>> avoided. So going by the above example . . .
>>>
>>> ((4024 / 4096) * 300) or 294.7265625v
>>>
>>> Does this make sense ?
>>>
>>>
>>> On Fri, Oct 30, 2015 at 9:59 AM, William Hermans < 
>>> yyrk...@gmail.com> wrote:
>>>
 *BBB and Linux are new to me.  One of the things I would like to do is
> compute a ratio between two voltages, each of which might exceed 1.8 VDC.
> One solution might be to use DACs to sent feedback voltages to operational
> amplifiers that are supplied by 1.8 VDC.  The goal is to determine the
> ratio as quickly as possible and without waiting for Linux to get around 
> to
> it (waiting for the ADC to happen).*
>

 What sample rate do you need ? If something around only a few thousand
 samples a second. This can be done from userspace without using the PRU's.
 You can even use mmap() with /dev/mem/ and directly manipulate the ADC's
 registers, which can sample the ADC faster than 200ksps. However, the
 sample rate would not be as deterministic as using the PRU's.

 You can use a PRU to read the ADC's for sure. If you search the web for
 Beaglebone PRU + ADC
 , you will find many ways. People have been doing this for a long time(
 since the beaglebone white ), and if you search this google group, you'll
 even find full code for something someone called "ADCcollector". It's C,
 and PASM assembly, but is a very short / easy read / understanding.

 As for how to physically connect to the ADC, I'd listen to evilwulfile.
 He's been an EE for longer than many people on this group have been alive,
 and he knows his stuff ( I know him personally ). Don't risk burning up
 your board, as I've seen several people on these groups do . . .

 On Fri, Oct 30, 2015 at 9:43 AM, TJF < 
 jeli.freih...@gmail.com> wrote:

> Hi John!
>
> As Przemek mentioned, a simple voltage divider can scale the input
> voltage. Additionaly I use a LED (orange color) between the ADC input and
> ground in order to block overvoltage. (The LED starts to light up at 1V5
> and consumes full power at 1V8. 1 / 6 of the ADC resolution get lost (is
> less accurate), but the burning LED as indicatior is a nice side effect.)
>
> Regarding software you should have a look at libpruio
> 
> .
>
> BR
> --
> 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.
> 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
>>>

Re: [beagleboard] Re: ADC & PRU?

#include 

int main(void)
{
const float max_val = 4096;

float test = ((4024 / max_val) * 1.8);
printf("%f\n",  test);

return 0;
}

$ gcc test.c -Wall -o test
$ ./test
1.768359


On Mon, Nov 2, 2015 at 8:59 AM, William Hermans  wrote:

> Anyway, since you do not seem to know why that does not work.
>
> Math on two integer values can not give out a float value. This is not a
> math problem, but a compiler behavior issue. Intentional or no, one value
> in the equation brackets *has* to be forced to a float value as such.
>
> 1) ((4024 / 4096.0) * 1.8)
> *OR*
> 2) const float max_value = 4096; ((4024 / max_value) * 1.8)
>
> It's also why I suggested using a const above.
>
> On Mon, Nov 2, 2015 at 8:16 AM, William Hermans  wrote:
>
>> really now. Prey tell, enlighten us then with your logic.
>>
>> On Mon, Nov 2, 2015 at 5:10 AM, Chad Baker  wrote:
>>
>>> No, I don't, but having taught programming for over 40 years, I know
>>> that students would take your equation and plug it in and then be surprised
>>> that they get 0 for an answer.
>>>
>>> On 11/1/2015 6:13 PM, William Hermans wrote:
>>>
>>> *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 12:18 PM, William Hermans wrote:

 By the way, the ADC gives out a value of 0-4095. So scaling voltage is
 really simple. Say you get a value of 4024 for a reading. In order to get a
 reading from 0-1.8v from this  . . .

 ((4024 / 4096) * 1.8) or 1.768359375v

 The max voltage on the pins still can not exceed 1.8v, this is why one
 needs an opamp, or similar device to keep the input scaled down. But, in
 this manner you could even track large voltages. Hundreds or even thousands
 of volts, at the cost of resolution. Which unfortunately can not be
 avoided. So going by the above example . . .

 ((4024 / 4096) * 300) or 294.7265625v

 Does this make sense ?


 On Fri, Oct 30, 2015 at 9:59 AM, William Hermans < 
 yyrk...@gmail.com> wrote:

> *BBB and Linux are new to me.  One of the things I would like to do is
>> compute a ratio between two voltages, each of which might exceed 1.8 VDC.
>> One solution might be to use DACs to sent feedback voltages to 
>> operational
>> amplifiers that are supplied by 1.8 VDC.  The goal is to determine the
>> ratio as quickly as possible and without waiting for Linux to get around 
>> to
>> it (waiting for the ADC to happen).*
>>
>
>
> What sample rate do you need ? If something around only a few thousand
> samples a second. This can be done from userspace without using the PRU's.
> You can even use mmap() with /dev/mem/ and directly manipulate the ADC's
> registers, which can sample the ADC faster than 200ksps. However, the
> sample rate would not be as deterministic as using the PRU's.
>
> You can use a PRU to read the ADC's for sure. If you search the web
> for Beaglebone PRU + ADC
> , you will find many ways. People have been doing this for a long
> time( since the beaglebone white ), and if you search this google group,
> you'll even find full code for something someone called "ADCcollector".
> It's C, and PASM assembly, but is a very short / easy read / 
> understanding.
>
> As for how to physically connect to the ADC, I'd listen to
> evilwulfile. He's been an EE for longer than many people on this group 
> have
> been alive, and he knows his stuff ( I know him personally ). Don't risk
> burning up your board, as I've seen several people on these groups do . . 
> .
>
> On Fri, Oct 30, 2015 at 9:43 AM, TJF < 
> jeli.freih...@gmail.com> wrote:
>
>> Hi John!
>>
>> As Przemek mentioned, a simple voltage divider can scale the input
>> voltage. Additionaly I use a LED (orange color) between the ADC input and
>> ground in order to block overvoltage. (The LED starts to light up at 1V5
>> and consumes full power at 1V8. 1 / 6 of the ADC resolution get lost (is
>> less accurate), but the burning LED as indicatior is a nice side effect.)
>>
>> Regarding software you should have a look at libpruio
>> 
>> .
>>
>> BR
>> --
>> 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

Re: [beagleboard] WL1835mod not working with latest TI kernel?

On Mon, Nov 2, 2015 at 9:46 AM,   wrote:
> Hello,
>
> I have a wl1835mod cape and am trying to run the latest TI kernel so I can
> have sleep mode too (4.1.12-ti-rt-r26).
>
> The problem is that the WL1835mod cape no longer works, all I get is:
>
> dmesg | grep wl
> [4.160681] wlan-en-regulator: disabling
> [   13.628431] wl1271_sdio: probe of mmc1:0001:1 failed with error -16
> [   13.628584] wl1271_sdio: probe of mmc1:0001:2 failed with error -16
>
> ...makes sense if it's looking for a WL1271 and I have a WL1835, but how can
> I get it to load the correct driver?
>
> My uEnv.txt:
>
> uname_r=4.1.12-ti-rt-r26
> uuid=09597df5-a634-419c-b9cb-3315c5284ec1
> dtb=am335x-boneblack-wl1835mod.dtb
>
> cmdline=coherent pool=1M quiet

Please help use by apt-get'ing previous kernel's till it worksl:

sudo apt-cache search linux-image-4.1 | grep ti

Regards,

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] WL1835mod not working with latest TI kernel?

Hopefully this doesn't turn into a no disk space left - issue
;)

On Mon, Nov 2, 2015 at 9:07 AM, Robert Nelson 
wrote:

> On Mon, Nov 2, 2015 at 9:46 AM,   wrote:
> > Hello,
> >
> > I have a wl1835mod cape and am trying to run the latest TI kernel so I
> can
> > have sleep mode too (4.1.12-ti-rt-r26).
> >
> > The problem is that the WL1835mod cape no longer works, all I get is:
> >
> > dmesg | grep wl
> > [4.160681] wlan-en-regulator: disabling
> > [   13.628431] wl1271_sdio: probe of mmc1:0001:1 failed with error -16
> > [   13.628584] wl1271_sdio: probe of mmc1:0001:2 failed with error -16
> >
> > ...makes sense if it's looking for a WL1271 and I have a WL1835, but how
> can
> > I get it to load the correct driver?
> >
> > My uEnv.txt:
> >
> > uname_r=4.1.12-ti-rt-r26
> > uuid=09597df5-a634-419c-b9cb-3315c5284ec1
> > dtb=am335x-boneblack-wl1835mod.dtb
> >
> > cmdline=coherent pool=1M quiet
>
> Please help use by apt-get'ing previous kernel's till it worksl:
>
> sudo apt-cache search linux-image-4.1 | grep ti
>
> Regards,
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Power button and /dev/input/event0 on 4.1.10-bone16

On Mon, Nov 2, 2015 at 11:00 AM, Alberto Potenza
 wrote:
> Thanks for the answer.
> It seems there is not /etc/acpi. I guess it is done somewhere else.
> Any ideas?

systemd:

https://github.com/systemd/systemd/blob/master/src/login/70-power-switch.rules#L13

Regards,

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: ADC & PRU?

Anyway Chad, it is not my responsibility to teach basic C skills. So
hopefully your Students were taught to understand why something like this
would / could fail. And how to figure out why. Honestly though. Any 6 year
old with a browser + know how to use google could figure this out in 2
minutes.

On Mon, Nov 2, 2015 at 9:00 AM, William Hermans  wrote:

> #include 
>
> int main(void)
> {
> const float max_val = 4096;
>
> float test = ((4024 / max_val) * 1.8);
> printf("%f\n",  test);
>
> return 0;
> }
>
> $ gcc test.c -Wall -o test
> $ ./test
> 1.768359
>
>
> On Mon, Nov 2, 2015 at 8:59 AM, William Hermans  wrote:
>
>> Anyway, since you do not seem to know why that does not work.
>>
>> Math on two integer values can not give out a float value. This is not a
>> math problem, but a compiler behavior issue. Intentional or no, one value
>> in the equation brackets *has* to be forced to a float value as such.
>>
>> 1) ((4024 / 4096.0) * 1.8)
>> *OR*
>> 2) const float max_value = 4096; ((4024 / max_value) * 1.8)
>>
>> It's also why I suggested using a const above.
>>
>> On Mon, Nov 2, 2015 at 8:16 AM, William Hermans 
>> wrote:
>>
>>> really now. Prey tell, enlighten us then with your logic.
>>>
>>> On Mon, Nov 2, 2015 at 5:10 AM, Chad Baker  wrote:
>>>
 No, I don't, but having taught programming for over 40 years, I know
 that students would take your equation and plug it in and then be surprised
 that they get 0 for an answer.

 On 11/1/2015 6:13 PM, William Hermans wrote:

 *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 12:18 PM, William Hermans wrote:
>
> By the way, the ADC gives out a value of 0-4095. So scaling voltage is
> really simple. Say you get a value of 4024 for a reading. In order to get 
> a
> reading from 0-1.8v from this  . . .
>
> ((4024 / 4096) * 1.8) or 1.768359375v
>
> The max voltage on the pins still can not exceed 1.8v, this is why one
> needs an opamp, or similar device to keep the input scaled down. But, in
> this manner you could even track large voltages. Hundreds or even 
> thousands
> of volts, at the cost of resolution. Which unfortunately can not be
> avoided. So going by the above example . . .
>
> ((4024 / 4096) * 300) or 294.7265625v
>
> Does this make sense ?
>
>
> On Fri, Oct 30, 2015 at 9:59 AM, William Hermans < 
> yyrk...@gmail.com> wrote:
>
>> *BBB and Linux are new to me.  One of the things I would like to do
>>> is compute a ratio between two voltages, each of which might exceed 1.8
>>> VDC.  One solution might be to use DACs to sent feedback voltages to
>>> operational amplifiers that are supplied by 1.8 VDC.  The goal is to
>>> determine the ratio as quickly as possible and without waiting for 
>>> Linux to
>>> get around to it (waiting for the ADC to happen).*
>>>
>>
>>
>> What sample rate do you need ? If something around only a few
>> thousand samples a second. This can be done from userspace without using
>> the PRU's. You can even use mmap() with /dev/mem/ and directly manipulate
>> the ADC's registers, which can sample the ADC faster than 200ksps. 
>> However,
>> the sample rate would not be as deterministic as using the PRU's.
>>
>> You can use a PRU to read the ADC's for sure. If you search the web
>> for Beaglebone PRU + ADC
>> , you will find many ways. People have been doing this for a long
>> time( since the beaglebone white ), and if you search this google group,
>> you'll even find full code for something someone called "ADCcollector".
>> It's C, and PASM assembly, but is a very short / easy read / 
>> understanding.
>>
>> As for how to physically connect to the ADC, I'd listen to
>> evilwulfile. He's been an EE for longer than many people on this group 
>> have
>> been alive, and he knows his stuff ( I know him personally ). Don't risk
>> burning up your board, as I've seen several people on these groups do . 
>> . .
>>
>> On Fri, Oct 30, 2015 at 9:43 AM, TJF < 
>> jeli.freih...@gmail.com> wrote:
>>
>>> Hi John!
>>>
>>> As Przemek mentioned, a simple voltage divider can scale the input
>>> voltage. Additionaly I use a LED (orange color) between the ADC input 
>>> and
>>> ground in order to block overvoltage. (The LED starts to light up at 1V5
>>> and consumes full power at 1V8. 1 / 6 of the ADC resolution get lost (is
>>> less

Re: [beagleboard] Power button and /dev/input/event0 on 4.1.10-bone16

2015-11-02 Thread Alberto Potenza

Thanks for the answer.
It seems there is not /etc/acpi. I guess it is done somewhere else.
Any ideas?



Il giorno lunedì 2 novembre 2015 15:43:52 UTC+1, toni incog ha scritto:
>
>
> iirc power button input event is routed to acpid. See the /etc/acpi for 
> the actual shutdown script.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Power button and /dev/input/event0 on 4.1.10-bone16

2015-11-02 Thread Alberto Potenza

Great!!!
It works. Thans a lot for all your effort.
Regards.

Alberto

Il giorno lunedì 2 novembre 2015 18:04:15 UTC+1, RobertCNelson ha scritto:
>
> On Mon, Nov 2, 2015 at 11:00 AM, Alberto Potenza 
>  wrote: 
> > Thanks for the answer. 
> > It seems there is not /etc/acpi. I guess it is done somewhere else. 
> > Any ideas? 
>
> systemd: 
>
>
> https://github.com/systemd/systemd/blob/master/src/login/70-power-switch.rules#L13
>  
>
> Regards, 
>
> -- 
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] I2C driver by PRU

Here is one such project, although I'm not sure this is the one I was
thinking of

https://github.com/BeaglePilot/PRUSS-C

the starterware stuff is located in the PRUSS_LIB sub directory.

On Mon, Nov 2, 2015 at 10:21 AM, William Hermans  wrote:

> Yeah that link John gave out seems good. I've been meaning to follow it
> myself for a couple weeks now. But I've been doing other things waiting for
> remoteproc / rpmsg to settle down.
>
> I really like the idea of remoteproc / rpmsg, it seems very intuitive /
> natural.
>
> Also Micka, there is *some* github project that uses starterware too . . .
> demonstrating how to use starterware inside a ti_cgt C compiler project . .
> . I do not remember which it is, so may not be able to find a link to it .
> . .
>
> On Mon, Nov 2, 2015 at 8:37 AM, John Syne  wrote:
>
>> Hi Micka,
>>
>> Follow this tutorial:
>>
>> http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Nov 2, 2015, at 1:26 AM, Micka  wrote:
>>
>> Ok, the problem is that in a PRU project you don't have access to the I2C
>> function that you have in the starterware :'( .
>>
>>
>> I guess that I need to code in ASM then ^^ .
>>
>> Le lun. 2 nov. 2015 à 10:01, Micka  a écrit :
>>
>>> I found that :
>>>
>>>
>>> http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone//blog/2014/04/30/bbb--pru-c-compiler
>>>
>>>
>>> Le lun. 2 nov. 2015 à 09:48, Micka  a écrit :
>>>
 Ok, thx for the tips.

 I've CCS & starterware installed. I found the I2C driver. But how do
 you create a PRU project for the beaglebone black ?

 In the CCS App center, the PRU compiler is installed, but I can't find
 how to create a PRU project ?


 Micka,


 Le lun. 2 nov. 2015 à 01:30, John Syne  a écrit :

> 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 one
> file, compile with the PRU C compiler and fix errors and warnings. Don’t
> forget to add CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;[2] to the start of
> main().
>
> I do this all with a JTAG emulator. Not sure how you will be able to
> debug this code otherwise.
>
> [1] http://www.ti.com/tool/starterware-sitara
> [2] https://git.ti.com/pru-software-support-package
>
>
> Regards,
> John
>
>
>
>
> On Nov 1, 2015, at 4: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 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 Hermans 
> wrote:
>
>> 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 registers in
>> the table  *which seems to me he is setting up the I2C hardware
>> module directly through it's registers in memory. But the other link, he
>> pasted I do not know if you saw it or not
>> http://beagleboard.org/Community/Forums/?place=msg%2Fbeagleboard%2FDAXyYJOrDIc%2FDZ8WKkRWaC0J
>> he talks about the problem being solved and he was not bringing the
>> hardware module out of reset, which is similar to how the ADC module 
>> works.
>>
>> Wish I could help you more, but I know nearly nothing about I2C. I
>> know what it is, and vaguely how it's done, but have never used I2C . . .
>>
>> On Sun, Nov 1, 2015 at 2:45 PM, Micka  wrote:
>>
>>> 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 you have the c code also it would be great.
>>>
>>> ( if possible, also the part of you managed to activate the module
>>> by writing MODULEMODE field into register CM_PER_I2C1_CLKCTRL register 
>>> and
>>> also the code that wait for IDLEST field to confirm that

Re: [beagleboard] potential toolchains for building for BBB

Just an additional thought . . . Personally, I rather like the idea of
Linaro's toolchain. It makes it really simple for a regular user to setup,
use, and compile stuff without having to actually having to install
anything into / onto the system.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] kernel updates thread

John,

Not an argument so much as a concern . . . those hands-on labs are specific
to CCS, with no clear way of proceeding otherwise. e.g. I'd much prefer a
GNU approach. But I'll gloss over those labs yet again . . . and read what
other information is out there to see if this can be done with a gcc
toolchain.

CCS is a fine IDE, and set of tools, but not everyone has the need, or even
want / capability to use such a tool.

On Mon, Nov 2, 2015 at 2:24 PM, John Syne  wrote:

> The best way to learn this is to follow the LAB
>
> http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs
>
> Specifically, Lab4 onwards. Other than that, the examples are well
> documented.
>
>
> Regards,
> John
>
>
>
>
> On Nov 2, 2015, at 12:55 PM, William Hermans  wrote:
>
> *John Syne got the remoteproc_pruss working*
>>
>> * Grab the firmware:*
>>
>> * cd /opt/scripts/tools/*
>> * git pull*
>> * sudo cp /opt/scripts/device/bone/pru-**rpmsg_client_sample/am335x*
>> /lib/firmware/*
>> * sudo reboot*
>>
>> * sudo modprobe rpmsg_client_sample*
>
>
> So Robert, or John,
>
> What remoteproc's capability in our kernel right now ? Is this a simple
> example of what's to come, or is this fully functional now ? Also, is there
> good documentation out there other than the txt file / source code ? I know
> that Jason Reeder ? from TI has been doing a lot of work on code, and
> documentation here and there. But is there a comprehensive guide, or
> documentation that covers the whole API, etc ?
>
> On Mon, Nov 2, 2015 at 12:33 PM, Robert Nelson 
> wrote:
>
>> 4.1.12-ti-r26
>> We've re-enabled the shutdown button, works best with "systemd"...
>>
>> John Syne got the remoteproc_pruss working
>>
>> Grab the firmware:
>>
>> cd /opt/scripts/tools/
>> git pull
>> sudo cp /opt/scripts/device/bone/pru-rpmsg_client_sample/am335x*
>> /lib/firmware/
>> sudo reboot
>>
>> sudo modprobe rpmsg_client_sample
>>
>>
>> kernel updater:
>>
>> cd /opt/scripts/tools/
>> git pull
>> sudo ./update_kernel.sh 
>>
>> "--bone-kernel --testing" is now "4.3.0-bone1"  vs "4.2.5-bone2"
>>
>> Consider v4.2.x now retired, yet still buildable via:
>>
>> https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.2
>>
>> Regards,
>>
>> --
>> 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.
>> 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.
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] potential toolchains for building for BBB

2015-11-02 Thread Robert P. J. Day

On Mon, 2 Nov 2015, William Hermans wrote:

> Ubuntu 14.04 comes out of the box, or rather has APT packages for
> cross toolchains that "just work". If you need an example of what
> I'm talking about, check out Professor Molloy's youtube videos on
> the subject.

  i'll mention those, the class is based on fedora but making them
aware of working ubuntu packages is never a bad thing.

> There is also *gasp* crosstool-ng, which may be worth mentioning, in
> passing. e.g. the option to build ones own toolchain.

  i always mention crosstool-ng, but i typically don't recommend going
down that road unless they have a *specific* need. there are enough
out-of-the-box toolchains that should already work.

rday

-- 

Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] kernel updates thread

Yeah, I hear you. This is part of what I described earlier regarding GEL files 
which are necessary to configure the SOC so that the PRU’s can function. I 
guess it is possible to do what you need, but then you have to create a small 
bare bones file to run on the CortexA8 to replicate what the GEL file does. 
Seems like a lot of work so I just use CCSV6 and a JTAG emulator. Speak to TI 
and see if they have a solution for you. 

You may want to look at the demo example on 
ti-processor-sdk-linux-am335x-evm-01.00.00.03 with the PRU patch applied. The 
work with the PRU cape. That may be a good starting point to do what you need. 

Regards,
John




> On Nov 2, 2015, at 1:31 PM, William Hermans  wrote:
> 
> John,
> 
> Not an argument so much as a concern . . . those hands-on labs are specific 
> to CCS, with no clear way of proceeding otherwise. e.g. I'd much prefer a GNU 
> approach. But I'll gloss over those labs yet again . . . and read what other 
> information is out there to see if this can be done with a gcc toolchain.
> 
> CCS is a fine IDE, and set of tools, but not everyone has the need, or even 
> want / capability to use such a tool. 
> 
> On Mon, Nov 2, 2015 at 2:24 PM, John Syne  > wrote:
> The best way to learn this is to follow the LAB
> 
> http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs 
> 
> 
> Specifically, Lab4 onwards. Other than that, the examples are well documented.
> 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Nov 2, 2015, at 12:55 PM, William Hermans > > wrote:
>> 
>> John Syne got the remoteproc_pruss working
>> 
>> Grab the firmware:
>> 
>> cd /opt/scripts/tools/
>> git pull
>> sudo cp /opt/scripts/device/bone/pru-rpmsg_client_sample/am335x* 
>> /lib/firmware/
>> sudo reboot
>> 
>> sudo modprobe rpmsg_client_sample
>> 
>> So Robert, or John,
>> 
>> What remoteproc's capability in our kernel right now ? Is this a simple 
>> example of what's to come, or is this fully functional now ? Also, is there 
>> good documentation out there other than the txt file / source code ? I know 
>> that Jason Reeder ? from TI has been doing a lot of work on code, and 
>> documentation here and there. But is there a comprehensive guide, or 
>> documentation that covers the whole API, etc ? 
>> 
>> On Mon, Nov 2, 2015 at 12:33 PM, Robert Nelson > > wrote:
>> 4.1.12-ti-r26
>> We've re-enabled the shutdown button, works best with "systemd"...
>> 
>> John Syne got the remoteproc_pruss working
>> 
>> Grab the firmware:
>> 
>> cd /opt/scripts/tools/
>> git pull
>> sudo cp /opt/scripts/device/bone/pru-rpmsg_client_sample/am335x* 
>> /lib/firmware/
>> sudo reboot
>> 
>> sudo modprobe rpmsg_client_sample
>> 
>> 
>> kernel updater:
>> 
>> cd /opt/scripts/tools/
>> git pull
>> sudo ./update_kernel.sh 
>> 
>> "--bone-kernel --testing" is now "4.3.0-bone1"  vs "4.2.5-bone2"
>> 
>> Consider v4.2.x now retired, yet still buildable via:
>> 
>> https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.2 
>> 
>> 
>> Regards,
>> 
>> --
>> 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 
>> .
>> 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 
>> .
>> 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 
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received

Re: [beagleboard] kernel updates thread

>
> *Yeah, I hear you. This is part of what I described earlier regarding GEL
> files which are necessary to configure the SOC so that the PRU’s can
> function. I guess it is possible to do what you need, but then you have to
> create a small bare bones file to run on the CortexA8 to replicate what the
> GEL file does. Seems like a lot of work so I just use CCSV6 and a JTAG
> emulator. Speak to TI and see if they have a solution for you. *
>
> *You may want to look at the demo example on
> ti-processor-sdk-linux-am335x-**evm-01.00.00.03 with the PRU patch
> applied. The work with the PRU cape. That may be a good starting point to
> do what you need. *
>

I'm not even sure what a GEL file is, or does. But this has to be possible
without using CCS, as remoteproc + rpmsg is a Linux specific thing. So
perhaps, maybe I need to get my hands on a GEL file, and figure out how to
"disassemble" what is being done. This, I can do, but it might take me time.

On Mon, Nov 2, 2015 at 2:43 PM, John Syne  wrote:

> Yeah, I hear you. This is part of what I described earlier regarding GEL
> files which are necessary to configure the SOC so that the PRU’s can
> function. I guess it is possible to do what you need, but then you have to
> create a small bare bones file to run on the CortexA8 to replicate what the
> GEL file does. Seems like a lot of work so I just use CCSV6 and a JTAG
> emulator. Speak to TI and see if they have a solution for you.
>
> You may want to look at the demo example on
> ti-processor-sdk-linux-am335x-evm-01.00.00.03 with the PRU patch applied.
> The work with the PRU cape. That may be a good starting point to do what
> you need.
>
> Regards,
> John
>
>
>
>
> On Nov 2, 2015, at 1:31 PM, William Hermans  wrote:
>
> John,
>
> Not an argument so much as a concern . . . those hands-on labs are
> specific to CCS, with no clear way of proceeding otherwise. e.g. I'd much
> prefer a GNU approach. But I'll gloss over those labs yet again . . . and
> read what other information is out there to see if this can be done with a
> gcc toolchain.
>
> CCS is a fine IDE, and set of tools, but not everyone has the need, or
> even want / capability to use such a tool.
>
> On Mon, Nov 2, 2015 at 2:24 PM, John Syne  wrote:
>
>> The best way to learn this is to follow the LAB
>>
>> http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs
>>
>> Specifically, Lab4 onwards. Other than that, the examples are well
>> documented.
>>
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Nov 2, 2015, at 12:55 PM, William Hermans  wrote:
>>
>> *John Syne got the remoteproc_pruss working*
>>>
>>> * Grab the firmware:*
>>>
>>> * cd /opt/scripts/tools/*
>>> * git pull*
>>> * sudo cp /opt/scripts/device/bone/pru-**rpmsg_client_sample/am335x*
>>> /lib/firmware/*
>>> * sudo reboot*
>>>
>>> * sudo modprobe rpmsg_client_sample*
>>
>>
>> So Robert, or John,
>>
>> What remoteproc's capability in our kernel right now ? Is this a simple
>> example of what's to come, or is this fully functional now ? Also, is there
>> good documentation out there other than the txt file / source code ? I know
>> that Jason Reeder ? from TI has been doing a lot of work on code, and
>> documentation here and there. But is there a comprehensive guide, or
>> documentation that covers the whole API, etc ?
>>
>> On Mon, Nov 2, 2015 at 12:33 PM, Robert Nelson 
>> wrote:
>>
>>> 4.1.12-ti-r26
>>> We've re-enabled the shutdown button, works best with "systemd"...
>>>
>>> John Syne got the remoteproc_pruss working
>>>
>>> Grab the firmware:
>>>
>>> cd /opt/scripts/tools/
>>> git pull
>>> sudo cp /opt/scripts/device/bone/pru-rpmsg_client_sample/am335x*
>>> /lib/firmware/
>>> sudo reboot
>>>
>>> sudo modprobe rpmsg_client_sample
>>>
>>>
>>> kernel updater:
>>>
>>> cd /opt/scripts/tools/
>>> git pull
>>> sudo ./update_kernel.sh 
>>>
>>> "--bone-kernel --testing" is now "4.3.0-bone1"  vs "4.2.5-bone2"
>>>
>>> Consider v4.2.x now retired, yet still buildable via:
>>>
>>> https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.2
>>>
>>> Regards,
>>>
>>> --
>>> 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.
>>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> For more options, visit

Re: [beagleboard] potential toolchains for building for BBB

>
> *that should be more than enough, but is there anything else i can*
> * throw into the mix, just for completeness?*
>

Ubuntu 14.04 comes out of the box, or rather has APT packages for cross
toolchains that "just work". If you need an example of what I'm talking
about, check out Professor Molloy's youtube videos on the subject.

Anyway, this is a method for "no fuss" setup. You simply apt-get install
 Granted, I've never used these toolchains to build uboot, or the
kernel.

There is also *gasp* crosstool-ng, which may be worth mentioning, in
passing. e.g. the option to build ones own toolchain.

On Mon, Nov 2, 2015 at 1:22 PM, Robert P. J. Day 
wrote:

>
>   scenario: next week, i'm teaching an embedded linux course using the
> beaglebone black as a test vehicle, so i'm trying to enumerate all the
> possible S/W tools i might use for that class, just for the sake of
> variety.
>
>   for the sake of cross-compiling u-boot, the kernel and the rootfs,
> what are the best choices in ARM toolchain that people would
> recommend?
>
>   for now, i'm going to have the following available:
>
> * based on robert nelson's eewiki.net page, i'll have linaro's
> gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz
>
> * i'll also have linaro's much newer
> gcc-linaro-5.1-2015.08-x86_64_arm-linux-gnueabihf.tar.xz, which i
> admit i haven't tested as much
>
> * finally, i'll have the toolchain built by the yocto project:
> poky-glibc-x86_64-meta-toolchain-cortexa8hf-vfp-neon-toolchain-2.0.sh
>
>   that should be more than enough, but is there anything else i can
> throw into the mix, just for completeness?
>
> rday
>
> --
>
> 
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
>
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> 
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Recovering eMMc Data over JTAG?

2015-11-02 Thread 'andrew stillie' via BeagleBoard

I still haven't heard any news?

On 30 October 2015 at 13:22, Gerald Coley  wrote:

> Let me check.
>
> Gerald
>
> On Fri, Oct 30, 2015 at 6:54 AM, 'andrew stillie' via BeagleBoard <
> beagleboard@googlegroups.com> wrote:
>
>> Ok I  requested the RMA on Wednesday evening.
>>
>> On Fri, 30 Oct 2015 11:42 Gerald Coley  wrote:
>>
>>> Yes as soon as the people get to work and can reply.
>>>
>>> Gerald
>>> On Oct 30, 2015 6:33 AM, "'andrew stillie' via BeagleBoard" <
>>> beagleboard@googlegroups.com> wrote:
>>>
 Hi Gerald,

 I requested the RMA,  should I get an email confirmation?

 On Fri, 30 Oct 2015 11:27 Gerald Coley  wrote:

> If the board is blown and will not boot, the JTAG will not do you any
> good.
>
> If you send it in for repair, assuming we can repair the board which
> we usually can, there is a good chance the eMMC is good and we can send it
> back to working. Just note that you want to keep the eMMC in the RMA
> request.
>
>
> Gerald
>
> On Fri, Oct 30, 2015 at 4:50 AM, AndyS 
> wrote:
>
>> Hi there,
>>
>> I recently connected my beaglebone with reverse polarity 5v on the
>> power jack.
>>
>> The BBB is now unresponsive - no flashing user leds at startup - no
>> ability to SSH over usb.
>>
>> I have some work stored on the device - Is it possible to save this
>> data from emmc if I buy a jtag debugger?
>>
>> Thanks in advance.
>> Andy
>>
> --
>> 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.
>
>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Gerald
>
> ger...@beagleboard.org
> http://beagleboard.org/
>
> --
> 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/lLvGEUP7BnQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.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.
 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 a topic in the
>>> Google Groups "BeagleBoard" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/beagleboard/lLvGEUP7BnQ/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> beagleboard+unsubscr...@googlegroups.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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Gerald
>
> ger...@beagleboard.org
> http://beagleboard.org/
>
> --
> 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/lLvGEUP7BnQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Regards,

*Andrew Stillie*

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] kernel updates thread

On Mon, Nov 2, 2015 at 3:31 PM, William Hermans  wrote:
> John,
>
> Not an argument so much as a concern . . . those hands-on labs are specific
> to CCS, with no clear way of proceeding otherwise. e.g. I'd much prefer a
> GNU approach. But I'll gloss over those labs yet again . . . and read what
> other information is out there to see if this can be done with a gcc
> toolchain.
>
> CCS is a fine IDE, and set of tools, but not everyone has the need, or even
> want / capability to use such a tool.

The ti-pru compiler is available by default in the beagleboard.org
images..  So ccs project's just be transferable/buildable on the
beagle..

btw, the pru gnu examples are here, and i've gotten a patch from it's
author, so they should also be working in v4.1.x ;)

https://github.com/dinuxbg/pru-gcc-examples

Regards,

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] kernel updates thread

>
> *John Syne got the remoteproc_pruss working*
>
> * Grab the firmware:*
>
> * cd /opt/scripts/tools/*
> * git pull*
> * sudo cp /opt/scripts/device/bone/pru-**rpmsg_client_sample/am335x*
> /lib/firmware/*
> * sudo reboot*
>
> * sudo modprobe rpmsg_client_sample*


So Robert, or John,

What remoteproc's capability in our kernel right now ? Is this a simple
example of what's to come, or is this fully functional now ? Also, is there
good documentation out there other than the txt file / source code ? I know
that Jason Reeder ? from TI has been doing a lot of work on code, and
documentation here and there. But is there a comprehensive guide, or
documentation that covers the whole API, etc ?

On Mon, Nov 2, 2015 at 12:33 PM, Robert Nelson 
wrote:

> 4.1.12-ti-r26
> We've re-enabled the shutdown button, works best with "systemd"...
>
> John Syne got the remoteproc_pruss working
>
> Grab the firmware:
>
> cd /opt/scripts/tools/
> git pull
> sudo cp /opt/scripts/device/bone/pru-rpmsg_client_sample/am335x*
> /lib/firmware/
> sudo reboot
>
> sudo modprobe rpmsg_client_sample
>
>
> kernel updater:
>
> cd /opt/scripts/tools/
> git pull
> sudo ./update_kernel.sh 
>
> "--bone-kernel --testing" is now "4.3.0-bone1"  vs "4.2.5-bone2"
>
> Consider v4.2.x now retired, yet still buildable via:
>
> https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.2
>
> Regards,
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Windows 10 Bone_D64.exe Failing

2015-11-02 Thread don . fielden

All,

Don't know if you were able to resolve...just in case...i found solution as 
I had the exact same problem.  Go to the driver, right click and bring up 
"Properties" window.  The select "Compatibility" Tab and the click "Run 
compatibility troubleshooter".  Once troubleshooter runs then pick option 
that repairs compatibility.  Worked like a champ for me.

Many Thanks
Don

On Thursday, August 13, 2015 at 5:13:13 AM UTC+2, mscleavite wrote:
>
> I have just upgraded to Windows 10 on a machine that I have not previously 
> connected my BBB to.  I had success on other windows 8 machines as well as 
> SSHing using Putty.  I have spent SOME time searching forums and not 
> finding much at all on Windows 10.  During the install of the Bone_D64.exe, 
> the driver the status returned on all the drivers is "Install Failed".  Let 
> the flaming begin.  Or hopefully there is someone out there that has 
> encountered and concurred this. 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] kernel updates thread

Thanks again John - That is helpful. Actually, probably what I'll do is
create a WIP project on 43oh.com forums(Beagle section ), as they seem to
like it when I do that, and it gives me a place I can easily look up
previous things I've covered . . .

On Mon, Nov 2, 2015 at 3:00 PM, John Syne  wrote:

> http://www.ti.com/lit/an/spraa74a/spraa74a.pdf
>
> Regards,
> John
>
>
>
>
> On Nov 2, 2015, at 1:53 PM, William Hermans  wrote:
>
> *Yeah, I hear you. This is part of what I described earlier regarding GEL
>> files which are necessary to configure the SOC so that the PRU’s can
>> function. I guess it is possible to do what you need, but then you have to
>> create a small bare bones file to run on the CortexA8 to replicate what the
>> GEL file does. Seems like a lot of work so I just use CCSV6 and a JTAG
>> emulator. Speak to TI and see if they have a solution for you. *
>>
>> *You may want to look at the demo example on
>> ti-processor-sdk-linux-am335x-**evm-01.00.00.03 with the PRU patch
>> applied. The work with the PRU cape. That may be a good starting point to
>> do what you need. *
>>
>
> I'm not even sure what a GEL file is, or does. But this has to be possible
> without using CCS, as remoteproc + rpmsg is a Linux specific thing. So
> perhaps, maybe I need to get my hands on a GEL file, and figure out how to
> "disassemble" what is being done. This, I can do, but it might take me time.
>
> On Mon, Nov 2, 2015 at 2:43 PM, John Syne  wrote:
>
>> Yeah, I hear you. This is part of what I described earlier regarding GEL
>> files which are necessary to configure the SOC so that the PRU’s can
>> function. I guess it is possible to do what you need, but then you have to
>> create a small bare bones file to run on the CortexA8 to replicate what the
>> GEL file does. Seems like a lot of work so I just use CCSV6 and a JTAG
>> emulator. Speak to TI and see if they have a solution for you.
>>
>> You may want to look at the demo example on
>> ti-processor-sdk-linux-am335x-evm-01.00.00.03 with the PRU patch applied.
>> The work with the PRU cape. That may be a good starting point to do what
>> you need.
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Nov 2, 2015, at 1:31 PM, William Hermans  wrote:
>>
>> John,
>>
>> Not an argument so much as a concern . . . those hands-on labs are
>> specific to CCS, with no clear way of proceeding otherwise. e.g. I'd much
>> prefer a GNU approach. But I'll gloss over those labs yet again . . . and
>> read what other information is out there to see if this can be done with a
>> gcc toolchain.
>>
>> CCS is a fine IDE, and set of tools, but not everyone has the need, or
>> even want / capability to use such a tool.
>>
>> On Mon, Nov 2, 2015 at 2:24 PM, John Syne  wrote:
>>
>>> The best way to learn this is to follow the LAB
>>>
>>> http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs
>>>
>>> Specifically, Lab4 onwards. Other than that, the examples are well
>>> documented.
>>>
>>>
>>> Regards,
>>> John
>>>
>>>
>>>
>>>
>>> On Nov 2, 2015, at 12:55 PM, William Hermans  wrote:
>>>
>>> *John Syne got the remoteproc_pruss working*

 * Grab the firmware:*

 * cd /opt/scripts/tools/*
 * git pull*
 * sudo cp /opt/scripts/device/bone/pru-**rpmsg_client_sample/am335x*
 /lib/firmware/*
 * sudo reboot*

 * sudo modprobe rpmsg_client_sample*
>>>
>>>
>>> So Robert, or John,
>>>
>>> What remoteproc's capability in our kernel right now ? Is this a simple
>>> example of what's to come, or is this fully functional now ? Also, is there
>>> good documentation out there other than the txt file / source code ? I know
>>> that Jason Reeder ? from TI has been doing a lot of work on code, and
>>> documentation here and there. But is there a comprehensive guide, or
>>> documentation that covers the whole API, etc ?
>>>
>>> On Mon, Nov 2, 2015 at 12:33 PM, Robert Nelson 
>>> wrote:
>>>
 4.1.12-ti-r26
 We've re-enabled the shutdown button, works best with "systemd"...

 John Syne got the remoteproc_pruss working

 Grab the firmware:

 cd /opt/scripts/tools/
 git pull
 sudo cp /opt/scripts/device/bone/pru-rpmsg_client_sample/am335x*
 /lib/firmware/
 sudo reboot

 sudo modprobe rpmsg_client_sample


 kernel updater:

 cd /opt/scripts/tools/
 git pull
 sudo ./update_kernel.sh 

 "--bone-kernel --testing" is now "4.3.0-bone1"  vs "4.2.5-bone2"

 Consider v4.2.x now retired, yet still buildable via:

 https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.2

 Regards,

 --
 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.

Re: [beagleboard] kernel updates thread

The best way to learn this is to follow the LAB

http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs 


Specifically, Lab4 onwards. Other than that, the examples are well documented.


Regards,
John




> On Nov 2, 2015, at 12:55 PM, William Hermans  wrote:
> 
> John Syne got the remoteproc_pruss working
> 
> Grab the firmware:
> 
> cd /opt/scripts/tools/
> git pull
> sudo cp /opt/scripts/device/bone/pru-rpmsg_client_sample/am335x* 
> /lib/firmware/
> sudo reboot
> 
> sudo modprobe rpmsg_client_sample
> 
> So Robert, or John,
> 
> What remoteproc's capability in our kernel right now ? Is this a simple 
> example of what's to come, or is this fully functional now ? Also, is there 
> good documentation out there other than the txt file / source code ? I know 
> that Jason Reeder ? from TI has been doing a lot of work on code, and 
> documentation here and there. But is there a comprehensive guide, or 
> documentation that covers the whole API, etc ? 
> 
> On Mon, Nov 2, 2015 at 12:33 PM, Robert Nelson  > wrote:
> 4.1.12-ti-r26
> We've re-enabled the shutdown button, works best with "systemd"...
> 
> John Syne got the remoteproc_pruss working
> 
> Grab the firmware:
> 
> cd /opt/scripts/tools/
> git pull
> sudo cp /opt/scripts/device/bone/pru-rpmsg_client_sample/am335x* 
> /lib/firmware/
> sudo reboot
> 
> sudo modprobe rpmsg_client_sample
> 
> 
> kernel updater:
> 
> cd /opt/scripts/tools/
> git pull
> sudo ./update_kernel.sh 
> 
> "--bone-kernel --testing" is now "4.3.0-bone1"  vs "4.2.5-bone2"
> 
> Consider v4.2.x now retired, yet still buildable via:
> 
> https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.2 
> 
> 
> Regards,
> 
> --
> 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 
> .
> 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 
> .
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Recovering eMMc Data over JTAG?

2015-11-02 Thread Gerald Coley

Still working this. Not getting any cooperation.

Gerald

On Mon, Nov 2, 2015 at 3:27 PM, 'andrew stillie' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> I still haven't heard any news?
>
> On 30 October 2015 at 13:22, Gerald Coley  wrote:
>
>> Let me check.
>>
>> Gerald
>>
>> On Fri, Oct 30, 2015 at 6:54 AM, 'andrew stillie' via BeagleBoard <
>> beagleboard@googlegroups.com> wrote:
>>
>>> Ok I  requested the RMA on Wednesday evening.
>>>
>>> On Fri, 30 Oct 2015 11:42 Gerald Coley  wrote:
>>>
 Yes as soon as the people get to work and can reply.

 Gerald
 On Oct 30, 2015 6:33 AM, "'andrew stillie' via BeagleBoard" <
 beagleboard@googlegroups.com> wrote:

> Hi Gerald,
>
> I requested the RMA,  should I get an email confirmation?
>
> On Fri, 30 Oct 2015 11:27 Gerald Coley  wrote:
>
>> If the board is blown and will not boot, the JTAG will not do you any
>> good.
>>
>> If you send it in for repair, assuming we can repair the board which
>> we usually can, there is a good chance the eMMC is good and we can send 
>> it
>> back to working. Just note that you want to keep the eMMC in the RMA
>> request.
>>
>>
>> Gerald
>>
>> On Fri, Oct 30, 2015 at 4:50 AM, AndyS > > wrote:
>>
>>> Hi there,
>>>
>>> I recently connected my beaglebone with reverse polarity 5v on the
>>> power jack.
>>>
>>> The BBB is now unresponsive - no flashing user leds at startup - no
>>> ability to SSH over usb.
>>>
>>> I have some work stored on the device - Is it possible to save this
>>> data from emmc if I buy a jtag debugger?
>>>
>>> Thanks in advance.
>>> Andy
>>>
>> --
>>> 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.
>>
>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Gerald
>>
>> ger...@beagleboard.org
>> http://beagleboard.org/
>>
>> --
>> 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/lLvGEUP7BnQ/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard+unsubscr...@googlegroups.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.
> 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 a topic in the
 Google Groups "BeagleBoard" group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/beagleboard/lLvGEUP7BnQ/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 beagleboard+unsubscr...@googlegroups.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.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Gerald
>>
>> ger...@beagleboard.org
>> http://beagleboard.org/
>>
>> --
>> 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/lLvGEUP7BnQ/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Regards,
>
> *Andrew Stillie*
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe

Re: [beagleboard] kernel updates thread

>
> *The ti-pru compiler is available by default in the beagleboard.org
> *
> * images..  So ccs project's just be transferable/buildable on the*
> * beagle..*
>

Yeah, I prefer to use the ti-cgt A8 install script, as it gives me the
option of where to install the whole thing. e.g.

$ ./ti_cgt_pru_2.1.1_armlinuxa8hf_busybox_installer.sh --prefix ~/ti --temp
~/remote

I've installed, and have toyed with the x86 Linux version, but found it
difficult ( but not impossible ) to deal with. Probably my biggest hurdle
right now is absorbing all this information at once.

*btw, the pru gnu examples are here, and i've gotten a patch from it's*
> * author, so they should also be working in v4.1.x ;)*
>
> * https://github.com/dinuxbg/pru-gcc-examples
> *


Oh, nice, I do not think I've seen that repo yet. Hard to imagine since
I've searched, and searched . . . thanks :)


On Mon, Nov 2, 2015 at 2:35 PM, Robert Nelson 
wrote:

> On Mon, Nov 2, 2015 at 3:31 PM, William Hermans  wrote:
> > John,
> >
> > Not an argument so much as a concern . . . those hands-on labs are
> specific
> > to CCS, with no clear way of proceeding otherwise. e.g. I'd much prefer a
> > GNU approach. But I'll gloss over those labs yet again . . . and read
> what
> > other information is out there to see if this can be done with a gcc
> > toolchain.
> >
> > CCS is a fine IDE, and set of tools, but not everyone has the need, or
> even
> > want / capability to use such a tool.
>
> The ti-pru compiler is available by default in the beagleboard.org
> images..  So ccs project's just be transferable/buildable on the
> beagle..
>
> btw, the pru gnu examples are here, and i've gotten a patch from it's
> author, so they should also be working in v4.1.x ;)
>
> https://github.com/dinuxbg/pru-gcc-examples
>
> Regards,
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] kernel updates thread

Ok, thanks John. I'll start another thread( if needed ) to keep from
stepping all over this post. Which seems to be something I'm very good at
lately.

On Mon, Nov 2, 2015 at 2:57 PM, John Syne  wrote:

> GEL file is a simple script file CCSV6 uses to setup the SOC features like
> L3/L4 bus, DDR setup, Clock config, etc. The file is easy to read so you
> should be able to pull out the info you need.
>
> Regards,
> John
>
>
>
>
> On Nov 2, 2015, at 1:53 PM, William Hermans  wrote:
>
> *Yeah, I hear you. This is part of what I described earlier regarding GEL
>> files which are necessary to configure the SOC so that the PRU’s can
>> function. I guess it is possible to do what you need, but then you have to
>> create a small bare bones file to run on the CortexA8 to replicate what the
>> GEL file does. Seems like a lot of work so I just use CCSV6 and a JTAG
>> emulator. Speak to TI and see if they have a solution for you. *
>>
>> *You may want to look at the demo example on
>> ti-processor-sdk-linux-am335x-**evm-01.00.00.03 with the PRU patch
>> applied. The work with the PRU cape. That may be a good starting point to
>> do what you need. *
>>
>
> I'm not even sure what a GEL file is, or does. But this has to be possible
> without using CCS, as remoteproc + rpmsg is a Linux specific thing. So
> perhaps, maybe I need to get my hands on a GEL file, and figure out how to
> "disassemble" what is being done. This, I can do, but it might take me time.
>
> On Mon, Nov 2, 2015 at 2:43 PM, John Syne  wrote:
>
>> Yeah, I hear you. This is part of what I described earlier regarding GEL
>> files which are necessary to configure the SOC so that the PRU’s can
>> function. I guess it is possible to do what you need, but then you have to
>> create a small bare bones file to run on the CortexA8 to replicate what the
>> GEL file does. Seems like a lot of work so I just use CCSV6 and a JTAG
>> emulator. Speak to TI and see if they have a solution for you.
>>
>> You may want to look at the demo example on
>> ti-processor-sdk-linux-am335x-evm-01.00.00.03 with the PRU patch applied.
>> The work with the PRU cape. That may be a good starting point to do what
>> you need.
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Nov 2, 2015, at 1:31 PM, William Hermans  wrote:
>>
>> John,
>>
>> Not an argument so much as a concern . . . those hands-on labs are
>> specific to CCS, with no clear way of proceeding otherwise. e.g. I'd much
>> prefer a GNU approach. But I'll gloss over those labs yet again . . . and
>> read what other information is out there to see if this can be done with a
>> gcc toolchain.
>>
>> CCS is a fine IDE, and set of tools, but not everyone has the need, or
>> even want / capability to use such a tool.
>>
>> On Mon, Nov 2, 2015 at 2:24 PM, John Syne  wrote:
>>
>>> The best way to learn this is to follow the LAB
>>>
>>> http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs
>>>
>>> Specifically, Lab4 onwards. Other than that, the examples are well
>>> documented.
>>>
>>>
>>> Regards,
>>> John
>>>
>>>
>>>
>>>
>>> On Nov 2, 2015, at 12:55 PM, William Hermans  wrote:
>>>
>>> *John Syne got the remoteproc_pruss working*

 * Grab the firmware:*

 * cd /opt/scripts/tools/*
 * git pull*
 * sudo cp /opt/scripts/device/bone/pru-**rpmsg_client_sample/am335x*
 /lib/firmware/*
 * sudo reboot*

 * sudo modprobe rpmsg_client_sample*
>>>
>>>
>>> So Robert, or John,
>>>
>>> What remoteproc's capability in our kernel right now ? Is this a simple
>>> example of what's to come, or is this fully functional now ? Also, is there
>>> good documentation out there other than the txt file / source code ? I know
>>> that Jason Reeder ? from TI has been doing a lot of work on code, and
>>> documentation here and there. But is there a comprehensive guide, or
>>> documentation that covers the whole API, etc ?
>>>
>>> On Mon, Nov 2, 2015 at 12:33 PM, Robert Nelson 
>>> wrote:
>>>
 4.1.12-ti-r26
 We've re-enabled the shutdown button, works best with "systemd"...

 John Syne got the remoteproc_pruss working

 Grab the firmware:

 cd /opt/scripts/tools/
 git pull
 sudo cp /opt/scripts/device/bone/pru-rpmsg_client_sample/am335x*
 /lib/firmware/
 sudo reboot

 sudo modprobe rpmsg_client_sample


 kernel updater:

 cd /opt/scripts/tools/
 git pull
 sudo ./update_kernel.sh 

 "--bone-kernel --testing" is now "4.3.0-bone1"  vs "4.2.5-bone2"

 Consider v4.2.x now retired, yet still buildable via:

 https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.2

 Regards,

 --
 Robert Nelson
 https://rcn-ee.com/

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed

Re: [beagleboard] kernel updates thread

http://www.ti.com/lit/an/spraa74a/spraa74a.pdf 


Regards,
John




> On Nov 2, 2015, at 1:53 PM, William Hermans  wrote:
> 
> Yeah, I hear you. This is part of what I described earlier regarding GEL 
> files which are necessary to configure the SOC so that the PRU’s can 
> function. I guess it is possible to do what you need, but then you have to 
> create a small bare bones file to run on the CortexA8 to replicate what the 
> GEL file does. Seems like a lot of work so I just use CCSV6 and a JTAG 
> emulator. Speak to TI and see if they have a solution for you. 
> 
> You may want to look at the demo example on 
> ti-processor-sdk-linux-am335x-evm-01.00.00.03 with the PRU patch applied. The 
> work with the PRU cape. That may be a good starting point to do what you 
> need. 
> 
> I'm not even sure what a GEL file is, or does. But this has to be possible 
> without using CCS, as remoteproc + rpmsg is a Linux specific thing. So 
> perhaps, maybe I need to get my hands on a GEL file, and figure out how to 
> "disassemble" what is being done. This, I can do, but it might take me time.
> 
> On Mon, Nov 2, 2015 at 2:43 PM, John Syne  > wrote:
> Yeah, I hear you. This is part of what I described earlier regarding GEL 
> files which are necessary to configure the SOC so that the PRU’s can 
> function. I guess it is possible to do what you need, but then you have to 
> create a small bare bones file to run on the CortexA8 to replicate what the 
> GEL file does. Seems like a lot of work so I just use CCSV6 and a JTAG 
> emulator. Speak to TI and see if they have a solution for you. 
> 
> You may want to look at the demo example on 
> ti-processor-sdk-linux-am335x-evm-01.00.00.03 with the PRU patch applied. The 
> work with the PRU cape. That may be a good starting point to do what you 
> need. 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Nov 2, 2015, at 1:31 PM, William Hermans > > wrote:
>> 
>> John,
>> 
>> Not an argument so much as a concern . . . those hands-on labs are specific 
>> to CCS, with no clear way of proceeding otherwise. e.g. I'd much prefer a 
>> GNU approach. But I'll gloss over those labs yet again . . . and read what 
>> other information is out there to see if this can be done with a gcc 
>> toolchain.
>> 
>> CCS is a fine IDE, and set of tools, but not everyone has the need, or even 
>> want / capability to use such a tool. 
>> 
>> On Mon, Nov 2, 2015 at 2:24 PM, John Syne > > wrote:
>> The best way to learn this is to follow the LAB
>> 
>> http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs 
>> 
>> 
>> Specifically, Lab4 onwards. Other than that, the examples are well 
>> documented.
>> 
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Nov 2, 2015, at 12:55 PM, William Hermans >> > wrote:
>>> 
>>> John Syne got the remoteproc_pruss working
>>> 
>>> Grab the firmware:
>>> 
>>> cd /opt/scripts/tools/
>>> git pull
>>> sudo cp /opt/scripts/device/bone/pru-rpmsg_client_sample/am335x* 
>>> /lib/firmware/
>>> sudo reboot
>>> 
>>> sudo modprobe rpmsg_client_sample
>>> 
>>> So Robert, or John,
>>> 
>>> What remoteproc's capability in our kernel right now ? Is this a simple 
>>> example of what's to come, or is this fully functional now ? Also, is there 
>>> good documentation out there other than the txt file / source code ? I know 
>>> that Jason Reeder ? from TI has been doing a lot of work on code, and 
>>> documentation here and there. But is there a comprehensive guide, or 
>>> documentation that covers the whole API, etc ? 
>>> 
>>> On Mon, Nov 2, 2015 at 12:33 PM, Robert Nelson >> > wrote:
>>> 4.1.12-ti-r26
>>> We've re-enabled the shutdown button, works best with "systemd"...
>>> 
>>> John Syne got the remoteproc_pruss working
>>> 
>>> Grab the firmware:
>>> 
>>> cd /opt/scripts/tools/
>>> git pull
>>> sudo cp /opt/scripts/device/bone/pru-rpmsg_client_sample/am335x* 
>>> /lib/firmware/
>>> sudo reboot
>>> 
>>> sudo modprobe rpmsg_client_sample
>>> 
>>> 
>>> kernel updater:
>>> 
>>> cd /opt/scripts/tools/
>>> git pull
>>> sudo ./update_kernel.sh 
>>> 
>>> "--bone-kernel --testing" is now "4.3.0-bone1"  vs "4.2.5-bone2"
>>> 
>>> Consider v4.2.x now retired, yet still buildable via:
>>> 
>>> https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.2 
>>> 
>>> 
>>> Regards,
>>> 
>>> --
>>> 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 
>>>

Re: [beagleboard] I2C driver by PRU

I believe everything you need to setup, and use it is all accessible from
this link: http://processors.wiki.ti.com/index.php/PRU-ICSS

On Mon, Nov 2, 2015 at 2:05 AM, William Hermans  wrote:

> *Ok, thx for the tips.*
>>
>> *I've CCS & starterware installed. I found the I2C driver. But how do you
>> create a PRU project for the beaglebone black ? *
>>
>> *In the CCS App center, the PRU compiler is installed, but I can't find
>> how to create a PRU project ?*
>>
>
> I believe there is a proper TI wiki that covers the ti-cgt compiler, how
> to set it up, how to use it, example code, and all that. I'd give you a
> link, if I could find it . . .maybe I'll be able to find it quickly . .
>
> On Mon, Nov 2, 2015 at 2:01 AM, Micka  wrote:
>
>> I found that :
>>
>>
>> http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone//blog/2014/04/30/bbb--pru-c-compiler
>>
>>
>> Le lun. 2 nov. 2015 à 09:48, Micka  a écrit :
>>
>>> Ok, thx for the tips.
>>>
>>> I've CCS & starterware installed. I found the I2C driver. But how do you
>>> create a PRU project for the beaglebone black ?
>>>
>>> In the CCS App center, the PRU compiler is installed, but I can't find
>>> how to create a PRU project ?
>>>
>>>
>>> Micka,
>>>
>>>
>>> Le lun. 2 nov. 2015 à 01:30, John Syne  a écrit :
>>>
 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 one
 file, compile with the PRU C compiler and fix errors and warnings. Don’t
 forget to add CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;[2] to the start of
 main().

 I do this all with a JTAG emulator. Not sure how you will be able to
 debug this code otherwise.

 [1] http://www.ti.com/tool/starterware-sitara
 [2] https://git.ti.com/pru-software-support-package


 Regards,
 John




 On Nov 1, 2015, at 4: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 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 Hermans 
 wrote:

> 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 registers in the
> table  *which seems to me he is setting up the I2C hardware module
> directly through it's registers in memory. But the other link, he pasted I
> do not know if you saw it or not
> http://beagleboard.org/Community/Forums/?place=msg%2Fbeagleboard%2FDAXyYJOrDIc%2FDZ8WKkRWaC0J
> he talks about the problem being solved and he was not bringing the
> hardware module out of reset, which is similar to how the ADC module 
> works.
>
> Wish I could help you more, but I know nearly nothing about I2C. I
> know what it is, and vaguely how it's done, but have never used I2C . . .
>
> On Sun, Nov 1, 2015 at 2:45 PM, Micka  wrote:
>
>> 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 you have the c code also it would be great.
>>
>> ( if possible, also the part of you managed to activate the module by
>> writing MODULEMODE field into register CM_PER_I2C1_CLKCTRL register and
>> also the code that wait for IDLEST field to confirm that module is 
>> ready).
>>
>> Micka,
>>
>> Le dim. 19 juil. 2015 21:45, Gianfranco Rosso <
>> gianfranco.ro...@tiscali.it> a écrit :
>>
>> I've also posted this in I2C topic, the solution is there:
>>
>>
>> http://beagleboard.org/Community/Forums/?place=msg%2Fbeagleboard%2FDAXyYJOrDIc%2FDZ8WKkRWaC0J
>>
>>
>> Il giorno lunedì 13 luglio 2015 09:49:20 UTC+2, Gianfranco Rosso ha
>> scritto:
>>
>> I want to manage the I2C1 module by the PRU, in order to interface
>> some I/O expanders (MCP23017 by Microchip).
>> I use may own "cape" without the plug-n' play eeprom (one of the next

Re: [beagleboard] I2C driver by PRU

2015-11-02 Thread Micka

I found that :

http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone//blog/2014/04/30/bbb--pru-c-compiler


Le lun. 2 nov. 2015 à 09:48, Micka  a écrit :

> Ok, thx for the tips.
>
> I've CCS & starterware installed. I found the I2C driver. But how do you
> create a PRU project for the beaglebone black ?
>
> In the CCS App center, the PRU compiler is installed, but I can't find how
> to create a PRU project ?
>
>
> Micka,
>
>
> Le lun. 2 nov. 2015 à 01:30, John Syne  a écrit :
>
>> 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 one
>> file, compile with the PRU C compiler and fix errors and warnings. Don’t
>> forget to add CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;[2] to the start of
>> main().
>>
>> I do this all with a JTAG emulator. Not sure how you will be able to
>> debug this code otherwise.
>>
>> [1] http://www.ti.com/tool/starterware-sitara
>> [2] https://git.ti.com/pru-software-support-package
>>
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Nov 1, 2015, at 4: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 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 Hermans 
>> wrote:
>>
>>> 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 registers in the
>>> table  *which seems to me he is setting up the I2C hardware module
>>> directly through it's registers in memory. But the other link, he pasted I
>>> do not know if you saw it or not
>>> http://beagleboard.org/Community/Forums/?place=msg%2Fbeagleboard%2FDAXyYJOrDIc%2FDZ8WKkRWaC0J
>>> he talks about the problem being solved and he was not bringing the
>>> hardware module out of reset, which is similar to how the ADC module works.
>>>
>>> Wish I could help you more, but I know nearly nothing about I2C. I know
>>> what it is, and vaguely how it's done, but have never used I2C . . .
>>>
>>> On Sun, Nov 1, 2015 at 2:45 PM, Micka  wrote:
>>>
 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 you have the c code also it would be great.

 ( if possible, also the part of you managed to activate the module by
 writing MODULEMODE field into register CM_PER_I2C1_CLKCTRL register and
 also the code that wait for IDLEST field to confirm that module is ready).

 Micka,

 Le dim. 19 juil. 2015 21:45, Gianfranco Rosso <
 gianfranco.ro...@tiscali.it> a écrit :

 I've also posted this in I2C topic, the solution is there:


 http://beagleboard.org/Community/Forums/?place=msg%2Fbeagleboard%2FDAXyYJOrDIc%2FDZ8WKkRWaC0J


 Il giorno lunedì 13 luglio 2015 09:49:20 UTC+2, Gianfranco Rosso ha
 scritto:

 I want to manage the I2C1 module by the PRU, in order to interface some
 I/O expanders (MCP23017 by Microchip).
 I use may own "cape" without the plug-n' play eeprom (one of the next
 steps will be adding management for DCAN0 and DCAN1 so i'll need these pins
 too...).
 So, at present, there are just 2 MCP23017 connected to the P9.17 and
 P9.18.

 I load the *cape-universal* into slots and then I use *configure-pin*
 command to set P9.17 and P9.18 as *i2c*

 I've started from an example into the *am335x_pru_package-master* and
 wrote my own C PRU loader.
 Very simple, it just:

 loads the PRU codeinit the data exhanged with the PRUstart the PRUwait
 for ESC key presssignal to the PRU to stopwait for the PRU stopexit.


 Also the assembly PRU code is simple:

 init I2C1 module (by writing registers PSC, SCLL, SCLH, CON)init 1st
 I/O expander as 16 inputs (even if at power on it's already set as
 input)init 2nd I/O expander as 16 outputscicle reading status of inputs
 from 1st expander and echoing to the outputs of 2nd expanderexit cycle and
 halt when receive stop flag from the loader

 for send and

Re: [beagleboard] BBB hates me

>
> *I swear the Beagle hates me*.
>

No kidding, you seem to be having the worst of luck lately.

So pure speculation as I've no experience with that message, nor even where
it comes from but it sounds like uboot.img might be somehow corrupt. It
will be interesting to find out for sure exactly what it is. As always,
wait for the authoritative nod from Robert ;)

Good luck.

On Mon, Nov 2, 2015 at 1:10 AM, Rick Mann  wrote:

> I swear the Beagle hates me.
>
> I've been working off an SD card for the last week or two with nary a
> problem. Generally I leave the BBB powered all the time and issue shutdown
> or reboot commands. Sometimes I pull power, but I always issue shutdown -h
> before doing so.
>
> I went away this weekend, and powered it off with shutdown -h before
> leaving. I powered it back up, and the SD card won't boot now. U-boot ends
> up in the "FAILSAFE: U-Boot UMS (USB Mass Storage) enabled, media now
> available over the usb slave port " mode.
>
> It said something about "pl_load_image_fat_os: error reading image args,
> err - -1", but the serial port was a bit corrupt at that point.
>
> What should I look at/for to fix it up?
>
> If I boot with what's on the eMMC, and pop in the SD card, it auto-mounts
> on /media/rootfs, and seems intact. I can see /boot with my kernels, and my
> debian user home dir with all the usual files.
>
>
>
>
> --
> Rick Mann
> rm...@latencyzero.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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] I2C driver by PRU

2015-11-02 Thread Micka

Ok, the problem is that in a PRU project you don't have access to the I2C
function that you have in the starterware :'( .


I guess that I need to code in ASM then ^^ .

Le lun. 2 nov. 2015 à 10:01, Micka  a écrit :

> I found that :
>
>
> http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone//blog/2014/04/30/bbb--pru-c-compiler
>
>
> Le lun. 2 nov. 2015 à 09:48, Micka  a écrit :
>
>> Ok, thx for the tips.
>>
>> I've CCS & starterware installed. I found the I2C driver. But how do you
>> create a PRU project for the beaglebone black ?
>>
>> In the CCS App center, the PRU compiler is installed, but I can't find
>> how to create a PRU project ?
>>
>>
>> Micka,
>>
>>
>> Le lun. 2 nov. 2015 à 01:30, John Syne  a écrit :
>>
>>> 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 one
>>> file, compile with the PRU C compiler and fix errors and warnings. Don’t
>>> forget to add CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;[2] to the start of
>>> main().
>>>
>>> I do this all with a JTAG emulator. Not sure how you will be able to
>>> debug this code otherwise.
>>>
>>> [1] http://www.ti.com/tool/starterware-sitara
>>> [2] https://git.ti.com/pru-software-support-package
>>>
>>>
>>> Regards,
>>> John
>>>
>>>
>>>
>>>
>>> On Nov 1, 2015, at 4: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 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 Hermans 
>>> wrote:
>>>
 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 registers in the
 table  *which seems to me he is setting up the I2C hardware module
 directly through it's registers in memory. But the other link, he pasted I
 do not know if you saw it or not
 http://beagleboard.org/Community/Forums/?place=msg%2Fbeagleboard%2FDAXyYJOrDIc%2FDZ8WKkRWaC0J
 he talks about the problem being solved and he was not bringing the
 hardware module out of reset, which is similar to how the ADC module works.

 Wish I could help you more, but I know nearly nothing about I2C. I know
 what it is, and vaguely how it's done, but have never used I2C . . .

 On Sun, Nov 1, 2015 at 2:45 PM, Micka  wrote:

> 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 you have the c code also it would be great.
>
> ( if possible, also the part of you managed to activate the module by
> writing MODULEMODE field into register CM_PER_I2C1_CLKCTRL register and
> also the code that wait for IDLEST field to confirm that module is ready).
>
> Micka,
>
> Le dim. 19 juil. 2015 21:45, Gianfranco Rosso <
> gianfranco.ro...@tiscali.it> a écrit :
>
> I've also posted this in I2C topic, the solution is there:
>
>
> http://beagleboard.org/Community/Forums/?place=msg%2Fbeagleboard%2FDAXyYJOrDIc%2FDZ8WKkRWaC0J
>
>
> Il giorno lunedì 13 luglio 2015 09:49:20 UTC+2, Gianfranco Rosso ha
> scritto:
>
> I want to manage the I2C1 module by the PRU, in order to interface
> some I/O expanders (MCP23017 by Microchip).
> I use may own "cape" without the plug-n' play eeprom (one of the next
> steps will be adding management for DCAN0 and DCAN1 so i'll need these 
> pins
> too...).
> So, at present, there are just 2 MCP23017 connected to the P9.17 and
> P9.18.
>
> I load the *cape-universal* into slots and then I use *configure-pin*
> command to set P9.17 and P9.18 as *i2c*
>
> I've started from an example into the *am335x_pru_package-master* and
> wrote my own C PRU loader.
> Very simple, it just:
>
> loads the PRU codeinit the data exhanged with the PRUstart the PRUwait
> for ESC key presssignal to the PRU to stopwait for the PRU stopexit.
>
>
> Also the assembly PRU code is simple:
>

Re: [beagleboard] I2C driver by PRU