[beagleboard] Re: [beagle-alpha] v4.9.x-ti now open for testing...

[Robert Nelson]

On Mon, Jan 30, 2017 at 3:40 PM, Drew Fustini  wrote:
> On Mon, Jan 30, 2017 at 1:02 PM, Drew Fustini  wrote:
>> Thanks for the assistance, Franklin.  Here is the patch that is applied:
>> https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-4.9.y/patches/drivers/ti/eqep
>>
>> The boot log is in this gist and also attached:
>> https://gist.github.com/pdp7/0df175876304e30e8971c2aadb7493c7/
>
> I just found that I can avoid the abort by setting runtime power
> control to "on" instead of "auto" through sysfs.
>
> # uname -r
> 4.9.6-ti-r17
> # config-pin p8.11 qep
> # config-pin p8.12 qep
>
> # echo on > 
> /sys/devices/platform/ocp/4830.epwmss/48300180.eqep/power/control
> # echo on > 
> /sys/devices/platform/ocp/48302000.epwmss/48302180.eqep/power/control
> # echo on > 
> /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/power/control
>
> # cat 
> /sys/devices/platform/ocp/4830.epwmss/48300180.eqep/power/runtime_status
> active
> # cat 
> /sys/devices/platform/ocp/48302000.epwmss/48302180.eqep/power/runtime_status
> active
> # cat 
> /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/power/runtime_status
> active
>
> # cat /sys/devices/platform/ocp/4830.epwmss/48300180.eqep/position
> 0
> # cat /sys/devices/platform/ocp/48302000.epwmss/48302180.eqep/position
> 0
> # cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
> -1
>
> I'm guessing this is probably not a real solution, but it seems
> promising to finally avoid that unhandled fault ("external abort on
> non-linefetch") upon reading position.

Nice find Drew!

Once you enable the power control, it's it acting the same as v4.4.x was?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYi32UQNHOK%3DH8xu0nTFD00U5_JY65Vy4opaeD_%2BOoOuvg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: witch API is more suitable with beaglebne black for streaming and recording? thank u for help

[Robert Nelson]

On Mon, Jan 30, 2017 at 7:42 PM, 'woody stanford' via BeagleBoard
 wrote:
> I'm interested in this too. I'm looking for webcam over USB to what Wiem
> said saved to drive.

https://github.com/jacksonliam/mjpg-streamer

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYgEB5mmjXxRSiH95OyV_URrV_C9aTwT2skA_P71H1OJ1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: witch API is more suitable with beaglebne black for streaming and recording? thank u for help

[evilwulfie]

who are you talking to?

this particular thread was created march 31 2016



On 1/30/2017 6:42 PM, 'woody stanford' via BeagleBoard wrote:
> I'm interested in this too. I'm looking for webcam over USB to what
> Wiem said saved to drive.
>
> On Thursday, March 31, 2016 at 6:21:52 AM UTC-7, wiem barguellil wrote:
>
> witch API (jpeg streamer or pyhthon library.) is more suitable
> with beaglebne black for streaming and recording? thank u for help
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard+unsubscr...@googlegroups.com
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/d3466359-e933-4297-8581-c36c88737296%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8b40dd08-7461-deb3-196a-294db15fe0aa%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: witch API is more suitable with beaglebne black for streaming and recording? thank u for help

['woody stanford' via BeagleBoard]

I'm interested in this too. I'm looking for webcam over USB to what Wiem 
said saved to drive.

On Thursday, March 31, 2016 at 6:21:52 AM UTC-7, wiem barguellil wrote:
>
> witch API (jpeg streamer or pyhthon library.) is more suitable with 
> beaglebne black for streaming and recording? thank u for help
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d3466359-e933-4297-8581-c36c88737296%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: UAV Drone out of a BBBW

['woody stanford' via BeagleBoard]

Still trying to find my blueprints for it (I think its on my Ubuntu box, 
but my monitor is fried on it, grrr, and I'm sure its not accessable on 
FTP, I'm on my Windows 10 workstation now), but here is an interesting 
example of MOSFET motor speed control via GPIO or PWM.



The top center part of it is kind of dumb in that I think their point is to 
use a pot read by an ADC to do the speed control. However I would do it via 
UART or software instead. However the rest of the circuit is a great 
example of real motor speed control using an inexpensive MOSFET driven by 
MCU or BBB PWM.

On Monday, January 30, 2017 at 6:19:30 PM UTC-7, woody stanford wrote:
>
> I posted the remote control for this in Software, but I put a bunch of 
> hardware in it so I thought I'd post it here.
>
>
> https://groups.google.com/forum/#!category-topic/beagleboard/software/evSIUcuWfUY
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/bce4ee5c-0ce9-446d-8f35-7b39d3504b66%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] UAV Drone out of a BBBW

['woody stanford' via BeagleBoard]

I posted the remote control for this in Software, but I put a bunch of 
hardware in it so I thought I'd post it here.

https://groups.google.com/forum/#!category-topic/beagleboard/software/evSIUcuWfUY

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/785e81c8-0104-467a-9dd4-1b44d58b59c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Drone Remote out of $60 Win10 Tablet

['woody stanford' via BeagleBoard]

Here is my autonomous flight planner (so its a little more than a drone).




This is my "map editor" where I read in a Google Earth map and what I do is 
I calibrate it for 2D cartesian in meters around an origin (in this case 
Central and Van Buren downtown) and then I calibrate it by clicking two 
points on the map I know the NEMA coordinates for (which Earth just gives 
you by pointing and clicking).' 


Then I go to my actual flight planner window and I click on the points in 
my flight path, and set the altitudes for each waypoint and feed it to the 
BBBW via FTP (its a pretty big file). I just hit the Waypoint button on my 
drone remote and it just runs the program, so its a good way to fly out of 
wifi range. I then get someone with an identical tablet to "catch" it when 
it comes in range, and it would be manually landed, or just the autoland 
feature that just nulls everything out and causes it to descend slowly 
enough that it doesn't hurt the drone when it touches down.


It was interesting doing this because you need to set a 3D radius from each 
waypoint point because it never actually hits the point (more of a sphere 
of a preset diameter) that once is passes through this imaginary sphere 
then it knows to go to the next sphere or point.


It also has my environmentally sealed Emerson camera (that I still need to 
get an SD card for) that is just bolted to the underside of the base board 
that I just manually hit the video record before taking off. When I get 
some video I'll post it here.


On Monday, January 30, 2017 at 5:24:55 PM UTC-7, woody stanford wrote:
>
> I'm building a drone with my BBBW as its brain. I have my remote control 
> for it mostly coded in VB.NET. Basically what it does is it runs the BBBW 
> on the drone in hotspot mode and it just synchs the stacks in my tablet 
> with the BBBW and I send UDP packets via winsock with raw "joystick" 
> coordinates to the controlling daemon on the drone.
>
> Range is only about 400 feet out doors, but more than enough to fly a 
> drone around a little.
>
> Here is a screen shot of what appears on the tablet.
>
>
> 
>
>
>
>
> The left hand control is throttle and you can pitch by moving your thumb 
> up and down on the right hand control and yaw is with right to left. Roll 
> is nulled out by the 6DOF interial module. To fly forward what you do is 
> pitch forward and increase your throttle and then you steer by yawing.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e492efb7-2e50-467c-b74d-f9e54a87b687%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU FAQ 2013-05-15

[Rick Mann]

Jason, the Nixie Cape and Camera Interface project links are 404.

> On Wednesday, May 15, 2013 at 2:12:39 PM UTC-7, Jason Kridner wrote:
> Frequently asked questions regarding "PRU":
>   • What is a "PRU"?
>   • PRU stands for Programmable Real-time Unit.  The overall 
> subsystem is typically called the ICSS, PRU-ICSS or PRUSS.  ICSS stands for 
> Industrial Communications Subsystem and PRUSS stands for Programmable 
> Real-time Unit Subsystem.
>   • What does a PRU do?
>   • A PRU is a 200MHz microcontroller that is really useful at 
> "bitbanging" and has some peripherals attached to it that make it well suited 
> for building real-time interfaces to all types of digital electronics.
>   • What are the processing elements within the AM33xx PRUSS used on 
> BeagleBone and BeagleBone Black?
>   • 2 32-bit 200MHz PRU cores
>   • Each with 8KB of program memory
>   • Direct access to general purpose I/O
>   • Single cycle operations without cache or pipelines 
> (instructions *always* 5ns)
>   • Shared 12KB data memory
>   • Scratch pad registers
>   • Parallel and serial capture modes
>   • 32-bit port to memory and other peripherals outside of the 
> PRUSS, including external memory
>   • What are some example things built out of PRUs?
>   • DMX512 lighting protocol: 
> http://beagleboard.org/CapeContest/entries/BeagleBone+DMX+Cape/
>   • 6502 memory interface: 
> http://elinux.org/images/a/ac/What's_Old_Is_New-_A_6502-based_Remote_Processor.pdf
>   • Emulated memory interface on an Atari 600XL with BeagleBone 
> decoding video directly into Atari 600XL display memory: 
> http://www.youtube.com/watch?v=1irR4TQ5aMA
>   • Nixie tube interface: 
> https://github.com/mranostay/beagle-nixie
>   • Software UART: 
> http://processors.wiki.ti.com/index.php/Soft-UART_Implementation_on_AM335X_PRU_-_Software_Users_Guide
>   • Sine wave generator using PWMs: 
> http://elinux.org/ECE497_BeagleBone_PRU
>   • 3D printer stepper motor driver: 
> http://hipstercircuits.com/pypruss-a-simple-pru-python-binding-for-beaglebone/
>   • Camera interface: 
> http://www.hitchhikeree.org/beaglebone_capes/interacto/
>   • Where do I get some more details?
>   • https://github.com/beagleboard/am335x_pru_package is the 
> official location for documentation and tools for the PRUSS on BeagleBone and 
> BeagleBone Black.
>   • http://elinux.org/Ti_AM33XX_PRUSSv2 is the community wiki 
> page.
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/37abb769-2526-4420-bf06-d2a4af1beee9%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/85613C36-5E9E-41BE-80E0-C96B2B285E8C%40latencyzero.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Drone Remote out of $60 Win10 Tablet

['woody stanford' via BeagleBoard]

Here is a block diagram of the hardware on the drone. The remote is all 
software running on my POS Win10 tablet like I was saying.



On Monday, January 30, 2017 at 5:24:55 PM UTC-7, woody stanford wrote:
>
> I'm building a drone with my BBBW as its brain. I have my remote control 
> for it mostly coded in VB.NET. Basically what it does is it runs the BBBW 
> on the drone in hotspot mode and it just synchs the stacks in my tablet 
> with the BBBW and I send UDP packets via winsock with raw "joystick" 
> coordinates to the controlling daemon on the drone.
>
> Range is only about 400 feet out doors, but more than enough to fly a 
> drone around a little.
>
> Here is a screen shot of what appears on the tablet.
>
>
> 
>
>
>
>
> The left hand control is throttle and you can pitch by moving your thumb 
> up and down on the right hand control and yaw is with right to left. Roll 
> is nulled out by the 6DOF interial module. To fly forward what you do is 
> pitch forward and increase your throttle and then you steer by yawing.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/ffe1a5ac-bf93-458d-8618-77d303baa882%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


drone_block_diagram1.pdf
Description: Adobe PDF document

[beagleboard] Drone Remote out of $60 Win10 Tablet

['woody stanford' via BeagleBoard]

I'm building a drone with my BBBW as its brain. I have my remote control 
for it mostly coded in VB.NET. Basically what it does is it runs the BBBW 
on the drone in hotspot mode and it just synchs the stacks in my tablet 
with the BBBW and I send UDP packets via winsock with raw "joystick" 
coordinates to the controlling daemon on the drone.

Range is only about 400 feet out doors, but more than enough to fly a drone 
around a little.

Here is a screen shot of what appears on the tablet.






The left hand control is throttle and you can pitch by moving your thumb up 
and down on the right hand control and yaw is with right to left. Roll is 
nulled out by the 6DOF interial module. To fly forward what you do is pitch 
forward and increase your throttle and then you steer by yawing.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5e493ce2-dcd5-4d1b-9218-915c079dc78c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: [beagle-alpha] v4.9.x-ti now open for testing...

[Drew Fustini]

On Mon, Jan 30, 2017 at 1:02 PM, Drew Fustini  wrote:
> Thanks for the assistance, Franklin.  Here is the patch that is applied:
> https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-4.9.y/patches/drivers/ti/eqep
>
> The boot log is in this gist and also attached:
> https://gist.github.com/pdp7/0df175876304e30e8971c2aadb7493c7/

I just found that I can avoid the abort by setting runtime power
control to "on" instead of "auto" through sysfs.

# uname -r
4.9.6-ti-r17
# config-pin p8.11 qep
# config-pin p8.12 qep

# echo on > 
/sys/devices/platform/ocp/4830.epwmss/48300180.eqep/power/control
# echo on > 
/sys/devices/platform/ocp/48302000.epwmss/48302180.eqep/power/control
# echo on > 
/sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/power/control

# cat 
/sys/devices/platform/ocp/4830.epwmss/48300180.eqep/power/runtime_status
active
# cat 
/sys/devices/platform/ocp/48302000.epwmss/48302180.eqep/power/runtime_status
active
# cat 
/sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/power/runtime_status
active

# cat /sys/devices/platform/ocp/4830.epwmss/48300180.eqep/position
0
# cat /sys/devices/platform/ocp/48302000.epwmss/48302180.eqep/position
0
# cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
-1

I'm guessing this is probably not a real solution, but it seems
promising to finally avoid that unhandled fault ("external abort on
non-linefetch") upon reading position.

-Drew

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAPgEAj7DbRuS48KEt8C2nB6Bv801xAujL_7cr_VGULmoMBpxOA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] VAX

['woody stanford' via BeagleBoard]

Does anyone else just sit there with several PUTTY windows open and just 
watch that blinking blue light on their BBBW and just use their imagination 
that they are actually connected to the ole VAX at their old alma matter? 
It is a really nice little UN*X host right out of the box...I still can't 
believe it has man pages as well in FLASH. Rather impressed with Angstrom.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/436e3882-3768-4601-8ee0-8c4c91f1fee4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Of SPI and such

['woody stanford' via BeagleBoard]

The answer I was looking for. Thank you much Graham. A yes...this is good 
as now I have control of my BBB UARTS from C (and thus python, etc. etc.)

My next question might be an elaboration on how to access the 
GPIO/SPI/I2C/CAN/ADC however I have the magic key to BBB because I'm lazy 
and I can just break everything out to external MCU via UART. Clever huh?

My PIC's have bad ass multichannel 10-bit ADC, and I do the PWM in software 
which gives me absolutely perfect wave form control. I can even slow down 
my motors before stopping them at 20 Mhz on my PIC16Fx. I mean I'm not 
YouTube needing DMA-driven super streaming capability for my next round of 
financing. I'm just me.

I just want GPS, 9DOF accel/gyro with magnetometer calibration, RS485, 
MAX232, thermistor, pressure, stepper motor and industrial-strength servo 
motor control. I don't ask much. Not to mention ganged isolated MOSFET 
power handling and relay board capability. You know...the usual. :)

On Monday, January 30, 2017 at 5:55:06 AM UTC-7, woody stanford wrote:
>
> I'm of the opinion that a lot of the terminology being used is being 
> mixed, slurred, shifted in such a way to make basic concepts difficult to 
> understand. I thought I would just talk about it.
>
> What is SPI? You can use the terms UART and SPI interchangably. Bear with 
> me on this...my point is cultural. SPI is ***serial***, asynchronous (in 
> that it doesn't require a clock line, it uses timing purely) and 0V meaning 
> zero and +5V meaning one (TTL). That I suppose you can have SPI use +3.3V 
> to represent one is acceptable.
>
> This whole idea about SPI "throwing ioctl errors" is preposterous based on 
> the previous. SPI is generated by a UART, a chip, a piece of hardware (that 
> you can code a software UART not withstanding). SPI is the protocol that is 
> the raw output of a UART.
>
> I2C is understood to be (1) a protocol that uses a clock signal in 
> conjunction with a data line, and (2) has something to do with being able 
> to multiplex several "peripherals" at the same time with allusions to being 
> the little brother of RS485. And no one really knows what CAN does, only 
> that it is there and is comforting to know that you can connect as many 
> things to your CPU as you could possibly conceive. It is a mystery lol. 
>
> That we are being held hostage by electrical engineers and the whole 
> microcontroller community does in no way change the fact that the BBB is a 
> true UN*X host. Its just the way that it is.
>
> Which leads to the inevitable question, why this ambiguity regarding the 
> correct procedure to configure and utilize the P8 and P9 connectors. This 
> is a TRIVIAL issue on a microcontroller. You just set the configuration 
> registers such and communicate. Why this ambiguity on the BBB, whether real 
> or perceived? I suppose that someone in authority at Beagleboard has to 
> settle the issue for the prime path to success in using the P8/9 
> connectors. This ambiguity is killing me. Does libpruio do it? I don't know 
> :)
>
> My understanding of it is thus (and I'm sure its inaccurate and I beg 
> someone to definitively explain it better so that I might understand), that 
> it is a combination of a systems administration task combined with a 
> programming task, that both must be done in order to unlock the potent 
> connectivity powers of the BBB's P8 and P9 headers.That the crux of the 
> issue is two fold, that I must add some lines to various configuration 
> files so that it activates the ttyO1 thru ttyO6 "terminals" which allows 
> civilized serial (and other communication like GPIO) to happen. My 
> instincts tell me that this pertains intimately to the UN*X concept of a 
> "stream", a concept of power and thus an element of our UN*X faith.
>
> Is this so? And if not, how is it? Is my question to the minds greater 
> than my own.
>
> Thenwe use such programming concepts such as fopen() and open() to 
> communicate with ttyO1 thru ttyO6 providing abstraction yet nimble, 
> universal connectivity.
>
> Thoughts?
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/cf880373-d48e-4e48-aaa3-da8d75b8cef8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Of SPI and such

[Graham]

Simple answer, yes.  

As part of fopen, you need to flush and set up the buffers, and decide 
whether it is blocking or not, and check for initialization errors, but 
once you get the hang of that, it is not hard.

Being a "legacy" protocol, serial is very mature, and lots of good example 
code out there, that has not needed revision in the last 20 years. 

All of this dates to the dawn of UN*X.

The operator console on the very first UN*X machines were teletype (tty) 
machines or early electronic terminals that emulated teletype machine 
serial communications.

Your PICs will enjoy talking to ole Grand Dad.

--- Graham

==


On Monday, January 30, 2017 at 2:31:57 PM UTC-6, woody stanford wrote:
>
> Thank you for the quick and informative reply, Graham.
>
> So ttyOx IS the UART abstraction that is used by UN*X typically? So I 
> should just be able to fopen (speaking C) /dev/ttyO1 and have read write 
> stream access to the TX and RX pins of UART1, assuming of course I've setup 
> the "overlays" correctly? Is my question.
>
> Sorry, just so used to being able to read from and write to COM1, that 
> this process sounds so involved.
>
> I have some PIC's that want to make serial love to my BBBW is all. And I'm 
> not used to letting my PIC's down. I will have you know that my PIC16Fx's 
> are pretty good "bitbangers" themselves.
>
> On Monday, January 30, 2017 at 5:55:06 AM UTC-7, woody stanford wrote:
>>
>> I'm of the opinion that a lot of the terminology being used is being 
>> mixed, slurred, shifted in such a way to make basic concepts difficult to 
>> understand. I thought I would just talk about it.
>>
>> What is SPI? You can use the terms UART and SPI interchangably. Bear with 
>> me on this...my point is cultural. SPI is ***serial***, asynchronous (in 
>> that it doesn't require a clock line, it uses timing purely) and 0V meaning 
>> zero and +5V meaning one (TTL). That I suppose you can have SPI use +3.3V 
>> to represent one is acceptable.
>>
>> This whole idea about SPI "throwing ioctl errors" is preposterous based 
>> on the previous. SPI is generated by a UART, a chip, a piece of hardware 
>> (that you can code a software UART not withstanding). SPI is the protocol 
>> that is the raw output of a UART.
>>
>> I2C is understood to be (1) a protocol that uses a clock signal in 
>> conjunction with a data line, and (2) has something to do with being able 
>> to multiplex several "peripherals" at the same time with allusions to being 
>> the little brother of RS485. And no one really knows what CAN does, only 
>> that it is there and is comforting to know that you can connect as many 
>> things to your CPU as you could possibly conceive. It is a mystery lol. 
>>
>> That we are being held hostage by electrical engineers and the whole 
>> microcontroller community does in no way change the fact that the BBB is a 
>> true UN*X host. Its just the way that it is.
>>
>> Which leads to the inevitable question, why this ambiguity regarding the 
>> correct procedure to configure and utilize the P8 and P9 connectors. This 
>> is a TRIVIAL issue on a microcontroller. You just set the configuration 
>> registers such and communicate. Why this ambiguity on the BBB, whether real 
>> or perceived? I suppose that someone in authority at Beagleboard has to 
>> settle the issue for the prime path to success in using the P8/9 
>> connectors. This ambiguity is killing me. Does libpruio do it? I don't know 
>> :)
>>
>> My understanding of it is thus (and I'm sure its inaccurate and I beg 
>> someone to definitively explain it better so that I might understand), that 
>> it is a combination of a systems administration task combined with a 
>> programming task, that both must be done in order to unlock the potent 
>> connectivity powers of the BBB's P8 and P9 headers.That the crux of the 
>> issue is two fold, that I must add some lines to various configuration 
>> files so that it activates the ttyO1 thru ttyO6 "terminals" which allows 
>> civilized serial (and other communication like GPIO) to happen. My 
>> instincts tell me that this pertains intimately to the UN*X concept of a 
>> "stream", a concept of power and thus an element of our UN*X faith.
>>
>> Is this so? And if not, how is it? Is my question to the minds greater 
>> than my own.
>>
>> Thenwe use such programming concepts such as fopen() and open() to 
>> communicate with ttyO1 thru ttyO6 providing abstraction yet nimble, 
>> universal connectivity.
>>
>> Thoughts?
>>
>>
>>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/9b53a20f-1064-42cd-bfbe-8e90c3531d55%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: tpa81(sensor temperatur)

['woody stanford' via BeagleBoard]

You are using I2C to read a thermistor? What are you building an atom 
smasher lol?

Switch your I2C to ADC and find a PDF of a themistor-to-voltage network of 
discretes and just read the ADC.

My God man. :D

On Tuesday, November 15, 2016 at 10:35:27 PM UTC-7, zaenal abidin wrote:
>
> tomorrow i can running thermal with i2c in bbb ,therefor im clean one 
> file.there are file erased.
> when i run file again .showed
>
> thermal1= bus.read_byte_data(address, reg1)
> IOError: [Errno 121] Remote I/O error
>
>
> anyone know to fix it?
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/725a1fe9-3921-4738-ab6b-a8390efa86d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pyserial stopped working after Debian update?

[Robert Nelson]

On Mon, Jan 30, 2017 at 2:41 PM, Harke Smits  wrote:
> OK I got it working manually;
> Fist:
>
> debian@beaglebone:~$ cat /sys/devices/platform/bone_capemgr/slots
>  0: PF  -1 4D cape display variables
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
>
> Than:
>
> sudo sh -c "echo 'BB-UART2' > /sys/devices/platform/bone_capemgr/slots"
>
> Again:
>
> debian@beaglebone:~$ cat /sys/devices/platform/bone_capemgr/slots
>  0: PF  -1 etc...
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-UART2
>
> My testscript using UART2 now works. However, after a reboot all needs to be
> done again. Not very satisfactory.
> How can I get it installed on boot?

open /boot/uEnv.txt

cape_enable=bone_capemgr.enable_partno=BB-UART2

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYhbYZLBMoDmH2RRgPCNEteh-NkamXNeXU0A-mYdGhgDnQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Running .exe file after boot

['woody stanford' via BeagleBoard]

idk about the whole *.exe thing.

I've found programming ANSI C that its nice to be able to port my MinGW 
code directly to GCC without changing my build shell scripts (*blushes* 
well my make files I mean). Hense a lot of my bins on my UN*X have the exe 
extension.

Seems to work...alignment aside.

On Wednesday, October 26, 2016 at 11:57:42 AM UTC-7, Dieter Wirz wrote:
>
> ./someexecutable 
> This means run "someexecutable" in the in the current directory 
> because ./ is the current directory. 
> In startup scripts give the full path! without leading point! 
> e.g. 
> /home/you/somepath/someexecutable 
> AND as evilwulfie pinted out, never ever call a unix executable *.exe. 
> This is evil;) 
>
>
>
>
> On Wed, Oct 26, 2016 at 7:28 PM, Dror Lugasi  > wrote: 
> > Hello guys.. 
> > I have a code i wrote in monodevelop and i have the program .exe file 
> that i want to run after the desktop is loaded. 
> > When i go into the terminal and change the dir to the debug folder and 
> run ./thefile.exe it works. 
> > 
> > I tried to add this command to a shell script that i run at boot as 
> > ./thefile.exe 
> > And also cd  and then ./thefile.exe but none has worked. 
> > 
> > Can anyone please help me to figure out how to run my .exe file 
> automatically after boot (prefer as root if possible) 
> > 
> > Cheers! 
> > Dror. 
> > 
> > -- 
> > For more options, visit http://beagleboard.org/discuss 
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups "BeagleBoard" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to beagleboard...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/f73293bd-454b-4f41-8141-776bf8ca454c%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/760c7c57-11e3-4057-b463-a5f90a484b89%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pyserial stopped working after Debian update?

[Harke Smits]

OK I got it working manually;
Fist:

debian@beaglebone:~$ cat /sys/devices/platform/bone_capemgr/slots
 0: PF  -1 4D cape display variables
 1: PF  -1
 2: PF  -1
 3: PF  -1

Than:

sudo sh -c "echo 'BB-UART2' > /sys/devices/platform/bone_capemgr/slots"

Again:

debian@beaglebone:~$ cat /sys/devices/platform/bone_capemgr/slots
 0: PF  -1 etc...
 1: PF  -1
 2: PF  -1
 3: PF  -1
 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-UART2

My testscript using UART2 now works. However, after a reboot all needs to
be done again. Not very satisfactory.
How can I get it installed on boot?
Please advise!
Regards,
Harke


On 29 January 2017 at 23:35, Harke Smits  wrote:

> I repeated everything: same problem. BBB does not boot anymore!? Did I do
> something wrong here?
> Please advise, regards,
> Harke
>
> On 29 January 2017 at 21:36, Harke Smits  wrote:
>
>> Unfortunately that crashes the system. all four blue leds on
>> I will try and reflash from mem card.
>> H
>>
>> On 29 January 2017 at 21:13, Robert Nelson 
>> wrote:
>>
>>> On Sun, Jan 29, 2017 at 2:04 PM, Harke Smits  wrote:
>>> > Hello Robert,
>>> >
>>> > Thanks for your reaction. I understand /dev/ttyOx has been replaced by
>>> > /dev/ttySx (x from 0-5). However the rest is far beyond my level of
>>> skill. I
>>> > do not know what dt overlay I load. I just flashed the latest Debian
>>> > version. And then updated all (sudo apt-get update). I do not
>>> understand C,
>>> > just a bit of Python. I need to use the UARTs 2 and 4. and of course a
>>> > number of I/O bits. I hope that is still the same? I can and are
>>> prepared to
>>> > move to the latest versions, just need to know what to do
>>>
>>> btw, you can also just do:
>>>
>>> cd /opt/scripts/tools/
>>> git pull
>>> sudo ./update_kernel.sh --bone-channel --stable
>>> sudo reboot
>>>
>>> and then you can return to the classic 3.8.13 based kernel you are use
>>> too..
>>>
>>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAHmciaYy3Bs2tO9TqS9tXvnPx-6eLWcb9Wx_Krk-YCxJwfc5WA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Of SPI and such

['woody stanford' via BeagleBoard]

Thank you for the quick and informative reply, Graham.

So ttyOx IS the UART abstraction that is used by UN*X typically? So I 
should just be able to fopen (speaking C) /dev/ttyO1 and have read write 
stream access to the TX and RX pins of UART1, assuming of course I've setup 
the "overlays" correctly? Is my question.

Sorry, just so used to being able to read from and write to COM1, that this 
process sounds so involved.

I have some PIC's that want to make serial love to my BBBW is all. And I'm 
not used to letting my PIC's down. I will have you know that my PIC16Fx's 
are pretty good "bitbangers" themselves.

On Monday, January 30, 2017 at 5:55:06 AM UTC-7, woody stanford wrote:
>
> I'm of the opinion that a lot of the terminology being used is being 
> mixed, slurred, shifted in such a way to make basic concepts difficult to 
> understand. I thought I would just talk about it.
>
> What is SPI? You can use the terms UART and SPI interchangably. Bear with 
> me on this...my point is cultural. SPI is ***serial***, asynchronous (in 
> that it doesn't require a clock line, it uses timing purely) and 0V meaning 
> zero and +5V meaning one (TTL). That I suppose you can have SPI use +3.3V 
> to represent one is acceptable.
>
> This whole idea about SPI "throwing ioctl errors" is preposterous based on 
> the previous. SPI is generated by a UART, a chip, a piece of hardware (that 
> you can code a software UART not withstanding). SPI is the protocol that is 
> the raw output of a UART.
>
> I2C is understood to be (1) a protocol that uses a clock signal in 
> conjunction with a data line, and (2) has something to do with being able 
> to multiplex several "peripherals" at the same time with allusions to being 
> the little brother of RS485. And no one really knows what CAN does, only 
> that it is there and is comforting to know that you can connect as many 
> things to your CPU as you could possibly conceive. It is a mystery lol. 
>
> That we are being held hostage by electrical engineers and the whole 
> microcontroller community does in no way change the fact that the BBB is a 
> true UN*X host. Its just the way that it is.
>
> Which leads to the inevitable question, why this ambiguity regarding the 
> correct procedure to configure and utilize the P8 and P9 connectors. This 
> is a TRIVIAL issue on a microcontroller. You just set the configuration 
> registers such and communicate. Why this ambiguity on the BBB, whether real 
> or perceived? I suppose that someone in authority at Beagleboard has to 
> settle the issue for the prime path to success in using the P8/9 
> connectors. This ambiguity is killing me. Does libpruio do it? I don't know 
> :)
>
> My understanding of it is thus (and I'm sure its inaccurate and I beg 
> someone to definitively explain it better so that I might understand), that 
> it is a combination of a systems administration task combined with a 
> programming task, that both must be done in order to unlock the potent 
> connectivity powers of the BBB's P8 and P9 headers.That the crux of the 
> issue is two fold, that I must add some lines to various configuration 
> files so that it activates the ttyO1 thru ttyO6 "terminals" which allows 
> civilized serial (and other communication like GPIO) to happen. My 
> instincts tell me that this pertains intimately to the UN*X concept of a 
> "stream", a concept of power and thus an element of our UN*X faith.
>
> Is this so? And if not, how is it? Is my question to the minds greater 
> than my own.
>
> Thenwe use such programming concepts such as fopen() and open() to 
> communicate with ttyO1 thru ttyO6 providing abstraction yet nimble, 
> universal connectivity.
>
> Thoughts?
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/602d3230-974a-4ed2-a460-f8430d749b22%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Sensors + Arduino + Linux ?

[gorghino]

Hi guys,
at the moment I'm working with another board and this is the workflow:

I have an Arduino sketch that does the following:
- reads from hardware serial pin (Serial0)
- reads a DTH22 sensor with appropriate library on a pin
- communicates to other modules using I2C dedicated pins with appropriate 
libraries

This sketch reads from and writes to a serial port (tty/MCC) in order to 
communicate with a Python script running in Linux (Ubuntu).

I have also a GPS module connected to hardware UART to Linux attached to a 
gpsd daemon.

I need access (SSH) to Install python, libraries I need, drivers (I need to 
compile a Dekart SIM reader) and I need wpa_supplicant.

I'd like to know If I can do the same with a BBB. You, experts...do you 
think everything is feasible?
 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f5158b72-69ca-4220-be4f-1fb23854bb67%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Sensors + Arduino + Linux?

[Davide Aguiari]

Hi guys,
at the moment I'm working with another board and this is the workflow:

I have an Arduino sketch that does the following:
- reads from hardware serial pin (Serial0)
- reads a DTH22 sensor with appropriate library on a pin
- communicates to other modules using I2C dedicated pins with appropriate 
libraries

This sketch reads from and writes to a serial port (tty/MCC) in order to 
communicate with a Python script running in Linux (Ubuntu).

I have also a GPS module connected to hardware UART to Linux attached to a 
gpsd daemon.

I need access (SSH) to Install python, libraries I need, drivers (I need to 
compile some Dekart SIM reader driver I have), wpa_supplicant etc.

I'd like to know If I can do the same with a BBB. You, experts...do you 
think everything is feasible?
 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1fc3b5a0-3566-4cab-a005-f78554c784ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Of SPI and such

[Graham Haddock]

On Mon, Jan 30, 2017 at 12:24 PM, 'woody stanford' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> You are obviously knowledgeable, Graham, so we'll pose these questions to
> you then.
>
> (1) Is serial (ie. UART) communication on a BBBW (Rev C) Angstrom "distro"
> (ie. stock) done with the ttyO1 to ttyO6 "terminals". Is this HOW it is
> done? Elaborate if you feel the need. (Hoping he's going to say yes to this
> so I can just use stdio.h and feel confident about it)
>

Do you really mean Angstrom? If so, switch to one of the current Debian
distros as fast as you can.

ttyO1 to ttyO6 are not "terminals."  A terminal client would use ttyOx to
access the corresponding UART based serial ports.

The "stdio.h" equivalent for serial communications is "termios.h" .   I
suggest you Google that and start reading. Look for things like
"Programming with Termios".


> (2) What is THE accepted procedure(s) for enabling PWM/UART/TIMER/GPIOs on
> a BBB? Is it as they say by manipulating the uEnv.txt file, or would the
> pin-config utility be better, or am I mistaken here as well?
>
> There are many ways to enable an IO on the Beaglebone. Custom .dts/.dtb,
Universal I/O, or use the pre-compiled overlays you access from uEnv.txt.
I usually find that for a serious application, I am just better off doing a
custom .dts/.dtb for my application, so I am in control, and know
everything that is going on.
If you only want to do one or two things for a simple application, the
overlays work fine.
But, for instance, if you are using audio streaming from the McASP as part
of your application, you have to start with a different base .dtb, that I
am not sure has been tested for compatibility with all the overlays.

Not so critical but interested on your opinion:
>
> (3) How do you feel about, at the board level, running a BBB's UART's TX
> to a bunch of RX's on (slave) MCU's, and then using a 1 byte "address" to
> figure which MCU the following byte(s) were for?
>
> Lots of serial protocols do things like that.  If it is a closed system,
and you are in control of both ends, should work fine.


> (4) Conversely, how do you feel about, again at the board level, running
> the MCU's UART TX's all to one bus wire and connecting that to the BBB's
> RX. Electrically and otherwise I mean? And then prefacing each transmit
> with a 1-byte "address" so the BBB knows which MCU the following byte(s) is
> coming from?
>

See (3).  Sounds like you are re-inventing Ethernet.

The fun begins when you want status back from the slaves, and now you have
to build a custom bus receive combiner that adds everything back together
from the slaves.  And an overlay protocol that deals with bus collisions,
if the slaves can autonomously speak without being polled.

--- Graham

==

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CANN_KV7gXcLgOCpK%2B_gmZtxrLzLphTEOL_4HOQp7%3DHx33O9Jcw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Are Windows Driver Signings Going to be Updated?

['woody stanford' via BeagleBoard]

I would take your IT manager or sys admin out to lunch to Appleby's or 
Olive Garden and get to know him/her. This is a human issue not a technical 
one IMO.

On Wednesday, January 4, 2017 at 5:44:19 PM UTC-7, Jared McIntyre wrote:
>
> The Window's drivers haven't been install-able without turning off sign 
> checking for several months. I have a number of machines that I can't do 
> that on due to IT policy. Is there going to be an updated installer with 
> updated signings?
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/2e9b54b9-04f8-473c-986a-d72942e7dd78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PRU FAQ 2013-05-15

['woody stanford' via BeagleBoard]

Still I am a fan of my little K150 PIC programmer. I wish I could say that 
I soldered it myself however I pussed out this time and got a nice little 
jobby from Hong Kong or somewhere. Cased it myself. I can even carry it 
with me if I wanted to and its USB cable is just the right length.

My issue with PRU is this: Why would I learn yet another microcontroller 
language when I can just electrically load from hex file with my beloved 
K150 to a $1 PIC?

On Wednesday, May 15, 2013 at 2:12:39 PM UTC-7, Jason Kridner wrote:
>
> Frequently asked questions regarding "PRU":
>
>- What is a "PRU"?
>- PRU stands for Programmable Real-time Unit.  The overall subsystem 
>   is typically called the ICSS, PRU-ICSS or PRUSS.  ICSS stands for 
>   Industrial Communications Subsystem and PRUSS stands for Programmable 
>   Real-time Unit Subsystem.
>- What does a PRU do?
>   - A PRU is a 200MHz microcontroller that is really useful at 
>   "bitbanging" and has some peripherals attached to it that make it well 
>   suited for building real-time interfaces to all types of digital 
>   electronics.
>- What are the processing elements within the AM33xx PRUSS used on 
>BeagleBone and BeagleBone Black?
>   - 2 32-bit 200MHz PRU cores
>   - Each with 8KB of program memory
>   - Direct access to general purpose I/O
>   - Single cycle operations without cache or pipelines (instructions 
>   *always* 5ns)
>   - Shared 12KB data memory
>   - Scratch pad registers
>   - Parallel and serial capture modes
>   - 32-bit port to memory and other peripherals outside of the PRUSS, 
>   including external memory
>- What are some example things built out of PRUs?
>   - DMX512 lighting protocol: 
>   http://beagleboard.org/CapeContest/entries/BeagleBone+DMX+Cape/
>   - 6502 memory interface: 
>   
> http://elinux.org/images/a/ac/What's_Old_Is_New-_A_6502-based_Remote_Processor.pdf
>   - Emulated memory interface on an Atari 600XL with BeagleBone 
>   decoding video directly into Atari 600XL display memory: 
>   http://www.youtube.com/watch?v=1irR4TQ5aMA
>   - Nixie tube interface: https://github.com/mranostay/beagle-nixie
>   - Software UART: 
>   
> http://processors.wiki.ti.com/index.php/Soft-UART_Implementation_on_AM335X_PRU_-_Software_Users_Guide
>   - Sine wave generator using PWMs: 
>   http://elinux.org/ECE497_BeagleBone_PRU
>   - 3D printer stepper motor driver: 
>   
> http://hipstercircuits.com/pypruss-a-simple-pru-python-binding-for-beaglebone/
>   - Camera interface: 
>   http://www.hitchhikeree.org/beaglebone_capes/interacto/
>- Where do I get some more details?
>   - https://github.com/beagleboard/am335x_pru_package is the official 
>   location for documentation and tools for the PRUSS on BeagleBone and 
>   BeagleBone Black.
>   - http://elinux.org/Ti_AM33XX_PRUSSv2 is the community wiki page.
>   
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/a0f4dcab-55fb-4e51-af97-516d38311cc2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PRU FAQ 2013-05-15

['woody stanford' via BeagleBoard]

This is gold, Jason. Thank you so much for sharing this with us. I personal 
was wondering what a lot of this stuff was.

Have to admit that I was somewhat unclear as to quite a few of these 
concepts, but I was especially encouraged when I read the term 
"industrial". It is good to know we have that level of strength in our 
little SBC's. The assurance is comforting.

On Wednesday, May 15, 2013 at 2:12:39 PM UTC-7, Jason Kridner wrote:
>
> Frequently asked questions regarding "PRU":
>
>- What is a "PRU"?
>- PRU stands for Programmable Real-time Unit.  The overall subsystem 
>   is typically called the ICSS, PRU-ICSS or PRUSS.  ICSS stands for 
>   Industrial Communications Subsystem and PRUSS stands for Programmable 
>   Real-time Unit Subsystem.
>- What does a PRU do?
>   - A PRU is a 200MHz microcontroller that is really useful at 
>   "bitbanging" and has some peripherals attached to it that make it well 
>   suited for building real-time interfaces to all types of digital 
>   electronics.
>- What are the processing elements within the AM33xx PRUSS used on 
>BeagleBone and BeagleBone Black?
>   - 2 32-bit 200MHz PRU cores
>   - Each with 8KB of program memory
>   - Direct access to general purpose I/O
>   - Single cycle operations without cache or pipelines (instructions 
>   *always* 5ns)
>   - Shared 12KB data memory
>   - Scratch pad registers
>   - Parallel and serial capture modes
>   - 32-bit port to memory and other peripherals outside of the PRUSS, 
>   including external memory
>- What are some example things built out of PRUs?
>   - DMX512 lighting protocol: 
>   http://beagleboard.org/CapeContest/entries/BeagleBone+DMX+Cape/
>   - 6502 memory interface: 
>   
> http://elinux.org/images/a/ac/What's_Old_Is_New-_A_6502-based_Remote_Processor.pdf
>   - Emulated memory interface on an Atari 600XL with BeagleBone 
>   decoding video directly into Atari 600XL display memory: 
>   http://www.youtube.com/watch?v=1irR4TQ5aMA
>   - Nixie tube interface: https://github.com/mranostay/beagle-nixie
>   - Software UART: 
>   
> http://processors.wiki.ti.com/index.php/Soft-UART_Implementation_on_AM335X_PRU_-_Software_Users_Guide
>   - Sine wave generator using PWMs: 
>   http://elinux.org/ECE497_BeagleBone_PRU
>   - 3D printer stepper motor driver: 
>   
> http://hipstercircuits.com/pypruss-a-simple-pru-python-binding-for-beaglebone/
>   - Camera interface: 
>   http://www.hitchhikeree.org/beaglebone_capes/interacto/
>- Where do I get some more details?
>   - https://github.com/beagleboard/am335x_pru_package is the official 
>   location for documentation and tools for the PRUSS on BeagleBone and 
>   BeagleBone Black.
>   - http://elinux.org/Ti_AM33XX_PRUSSv2 is the community wiki page.
>   
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/37abb769-2526-4420-bf06-d2a4af1beee9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: [beagle-alpha] v4.9.x-ti now open for testing...

[Franklin S Cooper Jr]

So one thing I noticed is that the eqep node isn't adding any clocks
compared to EHRPWM and ECAP. So I would be curious if adding the
following entries to the eqep node may solve. I don't really remember
how we came up with this

clocks = <_root_clk_div>;
clock-names = "fck";

>From what I remember for ECAP and PWM that the PWMSS clock gate wouldn't
allow a clock to be ungated once you tell it to gate it. However, the
patch you mentioned shouldn't change anything because by default (on
reset) PWMSS ungates the PWM, ECAP and EQEP clocks.

You mind sharing a boot log showing this failure? Also can you share the
patch your using now for the eqep driver along with dts changes?


On 01/30/2017 03:15 AM, Drew Fustini wrote:
> On Sun, Jan 29, 2017 at 3:13 AM, Drew Fustini  wrote:
>> eqep was working for me in 4.4.x but I get a segmentation fault when I
>> read the sysfs position file:
>> # cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
>> [ 1858.108446] Unhandled fault: external abort on non-linefetch
>> (0x1028) at 0xfa304184
>>
>> I'm now reading about pm_runtime_get_sync() in
>> Documentation/power/runtime_pm.txt.  I'll update if I make any
>> progress.
> 
> I'm still investigating but I did notice that the original tieqep
> driver had this code to enable the clock to the eQEP unit:
> https://github.com/Teknoman117/beaglebot/blob/master/encoders/patches/0001-tieqep-driver.patch#L721
> 
> // Enable the clock to the eQEP unit
> status = pwmss_submodule_state_change(pdev->dev.parent, PWMSS_EQEPCLK_EN);
> 
> // If we failed to enable the clocks, fail out
> if (!(status & PWMSS_EQEPCLK_EN_ACK))
> {
>dev_err(>dev, "PWMSS config space clock enable failed\n");
>ret = -EINVAL;
>goto pwmss_clk_failure;
> }
> 
> The function pwmss_submodule_state_change() appears to have been
> removed by this commit:
> 
> commit cc37655e6bbf83ded1e4d1d7ffd977786a845a67
> Author: Cooper Jr., Franklin 
> Date:   Mon Mar 7 13:33:56 2016 -0600
> 
> pwm: pwm-ti*: Remove support for local clock gating
> 
> The PWMSS local clock gating registers have no real purpose on OMAP ARM
> devices. These registers were left over registers from DSP IP where the
> PRCM doesn't exist. There is a silicon bug where gating and ungating 
> clocks
> don't function properly. TRMs will be update to indicate that these
> registers shouldn't be touched.
> 
> Therefore, all code that accesses the PWMSS_CLKCONFIG or PWMSS_CLKSTATUS
> will be removed by this patch with zero loss of functionality by the ECAP
> and EPWM drivers.
> 
> 
> -Drew
> 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/a438a516-5f97-9af8-cd26-0e95237544c6%40ti.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Web Cams and UN*X

['woody stanford' via BeagleBoard]

I have a nice little environmentally-sealed Emerson camera ($30) that makes 
a spectacular web cam I've found.

Is there a library linkable (or otherwise) with GCC whereby I can capture 
its USB output and manipulate it programatically. I would also want to 
compress it to drive in MPEG or MP4 format on board my stock BBBW. Any idea 
on some command line bins that would do this easily and well?

Thanks in advance.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/00410c45-d631-4a6f-8d14-13f41761cb0d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Of SPI and such

['woody stanford' via BeagleBoard]

Furthermore, how about putting a byte after the address byte with the 
length of the "frame" (and I use this term loosely) using the BBB as master 
(for collision avoidance, I mean) with each MCU only speaking when spoken 
too? Just thinking out loud lol.

On Monday, January 30, 2017 at 5:55:06 AM UTC-7, woody stanford wrote:
>
> I'm of the opinion that a lot of the terminology being used is being 
> mixed, slurred, shifted in such a way to make basic concepts difficult to 
> understand. I thought I would just talk about it.
>
> What is SPI? You can use the terms UART and SPI interchangably. Bear with 
> me on this...my point is cultural. SPI is ***serial***, asynchronous (in 
> that it doesn't require a clock line, it uses timing purely) and 0V meaning 
> zero and +5V meaning one (TTL). That I suppose you can have SPI use +3.3V 
> to represent one is acceptable.
>
> This whole idea about SPI "throwing ioctl errors" is preposterous based on 
> the previous. SPI is generated by a UART, a chip, a piece of hardware (that 
> you can code a software UART not withstanding). SPI is the protocol that is 
> the raw output of a UART.
>
> I2C is understood to be (1) a protocol that uses a clock signal in 
> conjunction with a data line, and (2) has something to do with being able 
> to multiplex several "peripherals" at the same time with allusions to being 
> the little brother of RS485. And no one really knows what CAN does, only 
> that it is there and is comforting to know that you can connect as many 
> things to your CPU as you could possibly conceive. It is a mystery lol. 
>
> That we are being held hostage by electrical engineers and the whole 
> microcontroller community does in no way change the fact that the BBB is a 
> true UN*X host. Its just the way that it is.
>
> Which leads to the inevitable question, why this ambiguity regarding the 
> correct procedure to configure and utilize the P8 and P9 connectors. This 
> is a TRIVIAL issue on a microcontroller. You just set the configuration 
> registers such and communicate. Why this ambiguity on the BBB, whether real 
> or perceived? I suppose that someone in authority at Beagleboard has to 
> settle the issue for the prime path to success in using the P8/9 
> connectors. This ambiguity is killing me. Does libpruio do it? I don't know 
> :)
>
> My understanding of it is thus (and I'm sure its inaccurate and I beg 
> someone to definitively explain it better so that I might understand), that 
> it is a combination of a systems administration task combined with a 
> programming task, that both must be done in order to unlock the potent 
> connectivity powers of the BBB's P8 and P9 headers.That the crux of the 
> issue is two fold, that I must add some lines to various configuration 
> files so that it activates the ttyO1 thru ttyO6 "terminals" which allows 
> civilized serial (and other communication like GPIO) to happen. My 
> instincts tell me that this pertains intimately to the UN*X concept of a 
> "stream", a concept of power and thus an element of our UN*X faith.
>
> Is this so? And if not, how is it? Is my question to the minds greater 
> than my own.
>
> Thenwe use such programming concepts such as fopen() and open() to 
> communicate with ttyO1 thru ttyO6 providing abstraction yet nimble, 
> universal connectivity.
>
> Thoughts?
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/bce1a27d-758a-4a25-b7c2-1e99cb748092%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: [beagle-alpha] v4.9.x-ti now open for testing...

[Drew Fustini]

On Mon, Jan 30, 2017 at 10:56 AM, Franklin S Cooper Jr  wrote:
> So one thing I noticed is that the eqep node isn't adding any clocks
> compared to EHRPWM and ECAP. So I would be curious if adding the
> following entries to the eqep node may solve. I don't really remember
> how we came up with this
>
> clocks = <_root_clk_div>;
> clock-names = "fck";
>
> From what I remember for ECAP and PWM that the PWMSS clock gate wouldn't
> allow a clock to be ungated once you tell it to gate it. However, the
> patch you mentioned shouldn't change anything because by default (on
> reset) PWMSS ungates the PWM, ECAP and EQEP clocks.
>
> You mind sharing a boot log showing this failure? Also can you share the
> patch your using now for the eqep driver along with dts changes?

Thanks for the assistance, Franklin.  Here is the patch that is applied:
https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-4.9.y/patches/drivers/ti/eqep

The boot log is in this gist and also attached:
https://gist.github.com/pdp7/0df175876304e30e8971c2aadb7493c7/


Thanks!
Drew

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAPgEAj5eR2Tr1meUCAgow1Lfe%2B0-YwbZXKuJiEk%2BLqopt35Vkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
root@beaglebone:~# dmesg
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.9.6-ti-r17 (root@a6-imx6q-wandboard-2gb) (gcc 
version 4.9.2 (Debian 4.9.2-10) ) #1 SMP PREEMPT Sat Jan 28 11:37:11 UTC 2017
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] OF: fdt:Machine model: TI AM335x BeagleBone Black
[0.00] cma: Reserved 48 MiB at 0x9c80
[0.00] Memory policy: Data cache writeback
[0.00] On node 0 totalpages: 130560
[0.00] free_area_init_node: node 0, pgdat c13dd080, node_mem_map 
df961000
[0.00]   Normal zone: 1152 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 130560 pages, LIFO batch:31
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] AM335X ES2.1 (sgx neon)
[0.00] percpu: Embedded 15 pages/cpu @df92d000 s31936 r8192 d21312 
u61440
[0.00] pcpu-alloc: s31936 r8192 d21312 u61440 alloc=15*4096
[0.00] pcpu-alloc: [0] 0 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 129408
[0.00] Kernel command line: console=tty0 console=ttyO0,115200n8 
root=/dev/mmcblk0p2 rootfstype=ext4 rootwait coherent_pool=1M quiet 
cape_universal=enable
[0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
[0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Memory: 443920K/522240K available (12288K kernel code, 1086K 
rwdata, 4092K rodata, 1024K init, 736K bss, 29168K reserved, 49152K 
cma-reserved, 0K highmem)
[0.00] Virtual kernel memory layout:
vector  : 0x - 0x1000   (   4 kB)
fixmap  : 0xffc0 - 0xfff0   (3072 kB)
vmalloc : 0xe080 - 0xff80   ( 496 MB)
lowmem  : 0xc000 - 0xe000   ( 512 MB)
pkmap   : 0xbfe0 - 0xc000   (   2 MB)
modules : 0xbf00 - 0xbfe0   (  14 MB)
  .text : 0xc0008000 - 0xc0d0   (13280 kB)
  .init : 0xc120 - 0xc130   (1024 kB)
  .data : 0xc130 - 0xc140fa80   (1087 kB)
   .bss : 0xc1411000 - 0xc14c9138   ( 737 kB)
[0.00] Preemptible hierarchical RCU implementation.
[0.00]  Build-time adjustment of leaf fanout to 32.
[0.00]  RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1.
[0.00] RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=1
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128 
interrupts
[0.00] OMAP clockevent source: timer2 at 2400 Hz
[0.16] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 
89478484971ns
[0.32] clocksource: timer1: mask: 0x max_cycles: 0x, 
max_idle_ns: 79635851949 ns
[0.42] OMAP clocksource: timer1 at 2400 Hz
[0.001186] clocksource_probe: no matching clocksources found
[0.001673] Console: colour dummy device 80x30
[0.001728] console [tty0] enabled
[0.001751] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0'
[0.001756] This ensures that you still see kernel messages. Please
[0.001760] update your kernel commandline.
[0.001781] Calibrating 

[beagleboard] Re: Clock frequency for i2c1

['woody stanford' via BeagleBoard]

As I understand it, I2C can be used for high-speed communication, so as 
fast as you can realistically pull that clock line is how fast you can go. 
Hense the clock line. I would look at it holistically. The BBB can probably 
really reef on that clock line (1 Ghz processor...kernel aside) so I'd look 
at the peripheral's core clock speed and figure how fast you can 
realistically do it. Just an opinion.

On Tuesday, January 24, 2017 at 10:57:54 PM UTC-7, Madhu K wrote:
>
> Hi All,
>
> I am trying to enable I2C1 ( using device tree ) on beaglebone black. what 
> clock frequency should I use, from where to get this information?
>
> Please help me out find this information .
>
> Thanks & Regards,
> Madhu
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d156871b-0daf-403e-b17c-36ac2382f570%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Of SPI and such

['woody stanford' via BeagleBoard]

You are obviously knowledgeable, Graham, so we'll pose these questions to 
you then.

(1) Is serial (ie. UART) communication on a BBBW (Rev C) Angstrom "distro" 
(ie. stock) done with the ttyO1 to ttyO6 "terminals". Is this HOW it is 
done? Elaborate if you feel the need. (Hoping he's going to say yes to this 
so I can just use stdio.h and feel confident about it)

(2) What is THE accepted procedure(s) for enabling PWM/UART/TIMER/GPIOs on 
a BBB? Is it as they say by manipulating the uEnv.txt file, or would the 
pin-config utility be better, or am I mistaken here as well?

Not so critical but interested on your opinion:

(3) How do you feel about, at the board level, running a BBB's UART's TX to 
a bunch of RX's on (slave) MCU's, and then using a 1 byte "address" to 
figure which MCU the following byte(s) were for?

(4) Conversely, how do you feel about, again at the board level, running 
the MCU's UART TX's all to one bus wire and connecting that to the BBB's 
RX. Electrically and otherwise I mean? And then prefacing each transmit 
with a 1-byte "address" so the BBB knows which MCU the following byte(s) is 
comming from?


On Monday, January 30, 2017 at 5:55:06 AM UTC-7, woody stanford wrote:
>
> I'm of the opinion that a lot of the terminology being used is being 
> mixed, slurred, shifted in such a way to make basic concepts difficult to 
> understand. I thought I would just talk about it.
>
> What is SPI? You can use the terms UART and SPI interchangably. Bear with 
> me on this...my point is cultural. SPI is ***serial***, asynchronous (in 
> that it doesn't require a clock line, it uses timing purely) and 0V meaning 
> zero and +5V meaning one (TTL). That I suppose you can have SPI use +3.3V 
> to represent one is acceptable.
>
> This whole idea about SPI "throwing ioctl errors" is preposterous based on 
> the previous. SPI is generated by a UART, a chip, a piece of hardware (that 
> you can code a software UART not withstanding). SPI is the protocol that is 
> the raw output of a UART.
>
> I2C is understood to be (1) a protocol that uses a clock signal in 
> conjunction with a data line, and (2) has something to do with being able 
> to multiplex several "peripherals" at the same time with allusions to being 
> the little brother of RS485. And no one really knows what CAN does, only 
> that it is there and is comforting to know that you can connect as many 
> things to your CPU as you could possibly conceive. It is a mystery lol. 
>
> That we are being held hostage by electrical engineers and the whole 
> microcontroller community does in no way change the fact that the BBB is a 
> true UN*X host. Its just the way that it is.
>
> Which leads to the inevitable question, why this ambiguity regarding the 
> correct procedure to configure and utilize the P8 and P9 connectors. This 
> is a TRIVIAL issue on a microcontroller. You just set the configuration 
> registers such and communicate. Why this ambiguity on the BBB, whether real 
> or perceived? I suppose that someone in authority at Beagleboard has to 
> settle the issue for the prime path to success in using the P8/9 
> connectors. This ambiguity is killing me. Does libpruio do it? I don't know 
> :)
>
> My understanding of it is thus (and I'm sure its inaccurate and I beg 
> someone to definitively explain it better so that I might understand), that 
> it is a combination of a systems administration task combined with a 
> programming task, that both must be done in order to unlock the potent 
> connectivity powers of the BBB's P8 and P9 headers.That the crux of the 
> issue is two fold, that I must add some lines to various configuration 
> files so that it activates the ttyO1 thru ttyO6 "terminals" which allows 
> civilized serial (and other communication like GPIO) to happen. My 
> instincts tell me that this pertains intimately to the UN*X concept of a 
> "stream", a concept of power and thus an element of our UN*X faith.
>
> Is this so? And if not, how is it? Is my question to the minds greater 
> than my own.
>
> Thenwe use such programming concepts such as fopen() and open() to 
> communicate with ttyO1 thru ttyO6 providing abstraction yet nimble, 
> universal connectivity.
>
> Thoughts?
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/cc87d34b-8250-463e-93ba-2038a61de601%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Of SPI and such

['woody stanford' via BeagleBoard]

Hmmm. And I thought I was "old school".

http://www.mouser.com/ProductDetail/IQD/LFXTAL003185Bulk/?qs=sGAEpiMZZMsMyYRRhGMFNt26FzbIzMCTJO3fmLZxTac%3d

We all know what SPI is.

On Monday, January 30, 2017 at 5:55:06 AM UTC-7, woody stanford wrote:
>
> I'm of the opinion that a lot of the terminology being used is being 
> mixed, slurred, shifted in such a way to make basic concepts difficult to 
> understand. I thought I would just talk about it.
>
> What is SPI? You can use the terms UART and SPI interchangably. Bear with 
> me on this...my point is cultural. SPI is ***serial***, asynchronous (in 
> that it doesn't require a clock line, it uses timing purely) and 0V meaning 
> zero and +5V meaning one (TTL). That I suppose you can have SPI use +3.3V 
> to represent one is acceptable.
>
> This whole idea about SPI "throwing ioctl errors" is preposterous based on 
> the previous. SPI is generated by a UART, a chip, a piece of hardware (that 
> you can code a software UART not withstanding). SPI is the protocol that is 
> the raw output of a UART.
>
> I2C is understood to be (1) a protocol that uses a clock signal in 
> conjunction with a data line, and (2) has something to do with being able 
> to multiplex several "peripherals" at the same time with allusions to being 
> the little brother of RS485. And no one really knows what CAN does, only 
> that it is there and is comforting to know that you can connect as many 
> things to your CPU as you could possibly conceive. It is a mystery lol. 
>
> That we are being held hostage by electrical engineers and the whole 
> microcontroller community does in no way change the fact that the BBB is a 
> true UN*X host. Its just the way that it is.
>
> Which leads to the inevitable question, why this ambiguity regarding the 
> correct procedure to configure and utilize the P8 and P9 connectors. This 
> is a TRIVIAL issue on a microcontroller. You just set the configuration 
> registers such and communicate. Why this ambiguity on the BBB, whether real 
> or perceived? I suppose that someone in authority at Beagleboard has to 
> settle the issue for the prime path to success in using the P8/9 
> connectors. This ambiguity is killing me. Does libpruio do it? I don't know 
> :)
>
> My understanding of it is thus (and I'm sure its inaccurate and I beg 
> someone to definitively explain it better so that I might understand), that 
> it is a combination of a systems administration task combined with a 
> programming task, that both must be done in order to unlock the potent 
> connectivity powers of the BBB's P8 and P9 headers.That the crux of the 
> issue is two fold, that I must add some lines to various configuration 
> files so that it activates the ttyO1 thru ttyO6 "terminals" which allows 
> civilized serial (and other communication like GPIO) to happen. My 
> instincts tell me that this pertains intimately to the UN*X concept of a 
> "stream", a concept of power and thus an element of our UN*X faith.
>
> Is this so? And if not, how is it? Is my question to the minds greater 
> than my own.
>
> Thenwe use such programming concepts such as fopen() and open() to 
> communicate with ttyO1 thru ttyO6 providing abstraction yet nimble, 
> universal connectivity.
>
> Thoughts?
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/733197f6-b894-41c8-8943-0b14443ff036%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Phasors calculation using libpruio

[John Syne]

Well, again it depends on what you mean by realtime. To most developers, it 
means deterministic and since the AM335x ADC uses a sequencer to do the 
sampling, it is deterministic, and hence there is no difference between the PRU 
and ARM with DMA. This shouldn’t be a pissing match as to how fast you can 
sample, but rather focus on what the OP application was. In this case, since 
the PRU doesn’t have the required math functions, the PRU is only doing what 
the DMA is doing, moving samples from the FIFO to DDR memory. Hence, why waste 
the PRU on such a trivial function. Rather save it for something more useful. 

One more thing, the IIO framework is capable of GSPS performance. 

Regards,
John




> On Jan 30, 2017, at 9:17 AM, TJF  wrote:
> 
> 
> 
> Am Sonntag, 29. Januar 2017 21:50:31 UTC+1 schrieb john3909:
> Hi TJF,
> 
> The IIO ADC can sample at 800K samples per second [1].
> 
> This is not real-time sampling! When you transfer chunks of samples by DMA, 
> you add further and unsteady latency. The only way to sample real-time is 
> pulling samples one by one from the FiFo, and this is limited to 200 kSps (= 
> TI specification, on some boards I got up to 250 kSps).
>  
> You cannot achieve that sampling rate with with PRU and have it do something 
> useful with those samples.
> 
> Why do you know what I can achieve? I did experimental sampling at 1600 kSps 
> with the PRU, up to 295 samples (until the FiFo overflows). I assume that I 
> can get twice that number by using both FiFos (with more than one channel). 
> But this is not real-time, and it's not ready for daily use.
> 
> BTW: At 200 kSps the PRU performes 1000 instructions between two samples. 
> Fairly enough to do something useful (as long as you don't use remoteproc 
> framework).  
> 
> Please do not confuse the users! You should mention that your solution is 
> experimental and you're looking for beta testers.
> 
> I don’t see the purpose of having PRU read from /dev/iio:deviceX.
> 
> Not today, but in future you may notice that the PRUSS are very good in data 
> processing and you'll need to feed them with data for that purpose.
> 
> 
> @Fabián
> 
> The external ADC is an option when you may need the TSC_ADC_SS for a touch 
> screen on the board. Otherwise it's an overkill, just protect the analog 
> input lines against under-/overvoltage.
> 
> Regards
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/5148db1c-9819-47fc-a3e3-2a0dc8e1d9f0%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/29D31B81-D659-4821-8C05-D878B9563120%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Phasors calculation using libpruio

[TJF]

Am Sonntag, 29. Januar 2017 21:50:31 UTC+1 schrieb john3909:
>
> Hi TJF,
>
> The IIO ADC can sample at 800K samples per second [1]. 
>

This is not real-time sampling! When you transfer chunks of samples by DMA, 
you add further and unsteady latency. The only way to sample real-time is 
pulling samples one by one from the FiFo, and this is limited to 200 kSps 
(= TI specification, on some boards I got up to 250 kSps).
 

> You cannot achieve that sampling rate with with PRU and have it do 
> something useful with those samples.
>

Why do you know what I can achieve? I did experimental sampling at 1600 
kSps with the PRU, up to 295 samples (until the FiFo overflows). I assume 
that I can get twice that number by using both FiFos (with more than one 
channel). But this is not real-time, and it's not ready for daily use.

BTW: At 200 kSps the PRU performes 1000 instructions between two samples. 
Fairly enough to do something useful (as long as you don't use remoteproc 
framework).  

Please do not confuse the users! You should mention that your solution is 
experimental and you're looking for beta testers.

I don’t see the purpose of having PRU read from /dev/iio:deviceX.
>

Not today, but in future you may notice that the PRUSS are very good in 
data processing and you'll need to feed them with data for that purpose.


@Fabián

The external ADC is an option when you may need the TSC_ADC_SS for a touch 
screen on the board. Otherwise it's an overkill, just protect the analog 
input lines against under-/overvoltage.

Regards

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5148db1c-9819-47fc-a3e3-2a0dc8e1d9f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] eqep in linux 4.4.38+ not working

[abhilash h]

My bad . It was disabled in the kernel config.
On Mon, 30 Jan 2017 at 3:08 PM, abhilash h  wrote:

> Dear All,
>
> I am using linux kernel 4.4.38+ with busybox as rfs.
>
> I have loaded bone_eqep2b-00A0.dtbo  to slots.
>  i.e
> # echo bone_eqep2b > /sys/devices/platform/bone_
> capemgr/slots
>
> Then it got loaded
>
> [   35.295161] bone_capemgr bone_capemgr: part_number 'bone_eqep2b',
> version 'N/A'
> [   35.302625] bone_capemgr bone_capemgr: slot #4:
> override
> [   35.307977] bone_capemgr bone_capemgr: Using override eeprom data at
> slot 4
> [   35.314984] bone_capemgr bone_capemgr: slot #4: 'Override Board
> Name,00A0,Override Manuf,bone_eqep2b'
> [   35.332763] bone_capemgr bone_capemgr: slot #4: dtbo
> 'bone_eqep2b-00A0.dtbo' loaded; overlay id #0
>
> But in the /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep  i can
> see only
> #
> ls
>
> driver_override  of_node
> subsystem
>
> modalias poweruevent
>
> There are no period, or position files to read.
> It would be great if someone could help me out.
>
> Regards,
> Abhilash
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/9b9233c6-fad8-4d8a-ae6c-559dad53757f%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CA%2B-ZLiviwRy_HOoXreH197A3hBroPbJ097WTE_2oGFr0BKK24w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Interfacing kentec qvga display (BOOSTXL-K350QVG-S1) to beaglebone black

[Robert Nelson]

On Mon, Jan 30, 2017 at 10:28 AM, Girish Tiwari  wrote:
> Hey guys.
>
> We are newbies to beaglebone black having Debian(Jessie). We are trying to
> interface the LCD to BBblack (its not a cape). What we have understood is
> that we need to disable hdmi and make changes to devtree (Havnt done
> though). What chanegs are needed further. How to connect the pins. Shall we
> use SPI interfaces or the I2C. And what are the LCD_DATA pins for? Any help
> will be appreciated. Thanks.

Well, step 1: read the datasheet:

http://www.ti.com/lit/ug/slau601a/slau601a.pdf

 2.1.5 SPI Configuration By default the BOOSTXL-K350QVG-S1
comes configured as a "4-wire" 8-bit SPI. This is the standard SPI on
most MCUs with a hardware SPI peripheral. The user can reconfigure
R2/R3 and R8/R9 to instead use "3-wire" 9-bit SPI. In this
configuration, each SPI write is 9 bits instead of 8, allowing one
fewer GPIO pin to be used. 

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYiKGc37PW-VE8CSu9pOSthJKVPfUJGGhDYncY27xehgSA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Interfacing kentec qvga display (BOOSTXL-K350QVG-S1) to beaglebone black

[evilwulfie]

You scare me.

On 1/30/2017 9:28 AM, Girish Tiwari wrote:
> Hey guys.
>
> We are newbies to beaglebone black having Debian(Jessie). We are
> trying to interface the LCD to BBblack (its not a cape). What we have
> understood is that we need to disable hdmi and make changes to devtree
> (Havnt done though). What chanegs are needed further. How to connect
> the pins. Shall we use SPI interfaces or the I2C. And what are the
> LCD_DATA pins for? Any help will be appreciated. Thanks.
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard+unsubscr...@googlegroups.com
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/2012a20b-da05-43b8-bdf2-cef3f49f88f3%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/325d2026-b607-3e14-a006-6c22b8dc860c%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Interfacing kentec qvga display (BOOSTXL-K350QVG-S1) to beaglebone black

[Girish Tiwari]

Hey guys.

We are newbies to beaglebone black having Debian(Jessie). We are trying to 
interface the LCD to BBblack (its not a cape). What we have understood is 
that we need to disable hdmi and make changes to devtree (Havnt done 
though). What chanegs are needed further. How to connect the pins. Shall we 
use SPI interfaces or the I2C. And what are the LCD_DATA pins for? Any help 
will be appreciated. Thanks.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/2012a20b-da05-43b8-bdf2-cef3f49f88f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Of SPI and such

[Graham]

Woody:

SPI and Serial Data from a UART are very different.

SPI is synchronous with a supplied clock.  All that is sent on the data 
line is data.
Addressing is via a separate "Chip Select" line.

UARTs and their serial data are a legacy serial communications system from 
the teletype days.
There is no clock sent with UART.  It adds start and stop bits to frame the 
data as overhead, and requires that the independent clocks at the sending 
and receiving ends are within 5 percent of each other, or so. If you add a 
second stop bit (an option), then your independent send and receive clocks 
can be over ten percent apart. There is no explicit addressing. It is up to 
the receiver to figure out who the message is for.  The large permitted 
errors in clock frequency date from the time that quart crystals were 
extremely expensive, and therefore not a solution. The "clocks" were 
mechanical flyweight centrifugal regulators.

--- Graham

==

On Monday, January 30, 2017 at 6:55:06 AM UTC-6, woody stanford wrote:
>
> I'm of the opinion that a lot of the terminology being used is being 
> mixed, slurred, shifted in such a way to make basic concepts difficult to 
> understand. I thought I would just talk about it.
>
> What is SPI? You can use the terms UART and SPI interchangably. Bear with 
> me on this...my point is cultural. SPI is ***serial***, asynchronous (in 
> that it doesn't require a clock line, it uses timing purely) and 0V meaning 
> zero and +5V meaning one (TTL). That I suppose you can have SPI use +3.3V 
> to represent one is acceptable.
>
> This whole idea about SPI "throwing ioctl errors" is preposterous based on 
> the previous. SPI is generated by a UART, a chip, a piece of hardware (that 
> you can code a software UART not withstanding). SPI is the protocol that is 
> the raw output of a UART.
>
> I2C is understood to be (1) a protocol that uses a clock signal in 
> conjunction with a data line, and (2) has something to do with being able 
> to multiplex several "peripherals" at the same time with allusions to being 
> the little brother of RS485. And no one really knows what CAN does, only 
> that it is there and is comforting to know that you can connect as many 
> things to your CPU as you could possibly conceive. It is a mystery lol. 
>
> That we are being held hostage by electrical engineers and the whole 
> microcontroller community does in no way change the fact that the BBB is a 
> true UN*X host. Its just the way that it is.
>
> Which leads to the inevitable question, why this ambiguity regarding the 
> correct procedure to configure and utilize the P8 and P9 connectors. This 
> is a TRIVIAL issue on a microcontroller. You just set the configuration 
> registers such and communicate. Why this ambiguity on the BBB, whether real 
> or perceived? I suppose that someone in authority at Beagleboard has to 
> settle the issue for the prime path to success in using the P8/9 
> connectors. This ambiguity is killing me. Does libpruio do it? I don't know 
> :)
>
> My understanding of it is thus (and I'm sure its inaccurate and I beg 
> someone to definitively explain it better so that I might understand), that 
> it is a combination of a systems administration task combined with a 
> programming task, that both must be done in order to unlock the potent 
> connectivity powers of the BBB's P8 and P9 headers.That the crux of the 
> issue is two fold, that I must add some lines to various configuration 
> files so that it activates the ttyO1 thru ttyO6 "terminals" which allows 
> civilized serial (and other communication like GPIO) to happen. My 
> instincts tell me that this pertains intimately to the UN*X concept of a 
> "stream", a concept of power and thus an element of our UN*X faith.
>
> Is this so? And if not, how is it? Is my question to the minds greater 
> than my own.
>
> Thenwe use such programming concepts such as fopen() and open() to 
> communicate with ttyO1 thru ttyO6 providing abstraction yet nimble, 
> universal connectivity.
>
> Thoughts?
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5258340f-c5a5-47b1-8864-09f243ae3ad7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Starterware files needed to create executable for beaglebone

[scmanop]

Hey everybody,

Excuse me if this is already explained, but i could not find a clear 
answer..so here i am.

My goal is to load an executable to beaglebone white and see it 
working...Unfortunately i am a complete newbie
and thus i would need your help. Please show patience:) and excuse my 
ignorance for the following questions.
To begin with, i have used Starterware's source and header files along with 
some i created and i have managed to build them
successfully via arm-gcc cross toolchain. My intention is to load the 
produced executable in my board with the help of Code 
Composer Studio. 
The problem is that i suspect that i haven't linked all the necessary 
files. I mean, i guess that there should be some files 
regarding some initialization of the board or some memory mapping, aren't 
they?
So my question is:
What extra files should be also built and/or inked? (for example something 
like startup.c from starterware)
I have noticed that when building a project via CCS, the latter creates 
automatically a linker command file, appropriate for the target board.
Don't i need something like this?

I hope my question is clear but feel free to ask for clarifications.

Thanks in advance

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/24137324-97b5-4b83-b9a8-3f1ad1a5fd7e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Of SPI and such

['woody stanford' via BeagleBoard]

I'm of the opinion that a lot of the terminology being used is being mixed, 
slurred, shifted in such a way to make basic concepts difficult to 
understand. I thought I would just talk about it.

What is SPI? You can use the terms UART and SPI interchangably. Bear with 
me on this...my point is cultural. SPI is ***serial***, asynchronous (in 
that it doesn't require a clock line, it uses timing purely) and 0V meaning 
zero and +5V meaning one (TTL). That I suppose you can have SPI use +3.3V 
to represent one is acceptable.

This whole idea about SPI "throwing ioctl errors" is preposterous based on 
the previous. SPI is generated by a UART, a chip, a piece of hardware (that 
you can code a software UART not withstanding). SPI is the protocol that is 
the raw output of a UART.

I2C is understood to be (1) a protocol that uses a clock signal in 
conjunction with a data line, and (2) has something to do with being able 
to multiplex several "peripherals" at the same time with allusions to being 
the little brother of RS485. And no one really knows what CAN does, only 
that it is there and is comforting to know that you can connect as many 
things to your CPU as you could possibly conceive. It is a mystery lol. 

That we are being held hostage by electrical engineers and the whole 
microcontroller community does in no way change the fact that the BBB is a 
true UN*X host. Its just the way that it is.

Which leads to the inevitable question, why this ambiguity regarding the 
correct procedure to configure and utilize the P8 and P9 connectors. This 
is a TRIVIAL issue on a microcontroller. You just set the configuration 
registers such and communicate. Why this ambiguity on the BBB, whether real 
or perceived? I suppose that someone in authority at Beagleboard has to 
settle the issue for the prime path to success in using the P8/9 
connectors. This ambiguity is killing me. Does libpruio do it? I don't know 
:)

My understanding of it is thus (and I'm sure its inaccurate and I beg 
someone to definitively explain it better so that I might understand), that 
it is a combination of a systems administration task combined with a 
programming task, that both must be done in order to unlock the potent 
connectivity powers of the BBB's P8 and P9 headers.That the crux of the 
issue is two fold, that I must add some lines to various configuration 
files so that it activates the ttyO1 thru ttyO6 "terminals" which allows 
civilized serial (and other communication like GPIO) to happen. My 
instincts tell me that this pertains intimately to the UN*X concept of a 
"stream", a concept of power and thus an element of our UN*X faith.

Is this so? And if not, how is it? Is my question to the minds greater than 
my own.

Thenwe use such programming concepts such as fopen() and open() to 
communicate with ttyO1 thru ttyO6 providing abstraction yet nimble, 
universal connectivity.

Thoughts?


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/74281284-7fdd-474d-beef-f80632ece74e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: can't load device tree on Debian jessie 8.6 with kernel version 4.4.43-ti-r84

[Greg]

I think you are making progress, but I'm having a little trouble following 
the grep pru.

You should end up with 2 firmwares in /lib/firmware with very specific 
names:

am335x-pru0-fw
am335x-pru1-fw

Just do

ls /lib/firmware

and see if they are there.
Also:

ls /dev

If you got through the example from the support package, there should be a 
character device file there:

rpmsg_pru30

If you get the above, that is a very good sign that everything is 
configured and working.
Note that you will probably have to reboot for the character device to 
appear after successfully compiling the firmwares and moving them 
/lib/firmware.

Toggling a GPIO is easy.  You will need to use the __R30 special register 
variable.
Look in the am335x examples directory of the PRU support package:

PRU_gpioToggle

Yes you are correct I didn't use the CCS.  In the case of the PRUs, simple 
projects are not creating libraries of code.
And the C code files for the PRUs are no problem for the BeagleBone itself 
to compile.
If you have used a cross-compiler set-up before, there is a lot of 
configuration required, and probably debugging of problems.
I did see a note that the CCS no longer requires any sort of license.  I 
might go back and look at it in the future,
but for now the command line via SSH is more than adequate for what I want 
to achieve with the PRUs.

Greg

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e31269c3-803c-4d9b-b177-1cc953ad06b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] eqep in linux 4.4.38+ not working

[abhilash h]

Dear All,

I am using linux kernel 4.4.38+ with busybox as rfs.

I have loaded bone_eqep2b-00A0.dtbo  to slots.
 i.e 
# echo bone_eqep2b > /sys/devices/platform/bone_
capemgr/slots

Then it got loaded

[   35.295161] bone_capemgr bone_capemgr: part_number 'bone_eqep2b', 
version 'N/A'   
[   35.302625] bone_capemgr bone_capemgr: slot #4: 
override  
[   35.307977] bone_capemgr bone_capemgr: Using override eeprom data at 
slot 4   
[   35.314984] bone_capemgr bone_capemgr: slot #4: 'Override Board 
Name,00A0,Override Manuf,bone_eqep2b' 
[   35.332763] bone_capemgr bone_capemgr: slot #4: dtbo 
'bone_eqep2b-00A0.dtbo' loaded; overlay id #0 

But in the /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep  i can 
see only
# 
ls  
   

driver_override  of_node  
subsystem  

modalias poweruevent   

There are no period, or position files to read.
It would be great if someone could help me out.

Regards,
Abhilash

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/9b9233c6-fad8-4d8a-ae6c-559dad53757f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] eqep in linux 4.4.38+ not working

[abhilash h]

Dear All,

I am using linux kernel 4.4.38+ with busybox as rfs.

I have loaded bone_eqep2b-00A0.dtbo  to slots.
 i.e 
# echo bone_eqep2b > /sys/devices/platform/bone_capemgr/slots

Then it got loaded

[   35.295161] bone_capemgr bone_capemgr: part_number 'bone_eqep2b', 
version 'N/A'   
[   35.302625] bone_capemgr bone_capemgr: slot #4: 
override  
[   35.307977] bone_capemgr bone_capemgr: Using override eeprom data at 
slot 4   
[   35.314984] bone_capemgr bone_capemgr: slot #4: 'Override Board 
Name,00A0,Override Manuf,bone_eqep2b' 
[   35.332763] bone_capemgr bone_capemgr: slot #4: dtbo 
'bone_eqep2b-00A0.dtbo' loaded; overlay id #0 

But in the /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep  i can 
see only
# 
ls  
   

driver_override  of_node  
subsystem  

modalias poweruevent   

There are no period, or position files to read.
It would be great if someone could help me out.

Regards,
Abhilash




-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/808912ca-a63f-4106-a02e-5f92d33a1ef0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: [beagle-alpha] v4.9.x-ti now open for testing...

[Drew Fustini]

On Sun, Jan 29, 2017 at 3:13 AM, Drew Fustini  wrote:
> eqep was working for me in 4.4.x but I get a segmentation fault when I
> read the sysfs position file:
> # cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position
> [ 1858.108446] Unhandled fault: external abort on non-linefetch
> (0x1028) at 0xfa304184
>
> I'm now reading about pm_runtime_get_sync() in
> Documentation/power/runtime_pm.txt.  I'll update if I make any
> progress.

I'm still investigating but I did notice that the original tieqep
driver had this code to enable the clock to the eQEP unit:
https://github.com/Teknoman117/beaglebot/blob/master/encoders/patches/0001-tieqep-driver.patch#L721

// Enable the clock to the eQEP unit
status = pwmss_submodule_state_change(pdev->dev.parent, PWMSS_EQEPCLK_EN);

// If we failed to enable the clocks, fail out
if (!(status & PWMSS_EQEPCLK_EN_ACK))
{
   dev_err(>dev, "PWMSS config space clock enable failed\n");
   ret = -EINVAL;
   goto pwmss_clk_failure;
}

The function pwmss_submodule_state_change() appears to have been
removed by this commit:

commit cc37655e6bbf83ded1e4d1d7ffd977786a845a67
Author: Cooper Jr., Franklin 
Date:   Mon Mar 7 13:33:56 2016 -0600

pwm: pwm-ti*: Remove support for local clock gating

The PWMSS local clock gating registers have no real purpose on OMAP ARM
devices. These registers were left over registers from DSP IP where the
PRCM doesn't exist. There is a silicon bug where gating and ungating clocks
don't function properly. TRMs will be update to indicate that these
registers shouldn't be touched.

Therefore, all code that accesses the PWMSS_CLKCONFIG or PWMSS_CLKSTATUS
will be removed by this patch with zero loss of functionality by the ECAP
and EPWM drivers.


-Drew

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAPgEAj4EVcmo8coL7aMfxvX_E4p%2BVwgcNhYAvWque9m%2BgajRmg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.