Re: [beagleboard] OT: low cost development hardware and software

[Harvey White]

On Sun, 7 Aug 2016 23:51:55 -0700, you wrote:

>By the way, "bare metal ARM" means exactly nothing. The AM335x on the
>beaglebone black is not exactly something you'd want to write bare metal
>code for / on. Yes, it can be done ,but that is not a reason to do so. The
>AM335x
>is an applications processor which means it was designed to run an OS.

OK, I was rather thinking tools first, operating system secondly.

>
>Anyway, your post is rather vague, and long winded that tells us nothing.
>Seriously. "Display driver" - What does that mean ? a 128x8 display ? Or
>are you talking about 1080p or something crazy on a bare metal board ?

Oh, well, I was thinking the Epson S1D13781 chip driven in a parallel
interface mode, 16 bit, using the external memory interface to memory
map it.  I already wrote the code using an SPI interface, so only the
communications needs to be changed.  

If I said "I want to use a free compiler to generate C and C++ code
for the Nucleo boards" and that's all I asked, someone would ask me
what I wanted to do it for, and why I didn't use the BBB, and why I
didn't use some other board... etc.

I was not asking for help in *doing* any of this, I was looking for
tool suggestions.  

Thanks for the help

Harvey

>

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

Re: [beagleboard] OT: low cost development hardware and software

[Harvey White]

On Mon, 8 Aug 2016 07:53:37 -0400, you wrote:



>Hi Harvey,
>I routinely use low cost development boards for 
>specific application and attach them to either a 
>PC or one of low cost Linux board such as 
>Beagleboard or Raspberry. I also find they work 
>nicely in low cost test fixtures.
>
>You haven't mentioned you development environment, 
>but for Windows you are probably already familiar 
>with the tools players and associated cost. I 
>settled on the Nucleo boards using OpenSTM32 
>running Linux since I am not a big Windows fan, 
>however they do offer a Windows version. 

Thank you, I shall look into that.  

>The Linux 
>was a bit painful getting running, but it might be 
>a little easier on Windows. For some crazy reason 
>you have to register before you can even get to 
>the documentation which to me is the most 
>important part when researching development tools. 
>ST's CubeMx really helps in getting the low level 
>hardware code running without having to do a bunch 
>of custom work.

That also is a factor.

>
>Also you might want to take a look at  Mbed as 
>most if not all of the ST Nucleo board support it. 
>There is quite a bit of community code available 
>and it does not tie you to a single vendor. At one 
>time they only offered  on-line development tools, 
>but may now have alternatives.

Apparently, they do not yet offer anything much other than online.  I
somewhat prefer an IDE if I can get it.

>
>http://www.openstm32.org/HomePage
>https://www.mbed.com/en/
>
>Google has a wealth of information.

I've been searching, however, I thought I might try here to see if
anyone did anything similar.

Things should get interesting now.

Thanks for the help.

Harvey

>
>Good luck,
>Mark

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

Re: [beagleboard] OT: low cost development hardware and software

[Harvey White]

On Sun, 7 Aug 2016 17:11:57 -0700, you wrote:

>whats this got to do with a beaglebone ?

Not a thing, of course, except that they are both ARM processors.

Hence the OT.
Hence the hope that someone here might be doing similar ARM
development, and also the thought that what works well for the BBB
might cross over into another hardware platform.

Harvey

>
>On 8/7/2016 3:44 PM, Harvey White wrote:
>> I'm considering moving from an Atmel XMEGA environment to and ARM
>> environment.  (various reasons, one being the purchase of Atmel by
>> Microchip and some corresponding price increases...)
>>
>> I'm looking at the following scenario:
>>
>> 1) buying an explorer/development board: Nucleo 64 bit with a F446RET6
>> processor from STM.  Seems to have the highest performance for
>> processor intensive solutions and would support daughterboards with
>> memory access (good for things like displays and extra memory).
>>
>> 2) I will probably (for these designs) go bare metal.  The reasoning
>> is that I do not want Linux at the moment, and these are embedded
>> building blocks of larger systems.  I already have an operating system
>> that needs to be rewritten (low level drivers only) for the ARM.  It
>> already exists for the Xmega no, it's not FreeRtos. (there are
>> reasons).
>>
>> 2A) kinds of designs are display drivers mostly, which is where I need
>> the most processing power.  May end up keeping the Xmega stuff for
>> smaller functions, that's not all that bad depending on what Microchip
>> does with the prices (already up some)
>>
>> 3) Assuming that a 13 dollar development board will do well enough
>> (it's cheaper than I can make a board and populate it), and that there
>> are enough processor pins to run the daughter boards (which I don't
>> mind designing)...
>>
>> 4) What development tools are there that would work reasonably well?
>> I'd be using the (purchased with board) ST_link protocol.  
>>
>> 5) cost IS an object, so I'd be looking for a free version that is NOT
>> code size limited.  I've had Xmega projects at about 100K bytes of
>> code, which knocks out the "go see what it's like then pay us money"
>> approach of the major compiler vendors.
>>
>> 6) I'm hoping that people here with experience in ARM development have
>> some preferences and could help.  The BBB is not a hardware candidate
>> for several reasons, one being cost (I tend to do distributed systems,
>> which means lots of processors), another of which is simply
>> complexity.  A processor with add-ons (Arduino approach) seems to be a
>> minimalist hardware approach, which for now, is worth investigating.
>>
>> Currently I am using the AVR studio IDE, and developing in either C or
>> C++, PC projects tend to be Lazarus Pascal for historical reasons and
>> the fact that Microsoft's .net framework drives me up a wall.
>>
>> Comments welcome, and if this is sufficiently off topic for the group,
>> please reply directly.  Also would like to hear about inexpensive
>> hardware development boards that might work.  Considered the PSOC 5LP
>> boards, but they're such a loss leader that I wonder if they're going
>> to be permanent... Then again, everything changes.
>>
>> Thanks
>>
>> Harvey
>>

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

[beagleboard] OT: low cost development hardware and software

[Harvey White]

I'm considering moving from an Atmel XMEGA environment to and ARM
environment.  (various reasons, one being the purchase of Atmel by
Microchip and some corresponding price increases...)

I'm looking at the following scenario:

1) buying an explorer/development board: Nucleo 64 bit with a F446RET6
processor from STM.  Seems to have the highest performance for
processor intensive solutions and would support daughterboards with
memory access (good for things like displays and extra memory).

2) I will probably (for these designs) go bare metal.  The reasoning
is that I do not want Linux at the moment, and these are embedded
building blocks of larger systems.  I already have an operating system
that needs to be rewritten (low level drivers only) for the ARM.  It
already exists for the Xmega no, it's not FreeRtos. (there are
reasons).

2A) kinds of designs are display drivers mostly, which is where I need
the most processing power.  May end up keeping the Xmega stuff for
smaller functions, that's not all that bad depending on what Microchip
does with the prices (already up some)

3) Assuming that a 13 dollar development board will do well enough
(it's cheaper than I can make a board and populate it), and that there
are enough processor pins to run the daughter boards (which I don't
mind designing)...

4) What development tools are there that would work reasonably well?
I'd be using the (purchased with board) ST_link protocol.  

5) cost IS an object, so I'd be looking for a free version that is NOT
code size limited.  I've had Xmega projects at about 100K bytes of
code, which knocks out the "go see what it's like then pay us money"
approach of the major compiler vendors.

6) I'm hoping that people here with experience in ARM development have
some preferences and could help.  The BBB is not a hardware candidate
for several reasons, one being cost (I tend to do distributed systems,
which means lots of processors), another of which is simply
complexity.  A processor with add-ons (Arduino approach) seems to be a
minimalist hardware approach, which for now, is worth investigating.

Currently I am using the AVR studio IDE, and developing in either C or
C++, PC projects tend to be Lazarus Pascal for historical reasons and
the fact that Microsoft's .net framework drives me up a wall.

Comments welcome, and if this is sufficiently off topic for the group,
please reply directly.  Also would like to hear about inexpensive
hardware development boards that might work.  Considered the PSOC 5LP
boards, but they're such a loss leader that I wonder if they're going
to be permanent... Then again, everything changes.

Thanks

Harvey

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

Re: [beagleboard] Can't get SPI0 MOSI to idle low - Debian Jessie?

[Harvey White]

On Mon, 1 Aug 2016 22:50:12 -0700 (PDT), you wrote:

>Not sure what I'm doing wrong here, the MOSI pin stays high after the 
>BB-SPIDEV0-00A0.dtbo is loaded.
>
>Have it working fine on Wheezy, but want to move to Jessie.
>The .dtbo from Wheezy (BB-SPI0-01-00A0.dbto) won't load on Jessie so I'm 
>not able to verify that the dtbo is the issue.
>
>Does anyone know what is going on here?
>I need the MOSI pin to idle low.

You may have the wrong default mode on the SPI.

Harvey

>
>-Rudy.

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

Re: [beagleboard] BBB startup current

[Harvey White]

On Tue, 5 Jul 2016 16:00:05 -0400, you wrote:

>On Mon, Jul 4, 2016 at 9:14 PM, 'Morgaine' via BeagleBoard
> wrote:
>> John Syne writes:
>>>
>>> > a power supply that is spec’d at 4A should not shutdown when it sees a
>>> > 4A load, but rather, it should current limit at 4A. If the power supply is
>>> > spec’d at 4A, then 4A should not be treated as a short circuit.
>>
>>
>> That's impossible.  You can't recommend that fundamental electrical laws be
>> overridden. :P
>>
>> If a PSU current limits at 4A, it can do so only by reducing its output
>> voltage.  This may then drop below specification for its load and this can
>> have very bad consequences such as non-stop rebooting.  There is no way for
>> the voltage to be maintained above its minimum spec while still providing a
>> current limit.
>
>Yes, but remember that the problem here is a startup inrush current,
>which would be handled properly by current limiting. After all, that's
>what the 2A current supply is doing: essentially, it soft-starts,
>providing limited current charging the input caps, while ramping up
>the voltage. Once the caps are charged and the supply voltage
>stabilizes at the nominal value, the system progresses to boot.

Your discussion makes the assumption that the power supply provided or
specified is current limited at the maximum output current.  I
(without looking at PS specs) have no such assurance.  

*with* such limiting, behavior is one way.  Without that limiting,
behavior is quite something else.

I don't remember (particularly...) that the power supply specification
mentioned current limiting.  I thought that I had read only a voltage
tolerance.  People on this forum have mentioned using a particular
supply (not model number, simply rating).  The normal problem I have
seen was the current supply rating, so that the BBB could boot as well
as have sufficient power to drive such things as hard drives.

It seems to me that this does not address the *maximum* current of the
supply, nor does it specify what kind of supply is expected to supply
that maximum.

If this current capacity (as in surge current or current limiting) is
a difficulty, then perhaps it needs to be addressed.  I have not seen
(nor particularly searched for) such limitations.  

*if* they are important, then they need to be mentioned.  If they are
not, then perhaps that needs to be mentioned as well.

Harvey


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

Re: [beagleboard] BBB startup current

[Harvey White]

On Mon, 4 Jul 2016 20:27:22 -0700, you wrote:

>Nonsense. This is how the vast majority of power supplies work. The voltage 
>ramps up while the current is maintained at it’s maximum current. When the 
>voltage reaches the regulation voltage, the current is reduced. What the OP 
>proposed is that 4A was regarded as a short circuit and hence the power supply 
>shutdown. This is not normal. 

Much of this depends on the type of supply.

A bulk supply provides unregulated current to the limit of its
capacity.  Voltage decreases as current is drawn.  There are no
voltage or current regulating elements.  Obviously not used for the
BBB.

A voltage regulated supply may or may not have a current limit
circuit.

If not, then the supply current is limited by the resistance of the
parts.  From zero, the supply will try to charge up whatever
capacitance is on the output.  Large startup currents can happen,
similar to a bulk supply.  The voltage regulator does keep the output
voltage from rising past a set point, however.

A voltage and current regulated supply may operate in two ways
depending on the current limiter design.

If the supply is only current limited, then the supply is a constant
current supply at startup, supplying the maximum current it can
(depending on load) until the nominal voltage is reached (assuming
we're charging capacitors).  Under normal operation, the supply is a
voltage regulated supply.  Should current demand exceed (or try to)
the current limit, the supply becomes a constant current supply.  The
voltage drops to the point where the rated maximum current flows.

For instance, 5 volts 4 amps.  Put a 2 ohm load on the supply and you
have 5 volts at 2.5 amps load.  Put a 1 ohm load on it, and you will
have a 4 volt supply at 4 amps.  

It is possible for a supply to have foldback current limiting.  In
that case, the maximum supply current changes on maximum draw.  In
this case, you may have a 200 ma current foldback limit.  Try to draw
4 amps and the supply changes its limit to 200 ma and adjusts the
output voltage to maintain that lower limit.  Depending on the design
of the foldback, the load may have to be reduced or disconnected to
restore the regulated voltage.

Constant voltage with constant current limiting is common on lab
supplies, higher quality wall-wart power supplies, and is not common
on straight battery supplies, or bulk supplies, and some older (and
cheaper) power adaptors.

Power limiting can be built in rather easily, though, if you have the
right parts.

Harvey


>
>Regards,
>John
>
>
>
>
>> On Jul 4, 2016, at 6:14 PM, 'Morgaine' via BeagleBoard 
>>  wrote:
>> 
>> John Syne writes:
>> > a power supply that is spec’d at 4A should not shutdown when it sees a 4A 
>> > load, but rather, it should current limit at 4A. If the power supply is 
>> > spec’d at 4A, then 4A should not be treated as a short circuit.
>> 
>> That's impossible.  You can't recommend that fundamental electrical laws be 
>> overridden. :P
>> 
>> If a PSU current limits at 4A, it can do so only by reducing its output 
>> voltage.  This may then drop below specification for its load and this can 
>> have very bad consequences such as non-stop rebooting.  There is no way for 
>> the voltage to be maintained above its minimum spec while still providing a 
>> current limit.
>> 
>> This is the reason why ensuring that startup inrush transients cause no harm 
>> must always be handled within the design of the load, ie. the BBB in this 
>> case.  The load is a black box as far as the external PSU is concerned, so 
>> the external PSU has no means to perform this protective function while 
>> still maintaining regulation.  (Blowing a fuse does not maintain regulation, 
>> but is sometimes the only practical alternative.)
>> 
>> In other words, a load can demand a minimum current capability under a rated 
>> voltage specification, but it cannot demand a maximum current capability 
>> unless it can cope with arbitrary drops in supply voltage.  Such voltage 
>> tolerance is generally not available in electronic circuitry today, 
>> certainly not in BBB.
>> 
>> 
>> 
>> -- 
>> 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/CAM0uzStPOH3i%2B0pH2O4Bz3E_kcggLrJu9yZSaOO4HzZ%2BkLQ3mg%40mail.gmail.com
>>  
>> .
>> For more options, visit https://groups.google.com/d/optout 
>> .

-- 
For more options, visit http://be

Re: [beagleboard] BBB startup current

[Harvey White]

On Mon, 4 Jul 2016 16:49:05 -0700, you wrote:

>You cannot get the board layout done with 2 layers and you would have all kind 
>of issues with power supply noise, ground bounce, etc. You have to start with 
>2 power planes and then you need at least 4 layers to get the signals out from 
>the processor. You will not be able to route the board on 2 layers. You need a 
>minimum of 4 routing layers and add 2 power planes and so you have a minimum 
>of 6 layers. 

I wasn't considering a modification of an ARM design, I was thinking
more of different processors.  My preference (and cost limitations) as
well as what I already have software for, point me to other
processors.  If I were to use ARM processors ( a possibility), I'd be
working with a pre-made board of some sort, due to manufacturing
difficulties.

Harvey


>
>Regards,
>John
>
>
>
>
>> On Jul 4, 2016, at 4:30 PM, Harvey White  wrote:
>> 
>> If I needed something with that capability, I'd probably buy it
>> because my cost preference on a PC board is 2 layers and not 4 or 6. I
>> don't have the money to develop a product at this level, nor do I have
>> the desire, nor perhaps the time or expertise.  

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

Re: [beagleboard] BBB startup current

[Harvey White]

On Mon, 4 Jul 2016 16:41:47 -0700, you wrote:

>HI Harvey,
>
>I'd personally disagree.  Hardware costs as much as you pay for, and
>does what you design it to do.  I, for one, am willing to pay more for
>more capability, within reason.  Not your typical consumer,
>though.
>
>Id disagree with you. Only because we can second guess each other until the
>end of time. But the point here that this was part of the reasoning for the
>design behind the BBB, and without it we would not be where we are.

It's not second guessing.  We're (to me) looking at different design
goals.  I'm willing to pay more to have a feature if I want it.  Price
point is simply that, 5 more dollars and who knows how many customers
you lose?

Because I design *my* stuff (to my own price points) it's a matter
of divergent design goals.  Not right or wrong, just different.


>
>I'm not even aware that your initial design was 89 dollars.  I might
>not have bought it for that, but that would have been my decision. "I"
>however, am not "they" but there are a lot more of "them" than
>there are of me
>
>
>The initial design discussed here is the BBW I believe. By the time my
>biddy and I priced the BBW actually, the cost was $99.

Ah, now that is a different product.  Different design goals.

>
>
>If I needed something with that capability, I'd probably buy it
>> because my cost preference on a PC board is 2 layers and not 4 or 6. I
>> don't have the money to develop a product at this level, nor do I have
>> the desire, nor perhaps the time or expertise.
>>
>> The cost would, of course, determine how many I'd use, and for what,
>> but that's a simple economic decision.  Then there's the engineering
>> decision.
>>
>
>Problem is, if this design was only a 2 layer design. the actual board
>dimensions probably would have increased 5x or more.

>From my experience, perhaps a factor of 2 IF the board could be routed
properly.  With added layers, there's a factor that makes the board
more stable, gives better performance (due to transmission line
effects and signal isolation), and is often easier to route in a
particular size.  The physical cost is that the board can cost twice
as much (at least).

>
>>But, I suspect the majority will complain that it is too expensive and will
>>stay with the BBB and instead ask how to flash the latest image in the BBB
>>and why does my my GPIO does not work..
>
>Can't help you with that...
>
>
>If you want my take on this situation . . . it's because the I.Q. of the
>average person posting on theses forums seems to have diminished in the
>last couple of years. These people can not understand that the software
>people on this project are not paid and offer their service for free to the
>community. As well as software upgrades are not the responsibility of the
>community, nor are these upgrade required for the software that third
>parties have written to work properly. Nor, do these third parties take
>responsibility for doing so . . . I could go on all day . . .

I think that the BBB has transitioned from a somewhat specialized
product supported by hobbyists to a commodity.  Commodities are bought
by appliance users (a term borrowed from the amateur radio community).
The mindset is quite different.  The expectations of the consumer are
also quite different.

If you think the BBB is bad, I think we should both consider the
Arduino world

Harvey



>
>
>On Mon, Jul 4, 2016 at 4:30 PM, Harvey White  wrote:
>
>> On Mon, 4 Jul 2016 18:02:13 -0500, you wrote:
>>
>> >When you design low cost hardware, you have to make certain decisions to
>> >get the cost down.
>> >
>> >1) As few components as possible.
>>   granted, no problem with that.
>>
>> >2) Limit the application. Only one application,
>>   do we know what the application is?  Apparently people tend to think
>> that this can do anything.
>> >3) Push as much cost outside, for example the power supply.
>>   hmmm, then that says you have not as much control over the power
>> supply as you might want.  Certainly not as much as you may like.
>>
>> >4) Lowest cost components.
>>   no problem.
>> >5) Limit the features.
>>   no problem.  It does what it does.
>>
>> >6) Cut the profit.
>>   diminishing returns.
>> >
>> >Yes, there are several things I could have done different. Many of these
>> no
>> >one has even identified.
>> Perhaps it might be interesting to know what they were... Not
>> criticizing, but to know design alternatives might be nice.
>>
&

Re: [beagleboard] BBB startup current

[Harvey White]

On Mon, 4 Jul 2016 18:02:13 -0500, you wrote:

>When you design low cost hardware, you have to make certain decisions to
>get the cost down.
>
>1) As few components as possible.
  granted, no problem with that.

>2) Limit the application. Only one application,
  do we know what the application is?  Apparently people tend to think
that this can do anything.
>3) Push as much cost outside, for example the power supply.
  hmmm, then that says you have not as much control over the power
supply as you might want.  Certainly not as much as you may like.

>4) Lowest cost components.
  no problem.
>5) Limit the features.
  no problem.  It does what it does.

>6) Cut the profit.
  diminishing returns.
>
>Yes, there are several things I could have done different. Many of these no
>one has even identified. 
Perhaps it might be interesting to know what they were... Not
criticizing, but to know design alternatives might be nice.

>But if I had, you would not have bought it because
>it cost too much. After all hardware is supposed to be cheap. 

I'd personally disagree.  Hardware costs as much as you pay for, and
does what you design it to do.  I, for one, am willing to pay more for
more capability, within reason.  Not your typical consumer,
though.


>That is where
>the value is, in the price. Not the value..

Then you're designing to a price point, and that's a different thing
entirely.

>
>Nobody asked how I took it from $89 to $49. They just bought them up and
>complained that it didn't do all the things they wanted it to do for $49.

I'm not even aware that your initial design was 89 dollars.  I might
not have bought it for that, but that would have been my decision. "I"
however, am not "they" but there are a lot more of "them" than
there are of me

Not practical for you to put too many blank pads on a board and expect
the user to solder parts in.  I do, because I can build the boards.
Your average hobby type... not likely I suspect.

>
>If anyone of you want to change the design, add more features, make it more
>robust, add more cost, increase the price, manufacture it and sell it, by
>all means, go ahead. I am sure there will b a few folks that value the
>hardware and recognize that value, and will pay for it.

If I needed something with that capability, I'd probably buy it
because my cost preference on a PC board is 2 layers and not 4 or 6. I
don't have the money to develop a product at this level, nor do I have
the desire, nor perhaps the time or expertise.  

The cost would, of course, determine how many I'd use, and for what,
but that's a simple economic decision.  Then there's the engineering
decision.



>
>But, I suspect the majority will complain that it is too expensive and will
>stay with the BBB and instead ask how to flash the latest image in the BBB
>and why does my my GPIO does not work..

Can't help you with that


Harvey

>
>
>On Mon, Jul 4, 2016 at 5:46 PM, John Syne  wrote:
>
>> Harvey, you raised several very good points. I cannot say I disagree with
>> anything you said.
>>
>> Regards,
>> John
>>
>>
>>
>>
>> > On Jul 4, 2016, at 3:36 PM, Harvey White  wrote:
>> >
>> > On Mon, 4 Jul 2016 15:13:00 -0700, you wrote:
>> >
>> >> Pay no attention to William. You comments are welcome and Gerald has
>> accepted your comments as valuable input by thanking your for your
>> feedback. Now, let me address your concerns:
>> >
>> > From my own engineering standpoint (and opinions will, of course,
>> > vary):
>> >>
>> >> 1) The power supply used to power the BBB should be selected so that it
>> does not damage the BBB, so a 2A power supply was specified. If you wish to
>> change that specification, then the onus is on you to verify that a 4A
>> power supply will not damage the BBB. Your conclusion that is may damage
>> the BBB means that you should not use a 4A power supply. In addition, a
>> power supply that is spec’d at 4A should not shutdown when it sees a 4A
>> load, but rather, it should current limit at 4A. If the power supply is
>> spec’d at 4A, then 4A should not be treated as a short circuit.
>> >
>> > I would have designed the power supply circuitry so that with a power
>> > supply of appropriate minimum rating, the maximum rating would not
>> > have mattered.  Using a power supply with a maximum current rating to
>> > avoid damaging circuitry is not (again, IMHO) the best solution.  If,
>> > because of economic considerations, that decision is made, then it is
>> > imperative of the designer to put this information specifically in the
>

Re: [beagleboard] BBB startup current

[Harvey White]

On Mon, 4 Jul 2016 15:46:43 -0700, you wrote:

>Harvey, you raised several very good points. I cannot say I disagree with 
>anything you said.

Thank you.  I prefer paranoid designs myself.  However, I don't design
commercial products, I design stuff for myself.  It does make a
difference.  If I get it wrong, I have to fix it...  and I have LOTS
of stuff to fix myself.

I also don't have to design to a price point, at least, not as much as
for a commercial product.

Harvey


>
>Regards,
>John
>
>
>
>
>> On Jul 4, 2016, at 3:36 PM, Harvey White  wrote:
>> 
>> On Mon, 4 Jul 2016 15:13:00 -0700, you wrote:
>> 
>>> Pay no attention to William. You comments are welcome and Gerald has 
>>> accepted your comments as valuable input by thanking your for your 
>>> feedback. Now, let me address your concerns:
>> 
>> From my own engineering standpoint (and opinions will, of course,
>> vary):
>>> 
>>> 1) The power supply used to power the BBB should be selected so that it 
>>> does not damage the BBB, so a 2A power supply was specified. If you wish to 
>>> change that specification, then the onus is on you to verify that a 4A 
>>> power supply will not damage the BBB. Your conclusion that is may damage 
>>> the BBB means that you should not use a 4A power supply. In addition, a 
>>> power supply that is spec’d at 4A should not shutdown when it sees a 4A 
>>> load, but rather, it should current limit at 4A. If the power supply is 
>>> spec’d at 4A, then 4A should not be treated as a short circuit. 
>> 
>> I would have designed the power supply circuitry so that with a power
>> supply of appropriate minimum rating, the maximum rating would not
>> have mattered.  Using a power supply with a maximum current rating to
>> avoid damaging circuitry is not (again, IMHO) the best solution.  If,
>> because of economic considerations, that decision is made, then it is
>> imperative of the designer to put this information specifically in the
>> power supply recommendations.  Not doing this leads to damage, doing
>> this puts the responsibility on the user.  Is this a "before the
>> design/after the design"?  I don't know, and I don't remember (either
>> way) if this warning was ever in the power supply requirements.
>> Hindsight is 20/20, of course.  If it's that important, then perhaps
>> the documentation needs to be changed.  Decision not up to me.
>> 
>> 
>>> 2) The TI spec for the TPS65217C is a general recommendation as they are 
>>> unaware of how you are going to use the part. The BBB SYS_5V powers several 
>>> subsystems, including HDMI, I/O (VDD_3V3B) and USB. Clearly you could move 
>>> the 100uF to the other side of the TPS2051, but then you need an additional 
>>> capacitor on the SYS_5V which increases the cost and doesn’t provide any 
>>> clear benefit, if you choose the correct power supply.
>> 
>> "correct power supply" bothers me.  I'm familiar with minimum current
>> capacity, voltage limits, short circuit current limits (infrequently
>> applied).  Again, "a 4 amp power supply will allow the board to damage
>> itself, so we depend on a 2 amp maximum supply to avoid damage."  This
>> could be discussed a bit
>> 
>> 
>>> 3) As Gerald has pointed out, the BBB is just a reference design. It was 
>>> designed as a low cost solution which meant that tradeoffs were required to 
>>> keep the price low. Clearly things could have been done differently, but 
>>> then the BBB price would have been much higher and the board larger. Given 
>>> that most users would probably not need these extra features, they were not 
>>> incorporated into the current design. There are several spinoffs of the 
>>> BBB, some with wifi, some with more RAM, etc, but none have been as 
>>> successful as the BBB. 
>> 
>> Hmmm, well, perhaps (although not required) it might be nice to know
>> what the engineering limitations are of the design.
>> 
>> I've seen 1) the ones I know about, and 2) the ones I haven't found
>> out yet... and 3) the ones people are going to have to tell me
>> about...
>> 
>> and I do like paranoid designs.
>> 
>> Harvey
>> 
>> 
>>> 4) While I have provided Gerald input into both the BBB and BeagleBoard-x15 
>>> designs, I ultimately defer to his judgement because he has the track 
>>> record or having designed several products that are very successful. 
>>> 
>>> From my prospective, the BBB d

Re: [beagleboard] BBB startup current

[Harvey White]

On Mon, 4 Jul 2016 15:13:00 -0700, you wrote:

>Pay no attention to William. You comments are welcome and Gerald has accepted 
>your comments as valuable input by thanking your for your feedback. Now, let 
>me address your concerns:

>From my own engineering standpoint (and opinions will, of course,
vary):
>
>1) The power supply used to power the BBB should be selected so that it does 
>not damage the BBB, so a 2A power supply was specified. If you wish to change 
>that specification, then the onus is on you to verify that a 4A power supply 
>will not damage the BBB. Your conclusion that is may damage the BBB means that 
>you should not use a 4A power supply. In addition, a power supply that is 
>spec’d at 4A should not shutdown when it sees a 4A load, but rather, it should 
>current limit at 4A. If the power supply is spec’d at 4A, then 4A should not 
>be treated as a short circuit. 

I would have designed the power supply circuitry so that with a power
supply of appropriate minimum rating, the maximum rating would not
have mattered.  Using a power supply with a maximum current rating to
avoid damaging circuitry is not (again, IMHO) the best solution.  If,
because of economic considerations, that decision is made, then it is
imperative of the designer to put this information specifically in the
power supply recommendations.  Not doing this leads to damage, doing
this puts the responsibility on the user.  Is this a "before the
design/after the design"?  I don't know, and I don't remember (either
way) if this warning was ever in the power supply requirements.
Hindsight is 20/20, of course.  If it's that important, then perhaps
the documentation needs to be changed.  Decision not up to me.


>2) The TI spec for the TPS65217C is a general recommendation as they are 
>unaware of how you are going to use the part. The BBB SYS_5V powers several 
>subsystems, including HDMI, I/O (VDD_3V3B) and USB. Clearly you could move the 
>100uF to the other side of the TPS2051, but then you need an additional 
>capacitor on the SYS_5V which increases the cost and doesn’t provide any clear 
>benefit, if you choose the correct power supply.

"correct power supply" bothers me.  I'm familiar with minimum current
capacity, voltage limits, short circuit current limits (infrequently
applied).  Again, "a 4 amp power supply will allow the board to damage
itself, so we depend on a 2 amp maximum supply to avoid damage."  This
could be discussed a bit


>3) As Gerald has pointed out, the BBB is just a reference design. It was 
>designed as a low cost solution which meant that tradeoffs were required to 
>keep the price low. Clearly things could have been done differently, but then 
>the BBB price would have been much higher and the board larger. Given that 
>most users would probably not need these extra features, they were not 
>incorporated into the current design. There are several spinoffs of the BBB, 
>some with wifi, some with more RAM, etc, but none have been as successful as 
>the BBB. 

Hmmm, well, perhaps (although not required) it might be nice to know
what the engineering limitations are of the design.

I've seen 1) the ones I know about, and 2) the ones I haven't found
out yet... and 3) the ones people are going to have to tell me
about...

and I do like paranoid designs.

Harvey


>4) While I have provided Gerald input into both the BBB and BeagleBoard-x15 
>designs, I ultimately defer to his judgement because he has the track record 
>or having designed several products that are very successful. 
>
>From my prospective, the BBB design is good, but your input was none the less 
>valuable. 
>
>Regards,
>John
>
>
>
>
>> On Jul 4, 2016, at 2:11 PM, William Hermans  wrote:
>> 
>> kzsoltkzsolt,
>> 
>> I would like to point out to you that you're talking to *the* person who 
>> designed the beaglebones, who also used to work for Texas Instruments at 
>> some point in his career. Someone who has made his designs free of charge to 
>> the public, which he has made perfectly clear to you in these post that 
>> you're free to change and use for your own personal use.
>> 
>> So, telling him things, he probably already knows, in hopes of making 
>> yourself looks good. Actually make you look like a "know it all". e.g. it 
>> doesn't make you look good.
>> 
>> SO perhaps you should realize that Gerald is probably well aware of what 
>> you're trying to discuss here, but is unwilling to change for various 
>> reasons. Reason, that you, I, or the next person do not need to understand. 
>> Because we can change to designs to our own liking if we so wish.
>> 
>> On Mon, Jul 4, 2016 at 1:55 PM, Gerald Coley > > wrote:
>> Thank you for your feedback. 
>> 
>> Gerald
>> 
>> On Mon, Jul 4, 2016 at 3:18 PM, > > wrote:
>> First of all making changes on design "tomorrow" is irresponsible, so I 
>> never request it. But good to know where is some "leak" in design. For 
>> example

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

[Harvey White]

On Sat, 25 Jun 2016 18:32:51 -0700, you wrote:

>Think about what you are proposing. When the kernel loads, it discovers 
>devices and then loads the appropriate drivers. Now what happens when it 
>discovers the PRU, which driver does it load, PRUSS_UIO or RemoteProc?

Why not give it a configuration choice?  Both modules can be optional,
load or not load only one.  Develop your application to match.

You already do this with the pin overlays/pin mux.   

Can you decouple it from the main program/OS and then have resources
that you need?

Harvey


>
>Regards,
>John
>
>
>
>
>> On Jun 25, 2016, at 6:11 PM, Rick Mann  wrote:
>> 
>>> 
>>> On Jun 25, 2016, at 14:44 , John Syne  wrote:
>>> 
 On Jun 25, 2016, at 2:20 PM, Rick Mann  wrote:
 
 
> On Jun 25, 2016, at 12:56 , John Syne  wrote:
 
>> On Jun 25, 2016, at 11:56 AM, Jason Kridner  
>> wrote:
>> 
>> I will work to enable uio_pruss functionality, and I think that is what 
>> you want, not just getting remoteproc out. 
> 
> Please don’t do that. Robert Nelson has the “bone” kernel for this 
> purpose which supports pruss_uio by default and does not have 
> RemoteProc/RPMSG installed. The “ti” kernel however does the reverse, 
> with the RemoteProc/RPMSG installed by default and pruss_uio no 
> installed. I believe the two frameworks conflict so it is not possible to 
> have both installed. 
 
 It sure seems to me that if both can exist in the source tree and be 
 selected at runtime with configuration (ideally via device tree, 
 switchable later by loading and unloading modules), that would be the 
 ideal solution. It sounds like John is saying this is technically not 
 possible, but I feel like it should be (it is just code, after all).
>>> If you read the discussion, TJF and William don’t want to build a custom 
>>> kernel. So since you cannot have pruss_uio and RemoteProc/RPMSG, configured 
>>> simultaneously, this is the dilemma we are facing. Currently Robert Nelson 
>>> has configured the “bone” kernel to have pruss_uio dn the “ti” kernel to 
>>> have RemoteProc/RPMSG. William is concerned that the “ti” kernel has more 
>>> features than the “bone” kernel. Solution is to ask Robert Nelson to add 
>>> the missing features to the “bone” kernel. 
>> 
>> I'm not sure specifically what's preventing the two from being configured 
>> simultaneously, so long as both their code doesn't execute simultaneously. 
>> It seems one or the other or both can be modified to coexist in the 
>> configuration, and that may be the best way to ensure the kernel supports 
>> all users.
>> 
>> We have the source, it should be possible. The kernel can support multiple 
>> ethernet drivers configured simultaneously, why not multiple PRU drivers?
>> 
>> -- 
>> 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/19C6420A-AF09-4542-B907-AD54429E56B4%40latencyzero.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/r2eumbpmal4tma0q3or5rp3q82dkg9d801%404ax.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Burned out BBB with AIN0 > 1.8V

[Harvey White]

On Tue, 7 Jun 2016 15:20:30 -0700, you wrote:

>Good explanation. The other benefit from using an opamp is the low impedance 
>it provides to the ADC Sample&Hold circuit. As you know, when the circuit is 
>in sample mode, it is charging and internal capacitance which means the 
>current spikes for a short time and that will cause noise and measurement 
>inaccuracy if a simple resistor divider is used. The opamp on the other hand 
>is a low impedance source and can supply the current required by the ADC 
>Sample&Hold circuit. 

True, and if there's a buffer amplifier, this can possibly be set for
low or high impedance (can in the XMEGA... ARM? no idea).  Didn't
occur to me, and on second thought, if a beginner can understand that
one, perhaps they're not a beginner?

Nice comment, though.

Harvey

>
>Regards,
>John
>
>
>
>
>> On Jun 7, 2016, at 2:54 PM, Harvey White  wrote:
>> 
>> On Tue, 7 Jun 2016 13:03:29 -0700 (PDT), you wrote:
>> 
>>> Hi,
>>> 
>>> chiming in here because I'm about to build my first circuit that uses ADCs 
>>> on BBB...
>>> 
>>>>  My standard advice 
>>>>>> would be to run the analog voltage through a non-inverting op amp 
>>>>>> configured as a gain stage.  You run the op-amp (and have to pick one 
>>>>>> that does rail to rail and also runs from 1.8 volts) from the 1.8 volt 
>>>>>> supply.   
>>>>>> 
>>>>> Yes, that's what I do.  There are quite a few very low power op-amps 
>>>>> suitable for running from the 1.8 volt rail on the BBB.  If OP is 
>>>>> interested I can look up the device, it's from TI if I remember. 
>>>>> 
>>>> 
>>> In my somewhat amateurish approach to this I was planning to use a DC-DC 
>>> converter to provide 1.8 VCC for my sensors. I'm still learning about 
>>> op-amps and anything more advanced than a transistor, so I wonder whether 
>>> there are any advantages to using an op-amp compared to providing 1.8 V 
>>> from a switching DC-DC converter? 
>> 
>> Let's see.  Firstly, the goal is to make sure that the voltage to the
>> analog terminal does not go negative at all, and does not go more
>> positive than 1.8 volts, ever.
>> 
>> So firstly, let's feed all the sensors from 1.8 volts.  Now this
>> works, and can work well.  The question is how to get the 1.8 volts. A
>> switching converter, while efficient, generates noise, is relatively
>> complex, and is moderately large.  An easier way to get 1.8 volts is
>> to use a simple 3 terminal regulator.  There are some very small ones
>> available.  They generate little electrical noise.  A typical current
>> limit is about 100 ma, which should power a number of sensors.
>> 
>> Now, failing that we can (and often we cannot) power the sensors from
>> only 1.8 volts, we still need a method of reducing the input voltage.
>> 
>> Some will say to put a resistor in series, thinking that it's the
>> current you get with an overvoltage.  This is not necessarily true,
>> often it is simply the voltage itself, and the damage is done by the
>> way that the processor is constructed.
>> 
>> Others would say that the best way is to add two diodes (back biased)
>> to 1.8 volts and ground, and then add a protective resistor.  The
>> problem with this is that the diodes must conduct before they limit,
>> and that means that your voltage range is -.7 to 2.5 volts to the pin,
>> which violates the limits.  
>> 
>> Another approach would be a zener diode.  One problem is that the
>> zener needs roughly 0.001 amp to work, and that the sensor must supply
>> that voltage.  Another is that if you are trying to drop 12 volts down
>> to 1.8, you can, but by a fixed amount.  Go to 13 volts and you still
>> drop the 13 down to 2.8, and exceed the chip limits.  Zeners are
>> standard diodes in reverse, so you have no protection below -0.7 volts
>> at the input.
>> 
>> Yet another way would be to use a voltage divider.  This reduces the
>> input voltage by a fixed amount, and can be a decent solution IF and
>> ONLY IF the voltage does not go negative (and can NEVER go negative),
>> and the maximum voltage you can ever see is reduced down to 1.8
>> volts).  As a specific cure, it can work, but as a general cure, it
>> isn't recommended because you can still go over 1.8 volts and less
>> than 0.  For those who consider it important, the impedance of the
>> divider can also be an issue, too little and not

Re: [beagleboard] Re: Burned out BBB with AIN0 > 1.8V

[Harvey White]

On Tue, 7 Jun 2016 09:43:50 -0700 (PDT), you wrote:

>Any suggestions or part numbers are much appreciated!  Please, if it's not 
>to difficult, let me know which op-amps you've used.

MCP604SL, and there are 1 and 2 amp versions of that chip.  It's
currently protecting an XMEGA (3.3 volt VCC here and 3.3 volts max ADC
input, practical input level 2.5 volts due to reference).  Check the
specs, I think it's microchip and available from Mouser.

The 324 has a maximum output of about VCC - 1.25 volts, which is OK,
if you can live with that.  Supposedly you can go down to ground.

The 604 has a different voltage limit depending on the configuration,
so you need to be a bit careful with it.  It's inexpensive, though, so
it may work for your application.

It's in a +/- 20 volt 1.5 amp power supply board that allows current
measurement and setting output voltage from the XMEGA's onboard DACs.

(it's really intended for a transistor curve tracer, still in
development).

Harvey
>
>I've worked with the LM324 in the past for another project so I'm 
>relatively comfortable with this one.
>
>Thanks again all!
>
>On Tuesday, June 7, 2016 at 1:33:40 AM UTC-7, Chris Green wrote:
>>
>> Harvey White > wrote: 
>> > >3.  What is the "normal" way of using the BBB analog inputs with 5V 
>> levels? 
>> > > Is it possible - or is there where I would use a level-shifter or 
>> zener 
>> > >diode? 
>> > 
>> > Level shifters are generally digital, and zener diodes don't help all 
>> > that much (and are not really a good idea here).  My standard advice 
>> > would be to run the analog voltage through a non-inverting op amp 
>> > configured as a gain stage.  You run the op-amp (and have to pick one 
>> > that does rail to rail and also runs from 1.8 volts) from the 1.8 volt 
>> > supply.   
>> > 
>> Yes, that's what I do.  There are quite a few very low power op-amps 
>> suitable for running from the 1.8 volt rail on the BBB.  If OP is 
>> interested I can look up the device, it's from TI if I remember. 
>>
>> -- 
>> Chris Green 
>> · 
>>
>>

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

Re: [beagleboard] Re: Burned out BBB with AIN0 > 1.8V

[Harvey White]

On Tue, 7 Jun 2016 13:03:29 -0700 (PDT), you wrote:

>Hi,
>
>chiming in here because I'm about to build my first circuit that uses ADCs 
>on BBB...
>
>>   My standard advice 
>>> > would be to run the analog voltage through a non-inverting op amp 
>>> > configured as a gain stage.  You run the op-amp (and have to pick one 
>>> > that does rail to rail and also runs from 1.8 volts) from the 1.8 volt 
>>> > supply.   
>>> > 
>>> Yes, that's what I do.  There are quite a few very low power op-amps 
>>> suitable for running from the 1.8 volt rail on the BBB.  If OP is 
>>> interested I can look up the device, it's from TI if I remember. 
>>>
>>
>In my somewhat amateurish approach to this I was planning to use a DC-DC 
>converter to provide 1.8 VCC for my sensors. I'm still learning about 
>op-amps and anything more advanced than a transistor, so I wonder whether 
>there are any advantages to using an op-amp compared to providing 1.8 V 
>from a switching DC-DC converter? 

Let's see.  Firstly, the goal is to make sure that the voltage to the
analog terminal does not go negative at all, and does not go more
positive than 1.8 volts, ever.

So firstly, let's feed all the sensors from 1.8 volts.  Now this
works, and can work well.  The question is how to get the 1.8 volts. A
switching converter, while efficient, generates noise, is relatively
complex, and is moderately large.  An easier way to get 1.8 volts is
to use a simple 3 terminal regulator.  There are some very small ones
available.  They generate little electrical noise.  A typical current
limit is about 100 ma, which should power a number of sensors.

Now, failing that we can (and often we cannot) power the sensors from
only 1.8 volts, we still need a method of reducing the input voltage.

Some will say to put a resistor in series, thinking that it's the
current you get with an overvoltage.  This is not necessarily true,
often it is simply the voltage itself, and the damage is done by the
way that the processor is constructed.

Others would say that the best way is to add two diodes (back biased)
to 1.8 volts and ground, and then add a protective resistor.  The
problem with this is that the diodes must conduct before they limit,
and that means that your voltage range is -.7 to 2.5 volts to the pin,
which violates the limits.  

Another approach would be a zener diode.  One problem is that the
zener needs roughly 0.001 amp to work, and that the sensor must supply
that voltage.  Another is that if you are trying to drop 12 volts down
to 1.8, you can, but by a fixed amount.  Go to 13 volts and you still
drop the 13 down to 2.8, and exceed the chip limits.  Zeners are
standard diodes in reverse, so you have no protection below -0.7 volts
at the input.

Yet another way would be to use a voltage divider.  This reduces the
input voltage by a fixed amount, and can be a decent solution IF and
ONLY IF the voltage does not go negative (and can NEVER go negative),
and the maximum voltage you can ever see is reduced down to 1.8
volts).  As a specific cure, it can work, but as a general cure, it
isn't recommended because you can still go over 1.8 volts and less
than 0.  For those who consider it important, the impedance of the
divider can also be an issue, too little and nothing drives it, too
high and the chip characteristics override the divider resistors.

Putting an op amp in allows several possibilities.  Op amps can be
inverting or non-inverting.  By running the op-amp from 1.8 volts and
ground, the maximum output voltage that the op-amp can put out is
limited to these values.  You will need a chip that outputs rail to
rail (ground to positive power supply voltage).

Inverting: the voltage has to be offset to keep the opamp from going
negative (and it will try, even when powered from 1.8 volts and
ground).  This also inverts the voltage so that as the voltage at the
input increases, the output decreases.

Non-inverting:  the voltage increases and the output increases.  Non
inverting unity gain (buffer) may have output voltage limits, so that
must be checked.  It will have an extremely high impedance, though. If
gain is needed, then the non-inverting configuration with gain can be
used.

I'd personally recommend the op-amp for the most general solution, and
the resistive divider ONLY if the application can be guaranteed to
never exceed the voltage limits of the chip under any reasonable
conditions.

Level converters are digital devices, and not suitable for use on
analog circuits.

Good design is frequently paranoid design.

Harvey



>
>I would be very grateful if one of the electronically literate participants 
>to this discussion would share their insight with a newbie :)

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

Re: [beagleboard] Burned out BBB with AIN0 > 1.8V

[Harvey White]

On Mon, 6 Jun 2016 10:12:43 -0700 (PDT), you wrote:

>Hi,
>
>Yesterday I was trying to use some of the analog inputs on the BBB to read 
>my photodiode, and instead, I think I blew up the power supply on my board.
>With power applied, I get no PWR led, so I'm pretty certain it's dead.
>Short of replacing the power management chip, is there anything I can 
>do/replace to get the board working again?
>
>
>Brief Background
>
>I hooked up the photodiode to an Arduino and was able to read 0 - 5V 
>easily, so I wanted to do the same on the BBB.
>I read some of the materials re: AIN on the BBB, but apparently I missed 
>all the references to the max voltage of 1.8V!
>I started by enabling the analog inputs on the BBB, and started with AIN0.
>
>With nothing attached, I was reading about 0 - so far, so good.
>Then I figured I'd try to see what a full 5.0V read out, so I plugged in 
>the VDD 5V to AIN0, and all the LEDs went out instantly.
>Now all LEDs stay off, even the PWR LED, when power is applied.
>
>No doubt, it was stupid, but I have a few additional takeaways - 
>1. Very minor references in most BBB documentation/webpages discussing 
>Analog Inputs and max voltages. 
>Coming from working with Pi's and Arduino's, it was common to have analog 
>inputs range from 0 to 5V, so the 1.8V was unexpected.

Actually, it's 0 to VCC on the MEGA and XMEGA chips.  The Mega chips
can run at 3.3 volts, and the XMEGA chips *must* run at no more than
3.3 volts.

>
>2.  Isn't there any protection at all from this kind of damage?  Or was the 
>main problem that I used the VDD 5V and fed it into the AIN0 port?

These are generally direct chip inputs, and there's generally no
buffering.

>Would I have killed it if I used the VDD ADC instead of the VDD 5v or would 
>using the VCC ADC possibly have protected it?

1.8 volts maximum.

>
>3.  What is the "normal" way of using the BBB analog inputs with 5V levels? 
> Is it possible - or is there where I would use a level-shifter or zener 
>diode?

Level shifters are generally digital, and zener diodes don't help all
that much (and are not really a good idea here).  My standard advice
would be to run the analog voltage through a non-inverting op amp
configured as a gain stage.  You run the op-amp (and have to pick one
that does rail to rail and also runs from 1.8 volts) from the 1.8 volt
supply.  

Harvey

>
>Thanks for the any comments or additional info provided!


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

Re: [beagleboard] Re: Serial Communication on Beaglebone Black

[Harvey White]

On Sun, 22 May 2016 21:50:53 -0600, you wrote:

>@Harvey
>
>He is using a mini cape which does the proper voltage level shifting. Link
>in previous message in this thread.

Thanks, then it seems to be all software from this point on.  Glad
that this hardware setup will not damage the BBB.

Harvey

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

Re: [beagleboard] Re: Serial Communication on Beaglebone Black

[Harvey White]

On Sun, 22 May 2016 21:02:15 -0400, you wrote:

>It is confusing indeed.
>
>I have a HAAS CNC machine. The documentation specifically states that
>interaction can occur only through an RS232 port.
>Moving on, I connected the female DB 25 at the HAAS CNC using a null modem
>25 to 9 and an RS232 to USB(initially). This connection worked perfectly
>when i connected it to my PC(USB at the PC). What the CNC does is: I send a
>command from my PC and the CNC spits back corresponding data.
>Now all of it works perfectly fine.
>
>But now I want to replicate the entire thing on a BBB. So that instead of
>my PC there is BBB.
>
>I know the exact null modem + RS 232 works fine with my PC. But is not
>working at all with the BBB.
>No handshake protocols are enabled. I have triple checked that just to be
>sure.
>From what i think at the BBB :it should be DTE since at PC it is. I can try
>making it DCE.

One last time.  

Computer USB (5 volts) to RS232 adaptor (+/- 9 volts or so).  DTE or
DCE is solved by a null modem if needed.

BBB does not put out USB (in this case).  BBB puts out 3.3 volts and
needs 3.3 volts.  RS-232 adaptor MUST accept 3.3 volts from the BBB
and ONLY put out 3.3 volts TO the BBB.

RS-232 adaptor provides the interface to the CNC machine.

1) you MUST use an RS-232 adaptor to connect to the BBB
2) the adaptor MUST be set to produce only 3.3 volts and NOT 5.0 volts
to the BBB
3) once you figure out what the BBB is producing on what pin, and what
the CNC needs to see, connect the RS-232 adaptor accordingly.

IF the BBB is putting out signals on the TXD pin, then you have a
source to drive the RS-232 adaptor.

IF the BBB can see 3.3 volt signals on the RXD pin, then you can
listen to the CNC machine if it says anything.

I'd suggest the following:

1) oscilloscope
2) RS-232 analyzer (if needed)

The bits about CTS, RTS, CD, DSR and so can be determined from looking
at what the working interface is doing when you measure the signals at
the CNC machine's pins.

Harvey



>
>On Sun, May 22, 2016 at 8:47 PM, Bruce Boyes  wrote:
>
>> @Shaurabh
>> OK they actually have a pretty nice document for that!
>>
>> Now what is your CNC machine? What serial port document do you have for it?
>>
>> The serial cape has only TXD and RXD driven, no handshake or flow control.
>> The CNC might expect something specific. It does look like the serial cape
>> has some of the control signals fed back, I did not study it enough and map
>> the 5x2 ribbon cable to the DB9 to figure that out.
>>
>> You would need a null modem cable between the BBB DTE serial port and the
>> CNC DTE serial port, or you can modify the BBB serial as DCE instead. If
>> you make the BBB as DCE, and connect a straight serial cable to your PC
>> DTE, you should see the BBB bootloader information every time BBB powers
>> up. And you can log in to BBB on that serial0 port too.
>>
>> If things are eventually connected correctly to the CNC, it will also see
>> the BBB bootloader information: is that OK for the CNC or will it get
>> confused? If the CNC sends some data to the BBB during bootup it could
>> confuse BBB.
>>
>> So it might be better to use serial4, set as DCE which has no BBB debug
>> use already.
>>
>> If you do that, you could connect serial4 as DCE from BBB to your PC with
>> a straight cable, and pretend your PC is the CNC. See if you can open a
>> terminal on the PC and BBB and see data both ways. If so then it should
>> work on the CNC just by moving the cable over. This assumes the CNC doesn't
>> need some specific flow control or handshake. You might be able to disable
>> that from the CNC side so all it needs is TX and RX.
>>
>> Aren't serial ports wonderfully confusing?
>>
>> At this moment I have a headache from working on code and hardware (not on
>> BBB, we are using a Teensy ARM Cortex M4 this time) talking to a custom
>> RS422-sort-of serial connection so I feel your pain.
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/beagleboard/Z1s_NwXYNrw/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/CAC32br%2BK65pihWC4ZwDfCB8xgwNxe1pAZ2oj_RWME%3DL3KVPX%3DQ%40mail.gmail.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+uns

Re: [beagleboard] Re: Serial Communication on Beaglebone Black

[Harvey White]

On Fri, 20 May 2016 14:41:25 -0400, you wrote:

>Okay from what you said I guess it could be a drivers issue. The rest of it
>i have tried. What do you suggest if it is a driver problem?which driver
>and how do i install the drivers? could you perhaps tel me where to look
>exactly.

I've reached the limits of my expertise on this platform.  Someone
else will have to answer the question.

Harvey


>
>Thank you
>
>On Fri, May 20, 2016 at 1:12 PM, Harvey White 
>wrote:
>
>> rOn Fri, 20 May 2016 11:55:28 -0400, you wrote:
>>
>> >Exactly. I did what you just said. Used the ground RXD TXD. And the
>> >examples shown online do not use the red wire(power line) at all. And that
>> >is exactly what i did. I went by the conventional method before starting
>> to
>> >try out other things. also i later used the 3.3 V jumper.
>> >Do you have any suggestions on what i could perhaps try?
>>
>> If you have the 3.3 volt jumper enabled, then that will protect your
>> processor from overvoltage.
>>
>> Now I'd ask if you have RXD and TXD reversed (regardless of how the
>> software works, unless it can do that).  Check the pins with a logic
>> probe, or a scope to see that the TXD is connected to the proper RXD
>> line.
>>
>> If you have the right signals on the right lines, it's going to be
>> either a hardware configuration problem (in terms of what the software
>> is set to do) or a software problem (no drivers).
>>
>> I'd also write a small routine to output characters from one to the
>> other to see what's going on, just test signals.
>>
>> Check the destination to see what lines are active other than TXD and
>> RXD, you may need to duplicate them.
>>
>>
>> Note that an RS232 line level input and output are at least +/- 6
>> volts.
>>
>> From a computer to the BBB is likely to be USB to 3.3 volts, and the
>> output from the BBB to the RS-232 level converter is likely to need 5
>> volts unless it is specified to be 3.3.  It is likely that the BBB
>> cannot properly drive the RS-232 converter unless the converter can
>> tolerate that.
>>
>> The input from the 5 volt RS232 converter is going to be 5 volts,
>> which cannot be connected to the BBB directly, it needs to go through
>> a level converter.
>>
>> the BBB is a 3.3 volt world.
>>
>> Harvey
>>
>>
>> >Thanks
>> >
>> >On Fri, May 20, 2016 at 11:49 AM, Harvey White 
>> >wrote:
>> >
>> >> On Fri, 20 May 2016 11:11:39 -0400, you wrote:
>> >>
>> >> >The RX and TX at the beaglebone are working just fine. The TX output
>> from
>> >> >the RS-232 is 5V.  Also i tried with and without connecting the red
>> >> >wire(5V) from the RS 232. The necessary connections are GND (black
>> wire) ,
>> >> >RX and TX(green and white wires) of the PL2303 USB to Serial adapter.
>> >> >I also tried using a BeagleBone Black RS-232 Serial Micro-cape (see
>> >> >http://www.logicsupply.com/cbb-ttl-232/).
>> >> >
>> >> >Note: RX and TX are working just fine for all the UART ports.(i confirm
>> >> >after every try)
>> >>
>> >> Even though you check after each try, putting a signal over 3.3 volts
>> >> on the BBB pins (or 1.8 volts on the analog pins) is just asking for
>> >> trouble.
>> >>
>> >> Good engineering says not to put too much voltage on processor pins.
>> >>
>> >> 5 volts on a 3.3 volt maximum pin is too much.  You may or may not
>> >> have overstressed the pins, which may or may not fail sooner or later.
>> >>
>> >> If you are in college, and you have not been told this, then you need
>> >> to speak to your professors.  Data sheet maximum ratings are not
>> >> suggestions.
>> >>
>> >> You need the ground and the RXD and TXD lines.  The maximum voltage on
>> >> the RXD and TXD lines should be 3.3 volts, on the average adaptor,
>> >> there's a jumper for that.  There's also a jumper to select a 5 volt
>> >> swing.  You do not need either the 3.3 volt power line or the 5 volt
>> >> power line.
>> >>
>> >> Harvey
>> >>
>> >>
>> >>
>> >> >
>> >> >On Fri, May 20, 2016 at 10:32 AM, evilwulfie 
>> >> wrote:
>> >> >
>> >> >> if he connected it to the cnc with no 3.3v adapter it also

Re: [beagleboard] Re: Serial Communication on Beaglebone Black

[Harvey White]

rOn Fri, 20 May 2016 11:55:28 -0400, you wrote:

>Exactly. I did what you just said. Used the ground RXD TXD. And the
>examples shown online do not use the red wire(power line) at all. And that
>is exactly what i did. I went by the conventional method before starting to
>try out other things. also i later used the 3.3 V jumper.
>Do you have any suggestions on what i could perhaps try?

If you have the 3.3 volt jumper enabled, then that will protect your
processor from overvoltage.

Now I'd ask if you have RXD and TXD reversed (regardless of how the
software works, unless it can do that).  Check the pins with a logic
probe, or a scope to see that the TXD is connected to the proper RXD
line.  

If you have the right signals on the right lines, it's going to be
either a hardware configuration problem (in terms of what the software
is set to do) or a software problem (no drivers).

I'd also write a small routine to output characters from one to the
other to see what's going on, just test signals.

Check the destination to see what lines are active other than TXD and
RXD, you may need to duplicate them.


Note that an RS232 line level input and output are at least +/- 6
volts.  

>From a computer to the BBB is likely to be USB to 3.3 volts, and the
output from the BBB to the RS-232 level converter is likely to need 5
volts unless it is specified to be 3.3.  It is likely that the BBB
cannot properly drive the RS-232 converter unless the converter can
tolerate that.

The input from the 5 volt RS232 converter is going to be 5 volts,
which cannot be connected to the BBB directly, it needs to go through
a level converter.

the BBB is a 3.3 volt world.

Harvey


>Thanks
>
>On Fri, May 20, 2016 at 11:49 AM, Harvey White 
>wrote:
>
>> On Fri, 20 May 2016 11:11:39 -0400, you wrote:
>>
>> >The RX and TX at the beaglebone are working just fine. The TX output from
>> >the RS-232 is 5V.  Also i tried with and without connecting the red
>> >wire(5V) from the RS 232. The necessary connections are GND (black wire) ,
>> >RX and TX(green and white wires) of the PL2303 USB to Serial adapter.
>> >I also tried using a BeagleBone Black RS-232 Serial Micro-cape (see
>> >http://www.logicsupply.com/cbb-ttl-232/).
>> >
>> >Note: RX and TX are working just fine for all the UART ports.(i confirm
>> >after every try)
>>
>> Even though you check after each try, putting a signal over 3.3 volts
>> on the BBB pins (or 1.8 volts on the analog pins) is just asking for
>> trouble.
>>
>> Good engineering says not to put too much voltage on processor pins.
>>
>> 5 volts on a 3.3 volt maximum pin is too much.  You may or may not
>> have overstressed the pins, which may or may not fail sooner or later.
>>
>> If you are in college, and you have not been told this, then you need
>> to speak to your professors.  Data sheet maximum ratings are not
>> suggestions.
>>
>> You need the ground and the RXD and TXD lines.  The maximum voltage on
>> the RXD and TXD lines should be 3.3 volts, on the average adaptor,
>> there's a jumper for that.  There's also a jumper to select a 5 volt
>> swing.  You do not need either the 3.3 volt power line or the 5 volt
>> power line.
>>
>> Harvey
>>
>>
>>
>> >
>> >On Fri, May 20, 2016 at 10:32 AM, evilwulfie 
>> wrote:
>> >
>> >> if he connected it to the cnc with no 3.3v adapter it also could have
>> >> fried the bbb.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On 5/20/2016 7:08 AM, Wally Bkg wrote:
>> >>
>> >>
>> >> You do realize that on your PC the RS232 signal levels from the COM
>> ports
>> >> are +/- 12V while without extra hardware the Beaglebone levels are
>> 0-3.3V?
>> >> You may have fried the RX input on the Beaglebone if you've connected it
>> >> directly to a +/- 12V RS232 TX output.
>> >>
>> >> Assuming you've got the logic levels right, If you used a "standard"
>> >> serial cable on your PC to the CNC machine it probably activated the
>> CTS or
>> >> DTR automatically,  you may need to run one more wire from the
>> Beaglebone,
>> >>  or tie it active on the CNC interface side.
>> >>
>> >>
>> >> On Friday, May 20, 2016 at 7:36:15 AM UTC-5, Shaurabh Kumar Singh wrote:
>> >>>
>> >>> The cnc is dte as far as I know.
>> >>> And I am assuming since it worked without hardware handshaking on my
>> pc,
>> >>> it shouldn require t

Re: [beagleboard] Re: Serial Communication on Beaglebone Black

[Harvey White]

On Fri, 20 May 2016 11:11:39 -0400, you wrote:

>The RX and TX at the beaglebone are working just fine. The TX output from
>the RS-232 is 5V.  Also i tried with and without connecting the red
>wire(5V) from the RS 232. The necessary connections are GND (black wire) ,
>RX and TX(green and white wires) of the PL2303 USB to Serial adapter.
>I also tried using a BeagleBone Black RS-232 Serial Micro-cape (see
>http://www.logicsupply.com/cbb-ttl-232/).
>
>Note: RX and TX are working just fine for all the UART ports.(i confirm
>after every try)

Even though you check after each try, putting a signal over 3.3 volts
on the BBB pins (or 1.8 volts on the analog pins) is just asking for
trouble.

Good engineering says not to put too much voltage on processor pins.

5 volts on a 3.3 volt maximum pin is too much.  You may or may not
have overstressed the pins, which may or may not fail sooner or later.

If you are in college, and you have not been told this, then you need
to speak to your professors.  Data sheet maximum ratings are not
suggestions.

You need the ground and the RXD and TXD lines.  The maximum voltage on
the RXD and TXD lines should be 3.3 volts, on the average adaptor,
there's a jumper for that.  There's also a jumper to select a 5 volt
swing.  You do not need either the 3.3 volt power line or the 5 volt
power line.

Harvey



>
>On Fri, May 20, 2016 at 10:32 AM, evilwulfie  wrote:
>
>> if he connected it to the cnc with no 3.3v adapter it also could have
>> fried the bbb.
>>
>>
>>
>>
>>
>> On 5/20/2016 7:08 AM, Wally Bkg wrote:
>>
>>
>> You do realize that on your PC the RS232 signal levels from the COM ports
>> are +/- 12V while without extra hardware the Beaglebone levels are 0-3.3V?
>> You may have fried the RX input on the Beaglebone if you've connected it
>> directly to a +/- 12V RS232 TX output.
>>
>> Assuming you've got the logic levels right, If you used a "standard"
>> serial cable on your PC to the CNC machine it probably activated the CTS or
>> DTR automatically,  you may need to run one more wire from the Beaglebone,
>>  or tie it active on the CNC interface side.
>>
>>
>> On Friday, May 20, 2016 at 7:36:15 AM UTC-5, Shaurabh Kumar Singh wrote:
>>>
>>> The cnc is dte as far as I know.
>>> And I am assuming since it worked without hardware handshaking on my pc,
>>> it shouldn require the same for the bbb either.
>>> That said, I have tried both the settings. With and without hardware
>>> handshaking.
>>> The only thing I can think of is for some reason perhaps, the default
>>> serial port settings must be different on the bbb (with debian) than my pc
>>> (where I previously successfully had communicated-windows)
>>> On 20 May 2016 08:19, "Wally Bkg"  wrote:
>>>
 On Thursday, May 19, 2016 at 7:08:55 PM UTC-5, Shaurabh Kumar Singh
 wrote:

> Okay. I shall look it up.
> By the way, i did confirm the working of the UART pins(UART1 RX to
> UART4 TX and vice versa).
> I had two terminal tabs open and when i typed into one and
> entered(UART1 settings) it showed up on the other terminal with UART4
> settings. I inferred that the Adafruit libraries work just fine for the 
> BBB
> (correct me if i am mistaken)
>
> It is just that while interacting with a CNC machine(with a HAAS OS) it
> is not communicating rather just showing up what is being sent.
>

 You may need CTS or DTR active for the other end to accept data and
 respond.  Are you sure the CNC machine doesn't need a "hardware
 handshaking" protocol?

 If you have uart1 talking to uart4 on the Beaglebone, that says the
 problem is the physical connection and/or the protocol to the CNC machine.
 Is the CNC machine wired to be DTE or DCE?

 At this point I think you need help from the CNC machine's
 documentation, or from someone familiar with that particular machine.

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to a topic in the
 Google Groups "BeagleBoard" group.
 To unsubscribe from this topic, visit
 
 https://groups.google.com/d/topic/beagleboard/Z1s_NwXYNrw/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 beagleboard...@googlegroups.com.
 To view this discussion on the web visit
 
 https://groups.google.com/d/
 msgid/beagleboard/3b9db8f5-b454-4801-b4a5-49a867c0e255%
 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 s

Re: [beagleboard] Automatic shutdown options for loss of power?

[Harvey White]

On Mon, 16 May 2016 16:45:46 -0700, you wrote:

>that is . ..  it would cost us 4-5x as much to make our own BBB's . .

Economies of scale.  Throwing in design time and debug time for free.

Similar board (physically), cost of two layer board in prototype
quantities is about 14 dollars, Xmega processor about 8, (22), cost of
connectors 5 (27), graphics chip 9 dollars (optional, say 36),
miscellaneous parts perhaps 15 dollars, total cost 51 dollars.

That, however, is in single quantity units, effectively

Boards can be had for far less, roughly 2 dollars or so, processors in
100's quantity are less, etc I guess we could talk less than 30
dollars for parts, depending.

The difference in such a design, is that while less capable, it's mine
and I know where all the bodies are buried, and why

So the BBB is (all things considered) reasonably enough priced

Harvey


>
>On Mon, May 16, 2016 at 4:44 PM, William Hermans  wrote:
>
>> Also, while on the subject. It's kind of hard to understand how the rpi
>> foundation can create their rpi line at so little cost. My buddy and I (
>> mostly my buddy ) priced out what it would cost to make a beaglebone, and
>> for us, it would cost 4-5 as much as what they're sold for retail.
>>
>> Quite honestly, the first iteration of the rpi I found rather repugnant.
>> But now owning an rpi3 I see it is really a good little board that has
>> limited uses in the embedded arena( true embedded, not just small cheap
>> systems connected to 3 GPIO's )
>>
>> But see, the Raspberry PI3 has quad cores, a really good GPU( which is
>> where is shines ) 1G memory, ethernet, 40 or so pins for GPIO .
>> peripherals, wifi, and BLE all for $35 . . . Honestly I do not see them
>> making any money except from their government, from loses.
>>
>> So even though I think the rpi3 is a really good deal, and a steal at
>> $35USD, I still think the BBB is the better deal, even at a higher cost.
>> For many situations. But how in the hell does the rpi foundation do it ?
>> heh.
>>
>> On Mon, May 16, 2016 at 4:37 PM, Gerald Coley 
>> wrote:
>>
>>> I design systems like this all the time for our customers. They are nice
>>> enough to give me a bigger budget and not worried about keeping it low cost
>>> just to sell more boards.
>>>
>>> Gerald
>>>
>>>
>>> On Mon, May 16, 2016 at 6:34 PM, William Hermans 
>>> wrote:
>>>
>>>> *The bottom line seems to be that the BBB was not designed for this*
>>>>> * kind of situation or application, and making it fit this requires*
>>>>> * additional resources of some sort.  Now the question comes down to*
>>>>> * cost, utility, percentage of applications needing this, elegance of*
>>>>> * design, and whether or not the hardware platform can cooperate in
>>>>> this*
>>>>> * or whether or not it simply lives in its own world.*
>>>>>
>>>>>
>>>>> * Harvey*
>>>>>
>>>>
>>>> I think the real bottom line is that the BBB *could* have been designed
>>>> to do all this and more. At additional costs. As Gerald has stated many
>>>> times on this group. Which I can completely understand.
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, May 16, 2016 at 4:28 PM, Harvey White 
>>>> wrote:
>>>>
>>>>> On Mon, 16 May 2016 15:45:14 -0700, you wrote:
>>>>>
>>>>> >You do not need anything connected to the beaglebone for any reason.
>>>>> The
>>>>> >beaglebone has an on die ADC that can detect if the AC mains is
>>>>> powered or
>>>>> >not. In which case, after a preset time period the Beaglebone could
>>>>> shut
>>>>> >its self down.
>>>>>
>>>>> True enough.  The prevailing wisdom was going with an external device
>>>>> having all the smarts about power failure, while the BBB was being
>>>>> held up by batteries.
>>>>>
>>>>> The requirement that you propose is that the BBB have, somewhere,
>>>>> access to power long enough to do a graceful shutdown.
>>>>>
>>>>> How this is done is left as an exercise for the student.
>>>>>
>>>>>
>>>>> >
>>>>> >Meanwhile, an external "device" can just switch off the input 5V to the
>>>>> >beaglebone after a preset amount of time. Then o

Re: [beagleboard] Automatic shutdown options for loss of power?

[Harvey White]

On Mon, 16 May 2016 16:34:28 -0700, you wrote:

>>
>> *The bottom line seems to be that the BBB was not designed for this*
>> * kind of situation or application, and making it fit this requires*
>> * additional resources of some sort.  Now the question comes down to*
>> * cost, utility, percentage of applications needing this, elegance of*
>> * design, and whether or not the hardware platform can cooperate in this*
>> * or whether or not it simply lives in its own world.*
>>
>>
>> * Harvey*
>>
>
>I think the real bottom line is that the BBB *could* have been designed to
>do all this and more. At additional costs. As Gerald has stated many times
>on this group. Which I can completely understand.
>

Exactly.  Now this demonstrates the difference between a hobby project
(where cost is secondary) and a commercial product, where cost is a
goal, if not a limit.

Had I designed it, it would have had a graceful shutdown
procedure.

1) had I thought of it
2) had I had the need for it
3) had I figured out how to do it (after X tries, depending)
4) had I decided it was important enough to do (bearing in mind 1
through 3 above)
5) fill in other limits as needed

Second guessing a design is easy.  However, it does show that any
design (like plans of war) rarely survives contact with the enemy.

Harvey


>
>
>
>On Mon, May 16, 2016 at 4:28 PM, Harvey White 
>wrote:
>
>> On Mon, 16 May 2016 15:45:14 -0700, you wrote:
>>
>> >You do not need anything connected to the beaglebone for any reason. The
>> >beaglebone has an on die ADC that can detect if the AC mains is powered or
>> >not. In which case, after a preset time period the Beaglebone could shut
>> >its self down.
>>
>> True enough.  The prevailing wisdom was going with an external device
>> having all the smarts about power failure, while the BBB was being
>> held up by batteries.
>>
>> The requirement that you propose is that the BBB have, somewhere,
>> access to power long enough to do a graceful shutdown.
>>
>> How this is done is left as an exercise for the student.
>>
>>
>> >
>> >Meanwhile, an external "device" can just switch off the input 5V to the
>> >beaglebone after a preset amount of time. Then once you have AC power
>> back,
>> >the "Device" simply turns the 5V back on.
>>
>> Yep, and with the same requirements of powering from either a battery,
>> a supercapacitor, or something more exotic.
>>
>> The bottom line seems to be that the BBB was not designed for this
>> kind of situation or application, and making it fit this requires
>> additional resources of some sort.  Now the question comes down to
>> cost, utility, percentage of applications needing this, elegance of
>> design, and whether or not the hardware platform can cooperate in this
>> or whether or not it simply lives in its own world.
>>
>>
>> Harvey
>>
>>
>> >
>> >On Mon, May 16, 2016 at 3:09 PM, Harvey White 
>> >wrote:
>> >
>> >> On Mon, 16 May 2016 11:35:54 -0700 (PDT), you wrote:
>> >>
>> >> >Looks like nut been ported to Debian for the BBB.
>> >> >
>> >> >It and a smart UPS might be the easiest solution.
>> >> >
>> >> >I'm thinking along these lines, but haven't done anything with it yet.
>> >> The
>> >> >nut client getting a signal over the network from my desktop is kind of
>> >> >what I'm thinking.  I've my BBW IOT app, router, and ISP interface on
>> >> >a separate UPS that I want running as long as the battery lasts, but a
>> >> >controlled shutdown of the BBW is something I'd like to add eventually.
>> >> >
>> >> >The "shutdown if the power outage lasts longer than X" is pretty easy,
>> >> >robust automatic start-up when the power returns might require a
>> smarter
>> >> >than the average UPS.
>> >>
>> >> I'd say that you want one that does automatic battery tests as well.
>> >> The one that I knew of at one time was a sine wave inverter.
>> >>
>> >> To summarize the types of inverters, there are two schemes.
>> >>
>> >> 1) keep a battery charged at all times.  When power fails, detect the
>> >> loss of AC at the output.  Start the inverter and switch that power to
>> >> the output of the inverter.  What happens is that power drops out for
>> >> the output with a power failure, and yo

Re: [beagleboard] Automatic shutdown options for loss of power?

[Harvey White]

On Mon, 16 May 2016 15:45:14 -0700, you wrote:

>You do not need anything connected to the beaglebone for any reason. The
>beaglebone has an on die ADC that can detect if the AC mains is powered or
>not. In which case, after a preset time period the Beaglebone could shut
>its self down.

True enough.  The prevailing wisdom was going with an external device
having all the smarts about power failure, while the BBB was being
held up by batteries.

The requirement that you propose is that the BBB have, somewhere,
access to power long enough to do a graceful shutdown.

How this is done is left as an exercise for the student.


>
>Meanwhile, an external "device" can just switch off the input 5V to the
>beaglebone after a preset amount of time. Then once you have AC power back,
>the "Device" simply turns the 5V back on.

Yep, and with the same requirements of powering from either a battery,
a supercapacitor, or something more exotic.

The bottom line seems to be that the BBB was not designed for this
kind of situation or application, and making it fit this requires
additional resources of some sort.  Now the question comes down to
cost, utility, percentage of applications needing this, elegance of
design, and whether or not the hardware platform can cooperate in this
or whether or not it simply lives in its own world.


Harvey


>
>On Mon, May 16, 2016 at 3:09 PM, Harvey White 
>wrote:
>
>> On Mon, 16 May 2016 11:35:54 -0700 (PDT), you wrote:
>>
>> >Looks like nut been ported to Debian for the BBB.
>> >
>> >It and a smart UPS might be the easiest solution.
>> >
>> >I'm thinking along these lines, but haven't done anything with it yet.
>> The
>> >nut client getting a signal over the network from my desktop is kind of
>> >what I'm thinking.  I've my BBW IOT app, router, and ISP interface on
>> >a separate UPS that I want running as long as the battery lasts, but a
>> >controlled shutdown of the BBW is something I'd like to add eventually.
>> >
>> >The "shutdown if the power outage lasts longer than X" is pretty easy,
>> >robust automatic start-up when the power returns might require a smarter
>> >than the average UPS.
>>
>> I'd say that you want one that does automatic battery tests as well.
>> The one that I knew of at one time was a sine wave inverter.
>>
>> To summarize the types of inverters, there are two schemes.
>>
>> 1) keep a battery charged at all times.  When power fails, detect the
>> loss of AC at the output.  Start the inverter and switch that power to
>> the output of the inverter.  What happens is that power drops out for
>> the output with a power failure, and your equipment is supposed to
>> stay "up" for a certain amount of time (that the UPS takes to switch
>> on).  Then the UPS takes up the load and life is good.
>>
>> 2) keep a battery charged at all times.  Power the inverter from the
>> battery at all times.  When the power fails, the battery charger
>> simply shuts down.
>>
>> The second one is the one I'd think you'd want to get.
>>
>> An opto isolator, driven by an AC bridge (or an AC style optoisolator)
>> would give you a power failure indication within a half cycle.
>>
>> Harvey
>>
>>
>> >
>> >I'd be interested in success stories, but my experience with brand name
>> >(APC) and off-brand UPS with desktop system is while they are better than
>> >nothing, they  aren't good at reporting battery issues and ultimately I
>> end
>> >up with a power failure and "pull the plug" type shutdown because the UPS
>> >batteries can't support the switch over.  We get a lot of 0.5 - 15 minute
>> >power failures from thunderstorms here,  so I'm sure the USP has saved me,
>> >but they are not foolproof.
>> >
>> >
>> >Ultimately I'm trying to sell the wife on a "whole house" natural gas
>> >powered backup system so that a dumb UPS or battery with only a few
>> minutes
>> >run time to let the generator come on and switch over would be needed.
>> >She was excited about it after Hurricane Ike, but now that its been ~eight
>> >years, selective memory has her thinking we don't need 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+unsubsc

Re: [beagleboard] Automatic shutdown options for loss of power?

[Harvey White]

On Mon, 16 May 2016 11:35:54 -0700 (PDT), you wrote:

>Looks like nut been ported to Debian for the BBB.
>
>It and a smart UPS might be the easiest solution.
>
>I'm thinking along these lines, but haven't done anything with it yet.  The 
>nut client getting a signal over the network from my desktop is kind of 
>what I'm thinking.  I've my BBW IOT app, router, and ISP interface on 
>a separate UPS that I want running as long as the battery lasts, but a 
>controlled shutdown of the BBW is something I'd like to add eventually.
>
>The "shutdown if the power outage lasts longer than X" is pretty easy, 
>robust automatic start-up when the power returns might require a smarter 
>than the average UPS.

I'd say that you want one that does automatic battery tests as well.
The one that I knew of at one time was a sine wave inverter.

To summarize the types of inverters, there are two schemes.

1) keep a battery charged at all times.  When power fails, detect the
loss of AC at the output.  Start the inverter and switch that power to
the output of the inverter.  What happens is that power drops out for
the output with a power failure, and your equipment is supposed to
stay "up" for a certain amount of time (that the UPS takes to switch
on).  Then the UPS takes up the load and life is good.

2) keep a battery charged at all times.  Power the inverter from the
battery at all times.  When the power fails, the battery charger
simply shuts down.

The second one is the one I'd think you'd want to get.

An opto isolator, driven by an AC bridge (or an AC style optoisolator)
would give you a power failure indication within a half cycle.

Harvey


>
>I'd be interested in success stories, but my experience with brand name 
>(APC) and off-brand UPS with desktop system is while they are better than 
>nothing, they  aren't good at reporting battery issues and ultimately I end 
>up with a power failure and "pull the plug" type shutdown because the UPS 
>batteries can't support the switch over.  We get a lot of 0.5 - 15 minute 
>power failures from thunderstorms here,  so I'm sure the USP has saved me, 
>but they are not foolproof.
>
>
>Ultimately I'm trying to sell the wife on a "whole house" natural gas 
>powered backup system so that a dumb UPS or battery with only a few minutes 
>run time to let the generator come on and switch over would be needed.   
>She was excited about it after Hurricane Ike, but now that its been ~eight 
>years, selective memory has her thinking we don't need 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/apfkjbtvsk9h94q0qvfpke40ofhbc7c22h%404ax.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Automatic shutdown options for loss of power?

[Harvey White]

On Mon, 16 May 2016 09:14:13 -0700 (PDT), you wrote:

>That is pretty limited.  Sounds like just punting the software and going 
>with a mostly hardware solution would be just as easy but then I am a 
>hardware guy.  I think a UPS with auto shutdown AND restart capability 
>would be something a lot of people would want but I could be wrong.


How about an inexpensive microprocessor (of whatever variety), an
on-board backup battery, and enough smarts to shut down a BBB
intelligently?  Perhaps a pin on the BBB might be dedicated to a
shutdown option.  It's a combination of both hardware and software.
How much you pay for it, how much you decide to build into it depends
on your own desires.

Harvey

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

Re: [beagleboard] Hardware watchdog for BBB

[Harvey White]

On Sun, 15 May 2016 17:08:40 -0700 (PDT), you wrote:

>
>Sorry guys.  I might be confusing my terms here, or misusing the phrase 
>'watchdog timer'.  Would 'hardware watchdog circuit' fit?  "Intelligent 
>power switch?"  I'm not quite sure what to search for!

I generally call a watchdog timer (and it can be external if desired)
as a timer that must be continually refreshed, if it times out, it
resets the microprocessor.  However, the processor remembers that it
has been reset by a watchdog (most of them ought to), and then your
bootup routine will know that the program hung somewhere and didn't
reset the watchdog timer in time.

What the BBB needs is not so much a watchdog timer, but an intelligent
power monitor.  If that processor (and it could be very simple) does
*not* have an operating system but simply runs embedded firmware, then
it will not suffer from shutdown problems as does the BBB.

It could have an operating system, but should not depend on file
systems being set up properly (a la windows or linux, I think).  

You could use something as simple as an Arduino.

Harvey

>
>The circuit I'm looking for is what John3909 is describing; something to 
>address the corner-cases around power and ensure graceful, and hands-off, 
>system recovery amidst all of the corner cases (brownouts, drop+restart 
>(incl at 'inconvenient' times, ie during shutdown, etc)).  
>
>Fwiw, my application is already kicking the onboard watchdog, and relying 
>on its reboot if the software system fails.  I need to make sure that that 
>reboot ALWAYS happens, no matter what the power throws at it, as the system 
>will be installed in walls, ceilings and such.
>
>Does anyone know of a good public-domain/open-source external circuit 
>design that might work around the BBB (or something close -- a good 
>starting point)?  Or, even better, would anyone be able & willing to share 
>their circuit design?  I realize that this kind of circuit requires some 
>solid engineering to get right.  The EE part is a stretch for me, 
>capability-wise, but I can offer software services in trade for hardware 
>help. 
>
>I'm personally blocked by this issue, and just trying to work out the best 
>path forward, but I'd love to see this problem definitively solved for 
>everyone using the BBB.  It is such a great platform. I'd love to ensure 
>it'll always be online and ready for what we all throw at it.
>
>Best,
>ST

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

Re: [beagleboard] Pull-up resistors

[Harvey White]

On Fri, 13 May 2016 10:21:52 -0700, you wrote:

>Also, I'm not exactly an EE, but the one EE I do know, seems to prefer
>using external pull up/down resistors. Why, I'm not sure, but perhaps
>someone who is an EE can explain why.

You can control the values for external parts.  Not all processors or
chips have internal resistors that can be enabled.

Example:  cable tester, open drain outputs driving an input, chip
provided resistor 100K (not a processor)...  That's rather high, and
susceptible to noise.  1K to 10K would be better, but would require
external parts.

lower the resistor value, more current flows, but the less susceptible
to noise you happen to be.

Harvey


>
>On Fri, May 13, 2016 at 10:19 AM, William Hermans  wrote:
>
>> *Are pull up resistors required for the GPIO pins when used as inputs or
>>> as outputs for the beaglebone black? I am using the beaglebone to drive a
>>> few n-channel MOSFETs. Thanks!*
>>
>>
>> Pull up/down resistors are typically "required" by the circuit. In your
>> case where you're using a device that tends to be used as a switch. Leaving
>> the circuit floating can cause unexpected behavior.
>>
>> So, is it "required" ? No. Is it desired? Yes.
>>
>> On Fri, May 13, 2016 at 9:14 AM, Chad Baker  wrote:
>>
>>> The AM3358 has internal pullup/pulldown resistors available for GPIO
>>> inputs. These can be enabled using the universal-io
>>> "https://github.com/cdsteinkuehler/beaglebone-universal-io";
>>> . If you are
>>> using a current version of Debian, the device tree should already be
>>> included. The github overview shows how to use config-pin, the command
>>> "config-pin -h" shows how to engage the pullup/pulldown resistors.
>>> Chad
>>>
>>>
>>> On 5/13/16 10:48 AM, 37ronaldpare...@gmail.com wrote:
>>>
>>> Are pull up resistors required for the GPIO pins when used as inputs or
>>> as outputs for the beaglebone black? I am using the beaglebone to drive a
>>> few n-channel MOSFETs. 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/81b4dd20-bdad-4034-b024-d71f1b19c71b%40googlegroups.com
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
>>> --
>>> Chad Baker
>>> Professor Emeritus
>>> Electrical and Computer Engineering
>>> Christian Brothers university901-321-3440cmba...@cbu.edu
>>>
>>> --
>>> 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/5735FD57.7070009%40cbu.edu
>>> 
>>> .
>>>
>>> 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/o08cjbh5s011s8vrlrevumd6tda5k9oad4%404ax.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: RS485 problem with DE/!RE

[Harvey White]

On Mon, 25 Apr 2016 04:31:43 -0700 (PDT), you wrote:

>Hey all,

I can't tell you Beaglebone specifics, but to stop after a certain
number of characters and set DE/!RE high (I'm guessing this is a full
indication?), sounds like you've hit the limits on a buffer of some 50
bytes, so it may be that you're running up against this limit.

Normally, when you read data from a hardware UART within a chip, the
internal FIFO in the hardware is cleared of that byte, data flags are
reset.

It sounds as if something's not being done.

If there is a software FIFO involved, and you're reading the data
directly from the chip (not sure how), then the FIFO is loaded, but
never read.  When it's full, the serial interface should tell the
transmitter to stop sending.

These, of course, are just guesses.

Harvey



>
>I did some further tests.
>Actually none of the screens from my scope looks like I would expect it...
>
>Picture 1 shows the result, if I try to read something on the bus with a 
>14s timeout (nothing was sended on the bus...)
>Pic1 
>Picture 2 shows the same, but this time there were messages send over the 
>bus. After 49 bytes, the beagle bone toggles the DE/!RE gpio to high for 
>unknown reasons (the test program is still reading from the UART interface)
>Pic2 
>Picture 3 shows the test, where the BeagleBone is sending
>Pic3 
>and finally picture 4 shows a test, where the BeagleBone should read 
>(timeout 3s) on the bus, then send something and again reading (with 3s 
>timeout)...
>Pic4 
>As you see, DE/!RS stays high after sending, although it should be low...
>
>In addition I would expect this line to be low when the port is not used, 
>but it's high..
>
>I checked if there is any other process (or driver) accessing GPIO3_19 but 
>I could not find any...
>
>Any help is very much appreciated!
>Florian
>
>
>
>Am Freitag, 22. April 2016 15:22:48 UTC+2 schrieb 
>florian.f...@googlemail.com:
>>
>> Hey all,
>>
>> I'm using the Debian Jessie image with kernel version 4.4.6-ti-r15 on my 
>> BeagleBone Black.
>>
>> To monitor our vacuum system in the lab, we need a RS485 interface, so I 
>> simply connected an ADM2682 RS422/485 line driver
>> to UART4 of the BeagleBone using this Device Tree Overlay
>> BB-UART4-RS485-00A0.dts 
>> 
>>  (commit 
>> 16f76f7 on master branch)
>>
>> P9.27 is connected to the DE and !RE inputs of the chip.
>>
>> Using this for sending works just fine, but I have problems receiving 
>> messages over the bus.
>>
>> For testing I wrote a small C-program which should read on the bus until 
>> it gets two times a timeout.
>> The reading is done via select-call with a 5 second timeout.
>> The device on the other end of the bus is contentiously sending data over 
>> the bus. 
>> After receiving 49 bytes at most, the DE/!RE line goes up and my 
>> BeagleBone stops receiving any data...
>>
>> I've uploaded a screenshot of the scope showing the three signals from the 
>> UART interface
>> Scope 
>>
>> Does anyone has a clue what could go wrong?
>>
>> Any help appreciated!
>> Regards
>> Florian
>>
>>
>>

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

Re: [beagleboard] Loading on Beaglebone Black Boot Pins?

[Harvey White]

On Mon, 18 Apr 2016 17:12:37 -0700 (PDT), you wrote:

>I'm trouble shooting a problem on a simple cape for a BeagleBone Black.
>
>I have a bipolar switch for an LED, very similar to that used for the "User 
>LEDS".
>So I have added an approximately 10Kohm load to one of the "boot pins", 
>which
>in header lingo is P8_44.
>
>P8_44 is also one of the "boot" pins.  I'm interesting in using the PRU 
>connection mode of this pin.
>
>The System Reference Manuals says the boot pins must not be *driven* prior 
>to coming out of reset (SYS_RESET goes high).
>
>So maybe my understanding of the term "driven" in this context is 
>incorrect, and it could also be interpreted as "loading",
>as in excessive resistive loading?

Driven in this case (and lots of others) means a signal connected to
that pin.

A resistor going to VCC or ground does indeed "drive" that signal.  

BOOT pins must completely float until the boot process is done, *then*
you can do something with them.

A good idea is to avoid boot pins
Another good idea is to use tri-state drivers on those pins, and turn
them on ONLY when the boot process is done.

There are a number of threads discussing this.

However, nobody has specifically said that resistors effectively drive
boot pins.  They do.

Harvey


>
>I tried an experiment on both BBB and BBG with a 10kohm resistor to ground 
>on P8_44.  Both refused to boot up and run.
>So is it a requirement to keep resistive loads off this pin during the boot 
>process?
>
>Regards,
>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/jkuahbpu3i94tkjuam7ifbc77hpue29nn4%404ax.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: beaglebone black PWM

[Harvey White]

On Thu, 14 Apr 2016 07:02:15 -0700 (PDT), you wrote:

>While I prefer CVI over LabView, you might find the new LINX 3.0 LabView 
>for Linux libraries useful:
>http://forums.ni.com/t5/LabVIEW/LINX-3-0-LabVIEW-for-BeagleBone-Black-and-Raspberry-Pi-2-3/td-p/3278758
>
>OTOH, I'm not sure why you want a C program to generate PWM when there 
>already are multiple ways to generate PWM signals on the GPIO pins that 
>support being PWM (analogWrite in the Bonescript examples) outputs.

You're missing that this is an educational project.  Often times the
students are told "solve it this way only" for various reasons.  One
might be that the student is to use certain tools that are regarded as
essential to the course.  Another might be that the instructor
understands only those particular methods and will not be able to
figure out a different method or processor.

Harvey



>
>Unless your C/C++ code project is really large, native development on the 
>BBB is not too painful, ditch the HDMI and use ssh -X over the USB "gadget" 
>Ethernet interface and install a lightweight IDE like geany.
>
>On Thursday, April 14, 2016 at 3:56:50 AM UTC-5, Brainiac wrote:
>>
>> hi everyone,
>>
>> i'm working with BBB rev C for my final year project , i want to controle 
>> a 3 step by step motors of a 3 axis cartesien robot, i didn't come to a 
>> solution to set up a cross compiler for my BBB , i tried Eclipse and 
>> NetBeans but it didn't work , can u help me to program the BBB ?? the " 
>> Master " want a C program that can generate a PWM , and he wants to 
>> controle the robot using a LabWindows/CVI human-machine interface , that's 
>> another problem for me , i'm stocked , please need 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] beaglebone black PWM

[Harvey White]

On Thu, 14 Apr 2016 01:56:50 -0700 (PDT), you wrote:

>hi everyone,
>
>i'm working with BBB rev C for my final year project , i want to controle a 
>3 step by step motors of a 3 axis cartesien robot, i didn't come to a 
>solution to set up a cross compiler for my BBB , i tried Eclipse and 
>NetBeans but it didn't work , can u help me to program the BBB ?? the " 
>Master " want a C program that can generate a PWM , and he wants to 
>controle the robot using a LabWindows/CVI human-machine interface , that's 
>another problem for me , i'm stocked , please need help

Just a comment on the hardware here.  The usual stepper motor driver
(that's a motor with multiple coils that needs either a grounding
driver or a phase switching bipolar driver to run) takes a direction
logic input (CW or CCW) and a step pulse.

Servo motor systems (not the motors themselves) take a PWM directly,
these are often used in model aircraft and boats.

Servo motors (the motors themselves) can run on a PWM signal, but need
a hardware driver and a direction input.  Many controllers take an
analog input for speed.

Important to know exactly what kind of motor you're working with,
since that will absolutely control what kind of signals you need.

Harvey


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

Re: [beagleboard] SPI BBB Master, BBB Slave

[Harvey White]

On Mon, 4 Apr 2016 14:54:37 -0700, you wrote:

>If you are using an SPI master, then what you say is correct, but if you are a 
>SPI slave, then some other device is controlling the clock, which means you 
>have to have data available before the clock starts. If there is no delay 
>between packets, then timing is critical.

Quite correct, so the designers of the slave interface reply with what
when the device is not ready?  My suspicion is that it's 0xFF.  I
think they have to deal with this gracefully.

Harvey


>
>Regards,
>John
>> 

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

Re: [beagleboard] SPI BBB Master, BBB Slave

[Harvey White]

On Mon, 4 Apr 2016 13:13:48 -0700, you wrote:

>
>
>> On Apr 4, 2016, at 12:49 PM, ybeag...@rehut.com wrote:
>> 
>> On Monday, April 04, 2016 12:04:56 John Syne wrote:
>>> I’m not sure that is correct. The master will normally send a command and
>>> then your slave driver will have to respond with relevant packet. The
>>> protocol will have to be well defined.
>> 
>> None of that is required by SPI (in the most basic form  it is just a shift 
>> register). What I was alluding it protocol games that be played like Master 
>> writes byte to slave and waits for an active GPIO before anymore clocking. 
>> Or 
>> even a dumb (unidirectional) protocol where the master waits for a GPIO to 
>> go 
>> active before clocking out data. 
>Well, technically, that is correct, because data is shifted in and out at the 
>same time, using the same clock. However, when the master hasn’t requested a 
>specific data, what do you respond with? Random data? Perhaps if it was just 
>streaming channel data, then I can see your point. 

Data that is shifted back into the master is generally a known
quantity, generally 0xFF.

I haven't run into a device that requires data to be sent within a
certain amount of time.  Generally, you don't have to always run at
the maximum, although there's sometimes a minimum.

I've been debugging SPI stuff on another platform, and the time
between bytes did not seem to be significant if it were held up by the
debugger.

>> 
>> In contrast, doing it like a lot of common devices where you can clock in a 
>> byte (i.e. register address or a command) and expect data after another 8 
>> clocks could impose some very tight timing requirements.
>I agree, this could be very difficult to achieve using interrupts, but using 
>DMA that should be pretty simple. That presupposes that the data is already in 
>the DMA buffer and this is some streaming interface I spoke of previously. 
>Streaming channel data into the BBB using DMA would also be pretty simple. 
>Exchanging of short master/slave command/response would need interrupt 
>processing. Maybe using fixed size messages and using fifo watermark might 
>limit the interrupt overhead. 

IF you're dealing with a streaming interface, then the timing is
imposed by the data stream output, and all the timing relaxations have
limits.


Harvey

>> 
>> 
>>> However, you are correct that the
>>> SPI slave must be preconfigured and waiting for the master to start
>>> clocking the interface. The problem with the SPI framework and in
>>> particular the McSPI driver is that they is written around a master
>>> implementation and adding slave support is almost impossible. It would be
>>> easier to write a slave McSPI from scratch. The I2C slave framework might
>>> be a good guide on how to make this work.
>> 
>> There are 2 things being mixed up here -
>> Merely grafting on slave functionality isn't too difficult with the current 
>> McSPI driver (that's what I did). The main thing this gets you is a lot of 
>> the 
>> driver registration and McSPI init is reused; this is a big hack but it gets 
>> data flowing.
>Can you share that with me? I would be interested to see how you managed to do 
>this. I’ve looked at this several times and each time my head wants to 
>explode. 
>> 
>> Getting it as a clean interface would definitely benefit from a rewrite as 
>> you 
>> described.
>If you are willing, perhaps this is a project we can work on together. 
>
>Regards,
>John
>>> 
>>> Regards,
>>> John


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

Re: [beagleboard] BBB Broken? SPI signal is at 1.8v

[Harvey White]

On Tue, 22 Mar 2016 05:47:19 -0700 (PDT), you wrote:

>I've been building a custom cape for a robotics project and one of the 
>chips I'm using is controlled via SPI.  I've used an oscilloscope to 
>validate that the SPI is working as expected.  However, two days ago I 
>noticed that the chip stopped responding and after scoping the SPI signal I 
>can see that the BBB is sending the SPI data pulses at 1.8v.  The SPI 
>signal is still happening... and the clock signal is still at 3.3v.  It's 
>just the SPI data line that is only peaking at 1.8v.


Had a chip (Epson S1D13781) with an SPI interface.  Had a similar
problem when sharing the SPI interface with another chip.  Bottom line
was that, unlike the standard SPI chips where the chip gets completely
off line when not selected, this chip *always* (the Epson) drives MISO
line low.

I was getting about 1.8 volts or so maximum voltage out of the
paralleled chip because it was trying to pull up a driver that was
stuck at zero.  

Not sure that you have exactly the same problem, but is the chip
you're driving somehow trying to drive this line (and shouldn't)?

Harvey

>
>So, I'm wondering if I've done something bad to my BBB or if I've somehow 
>triggered a feature that I don't know about yet.  I'm attaching a photo of 
>the oscilloscope screen that shows the issue.

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

Re: [beagleboard] Driving a Multiplexed LED matrix directly from gpio

[Harvey White]

On Mon, 21 Mar 2016 14:31:56 -0500, you wrote:

>So, let me see if I understand your idea:
>My display looks like this:
>R0 
>...
>R7 

Ah, ok, dot matrix then.
>
>Data is written to the LED drivers while power is applied to one row.
>Then, new data is written and power is applied to the next row, etc.
>
>"I'd be tempted to do the following approach:  Divide the scan time
>into one slot per digit plus one.  Use that time to allow synchronized
>refresh to the display itself."
>
>When you say "digit", I assume you are thinking in terms of a multiplexed
>7-segment readout style display, which in my case would be the same thing
>as a row.  My driver operates on one row at a time before going to sleep.
>Are you suggesting that I scan through all 8 rows and then have a special
>9th "row" time where I do things like the memcpy?  This would be pretty
>close to a VSYNC idea, right?  I suppose that this 9th "row" wouldn't have
>to wait a full row time, but could schedule the next row sooner.  Hmm
>

Exactly, VSync or Hsync depending on what analogy you want.  In this
case, Vsync would be right.

If you're doing an operating system, then your timing is really
generated by interrupts, so I'd be using a relatively high priority
hardware interrupt from a timer here, or if you want to do an
operating system, then just give the remaining time back to the OS so
it can pick the next task.  No need to chew up one tick period.

In my OS, tasks suspended or delayed check the time (or semaphore) or
yield back the time, then the OS simply looks for the next active
task.



>You are totally right about MCUs and burning the LEDs.  This particular
>display is safe because the LEDs are not being over-driven.  Your idea
>about a CPLD is a good one.  I've never used them, but have know about
>them.  I found this XC2C32A for $1.8USD.  I will probably try this out at
>some point just for educational purposes :)

You would want the Xilinx free version of their web support (ISE),
which works fine those chips.  You'll need to find the USB programming
cable as well, I got mine from Amazon.

There are times when it's nice to be able to throw hardware at a
problem.  You have the driver done well enough, but IIRC, there are
some subsystems out there that do this.  A simple Atmel Mega processor
would work well for this, if you wanted.  

The nice thing about the XC2C32A and the Xc2C64A is that they have
exactly the same footprint.  Once you get to 128 or 256 cells, you go
to a TQFP-100 package.  

I'd recommend VHDL (simply because I like it) for the design language.
Remember that in VHDL you do not have to design components like chips,
but you can tell the chip "I want a divide by 37 counter" by
explaining how it counts, and then let the program built it.  This
makes it an easier design process than designing the counter with
logic by itself.

Harvey


>
>http://www.digikey.com/product-detail/en/xilinx-inc/XC2C32A-6VQG44I/122-1704-ND/1952030
>
>--David
>
>
>On Mon, Mar 21, 2016 at 12:28 PM, Harvey White 
>wrote:
>
>> On Mon, 21 Mar 2016 11:16:49 -0500, you wrote:
>>
>> >Hmm... I'm using UCN5821 driver chips from Allegro.  They do indeed have a
>> >hardware latch (strobe) which latches the received serial data from the
>> >internal shift register to the outputs.
>> >
>> >My write algorithm is (per row):
>> >1> set_current_state(TASK_RUNNING)
>>
>> For state 2, I'd be tempted to do a non-interruptible write to the
>> display memory (or protect it by a semaphore).  You want to interlock
>> the process so that you have a safe zone to write new data to the
>> memory.
>> >2> If new data is ready in RAM, memcpy it to the real display buffer in
>> RAM.
>>
>> This should not cause a problem unless the data changes somehow.
>> >3> Serially shift out next row data in the background, but do not latch
>> yet
>> >(background)
>>
>> This may be too fast for you to see, and you don't want it slow.
>>
>> >4> Blank the display - This is not actually working right now.  I never
>> see
>> >the blank line move. Hmm
>>
>> I'm assuming you have the data for the new row in the buffer, of
>> course,
>>
>> >5> Adjust the multiplexed row select pins to the next row (A2...A0)
>> >6> Latch the data already in the serial buffers
>>
>> Problem with blanking and unblanking the whole display could cause
>> flicker.
>> >7> Unblank the display
>> >8> set_current_state(TASK_INTERRUPTIBLE)
>> >9> usleep until time to update next row
>> >
>> >I 

Re: [beagleboard] Driving a Multiplexed LED matrix directly from gpio

[Harvey White]

On Mon, 21 Mar 2016 11:16:49 -0500, you wrote:

>Hmm... I'm using UCN5821 driver chips from Allegro.  They do indeed have a
>hardware latch (strobe) which latches the received serial data from the
>internal shift register to the outputs.
>
>My write algorithm is (per row):
>1> set_current_state(TASK_RUNNING)

For state 2, I'd be tempted to do a non-interruptible write to the
display memory (or protect it by a semaphore).  You want to interlock
the process so that you have a safe zone to write new data to the
memory.
>2> If new data is ready in RAM, memcpy it to the real display buffer in RAM.

This should not cause a problem unless the data changes somehow.
>3> Serially shift out next row data in the background, but do not latch yet
>(background)

This may be too fast for you to see, and you don't want it slow.

>4> Blank the display - This is not actually working right now.  I never see
>the blank line move. Hmm

I'm assuming you have the data for the new row in the buffer, of
course,

>5> Adjust the multiplexed row select pins to the next row (A2...A0)
>6> Latch the data already in the serial buffers

Problem with blanking and unblanking the whole display could cause
flicker.
>7> Unblank the display
>8> set_current_state(TASK_INTERRUPTIBLE)
>9> usleep until time to update next row
>
>I wanted to spend a little time as possible with the LEDs off, which is why
>I'm shifting data while the LEDs are still showing the current row data.

That shouldn't be a problem at all, the chip is designed for it.

>Using this technique, I've seen ghosting issues when a mcu is very fast as
>the drivers themselves need a little time to switch the state of their
>outputs, and also the high-side switching power transistors sometimes need
>some time to fully turn off.  I don't think that's what I'm seeing here
>though.

Let's assume that it is a problem, so you can fix that.
>
>The display artifacts that I see look like stuttering on the display when
>the processor gets busy.  I suspect that this is due to inconsistent usleep
>times (Linux isn't an RTOS) but I'm still trying to catch it with my logic
>analyzer.
>

I've had similar task interlocking problems with an RTOS, but I'd
suggest a slightly different approach.

>My basic question is this: Does the Linux kernel "usually" do this kind of
>bit-banged driver for other things (I2C, video, framebuffers, audio, etc.)
>or does it "usually" pass these tasks off to hardware peripherals?  The
>question behind the question is: Am I doing this the "usual" way or am I
>trying something very specialized.

Not an expert on Linux at all, but it depends on the data rates, and
whether or not there's hardware available to do it.  

>
>My goal is to look into the framebuffer devices and see if I can learn
>anything there, but kernel programming is very new to me.

Kernel programming (for microprocessors) is not all that bad, but
there are things you probably don't think of when writing kernel level
drivers and code.

1) everything is asynchronous
2) this can be inconvenient
3) lots of mechanisms exist to keep this from happening

I'd be tempted to do the following approach:  Divide the scan time
into one slot per digit plus one.  Use that time to allow synchronized
refresh to the display itself.  You may need to limit the on time
depending on your sink current (per driver's data sheet).

Assuming you use a semaphore, then while actively scanning digits, the
scanning process "owns" it.  During the update time, the scanning
process gives it back.  The update process can grab that, then can
update all the ram buffers that the scanning process uses.  The update
process then gives back the semaphore and the scanning process can
grab it again during the next scan time.  Result: display does all RAM
updates while blanked.

Now for the scan itself.  Assuming the scan time has just happened,
you may want to disable task switching.  shift in the new data, switch
the row drivers off, then latch the column data, then enable the new
row drivers.  Since darlingtons are slow, I'd be looking at the
driving waveforms for the darlington outputs to the display for any
overlap.  Shouldn't be much, though, if any.  Some software delays of
a few microseconds may be needed.  At this point, enable task
switching for the OS and you're in good shape.

The problem with multiplexed displays run directly by a microprocessor
is debugging during the scan cycle, where the average display current
can exceed the steady state limits for the display.  I'd have been
tempted to put in a small CPLD which appears as external registers to
the processor, and then allow the hardware to do all the work.  Xilinx
coolrunner II 32 or 64 ce

Re: [beagleboard] Driving a Multiplexed LED matrix directly from gpio

[Harvey White]

On Mon, 21 Mar 2016 01:20:34 -0500, you wrote:

I've often seen artifacts in LED displays where the write to the
display process (which should be amazingly short for each digit) is
interrupted.  You might be seeing some differences in digit brightness
as well.

Once you have the pattern in Ram, ready to be written, you would
ideally update right at the beginning of each scan for each digit. You
want to make sure that the pattern is not updated during the active
strobe to display process as well.  (I'm assuming that there's a
hardware latch in there that you write, and you're not depending on
the output pins to be constant, that strobe to activate the display is
also a latch).  This approach would minimize the critical time where
the display data cannot be interfered with.  This would ideally be in
the microsecond range (i.e. turn off previous strobe, load next data,
turn on this strobe).  That part of the code cannot be interrupted and
should ideally protected by turning interrupts off during those few
instructions. 

So the first question to ask is "what's going on with the strobes and
data?"

Harvey



>Ok, I posted the full source code here:
>https://github.com/davidgood1/ledmsgchar
>
>I'm not sure that userspace has much to do with what I'm seeing right now.
>I'm using a kthread that runs until a flag is set indicating that there is
>a new buffer of data ready from user space and my task (update_row) copies
>the buffer, so no one should be waiting on slow user space operations, but
>maybe there's something I don't see.
>
>I didn't know if I was getting interrupted in the memcpy call in
>update_row, so I am going to try to copy the buffer by rows one call at a
>time rather than copy the whole buffer at once.
>
>Also, I notice that I see visual artifacts whenever anything else is going
>on, such as ssh, typing on the terminal, etc.  The CPU usage is ~3% using
>the timing in the file right now.  BTW, the update_row task regulates its
>timing by calling usleep_range() which is supposed to be backed by high
>resolution timers.  I am using the same number on the upper and lower
>bounds to try and force stricter timing and because when I did +/- 10% you
>could definitely see more visual artifacts.
>
>Also, you will notice that the strobe pin is toggled high and then
>immediately low, which I've measured to be about 2us.  So, that seems to be
>the best the gpio interface can do.
>
>Thanks!
>
>--David
>
>On Sun, Mar 20, 2016 at 11:03 PM, William Hermans  wrote:
>
>> OK so yes, seeing your code would help us understand what you're
>> bottleneck but I've a pretty good idea why you're LCD matrix refresh is so
>> slow. It has to do with userspace communicating with kernel space, and
>> you're either invoking some system API calls ( which are notoriously slow
>> ), or you're copying data from userspace to kernel space, which again is
>> slow.
>>
>> The reason I said to show us some code above however is that I think it
>> *should* be possible to use /dev/mem/ + mmap() to access whatever you're
>> controlling. Using mmap() in this manner gives you no userspace to kernel
>> overheard . . . but again I need to see some relevant code to give you a
>> better idea how that might work.
>>
>> On Sun, Mar 20, 2016 at 8:58 PM, William Hermans 
>> wrote:
>>
>>> Show us some code.
>>>
>>> On Sun, Mar 20, 2016 at 6:28 PM, David Good 
>>> wrote:
>>>
 Hi All,

 I've been experimenting with embedded linux and matrixed LED displays.
 I started on a Raspberry pi user space program, but could see visual
 artifacts on the display due to inconsistent timing of my sleep command.
 So, I figured that moving the basic row scanning into the kernel would help
 out.  After failing to get the right kernel headers for the pi, I switched
 to a BeagleBone White.  I've now got a working character device LKM which
 takes new images by writing ASCII formatted hex strings to the device in
 /dev.  The performance is pretty good, but not great.  I still see visible
 artifacts, but am playing with things.

 My basic question is this: I know that Linux is not a RTOS, so timing
 will never be guaranteed, yet linux does a lot of things very quickly
 (video, audio, i2c, etc).  My driver is bit-banging a spi like stream over
 8 rows at a rate of ~3ms per row (333Hz row scanning or ~41Hz per complete
 frame) and is really struggling.  How does linux usually get large smooth
 video at over 60FPS while doing other things???  Is it simply taking
 advantage of special hardware resources?

 The obvious solution for this display is to use a little 8051 or M0
 microcontroller (or PRU!) and let the Bone feed it over uart or something,
 but I really thought I could do better with the LKM.

 Am I just doing something totally wrong?  Any other ideas?

 Thanks!

 --David

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 Y

Re: [beagleboard] Terminal Block Solutions for BeagleBone Black IO?

[Harvey White]

On Sat, 19 Mar 2016 12:24:12 -0700 (PDT), you wrote:

>Hey guys,
>
>I'm currently designing an automation control system for my aeroponic 
>greenhouse and would like to use the BeagleBone Black as the brain.  I 
>would like all wiring to the BBB to be done using terminal blocks.  The 
>Arduino Mega has a shield that breaks out all GPIO pins to terminal block 
> connectors and I would love to find the same thing for the BBB.  Do you 
>know if this exists?  Google hasn't really turned anything up so I'm 
>doubtful.


>
>How would I make one myself?  

If you can't find one that's commercial, then you design your own if
you can do hardware.  You need to consider which pins can do what, how
you want them buffered, whether or not they're inputs/outputs/or
inout.  How much current you want them to drive and at what voltages.
You also need to consider the BBB's boot sequence to avoid using any
pins involved in that until the sequence is done.  You also need the
configuration EEPROM and that needs to be set up properly.

All of these are steps.

A board the size of the BBB would be roughly 37 us dollars at Oshpark,
you'd have to be able to submit them an eagle layout or gerbers.

>What alternatives are there?  I created a 
>wire harness that fits into the P8 and P9 headers but it's not an elegant 
>solution. 

Then all you need is a breakout if you've considered all these other
matters.

I'd be tempted to take a 46 pin ribbon connector and wire it to each
header, then patch that over to whatever breakout board you want,
which could be individual pins.

Harvey

>
>I've seen others use the Arduino Mega with the terminal block shield as the 
>brain for various greenhouse automation projects but I want to utilize the 
>BBB as it has a more appropriate amount of IO and processing power.
>
>Thoughts?
>
>Thank you.

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

Re: [beagleboard] Re: BBG fried. Hint needed to undestand why.

[Harvey White]

On Fri, 11 Mar 2016 09:29:07 -0600, you wrote:

>I would not recommend shorting outputs of two processor together, something
>might get fried.

Exactly right, the output drivers will likely overheat and perhaps be
damaged when one chip is outputting a different state than the other.

In this case, it was a single output driving two inputs.  With
properly connected grounds, there shouldn't be a problem with multiply
connected outputs.

However, the question may be one of voltages.  The maximum voltage
input to the processor is 3.3 volts, and if driven by a 5.0 volt
source can certainly damage the processor.

Paranoid design would have a buffer (running from the processor's VCC)
connected to the real world, input to the real world, output to the
processor.  At the other end (driving end) you use another buffer to
drive the line, both must be either inverting or non-inverting.  For
each additional input to another processor, use another buffer.

If the processors use different supply voltages, then you would want a
circuit to translate the voltage levels.  There are chips that are
designed to do that.

I use a similar idea when connecting I2C driven systems (PCA9517 works
well).  

RS-232 drivers work the same way, and in fact, would be very tolerant
of voltage level differences.  I'd suggest a MAX232 style chip.  The
outputs of the chip are +/- 9 volts, so absolutely cannot be connected
directly to a processor.

Harvey


>
>Gerald
>
>On Fri, Mar 11, 2016 at 9:27 AM, Jordi Segura  wrote:
>
>> Related to my unanswered problem below, main point I want to know is:
>>
>> Is it safe to connect directly the same Tx external signal simultaneously
>> to a couple of BBs ?
>>
>> Cheers,
>> Jordi
>>
>> El dilluns, 7 març de 2016 0:11:32 UTC+1, Jordi Segura va escriure:
>>>
>>> My BBGreen got fried (when I power it up it just dims once the power led
>>> and that's all it does).
>>>
>>>
>>> Can someone explain me what I did wrong so it won't happen to me or
>>> others again?
>>>
>>>
>>> Explanation of what I did: The BBG died after several days working 24/7,
>>> powered up from a power supply 5V 2A, with an 3G usb dongle connected on
>>> it, and (maybe that's my fault ...) I connected the Tx output of another
>>> microcontroller to one Rx input of the BBG but also to one Rx input of a
>>> BBB (I had both the BBG and the BBB receiving the same Tx signal from a
>>> third micro)
>>> The same power supply was powering both systems (BBG and BBB) and I also
>>> interconnected GNDs. The third micro sending the Tx signal was powered from
>>> the BBB. BBB is working well so far.
>>>
>>>
>>> Cheers.
>>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
>-- 
>Gerald
>
>ger...@beagleboard.org
>http://beagleboard.org/

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

Re: [beagleboard] Custom Power Supply

[Harvey White]

On Sat, 20 Feb 2016 11:02:50 -0800, you wrote:

>I will take a look at SMPS circuits. i would need to design this because this 
>is part of my senior project. I was just concerned about supplying different 
>voltage values to sensors solenoids and motors, plus 3 BBBs. 

Suggest to your professor that it is often more reasonable to buy a
pre-made wheel than to invent the wheel along with the new engine for
the car (which is really your project).  

You will find that the use and specification of power modules is often
an "off the shelf" item in industry.  Those that don't avail
themselves of the design tools at TI, and use a reference design with
a "designer" package.  This then devolves the power supply into "lay
out the board, put on the chips."


>
>I have read online that an SMPS is not ideal for circuits that are dealing 
>with radio frequency. our project relies telemetry data that may be sent by 
>radio. im not sure how much of an effect the power supply would have.

Think that there's a switching supply in your cell phone?

Harvey


>
>> On Feb 20, 2016, at 8:53 AM, Seppo Nikkilä 
>>  wrote:
>> 
>> Quality switching supplies are dirt cheap so save your time and money
>> and get one!
>> 
>>> On Sat, Feb 20, 2016 at 3:39 PM, Przemek Klosowski 
>>>  wrote:
>>> On Fri, Feb 19, 2016 at 11:03 PM, Rizalino Antonio de Guzman
>>>  wrote:
>>> > I opted for the LM317 design due to the adjustable feature, since im
>>> > supplying 3.3, 5, 12 and possibly 18V. we're controlling multiple 
>>> > solenoids,
>>> > stepper motors, various sensors and multiple BBB on one system. i was
>>> > thinking designing the p/s in a parallel manner where i have multiple 
>>> > LM317s
>>> > connected to a single source (ie. battery)
>>> 
>>> You definitely don't want to use a linear regulator on a battery.
>>> because you will waste most of the battery energy in the regulator. If
>>> your battery is 25V and the BBB supply is 5V, and you're drawing 1A,
>>> 20W is being dissipated into heat in the linear regulator, while only
>>> 5W is being used productively to run the BBB. A switching power supply
>>> is not 100% efficient, but can attain 80-90% so you will only draw
>>> 5-6W from the battery and your system will last 4-5 times longer on
>>> the initial charge.
>>> 
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google Groups 
>>> "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to beagleboard+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>> 
>> 
>> 
>> -- 
>> Developing next generation wireless audio
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

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

Re: [beagleboard] can't connect through 192.168.7.2.

[Harvey White]

On Wed, 17 Feb 2016 22:41:30 +0100, you wrote:

>Smart people believe, that not sharing knowledge will keep you smarter then
>anyone else.

Knowledge is not a zero-sum game.

Harvey


>
>
>2016-02-17 22:34 GMT+01:00 Rudie van Willigen :
>
>>  Forget it, thanks
>>
>> 2016-02-14 19:33 GMT+01:00 Rudie van Willigen :
>>
>>> can't connect through 192.168.7.2.
>>> reset doesn't help
>>> Led's:
>>> USR0 blinks fast(faster then the usual heartbeat)
>>> USR2 blinks 2x the speed of  USR0
>>>
>>> BBB 1 week old and has worked properly all the time with putty
>>> and BB.org homepage "Getting started" and VNCserver
>>> only connection is USB, no SD and original Debian-Linux OS and nothing
>>> changed
>>>
>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "BeagleBoard" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/beagleboard/Rinhtx40QEk/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> beagleboard+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

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

Re: [beagleboard] Help! ADC 'stopped working' overnight

[Harvey White]

On Tue, 16 Feb 2016 12:45:18 -0700, you wrote:

>Anyway, two possibilities here if the raw values are higher than 4095.
>
>1) Your ADC need to be calibrated. I believe there is info in the TRM on
>this, but I have yet to fully understand this process myself. So see the
>TRM for details.
>
>2) your ADC is damaged, and very likely irreversibly.

3) 4096?

If the registers are 16 bits, can the result be (by program) shifted
to be left justified or right justified?  In many microprocessors this
is possible.  If it's left justified, then > 4096 is just about
guaranteed.

Harvey


>
>On Tue, Feb 16, 2016 at 12:43 PM, William Hermans  wrote:
>
>> OK, so define "way higher". Higher than 4095 ?
>>
>> On Tue, Feb 16, 2016 at 12:26 PM, hllpc  wrote:
>>
>>> Yes I know about the conversion raw values-> real values, two days ago
>>> the raw values where in the range0-2000 as they should have been, now they
>>> are way way higher
>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google Groups
>>> "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to beagleboard+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

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

Re: [beagleboard] Re: Problem with power supply on BBB

[Harvey White]

On Mon, 14 Dec 2015 16:57:19 -0800, you wrote:

>Thanks for the advice, guys.
>
>I actually had a couple of relays attached to this without flyback diodes,
>so that may be causing voltage spikes on the 5V input line.
>
>I'll take a look at the un-loaded startup of my regulator tomorrow and see
>how it looks.
>
>The regulator portion of the schematic is:
>[image: Inline image 2]

The regulator portion looks more or less standard, depending on the
value of the capacitors and how the ground currents run.

Not having flyback diodes puts lovely spikes on the lines, so I'd add
these as soon as possible unless your relays have them (best is across
the relays in reverse polarity, of course) or the transistors have
them.  However, the transistors having them keeps the transistor
protected... but where does all that energy from the relay coil go?

Harvey

>
>Best,
>Morgan
>
>On Fri, Dec 11, 2015 at 9:15 PM, Graham  wrote:
>
>> Morgan:
>>
>> It is likely a transient voltage spike that can come out of your switcher.
>>
>> The BBB does not turn on it's power supply until it thinks the incoming
>> voltage is stable, which means that your 12V to 5V switcher is starting up
>> without a load.  If it overshoots badly in that start-up period, it could
>> kill something. Or if it overshoots when the BBB load is finally applied
>>
>> I would start by repetitively starting up your 12V to 5V switcher, without
>> a load on it, and watching what the output does on a storage (memory)
>> oscilloscope, so that you can see the worst case startup condition. Then
>> repetitively add a load equal to the BBB and all its input capacitance, and
>> watch what happens.
>>
>> What were you controlling with the BBB/Cape?  Things like relays or
>> stepper motors generate inductive spikes that can easily kill
>> semiconductors, if the spikes are not managed correctly.
>>
>> --- Graham
>>
>> ==
>>
>>
>> On Friday, December 11, 2015 at 7:14:38 PM UTC-6, Morgan Redfield wrote:
>>>
>>> I think I managed to burn out the TPS65217 on the BBB using a custom cape
>>> that I designed. The cape has a DCDC switching regulator that I'm using to
>>> drop a 12V supply down to 5V for the beagle bone. I have the 5V from that
>>> switching regulator connected to pins P9.6 and P9.5.
>>>
>>> I've now had two BBBs fail while powering them from the board. I left
>>> both on for a couple of days, and at some point the BBB just died. After
>>> that, the BBB don't boot at all, even with the cape unplugged.
>>>
>>> When I apply 5V from a benchtop supply to P9.6, I only see 1.1V on P9.7
>>> (system 5V).
>>> If I hit the power button (S3), then the voltage on P9.7 will jump up to
>>> around 2.5V before falling back to 1.1V over around 20s.
>>>
>>> I'm not sure what's going on here, since the power supply I'm using looks
>>> pretty clean to me. It's an average of 5.14V with max 150mVpp noise. It's
>>> rated to 2A current draw. Switching frequency is 150kHz.
>>>
>>> Does anyone have any idea what might be happening here? Any ideas about
>>> what I should try next?
>>>
>>> Thanks,
>>> Morgan
>>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/beagleboard/hpHmvGR3cGU/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>

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

Re: [beagleboard] UIO and Pruss

[Harvey White]

On Sun, 13 Dec 2015 17:22:43 -0700, you wrote:

>I actually think remoteproc / rpmsg is usefu for multi core systems. Say a
>dual core ARM processor where one core is running Linux, and the other is
>running bare metal for  deterministic purpose. I am however still
>unconvinced how it is useful when you have multiple cores on die that are
>not all application based processors. Such as the PRUs, or on die M4 / IPU
>on the X15's processor. DSP . . . yeah I do not know enough about those to
>make that call.

Atmel has made a processor (Xmega E series) that has some programmable
logic built in.  The idea is that by turning over some simple tasks to
the hardware, you get very low latency, very fast response times, and
do not have to deal with the time penalties imposed by an operating
system.  The rest of the Xmega chips already have an event system that
with DMA, could take the A/D outputs and automatically put them in an
array for you, giving you a periodic interrupt when done.  All this
without the processor doing anything other than a setup.

Even running bare metal, it is likely that a hardware system (such as
the Xmega or the PRU) will give you faster response times and higher
data rates.

Now tools to use that, well, that's the rub.  Currently, for some
designs, I would have to rely on an FPGA with hardwired logic for fast
data acquisition and (some) processing.

DSP?  Think a processor with extra instructions for multiply/divide
and such that runs fast enough to do FFT (Fast Fourier Transforms) on
a waveform.  Those will result in a spectrum produced from the data.
You can do things with that spectrum (filtering, for instance) that
you cannot easily do with the waveform in the time (waveform on an
oscilloscope) domain.

Harvey


>
>On Sun, Dec 13, 2015 at 5:05 PM, William Hermans  wrote:
>
>> It's a BS example because it does not illustrate how remoteproc and rpmsg
>> are useful. It also does not illustrate how to access the hardware modules
>> through this technology. Here . . .
>>
>> Something useful -> https://github.com/boxysean/beaglebone-DMX
>> Something else useful -> https://github.com/pgmmpk/beaglebone_pru_adc
>> Yet another something useful ->
>> https://github.com/abhishek-kakkar/BeagleLogic
>>
>> All these have been in the wild for a long time. They work, and the
>> hardware / software paradigm is well known, and explained many times all
>> over the web.
>>
>> Show us how to blink USR0, then explain how that works. Or even show us
>> how to use any on die hardware module, or something that can be "plugged
>> in" to demonstrate an immediate result. Without having to hook up external
>> electronics / circuits.
>>
>> That is why uio_pruss is better than remoteproc. People understand it, or
>> if they do not, they can read about it, and grasp the concept fairly
>> quickly. Because there is a lot of good documentation, and many, many good
>> examples that cover just about any on die hardware module.
>>
>> Anyway, I think the burden is actually on you, to explain to me, and
>> others why remoteproc / rpmsg is any good and should be used. Since,
>> uio_pruss has been around since 2011 or earlier, and is perfectly
>> functional. With that said, regurgitating sentiments such as "bla blah blah
>> has adopted x.y.z" is going to do you no good. We do not care who as
>> adopted what, and why. We want to know why remoteproc, and rpmsg is worth
>> out time investment. Especially considering we already have a large time
>> investment with uio_pruss.
>>
>> On Sun, Dec 13, 2015 at 4:40 PM, John Syne  wrote:
>>
>>> How is that a BS example? The example shows an ARM kernel module sending
>>> a message to the PRU, which interrupts the PRU, which then copies the
>>> message from the PRU rx buffer to the PRU tx buffer, which then executes a
>>> callback on the ARM kernel module. You should be able to take that code and
>>> make it do anything you need.
>>>
>>> Regards,
>>> John
>>>
>>>
>>>
>>>
>>> On Dec 13, 2015, at 3:21 PM, William Hermans  wrote:
>>>
>>> By real world I mean a real world useful example. Not some BS spit 100
>>> "hello" messages out into dmesg.
>>>
>>> On Sun, Dec 13, 2015 at 4:19 PM, William Hermans 
>>> wrote:
>>>
 OK, so show us a real world example of rpmsg.

 On Sun, Dec 13, 2015 at 3:53 PM, John Syne  wrote:

> OK, so maybe you can explain why you think there is a difference
> between writing PRU firmware targeting PRUSS vs PRU firmware targeting
> remoteproc? The only difference is the API. You can build the firmware for
> each in the same way. The only reference to CCSV6 is the examples TI
> created for remoteproc. Someone updated those examples to build with GCC.
> So I don’t understand what you mean by forced to use “close source tools”.
> Nothing in remoteproc is closed source. All remoteproc does is load the
> firmware on the PRU and then start the code. virtio_rpmsg_bus handles the
> communications between ARM and the PRU.
>
>>

Re: [beagleboard] I2C

[Harvey White]

On Sun, 1 Nov 2015 20:17:23 -0700, you wrote:

>Yeah, thanks. I always forget about the distance factor. It's a  shame that
>I2C is so "slow" though. ~400Khz is it's max speed right ?

There's a 1.5 Mhz implementation that's out there, and I think one
that's a bit faster.  The processors probably support at least 400
Khz, perhaps the 1.5 Mhz.

Consider, though, that this is not all that bad, it depends on the
message length.  4 bytes at 9 bits/byte, that's 11,000 such
messages/second (very roughly).

If you're doing high level commands, that's not bad.  Look up the
speed of wireless transfers, for instance.  Not all that much more for
the "inexpensive" methods.

Harvey

>
>On Sun, Nov 1, 2015 at 8:00 PM, Harvey White  wrote:
>
>> On Sun, 1 Nov 2015 19:32:56 -0700, you wrote:
>>
>> >By the way, that's an honest to god question. I see people use I2C all the
>> >time, and I do not know why. From a software developer's perspective, I'm
>> >often in the frame of mind that "faster is better".  I kind of feel like
>> >I'm missing something though.
>>
>> Maybe.  From the hardware developer's perspective it's often a matter
>> of how much additional circuitry it takes as well and how expandable
>> it is.
>> >
>> >I do know that some parts only come in I2C, UART, or SPI. Sometimes two of
>> >these serial types, but usually not all 3. So I've always assumed, that
>> >people pick a part they like, and deal with the serial protocol as needed.
>>
>> Sometimes, yes.  Lots of times it's also a question of what do you
>> have that's implemented already.  I have system level SPI and I2C
>> implemented, so I use (more or less) what I need when I need it.
>>
>> Controlling a graphics chip...?  (Epson S1D13781)... faster is better,
>> no I2C interface at all.
>>
>> Putting a console interface on something that has a standard I2C
>> interface on it but no SPI?  I2C to UART bridge and thence to USB.
>> Inexpensive addon...
>>
>> Processor expansion memory... RAM... acts somewhat like an external
>> disk drive and *not* in program or data space  SPI.
>>
>> Thermometer, LED controller, smart keyboard, smart power supply, use
>> I2C.
>>
>> SD card, graphics chip, OLED display, TFT color display, large flash
>> memory?  SPI, even if you could use I2C.  If the distance is short
>> enough for the lines (2 inches or so), then definitely SPI.
>>
>> Harvey
>>
>>
>> >
>> >On Sun, Nov 1, 2015 at 6:18 PM, William Hermans 
>> wrote:
>> >
>> >> I am curious though. So keep in mind I'm not so much of an EE type when
>> I
>> >> ask this. But why would you use I2C over another serial communications
>> type
>> >> ? I've used SPI on the msp430's before, and know that if one were to use
>> >> SPI through the PRU's on the BBB, it would / could be amazingly fast.
>> >>
>> >> Is this just some sort of "x.y.z only comes in I2C peripheral  . . . "
>> >> sort of deal ?
>> >>
>> >> On Sun, Nov 1, 2015 at 6:13 PM, Harvey White 
>> >> wrote:
>> >>
>> >>> On Sun, 1 Nov 2015 17:55:19 -0700, you wrote:
>> >>>
>> >>> >Hi Harvey,
>> >>> >
>> >>> >Yeah, I'm honestly not interested in I2C, at least not yet. I was just
>> >>> >trying to express that I know the register in memory layout "ok" and
>> that
>> >>> >the OP was not using a driver, really.
>> >>> >
>> >>> >Thanks for the offer though.
>> >>>
>> >>>
>> >>> You're welcome.  I use it extensively, so I can at least make some of
>> >>> it work.
>> >>>
>> >>> Harvey
>> >>>
>> >>> --
>> >>> For more options, visit http://beagleboard.org/discuss
>> >>> ---
>> >>> You received this message because you are subscribed to the Google
>> Groups
>> >>> "BeagleBoard" group.
>> >>> To unsubscribe from this group and stop receiving emails from it, send
>> an
>> >>> email to beagleboard+unsubscr...@googlegroups.com.
>> >>> For more options, visit https://groups.google.com/d/optout.
>> >>>
>> >>
>> >>
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>

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

Re: [beagleboard] I2C

[Harvey White]

On Sun, 1 Nov 2015 19:32:56 -0700, you wrote:

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

Maybe.  From the hardware developer's perspective it's often a matter
of how much additional circuitry it takes as well and how expandable
it is.
>
>I do know that some parts only come in I2C, UART, or SPI. Sometimes two of
>these serial types, but usually not all 3. So I've always assumed, that
>people pick a part they like, and deal with the serial protocol as needed.

Sometimes, yes.  Lots of times it's also a question of what do you
have that's implemented already.  I have system level SPI and I2C
implemented, so I use (more or less) what I need when I need it.

Controlling a graphics chip...?  (Epson S1D13781)... faster is better,
no I2C interface at all.

Putting a console interface on something that has a standard I2C
interface on it but no SPI?  I2C to UART bridge and thence to USB.
Inexpensive addon... 

Processor expansion memory... RAM... acts somewhat like an external
disk drive and *not* in program or data space  SPI.

Thermometer, LED controller, smart keyboard, smart power supply, use
I2C.  

SD card, graphics chip, OLED display, TFT color display, large flash
memory?  SPI, even if you could use I2C.  If the distance is short
enough for the lines (2 inches or so), then definitely SPI.  

Harvey


>
>On Sun, Nov 1, 2015 at 6:18 PM, William Hermans  wrote:
>
>> I am curious though. So keep in mind I'm not so much of an EE type when I
>> ask this. But why would you use I2C over another serial communications type
>> ? I've used SPI on the msp430's before, and know that if one were to use
>> SPI through the PRU's on the BBB, it would / could be amazingly fast.
>>
>> Is this just some sort of "x.y.z only comes in I2C peripheral  . . . "
>> sort of deal ?
>>
>> On Sun, Nov 1, 2015 at 6:13 PM, Harvey White 
>> wrote:
>>
>>> On Sun, 1 Nov 2015 17:55:19 -0700, you wrote:
>>>
>>> >Hi Harvey,
>>> >
>>> >Yeah, I'm honestly not interested in I2C, at least not yet. I was just
>>> >trying to express that I know the register in memory layout "ok" and that
>>> >the OP was not using a driver, really.
>>> >
>>> >Thanks for the offer though.
>>>
>>>
>>> You're welcome.  I use it extensively, so I can at least make some of
>>> it work.
>>>
>>> Harvey
>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google Groups
>>> "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to beagleboard+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

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

Re: [beagleboard] I2C

[Harvey White]

On Sun, 1 Nov 2015 18:18:36 -0700, you wrote:

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

I2C is meant for longer distances, off board, for instance. 

It's also an addressed scheme, where everything has an address, so
items can be added easily, just don't let the streams touch... er
don't duplicate addresses.

SPI is meant for very fast communications over short distances, and
you need an individual SS line (think chip/device select) for each
thing you add.

So I2C, two lines, runs board to board.  Add additional boards as
needed without modifying hardware, just watch the addresses.

SPI, 3 lines plus an individual select line, more difficult to add
devices, you have to dedicate one I/O line per device to be added to
get anything added.  In addition, I wouldn't want to run the lines
more than a few inches.  I2C can run feet.

I2C also has a built in "are you there, did you get this" mechanism,
while SPI has less of a one.

So I use SPI for talking to SD cards, graphics controller chips, fast
add-on memory, with clock rates of about 8 Mhz.

I use I2C to talk to peripheral chips, LED controllers, other smart
functions, EEPROM, clock chips, displays, smart processors, etc.  The
idea is that the commands are reasonably short, and rather than
updating a display with the data on a per-pixel basis, I just say
"draw one of these, here".

Some functions are available in only some interfaces, but for me, I2C
was more like an ethernet situation where things can be dynamically
added as needed, so I picked that for board to board communications.

Oddly enough, one of the designs I'm working on now that has a BBB
style form factor runs SPI to the add on "cape", although it's not a
BBB cape.  I'll see how that works.

The choices in picking a communications method run down to the
following kind of questions

1) how fast is it?
2) how far can it go?
3) how complicated is it to use?
4) how complicated is it to implement?  (not the same thing)
5) how much hardware do I need to add?  (I2C, two resistors with a
built-in interface on the chip)
6) how much do I need to say on the interface?
7) is it high level or low level?  Which do I need?

Harvey



>
>On Sun, Nov 1, 2015 at 6:13 PM, Harvey White  wrote:
>
>> On Sun, 1 Nov 2015 17:55:19 -0700, you wrote:
>>
>> >Hi Harvey,
>> >
>> >Yeah, I'm honestly not interested in I2C, at least not yet. I was just
>> >trying to express that I know the register in memory layout "ok" and that
>> >the OP was not using a driver, really.
>> >
>> >Thanks for the offer though.
>>
>>
>> You're welcome.  I use it extensively, so I can at least make some of
>> it work.
>>
>> Harvey
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>

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

Re: [beagleboard] I2C

[Harvey White]

On Sun, 1 Nov 2015 17:55:19 -0700, you wrote:

>Hi Harvey,
>
>Yeah, I'm honestly not interested in I2C, at least not yet. I was just
>trying to express that I know the register in memory layout "ok" and that
>the OP was not using a driver, really.
>
>Thanks for the offer though.


You're welcome.  I use it extensively, so I can at least make some of
it work.

Harvey

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

Re: [beagleboard] Re: I2C driver by PRU

[Harvey White]

On Sun, 1 Nov 2015 17:06:02 -0700, you wrote:

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

I know I2C pretty well, and have written drivers for it, just not for
this chip.

If you wish, email me privately and we can talk should you feel the
need.

NXP has some very good tutorials in their I2C chips, try a PCA9551 or
a PCA9634 as chips that have a decent tutorial on how I2C works.

Harvey


>
>On Sun, Nov 1, 2015 at 5:01 PM, William Hermans  wrote:
>
>> Hi Micka,
>>
>> I do not think he is using and driver. When speaking of the I2C module, I
>> believe hes speaking of the physical on chip module. But this . . .
>>
>> #define I2C1_BASEC2//base registri I2C1 nella
>> tabella
>>
>> translated from Italian to English  . . . *I2C1 base registers in the
>> table  *which seems to me he is setting up the I2C hardware module
>> directly through it's registers in memory. But the other link, he pasted I
>> do not know if you saw it or not
>> http://beagleboard.org/Community/Forums/?place=msg%2Fbeagleboard%2FDAXyYJOrDIc%2FDZ8WKkRWaC0J
>> he talks about the problem being solved and he was not bringing the
>> hardware module out of reset, which is similar to how the ADC module works.
>>
>> Wish I could help you more, but I know nearly nothing about I2C. I know
>> what it is, and vaguely how it's done, but have never used I2C . . .
>>
>> On Sun, Nov 1, 2015 at 2:45 PM, Micka  wrote:
>>
>>> Hi,
>>>
>>> I'm interested by what you have done.  I want to use i2c to read analog
>>> value from a component.
>>>
>>> The first solution that I found was to bitbang the i2c. But you, you use
>>> the i2c driver which is nice.
>>>
>>> Could you give us the peace of asm code that you use to interface with
>>> the MCP23017. And if you have the c code also it would be great.
>>>
>>> ( if possible, also the part of you managed to activate the module by
>>> writing MODULEMODE field into register CM_PER_I2C1_CLKCTRL register and
>>> also the code that wait for IDLEST field to confirm that module is ready).
>>>
>>> Micka,
>>>
>>> Le dim. 19 juil. 2015 21:45, Gianfranco Rosso <
>>> gianfranco.ro...@tiscali.it> a écrit :
>>>
>>> I've also posted this in I2C topic, the solution is there:
>>>
>>>
>>> http://beagleboard.org/Community/Forums/?place=msg%2Fbeagleboard%2FDAXyYJOrDIc%2FDZ8WKkRWaC0J
>>>
>>>
>>> Il giorno lunedě 13 luglio 2015 09:49:20 UTC+2, Gianfranco Rosso ha
>>> scritto:
>>>
>>> I want to manage the I2C1 module by the PRU, in order to interface some
>>> I/O expanders (MCP23017 by Microchip).
>>> I use may own "cape" without the plug-n' play eeprom (one of the next
>>> steps will be adding management for DCAN0 and DCAN1 so i'll need these pins
>>> too...).
>>> So, at present, there are just 2 MCP23017 connected to the P9.17 and
>>> P9.18.
>>>
>>> I load the *cape-universal* into slots and then I use *configure-pin*
>>> command to set P9.17 and P9.18 as *i2c*
>>>
>>> I've started from an example into the *am335x_pru_package-master* and
>>> wrote my own C PRU loader.
>>> Very simple, it just:
>>>
>>> loads the PRU codeinit the data exhanged with the PRUstart the PRUwait
>>> for ESC key presssignal to the PRU to stopwait for the PRU stopexit.
>>>
>>>
>>> Also the assembly PRU code is simple:
>>>
>>> init I2C1 module (by writing registers PSC, SCLL, SCLH, CON)init 1st I/O
>>> expander as 16 inputs (even if at power on it's already set as input)init
>>> 2nd I/O expander as 16 outputscicle reading status of inputs from 1st
>>> expander and echoing to the outputs of 2nd expanderexit cycle and halt when
>>> receive stop flag from the loader
>>>
>>> for send and receive I2C messages I use register SA, CNT, DATA and CON.
>>>
>>> That's very simple and linear... pity, it doesn't work.
>>>
>>> *I didn't see any activity at all in P9.17 and P9.18*.
>>>
>>> The PRU code is surely running, as I add a cycle counter and show it in
>>> the loader while it's waiting for ESC keypress, and also the PRU code
>>> correctly stops at the loader command.
>>>
>>> I was expecting that the PRU code stalls if I2C bus doesn't work, as
>>> there are waiting cycles both for STOP condition or for CNT reaching zero
>>> (depending on the write or read message sending).
>>>
>>> But it seems running, and running very fast also: the cycle counter is
>>> incremented to a very fast rate (over 550 kcycles/s)  that's not compatible
>>> with the correct executing of I2C sequences (I've setted the module for
>>> 400Kbps rate... so the PRU cycle it's even faster than a single I2C bit
>>> time!).
>>>
>>> I'm surely doing something wrong, but I cant fugure what.
>>>
>>> Any idea?
>>>
>>> Suggestions?
>>>
>>> Inserisci qui il codice...
>>>
>>> .origin 0
>>> .entrypoint START
>>>
>>> #include "iic_ioexp.hp"
>>>
>>> //costanti per l'accesso al mod

Re: [beagleboard] Sainsmart LCD2004 with Beaglebone Black

[Harvey White]

On Thu, 22 Oct 2015 21:23:51 -0400, you wrote:

>Ah, if you are referring to a logic level converter, I had ordered one but
>wasn't sure if that was what I needed.  I'll read more on how to use it,
>and try that.  Thank you.

You're welcome.  However, be aware that there are several kinds of
logic level converter.

The standard variety 8T245 or 74LVC1T45  (think that the numbers are
close) are the standard LS245 type, a bidirectional driver that only
works one way at a time, where the chip has two VCC inputs.  This is
quite useful for parallel inputs/outputs where you're only
transmitting one direction at a time, and have a control line that
enables that (such as a read/write line).

The PCA9517A chip is designed specifically for I2C, and is
bidirectional without needing a control.  The SCL line is driven by
whatever is the I2C master, but the SDA line is alternately driven by
the master (at all times on writes except for the ACK bit) and the
slave (all the times the slave talks to the master except the ACK bit
from the master).   Check the I2C spec for this information.  On the
chip, leave the ENA input open, it seems to work just fine like that
(or I suppose you could pull it up to the appropriate VCC).  

On this chip, use pins 7 and 6 for the local (processor) pins, and use
pins 2 and 3 for the system (chip to chip) connections.  Use pin 8 for
the system VCC and pin 1 for the local VCC.

Pins 7 and 6 are not designed to be paralleled with other chips, and
pins 2 and 3 are designed to be connected to *other* pins 2 and 3 on
other boards, which means that the connections to pins 7 and 6 are
always local.

I2C pins sink to ground and have a resistive pullup to the supply
voltage.  However, there is no guarantee that any chip can tolerate an
input voltage greater than its power supply voltage.  Thus you need a
voltage level translator between systems with different supply
voltages.

This is how I have the chips connected, and it works properly.  Check
the data sheets (NXP) for the details and the backup information.

Harvey


>
>On Thu, Oct 22, 2015 at 9:12 PM, Harvey White 
>wrote:
>
>> On Thu, 22 Oct 2015 17:48:01 -0700 (PDT), you wrote:
>>
>> >Hello,
>> >
>> >I purchased a SainSmart LCD2004, which I believe is a hd44780 LCD with an
>> >i2c module pre-soldered to the back of the board.  This board is designed
>> >for an Arduino, but I wanted to try using it on my Beaglebone.  Is this
>> >doomed to fail?
>>
>> Not necessarily so.  It depends on what the I2C module is.  You will
>> need to know what the I2C commands to the module happen to be, that is
>> one thing.  The known commands for the 44780 are likely to be easy to
>> get.  The module I don't know anything about.
>>
>> >
>> >Following a few online guides, I have the SDA and SDL pins, as well as the
>> >5v and ground pins attached (with a resistor).  I've tried endless python
>> >scripts and libraries, being careful to configure each to use the
>> addresses
>> >that i2cdetect is showing.  Upon running some of the scripts, the LCD
>> >actually blinks.  I tried to go the LCDd route, but no luck with that
>> >either.  The LCD backlight goes on, but no text.
>>
>> The backlight goes on most likely because there's 5 volts on the
>> display.  The uninitialized display shows a sequence of square blocks
>> on line 1 (and nothing on line 2).
>>
>> The SDA and SCL pins need to go to 5 volts through a resistor (each
>> line independently).  The resistor values are generally between about
>> 4.7K and 10K.
>>
>> What I don't know (and you need to check) is whether or not the BBB's
>> I2C system runs from 3.3 volts or 5.0 volts.  If 5.0 volts AND the LCD
>> display I2C runs from 5 volts, then you can connect them directly.  If
>> the LCD and BBB run on 3.3 volts (for the interface), then they can be
>> connected directly.  IF they are not the same, then you need a chip
>> (I'd recommend the PCA9517) to connect the two.  This chip allows
>> dealing with different supply voltages (such as 3.3 and 5.0).
>>
>> I use this chip in systems I design.  Typically, the processor I/O is
>> at 3.3 volts (even the I2C pins), and the system level is 5.0 volts.
>> Thus, I need a chip on each board to the system interface.  For a 5.0
>> volt system, I still use the chip because it provides isolation
>> (there's a limit on current, cable length (related to capacitive
>> loading) and capacitive loading on each driver; check the specs.)
>>
>> You might want to look at these issues, they're reasonably easy to
>> fix.
>>
>> Harvey
>>
>>
>> >
>&g

Re: [beagleboard] Sainsmart LCD2004 with Beaglebone Black

[Harvey White]

On Thu, 22 Oct 2015 17:48:01 -0700 (PDT), you wrote:

>Hello,
>
>I purchased a SainSmart LCD2004, which I believe is a hd44780 LCD with an 
>i2c module pre-soldered to the back of the board.  This board is designed 
>for an Arduino, but I wanted to try using it on my Beaglebone.  Is this 
>doomed to fail?

Not necessarily so.  It depends on what the I2C module is.  You will
need to know what the I2C commands to the module happen to be, that is
one thing.  The known commands for the 44780 are likely to be easy to
get.  The module I don't know anything about.

>
>Following a few online guides, I have the SDA and SDL pins, as well as the 
>5v and ground pins attached (with a resistor).  I've tried endless python 
>scripts and libraries, being careful to configure each to use the addresses 
>that i2cdetect is showing.  Upon running some of the scripts, the LCD 
>actually blinks.  I tried to go the LCDd route, but no luck with that 
>either.  The LCD backlight goes on, but no text.

The backlight goes on most likely because there's 5 volts on the
display.  The uninitialized display shows a sequence of square blocks
on line 1 (and nothing on line 2).

The SDA and SCL pins need to go to 5 volts through a resistor (each
line independently).  The resistor values are generally between about
4.7K and 10K.

What I don't know (and you need to check) is whether or not the BBB's
I2C system runs from 3.3 volts or 5.0 volts.  If 5.0 volts AND the LCD
display I2C runs from 5 volts, then you can connect them directly.  If
the LCD and BBB run on 3.3 volts (for the interface), then they can be
connected directly.  IF they are not the same, then you need a chip
(I'd recommend the PCA9517) to connect the two.  This chip allows
dealing with different supply voltages (such as 3.3 and 5.0).

I use this chip in systems I design.  Typically, the processor I/O is
at 3.3 volts (even the I2C pins), and the system level is 5.0 volts.
Thus, I need a chip on each board to the system interface.  For a 5.0
volt system, I still use the chip because it provides isolation
(there's a limit on current, cable length (related to capacitive
loading) and capacitive loading on each driver; check the specs.)

You might want to look at these issues, they're reasonably easy to
fix.

Harvey


>
>If I'm in the wrong Forum, or missing something simple, let me know.   I 
>can expand on anything that I've tried.
>
>A little background - I'm a competent Linux user, so running tools and 
>banging together scripts is the easy part for me.  The connecting the 
>electronic components has been the learning part of this journey.
>
>Many 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: 5V Power without use of an external Transistor

[Harvey White]

On Fri, 9 Oct 2015 12:58:10 -0700 (PDT), you wrote:

> 
>
>Thanks, so it basically seems there is not a way of getting a pulse of 5V 
>without using a transistor.  Oh well.

The I/O on a 3.3 volt processor goes between 0 and 3.3 volts.  To get
any other (larger) voltage, you'll need at least a transistor.

Harvey


>
>On Friday, October 9, 2015 at 2:44:38 PM UTC-4, TJF wrote:
>>
>> The CPU on BBB is powered by 3V3. This means all digital output (GPIO, 
>> PWM, ...) will be at 3V3 as well.
>>
>> In order to get a 5V pulse train, you'll need an external driver. I use 
>> darlington arrays for that purpose, like ULN2804 
>> 
>> .
>>
>> BR
>>

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

Re: [beagleboard] 8 ADC input @20 KHz

[Harvey White]

On Thu, 8 Oct 2015 19:41:33 -0700, you wrote:

>@ Harvey,
>
>So, buy a RevC, and join in on the fun :)

I have one already  

It's on my list of things to do.  

It has to run either linux or android, and I need the whole spectrum
of I2C available on one interface, it's existing hardware.

Still need to get that stuff up and running completely, but the BBB
(or equivalent) will be a high level controller (over I2C) running
custom data acquisition hardware.

Harvey



>
>On Thu, Oct 8, 2015 at 5:56 PM, Harvey White  wrote:
>
>> On Thu, 8 Oct 2015 14:57:28 -0700, you wrote:
>>
>> >>
>> >> *no longer returns any value or doesn't return a value you expect?  You*
>> >> * should be able to read the memory regardless.  What it says is
>> another*
>> >> * matter.*
>> >
>> >
>> >devmem2 returns a NULL value. Meaning, the completes the procedure, but
>> >returns a NULL value. Which is because the ADC module is in effect -
>> >Disabled. I'm convinced it works.
>>
>> Ok, I'm puzzled why you'd get a null value.  To me, says that an
>> allocation failed, or memory is not there.
>>
>> If I were writing this, it would mean that the driver could not be
>> found, or that the memory address is invalid...
>>
>> I probably don't understand that at all, just guessing how it might
>> work.
>>
>>
>> >
>> >*Just offhand, I'd suggest not messing with the hardware directly, but*
>> >> * using the system drivers unless you want to write system level*
>> >> * drivers.*
>> >>
>> >
>> >The whole idea, at least for me( and many others ) is to use the hardware
>> >without drivers that can unnecessarily add application execution overhead.
>> >Which is exactly how the PRU's control the ADC hardware in many examples
>> >I've seen. Some might consider this "the non Linux "way" ", But I'd argue
>> >that doing things the way *you*(generic term) want, is the true Linux way.
>> >i.e. Flexibility.
>>
>> OK, better system drivers, I can see that.
>>
>> Generally you get lots of different levels in an operating system
>>
>> Hardware -> driver -> medium level interface -> system level interface
>> -> application
>>
>> Hardware -> driver -> medium level interface -> high level interface->
>> system level interface -> application
>>
>> You get either.  Idea is that the driver messes with the hardware, and
>> the medium level interface does sequences, data fetches from the
>> driver (knows how to make the driver work) and provides resources to
>> the system level interface...
>>
>> System level interface is optional, but allows you to treat the ADC
>> (for instance) as a subsystem, while the medium level interface has a
>> bunch of device independent primitives (set resolution, make
>> measurement, set reference, etc)
>>
>> System stuff would be (make list of measurements using port/adc,
>> return scaled values, make averaged measurements, etc)  Depends on
>> how you treat a device.
>>
>> Graphics GUI commands can go to a system driver which commands remote
>> displays or on board hardware.  On board hardware driver selects
>> graphics hardware.  Driver makes dots appear
>>
>> That kind of thing.
>>
>> I think what you are doing is wanting to roll the hardware driver and
>> the medium level together, and then let the application do the work.
>>
>> I'm thinking that this has more to do with directly writing the
>> hardware driver, providing hardware agnostic routines to the
>> application program and letting it go at that.
>>
>> In a sense, this has nothing to do with linux, except the mechanism
>> for getting at the memory/hardware and such system things as fifos,
>> queues, semaphores and the like.
>>
>>
>>
>>
>>
>> >
>> >*Guess there isn't a linux ADC driver for this chip.  I'm used to*
>> >
>> >* writing bare metal drivers myself, but not for linux at all.*
>> >
>> >
>> >There is a Linux driver for the on chip ADC, but it is "slow". Well, to be
>> >100% accurate I suppose I should say that technically, there is a iio
>> >driver, or capability for a iio driver to have better performance. It also
>> >uses mmap(), but there may not be such a driver for this specific ADC. I
>> >honestly have no looked into that *yet*. To be honest( again )

Re: [beagleboard] 8 ADC input @20 KHz

[Harvey White]

n stuff I *think* I understand. Which is to
>say, I understand a small portion of it all, but still need more
>understanding. Which is why I want to find a good read on the subject.

I'd be happy to help if I knew a good linux reference that was slanted
towards the ARM architecture.  Don't, though.

>
>In the end it's all about the learning - For me. Which it does indeed seem
>I have a lot to keep me busy for a good long while.

Know that feeling.

Harvey

>
>On Thu, Oct 8, 2015 at 2:30 PM, Rathin Dholakia 
>wrote:
>
>> I m just sitting here astonished & awed by the discussion!!
>> Congratulations on success..! :-)
>>
>> Take away from this discussion for me is that, I have a long way to go!
>>
>> Rathin
>>
>> On Friday, October 9, 2015, William Hermans  wrote:
>>
>>> *Well, I'd guess something like this:  the FIFO data is stored on the*
>>>> * heap, which is malloc'd.  You need the pointers as needed to figure*
>>>> * out where it is.   Standard pointers to head and tail of the ring*
>>>> * buffer will be stored locally, unless someone did a pointer to the*
>>>> * data structure of the FIFO (but not the data itself).  I'm doing that*
>>>> * in an OS that I'm writing.  The only advantage here is that heap*
>>>> * memory (or managed memory) is managed by the OS, and should not belong*
>>>> * to any one task.  (you could argue that, but it's more convenient this*
>>>> * way for me.)*
>>>>
>>>
>>> I can not say it any better than this:
>>> http://linux.about.com/library/cmd/blcmdl4_mem.htm So basically, when
>>> you mmap() /dev/mem/ you get a pointer to any system address you point it
>>> to. In this case, for me, the physical address space assigned by the
>>> kernel, for the peripherals. This is what I *think* is happening. I'm still
>>> learning how this works, by starting off with examples by others.
>>>
>>> So what I've figured out already is that the code I'm using, and have
>>> partly written myself. Gives me a pointer to the ADC registers - and more.
>>> I know it works, as I can enable the ADC, take readings with my executable,
>>> or devmem2, the values are very likely accurate for reason mentioned
>>> previously. Then I've written code myself based on information I've read
>>> from the TRM to disable the ADC clock when done. After which devemem2 no
>>> longer returns a value from this area of memory - Which is the memory
>>> location for the first FIFO ( FIFO0 ) Of the ADC.
>>>
>>> What I would really like to find is a good comprehensive guide, document,
>>> or something about this whole process. I have not really found this yet,
>>> and maybe I've been looking in the wrong places ? Stuff like POSIX shared
>>> memory, etc, may be considered advanced topics in programming. But I'd
>>> personally consider the topic of /dev/mem/ far more advanced. Certainly, it
>>> can be "dangerous" to start poking around in random memory locations on a
>>> live system. Which is why in this case, I started off experimenting with
>>> code written by others.
>>>
>>> Being able to write code from scratch to disable the ADC when done with
>>> it, has boosted my confidence *some*. But I know I have a lot to learn
>>> about this topic, and at least the Linux kernel memory addressing schema.
>>>
>>> On Thu, Oct 8, 2015 at 12:18 PM, Harvey White 
>>> wrote:
>>>
>>>> On Wed, 7 Oct 2015 19:18:02 -0700, you wrote:
>>>>
>>>> >Harvey,
>>>> >
>>>> >Actually, you're right. the previously mentioned FIFO is actually 100h
>>>> in
>>>> >size, my bad. Too much on my brain here. What I described above is
>>>> actually
>>>> >what each 32bit field *in* that buffer *is*. hah !
>>>>
>>>> Good, that means that there *is* a FIFO.
>>>> >
>>>> >Anyway, I make it a habit to jump into things like this because they're
>>>> >hard to do. So I often find myself struggling with details like this.
>>>> But
>>>> >in this case, not only am I "fighting" the hardware. I'm also fighting
>>>> my
>>>> >ignorance of how Linux stores this information in memory.
>>>> >
>>>>
>>>> Well, I'd guess something like this:  the FIFO data is stored on the
>>>> heap, which is mall

Re: [beagleboard] Re: 8 ADC input @20 KHz

[Harvey White]

On Thu, 8 Oct 2015 14:00:39 -0700, you wrote:

>>
>> *Well, I'd guess something like this:  the FIFO data is stored on the*
>> * heap, which is malloc'd.  You need the pointers as needed to figure*
>> * out where it is.   Standard pointers to head and tail of the ring*
>> * buffer will be stored locally, unless someone did a pointer to the*
>> * data structure of the FIFO (but not the data itself).  I'm doing that*
>> * in an OS that I'm writing.  The only advantage here is that heap*
>> * memory (or managed memory) is managed by the OS, and should not belong*
>> * to any one task.  (you could argue that, but it's more convenient this*
>> * way for me.)*
>>
>
>I can not say it any better than this:
>http://linux.about.com/library/cmd/blcmdl4_mem.htm So basically, when you
>mmap() /dev/mem/ you get a pointer to any system address you point it to.
>In this case, for me, the physical address space assigned by the kernel,
>for the peripherals. This is what I *think* is happening. I'm still
>learning how this works, by starting off with examples by others.

mem is the whole system memory, protected or otherwise.  It doesn't
seem to include ports;

port is the I/O memory.

I suspect that you're right (not a linux type, but it seems to be
what's going on). 

>
>So what I've figured out already is that the code I'm using, and have
>partly written myself. Gives me a pointer to the ADC registers - and more.


>I know it works, as I can enable the ADC, take readings with my executable,
>or devmem2, the values are very likely accurate for reason mentioned
>previously. Then I've written code myself based on information I've read
>from the TRM to disable the ADC clock when done. After which devemem2 no
>longer returns a value from this area of memory - Which is the memory
>location for the first FIFO ( FIFO0 ) Of the ADC.

no longer returns any value or doesn't return a value you expect?  You
should be able to read the memory regardless.  What it says is another
matter.

>
>What I would really like to find is a good comprehensive guide, document,
>or something about this whole process. I have not really found this yet,
>and maybe I've been looking in the wrong places ? Stuff like POSIX shared
>memory, etc, may be considered advanced topics in programming. But I'd
>personally consider the topic of /dev/mem/ far more advanced. Certainly, it
>can be "dangerous" to start poking around in random memory locations on a
>live system. Which is why in this case, I started off experimenting with
>code written by others.

Just offhand, I'd suggest not messing with the hardware directly, but
using the system drivers unless you want to write system level
drivers.

>
>Being able to write code from scratch to disable the ADC when done with it,
>has boosted my confidence *some*. But I know I have a lot to learn about
>this topic, and at least the Linux kernel memory addressing schema.

Guess there isn't a linux ADC driver for this chip.  I'm used to
writing bare metal drivers myself, but not for linux at all.

The heap memory is effectively the *remaining* memory that the
operating system doesn't use, it should include all of the data
segments, the ram data, and the current stack.  From this, malloc
pulls memory, (in the GCC-AVR) from the bottom up.

So it doesn't at all seem to be the same as the "mem" array, or the
"port" array...

Harvey


>
>On Thu, Oct 8, 2015 at 12:18 PM, Harvey White 
>wrote:
>
>> On Wed, 7 Oct 2015 19:18:02 -0700, you wrote:
>>
>> >Harvey,
>> >
>> >Actually, you're right. the previously mentioned FIFO is actually 100h in
>> >size, my bad. Too much on my brain here. What I described above is
>> actually
>> >what each 32bit field *in* that buffer *is*. hah !
>>
>> Good, that means that there *is* a FIFO.
>> >
>> >Anyway, I make it a habit to jump into things like this because they're
>> >hard to do. So I often find myself struggling with details like this. But
>> >in this case, not only am I "fighting" the hardware. I'm also fighting my
>> >ignorance of how Linux stores this information in memory.
>> >
>>
>> Well, I'd guess something like this:  the FIFO data is stored on the
>> heap, which is malloc'd.  You need the pointers as needed to figure
>> out where it is.   Standard pointers to head and tail of the ring
>> buffer will be stored locally, unless someone did a pointer to the
>> data structure of the FIFO (but not the data itself).  I'm doing that
>> in an OS that I'm writing.  The only advanta

Re: [beagleboard] Re: 8 ADC input @20 KHz

[Harvey White]

On Wed, 7 Oct 2015 19:18:02 -0700, you wrote:

>Harvey,
>
>Actually, you're right. the previously mentioned FIFO is actually 100h in
>size, my bad. Too much on my brain here. What I described above is actually
>what each 32bit field *in* that buffer *is*. hah !

Good, that means that there *is* a FIFO.  
>
>Anyway, I make it a habit to jump into things like this because they're
>hard to do. So I often find myself struggling with details like this. But
>in this case, not only am I "fighting" the hardware. I'm also fighting my
>ignorance of how Linux stores this information in memory.
>

Well, I'd guess something like this:  the FIFO data is stored on the
heap, which is malloc'd.  You need the pointers as needed to figure
out where it is.   Standard pointers to head and tail of the ring
buffer will be stored locally, unless someone did a pointer to the
data structure of the FIFO (but not the data itself).  I'm doing that
in an OS that I'm writing.  The only advantage here is that heap
memory (or managed memory) is managed by the OS, and should not belong
to any one task.  (you could argue that, but it's more convenient this
way for me.)


>What I hope to take away from this is something like: "God, that was a pain
>in the butt, but man was it worth it!" Meaning: hopefully I'll learn
>something worth knowing ;)

I suspect you will, so go for it.

Best of luck

Harvey

>
>On Wed, Oct 7, 2015 at 6:58 PM, Harvey White  wrote:
>
>> On Wed, 7 Oct 2015 18:36:00 -0700, you wrote:
>>
>> >>
>> >> *You're working with two things, FIFO and ADC.*
>> >>
>> >> * What does the ADC do when the FIFO is full?*
>> >>
>> >> * What does the FIFO do when it is full?*
>> >>
>> >> * How do you know?*
>> >>
>> >> * Do you record it?*
>> >
>> >
>> >Hey Harvey,
>> >
>> >There is nothing wrong with my code per se. What is wrong however, and
>> >possibly indirectly related to the code in question. Is that I'm still
>> >learning the hardware, and some very obscure details as to how Linux plays
>> >a part in that.
>>
>> Oh, I'm not suggesting that there is something wrong with your code,
>> but I am wondering if there is something wrong with the process
>> involved.
>>
>> Just off the top of my head (and without offence, since I'd apply the
>> same list to myself... and have
>>
>> 1) do we know what the OS is doing?
>> 2) do we know what the hardware is doing?
>> 3) do we know what the firmware/driver is doing?
>> 4) have we made a mistake?
>> 5) is someone else's code not doing what's designed?
>> 6) have we run into a boundary condition of some sort that is not
>> handled?
>> 7) how do we know the above answers?
>>
>> Has nothing to do with programmer (your) competence.  I'd decent at
>> this, and I've graduated to more complex and obscure mistakes,
>> although I will occasionally make simple ones just to keep myself in
>> practice (for what, I don't know)
>>
>> >
>> >So, the way I understand it is that stepping is related to averaging. In
>> >this context, a step is a single sample in a set of samples contained in
>> an
>> >average. Here is what I think I understand. Once enabled, the first step
>> >reads from the pin, stores the value, decrements the stepping value, then
>> >checks if step > 0 - to possibly restart the sampling. Once all steps are
>> >finished ( 1, 2, 4, 8, or 16 possible steps ), the step enable bit is
>> >toggled. So this last part here, I'm not clear on, but I think I have the
>> >rest correct. But assuming this last part is correct, what could be
>> >happening is that once I have a full buffer, the step enable bit is
>> >enabled, and the ADC then "goes to sleep" until one, or more channels have
>> >their step enable bit set.
>>
>> Sounds more like a sequence where the "stepping" is used to indicate
>> which samples the multiplexed input of the ADC is actually sampling
>> and measuring.
>>
>> The AVR megas and Xmegas do this.
>>
>> Analog multiplexer hooked to ADC.
>>
>> >
>> >The FIFO, in my case FIFO0DATA is only a single 32bit register. 12bit
>> data,
>> >4bit reserved, 3bit channel id, the rest reserved. So, technically, it is
>> >always full. I never clear the whole register, only the data field 12
>> bits.
>> >When I do this with devmem2, the value resets, and the 

Re: [beagleboard] Re: 8 ADC input @20 KHz

[Harvey White]

On Wed, 7 Oct 2015 18:36:00 -0700, you wrote:

>>
>> *You're working with two things, FIFO and ADC.*
>>
>> * What does the ADC do when the FIFO is full?*
>>
>> * What does the FIFO do when it is full?*
>>
>> * How do you know?*
>>
>> * Do you record it?*
>
>
>Hey Harvey,
>
>There is nothing wrong with my code per se. What is wrong however, and
>possibly indirectly related to the code in question. Is that I'm still
>learning the hardware, and some very obscure details as to how Linux plays
>a part in that.

Oh, I'm not suggesting that there is something wrong with your code,
but I am wondering if there is something wrong with the process
involved.

Just off the top of my head (and without offence, since I'd apply the
same list to myself... and have

1) do we know what the OS is doing?
2) do we know what the hardware is doing?
3) do we know what the firmware/driver is doing?
4) have we made a mistake?
5) is someone else's code not doing what's designed?
6) have we run into a boundary condition of some sort that is not
handled?
7) how do we know the above answers?

Has nothing to do with programmer (your) competence.  I'd decent at
this, and I've graduated to more complex and obscure mistakes,
although I will occasionally make simple ones just to keep myself in
practice (for what, I don't know)

>
>So, the way I understand it is that stepping is related to averaging. In
>this context, a step is a single sample in a set of samples contained in an
>average. Here is what I think I understand. Once enabled, the first step
>reads from the pin, stores the value, decrements the stepping value, then
>checks if step > 0 - to possibly restart the sampling. Once all steps are
>finished ( 1, 2, 4, 8, or 16 possible steps ), the step enable bit is
>toggled. So this last part here, I'm not clear on, but I think I have the
>rest correct. But assuming this last part is correct, what could be
>happening is that once I have a full buffer, the step enable bit is
>enabled, and the ADC then "goes to sleep" until one, or more channels have
>their step enable bit set.

Sounds more like a sequence where the "stepping" is used to indicate
which samples the multiplexed input of the ADC is actually sampling
and measuring.  

The AVR megas and Xmegas do this.  

Analog multiplexer hooked to ADC.

>
>The FIFO, in my case FIFO0DATA is only a single 32bit register. 12bit data,
>4bit reserved, 3bit channel id, the rest reserved. So, technically, it is
>always full. I never clear the whole register, only the data field 12 bits.
>When I do this with devmem2, the value resets, and the whole field
>refreshes with new values.

Now *that* is not what I'd call a FIFO.  It's a single buffer, not a
First In First Out multibyte buffer with lots of storage, but a single
byte buffer for one reading.  The most you can ever get behind is one
reading cycle.
>
>With the above said, I suppose you are right in that my code might be
>wrong, but still I think it is more of a hardware misunderstanding. Not
>that I think that I am the greatest C programmer to ever live, but usually,
>I can code my way out of a wet paper bag.

Oh, and a few dry ones as well That, as I mentioned, is not the
issue.

Often times I find it useful to go back and check the fundamental
assumptions just because.


Is no fault, is only program.



>
>At any rate. Believe it or not prior to answering your post. I did hit on
>the idea that I could either manually toggle step enable ( was just reading
>a bit of code on this ), or I could manually clear the lower 12bits on the
>FIFO register, and see what happens.

Not sure what that'll do, but give it a try.

Not sure about the ARM hardware, but I know how other processor do
this, and there are some little gotchas.

Harvey

>
>
>On Wed, Oct 7, 2015 at 5:45 PM, Harvey White  wrote:
>
>> On Wed, 7 Oct 2015 17:20:26 -0700, you wrote:
>>
>> >Oh and dahm, one more thing heh. Sorry people I'm kind of remembering this
>> >as I think about it. Normally I keep notes, but was up late attempting to
>> >track this issue down. So, I'm reasonably sure the FIFO is not refreshing,
>> >as if I flush the data value manually ( value address &= ~0x ), it
>> >never gets repopulated.
>> >
>> >Once more, if I read out the sample in order based on channel id, the
>> >values stay the same form one iteration to the next. But If I burst read
>> in
>> >whatever comes from the FIFO next, the values do change, but repeat after
>> >many read. Which let us just assume, for now, it's the length of the
>> buffer
>> >I set through iio:device0.
>> &g

Re: [beagleboard] Re: 8 ADC input @20 KHz

[Harvey White]

On Wed, 7 Oct 2015 17:20:26 -0700, you wrote:

>Oh and dahm, one more thing heh. Sorry people I'm kind of remembering this
>as I think about it. Normally I keep notes, but was up late attempting to
>track this issue down. So, I'm reasonably sure the FIFO is not refreshing,
>as if I flush the data value manually ( value address &= ~0x ), it
>never gets repopulated.
>
>Once more, if I read out the sample in order based on channel id, the
>values stay the same form one iteration to the next. But If I burst read in
>whatever comes from the FIFO next, the values do change, but repeat after
>many read. Which let us just assume, for now, it's the length of the buffer
>I set through iio:device0.
>
>*Perhaps* I just need to enable / disable the ADC once the buffer fills -
>via iio ? I'm not sure, as I've only been working with the ADC for about
>what ? A week now ? With no prior experience . . .

You're working with two things, FIFO and ADC.

What does the ADC do when the FIFO is full?

What does the FIFO do when it is full?

How do you know?

Do you record it?

Harvey


>
>On Wed, Oct 7, 2015 at 5:10 PM, William Hermans  wrote:
>
>> More info on the issues I'm having with the FIFO. The data seems to
>> repeat, and never changes between system reboots. I'm not sure if this is
>> my fault, or the fault of something to do with this Linux kernel, the iio
>> user space drivers, or something else. For now, I'm assuming it is my
>> fault. Things that I am noticing:
>>
>> When reading the values out of the ADC via mmap() versus using iio, the
>> values read out are not in the same range. Using sysfs, the floating
>> voltage values are around ~4000. But with mmap() these values vary starting
>> from as low as in the hundreds, or up close to, but not passing 4000. The
>> ID field for the ADC's *always* stay in the correct range though. Which is
>> why I think I'm not flushing / clearing the FIFO correctly - More on this
>> later.
>>
>> It does not matter how I configure the ADC( sysfs or mmap() ) in this
>> case. What I've been experimenting with is a header file originally written
>> for the Beaglebone white, but I checked the base address / offset
>> constants( against the TRM ), and they seem to be exactly the same. Here,
>> my problem lies in not completely understanding the hardware, and how
>> various things interact inside of, or with Linux. Writing the software for
>> all this once understood. For me, will be trivial.
>>
>> What does make sense to me with this problem is that I do not understand
>> how to flush the buffer, and then tell the ADC "hey send more samples". But
>> I am not exactly sure this is what my problem is. This is just a guess on
>> my behalf, that makes the most sense.
>>
>> Another thing that did occur to me is that I'm reading from the FIFO too
>> fast. But there are many factors here, including but not limited to:
>> Averaging, stepping, clock divider, and ADC clock cycles needed to read out
>> a correct value. These are the things that are foremost on my mind right
>> now, of which I have limited understanding of - so far.
>>
>> On Wed, Oct 7, 2015 at 4:44 PM, William Hermans  wrote:
>>
>>> *Have  you experimented with buffer size? is there any optimal value
 calculation? Would it have any impact on the result, Like if we keep a
 larger buffer and than directly take that buffer that way it would be
 faster? I have currently kept 1k.*
>>>
>>>
>>> Yeah sorry, I'm kind of in my own world here at the moment. Anyway, like
>>> I mentioned above I was speaking of the ADC FIFO. As for buffering into
>>> system RAM, this is certainly possible, and very likely preferable. This
>>> can also be done, very easily, using POSIX shared memory. Potentially, this
>>> is a problem, as once the data is in RAM, how do you get it back out for
>>> transport. Without using additional CPU cycles, or using the PRU's ? Not
>>> using the PRU's for this by the way, is a constraint I've placed on myself.
>>> Just to see if it is *reasonably* possible. Indeed, I do believe it is
>>> possible, but not quite sure  how reasonable that possibility *is*. - Yet.
>>>
>>> On Wed, Oct 7, 2015 at 4:34 PM, William Hermans 
>>> wrote:
>>>
 Well, the buffer I'm talking about is the ADC buffer. I've been looking
 through others code for PRU -> ADC, and have been attempting to translate
 that. I'm afraid my ASM skills are very lacking for this task( I have not
 written ASM code in years ). However the constants used in much of the code
 out there, are the same. So while I do not yet know what LBBO, and stuff
 liek r0-r31 mean for program flow, I can figure out the addressing very
 quickly. Not to mention that the TRM has this information too, but the TRM
 is very terse reading for many things. It's great for "cherry picking"
 offsets, but much of the information is not presented in an order that
 makes the most sense to me. ie, you have to bounce around too much form one
 place 

Re: [beagleboard] Re: 8 ADC input @20 KHz

[Harvey White]

On Wed, 7 Oct 2015 17:10:49 -0700, you wrote:

>More info on the issues I'm having with the FIFO. The data seems to repeat,
>and never changes between system reboots. I'm not sure if this is my fault,
>or the fault of something to do with this Linux kernel, the iio user space
>drivers, or something else. For now, I'm assuming it is my fault. Things
>that I am noticing:

What that *sounds* like is when you allocate memory for the FIFO, it
is never cleared.  The variables that read from the FIFO *ought* to be
initialized appropriately, however.  So this is puzzling.


>
>When reading the values out of the ADC via mmap() versus using iio, the
>values read out are not in the same range. Using sysfs, the floating
>voltage values are around ~4000. But with mmap() these values vary starting
>from as low as in the hundreds, or up close to, but not passing 4000. The
>ID field for the ADC's *always* stay in the correct range though. Which is
>why I think I'm not flushing / clearing the FIFO correctly - More on this
>later.

I'd clear the FIFO memory (or queue memory) just because.  Look for
calloc rather than malloc if you're dealing with bare metal (I do)

>
>It does not matter how I configure the ADC( sysfs or mmap() ) in this case.
>What I've been experimenting with is a header file originally written for
>the Beaglebone white, but I checked the base address / offset constants(
>against the TRM ), and they seem to be exactly the same. Here, my problem
>lies in not completely understanding the hardware, and how various things
>interact inside of, or with Linux. Writing the software for all this once
>understood. For me, will be trivial.

Why do I think pointers are used here?

>
>What does make sense to me with this problem is that I do not understand
>how to flush the buffer, and then tell the ADC "hey send more samples". But
>I am not exactly sure this is what my problem is. This is just a guess on
>my behalf, that makes the most sense.

The ADC in most processors needs to be "started", and depending on the
interrupt handler (which may feed the FIFO), is automatic from then on
until a specified number of reads is done (or not...).

Since the FIFO pointers are supposedly initialized to
(beginning:beginning) for read/write (head/tail)... and since data is
supposedly written into the FIFO and the pointers are adjusted then
(which means clean data)

Either the FIFO is not being set up properly, or the code is wrong

>
>Another thing that did occur to me is that I'm reading from the FIFO too
>fast. But there are many factors here, including but not limited to:

Reading from the FIFO too fast is not really possible on a well
designed FIFO.  You either have data available or you do not.  Data
available should be set when the complete message is written.  FIFO
ought to be interlocked that read does not interfere with write


>Averaging, stepping, clock divider, and ADC clock cycles needed to read out
>a correct value. These are the things that are foremost on my mind right
>now, of which I have limited understanding of - so far.

Averaging generally handles noise, and averages n samples for a single
reading (and reports it).  Stepping I'm not sure of.  clock divider
simply means that the ADC is not reading at an optimum rate *for the
ADC hardware* which has nothing to do with sampling or anything else.
ADC clock cycles to read out simply means I say read, how soon (clock
cycles) do I get data?

So I don't know what's going on.

However, I'd try disabling the FIFO for the moment, slowing down the
read process to where a software loop could check it, and look for
data integrity.  *then* I'd go looking for things to blame

Just me, though.

Harvey

>
>On Wed, Oct 7, 2015 at 4:44 PM, William Hermans  wrote:
>
>> *Have  you experimented with buffer size? is there any optimal value
>>> calculation? Would it have any impact on the result, Like if we keep a
>>> larger buffer and than directly take that buffer that way it would be
>>> faster? I have currently kept 1k.*
>>
>>
>> Yeah sorry, I'm kind of in my own world here at the moment. Anyway, like I
>> mentioned above I was speaking of the ADC FIFO. As for buffering into
>> system RAM, this is certainly possible, and very likely preferable. This
>> can also be done, very easily, using POSIX shared memory. Potentially, this
>> is a problem, as once the data is in RAM, how do you get it back out for
>> transport. Without using additional CPU cycles, or using the PRU's ? Not
>> using the PRU's for this by the way, is a constraint I've placed on myself.
>> Just to see if it is *reasonably* possible. Indeed, I do believe it is
>> possible, but not quite sure  how reasonable that possibility *is*. - Yet.
>>
>> On Wed, Oct 7, 2015 at 4:34 PM, William Hermans  wrote:
>>
>>> Well, the buffer I'm talking about is the ADC buffer. I've been looking
>>> through others code for PRU -> ADC, and have been attempting to translate
>>> that. I'm afraid my ASM skills are very 

Re: [beagleboard] Voltage Data Through Bluetooth

[Harvey White]

On Fri, 18 Sep 2015 11:34:11 -0700, you wrote:

>>
>> *Any ideas on where can I start?*
>
>
>Yes. You can start by learning about the on die ADC,  and how to buffer the
>voltage input. That is, the BBB can not take much more than 1.8v on the ADC
>input, so you'd need to scale that down. I'm not an electronics engineer by
>any stretch of the imagination, so exactly how is best, I'm not sure.

One of the more reasonable failsafe options is to use an op amp that
will run at 1.8 volts vcc, use it in a non-inverting configuration,
and use it to scale the voltage to your A/D input.  You must have a
part that will do rail to rail (0 volts to vcc), or you must take
steps to use the available range.  Also, do check the maximum readable
input on the chip, which may not be the maximum input voltage, and may
well be less.  This would be your maximum voltage output from the amp.

The reason for an op-amp is that it is easier to get a high input
impedance for your measurement and also the op-amp itself can afford
some protection for the processor's ADC in an overload situation.

Harvey


>
>Passed that, knowing C reasonably well, and learning the libc function /
>API calls is pretty much a must. For this, you're either going to need to
>understand how to use sysfs, or mmap() to access the ADC. Once you get that
>down, you'll need some way to get the data out over the wire. There are
>more than a couple ways to do this. But you could use a shared memory file
>to store the data from your C application above, and a Nodejs app to put
>the data out over the wire. You could even directly call a C application as
>mentioned above through Nodejs. *Or* you could use strictly C with
>something like libmongoose, to put the data out over a websocket - To any
>listening browser clients.
>
>Not 100% sure here, But I think Jasons bonescript may be able to do most if
>not all of the above as well. No hands on here, so could not say for sure.
>
>Personally, I prefer the all C approach, but thats me.
>
>On Fri, Sep 18, 2015 at 6:57 AM,  wrote:
>
>> Hello Everyone,
>> Apologies if this has been asked before. I'm basically a newbie on
>> BeagleBone Boards but have a basic background on programming.
>>
>> Now part of my project is supposed  to gather data from a power source, it
>> will basically act as a voltmeter. My idea is to send this data either via
>> a Bluetooth dongle or wireless to
>> a phone running android, in which it will be displayed as a graph
>> real-time. Any ideas on where can I start?. I took a look at some other
>> projects but these use an arduino to read
>> the voltages and then send it to the Beaglebone, I would prefer if
>> everything is done on the BeagleBone as the whole actual project will be
>> based on it.
>>
>> If anyone have any idea, please let me know.
>>
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>

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

Re: [beagleboard] Re: Why beaglebone black restarts after a shutdown ??

[Harvey White]

On Tue, 8 Sep 2015 13:43:24 -0700 (PDT), you wrote:

>Hi,
>
>Did anybody find the cause for the restart?
>My BBB has the same problem, my adapter is 5V 2A and there is definitely no 
>restart issue with USB power.
>I'm running Debian 3.8.13-bone70.

>From what I remember, and I can be quite wrong, it goes something like
this:

USB power is monitored.

With external 5V supply, the processor is fed, but the USB power input
is still monitored.  If it is read as being "absent" then the
processor reboots due to a perceived power failure.  The power monitor
chip apparently decides that the USB (as in main power) has failed,
shuts the processor down, detects that 5 volts is there, boots the
processor back up.

Some people made a shorting plug that simply shorts USB power to
ground (in which case it was never "up" and is not checked).

You could "ground" it through a 100 ohm resistor in a dummy plug, or
perhaps a 1K resistor from USB VCC to ground.  100 ohms would draw 50
ma when installed on the board and then connected to VCC (10% drain),
and 1K ohms would draw 5 ma (1% power), and might work just as well.

Just what I seem to remember from the discussions.

Harvey


>
>Thanks.
>
>On Thursday, March 13, 2014 at 8:27:17 PM UTC+5:30, meerutmicr...@gmail.com 
>wrote:
>>
>> Hi,
>>
>> I have noticed that the beaglebone black starts up after a shutdown.
>>
>> I have a C++ program running in the bbb, the bbb is backed by an external 
>> +5V battery pack. When the C++ program issues the following command to 
>> start the shutdown procedure of the bbb.
>>
>> system("shutdown -h now");
>>>
>>> exit(0);
>>>
>>>
>> This does shutdown the bbb completely sometimes, most times the bbb starts 
>> up again, the power led turns off but then after a second or two lights up 
>> again and then bbb starts up all over again (the output voltage from the 
>> power bank does not switch OFF, it remains ON for some time).
>>
>> In my previous bbb systems I have not faced this problem.
>>
>> It is my belief that the output voltage from the power bank has a sudden 
>> dip, this causes the bbb to detect a new power cycle.
>>
>> I am not sure though if I am correct...
>>
>> Could anyone enlighten me on this problem ???
>>
>> I am sorry if the above problem sounds vague...
>>
>> thanks
>> a
>>
>>

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

Re: [beagleboard] Re: Could use some bug tracking advice.

[Harvey White]

On Tue, 25 Aug 2015 16:27:28 -0700, you wrote:

>>
>> *Then you're not getting to the printf.*
>>
>> * Ok, one possibility is that the system calls are taking lots of time.*
>> * Another possibility is that the wait time is giving you a problem.*
>>
>> * If you understand the mechanism of a semaphore, then you can implement*
>> * your own in code.*
>>
>> * Not sure what's going on.*
>
>
>Yeah, thats why I put the printf() there to begin with. A quick way to test
>where my code was "hanging". However, I did do some further testing, and
>found the stalling was actually std out flushing once every 5-10 seconds or
>so ( printf() no "\n" ) at least one the IPC server side. libmongoose on
>the other hand does not seem to function correctly with the -pthread linker
>option . . . so POSIX semaphores are out.
>
>I also suspect my previous data structure was malformed, hence why my
>binary access lock was not working before. However, this allowed me to
>rethink the program flow and switch to a binary access scheme versus a
>binary file lock scheme. Which I honestly prefer.
>
>Yeah it works great. Now.

NOW is all that counts.   You learned stuff, I learned stuff. Someone
reading this will (I hope) learn stuff.

All is good.

Thanks

Harvey

>
>On Tue, Aug 25, 2015 at 4:03 PM, Harvey White 
>wrote:
>
>> On Tue, 25 Aug 2015 15:11:30 -0700, you wrote:
>>
>>
>> If it works, then you have the solution.
>>
>> Good.
>>
>> Harvey
>>
>> >Anyway, I refactored the code, and wound up removing *a lot* of dead
>> weight
>> >code after the refactor. Went from using a union + struct data type to
>> just
>> >using a struct.
>> >
>> >Then changed the way my old binary locking mechanism worked. From 0->
>> >unlocked / 1->locked to 0-> IPC server has access / 1-> IPC client has
>> >access. Which works out exactly how I'd prefer it to. e.g. procedural /
>> >deterministic, and one process will wait on the other indefinitely. Which
>> >is a deadlock, but only one process running means the data is either old,
>> >or not needed anyway. But like so . .
>> >
>> >IPC server:
>> >
>> >while(1){
>> >frame = ReadFrame(sock);
>> >if(frame.can_dlc == FRAME_DLC)
>> >stats = ProcessFastpacket(frame);
>> >
>> >if(stats != NULL){
>> >
>> >*while(smd->file_lock != 0)usleep(1000);*
>> >
>> >WriteToShm(smd, stats);
>> >*smd->file_lock = 1;*
>> >
>> >stats = NULL;
>> >printf("%s", ReadFromShm(smd));
>> >}
>> >}
>> >
>> >IPC client:
>> >
>> >while(1){
>> >mg_poll_server(server, 100);
>> >
>> >
>> >*while(smd->file_lock != 1)usleep(1000);*
>> >
>> >push_message(server, smd->data);
>> >*smd->file_lock = 0;*
>> >}
>> >
>> >I do not think it will get any faster, or simpler than this.
>> >
>> >On Tue, Aug 25, 2015 at 11:47 AM, William Hermans 
>> wrote:
>> >
>> >> Harvey,
>> >>
>> >> Yeah, wow semaphores will *not* work! heh.
>> >>
>> >> So using sem_wait() / sem_post() introduces incredibly long stalls. Even
>> >> when using a single process. The webserver which uses libmongoose wont
>> even
>> >> function. Hell I put a printf() in the front of my control loop, and
>> that
>> >> doesn't even work :/
>> >>
>> >> Going to do some more digging, and see if I can somehow make this work.
>> >>
>> >> On Mon, Aug 24, 2015 at 6:32 PM, Harvey White 
>> >> wrote:
>> >>
>> >>> On Mon, 24 Aug 2015 18:19:14 -0700, you wrote:
>> >>>
>> >>> >>
>> >>> >> *I know the feeling.*
>> >>> >>
>> >>> >> * Good luck and don't hesitate to ask for more help, or at least
>> >>> advice,*
>> >>> >> * for whatever I can do.  Linux I can't really talk about, the*
>> >>> >> * fundamentals I think I can.*
>> >>> >>
>> >>> >
>> >>> >I think Linux in this context was not so important. I mean it is /
>> was,
&

Re: [beagleboard] Re: Could use some bug tracking advice.

[Harvey White]

On Tue, 25 Aug 2015 15:11:30 -0700, you wrote:


If it works, then you have the solution.  

Good.

Harvey

>Anyway, I refactored the code, and wound up removing *a lot* of dead weight
>code after the refactor. Went from using a union + struct data type to just
>using a struct.
>
>Then changed the way my old binary locking mechanism worked. From 0->
>unlocked / 1->locked to 0-> IPC server has access / 1-> IPC client has
>access. Which works out exactly how I'd prefer it to. e.g. procedural /
>deterministic, and one process will wait on the other indefinitely. Which
>is a deadlock, but only one process running means the data is either old,
>or not needed anyway. But like so . .
>
>IPC server:
>
>while(1){
>frame = ReadFrame(sock);
>if(frame.can_dlc == FRAME_DLC)
>stats = ProcessFastpacket(frame);
>
>if(stats != NULL){
>
>*while(smd->file_lock != 0)usleep(1000);*
>
>WriteToShm(smd, stats);
>*smd->file_lock = 1;*
>
>stats = NULL;
>printf("%s", ReadFromShm(smd));
>}
>}
>
>IPC client:
>
>while(1){
>mg_poll_server(server, 100);
>
>
>*while(smd->file_lock != 1)usleep(1000);*
>
>push_message(server, smd->data);
>*smd->file_lock = 0;*
>}
>
>I do not think it will get any faster, or simpler than this.
>
>On Tue, Aug 25, 2015 at 11:47 AM, William Hermans  wrote:
>
>> Harvey,
>>
>> Yeah, wow semaphores will *not* work! heh.
>>
>> So using sem_wait() / sem_post() introduces incredibly long stalls. Even
>> when using a single process. The webserver which uses libmongoose wont even
>> function. Hell I put a printf() in the front of my control loop, and that
>> doesn't even work :/
>>
>> Going to do some more digging, and see if I can somehow make this work.
>>
>> On Mon, Aug 24, 2015 at 6:32 PM, Harvey White 
>> wrote:
>>
>>> On Mon, 24 Aug 2015 18:19:14 -0700, you wrote:
>>>
>>> >>
>>> >> *I know the feeling.*
>>> >>
>>> >> * Good luck and don't hesitate to ask for more help, or at least
>>> advice,*
>>> >> * for whatever I can do.  Linux I can't really talk about, the*
>>> >> * fundamentals I think I can.*
>>> >>
>>> >
>>> >I think Linux in this context was not so important. I mean it is / was,
>>> but
>>> >I generally do ok with high level on topic discussions. So long as I know
>>> >what my options are, everything is good.
>>>
>>> It's more of a general operating system issue, and that is fundamental
>>> knowledge.  Personally, I don't see a problem, but the list moderators
>>> haven't seemed to have a problem either, so that's ok.
>>>
>>> >
>>> >*Ask either on the list or private email if you want.*
>>> >>
>>> >
>>> >I don't mind asking here if that is fine with everyone. Technically, I
>>> felt
>>> >a little funny posting here, as it was semi off topic( in relation to the
>>> >beaglebone ), but maybe the discussion helps someone else too ? If there
>>> is
>>> >a problem, then I have no issues moving to another forum.
>>>
>>> True, except it *is* to get the beaglebone working, and *is* an issue
>>> that can bite people writing somewhat more complicated projects.
>>>
>>> I'd hope that it will help others, and for that matter, if someone
>>> disagrees with what I've said, I'd welcome the discussion.
>>>
>>> Hopefully, the concepts will help with the more complicated projects
>>> using any sort of beagle
>>>
>>> Harvey
>>>
>>> >
>>> >On Mon, Aug 24, 2015 at 6:00 PM, Harvey White 
>>> >wrote:
>>> >
>>> >> On Mon, 24 Aug 2015 17:40:33 -0700, you wrote:
>>> >>
>>> >> >Hey Harvey, and Walter
>>> >> >
>>> >> >Just kind of an update. Last night after our discussion I found a
>>> really
>>> >> >good resource / discussion of what fork() is and the different ways
>>> it can
>>> >> >be used. So with this information in mind along with our discussion
>>> >> >yesterday it seems that what I want to do can indeed be done without
>>> using
>>> >> >POS

Re: [beagleboard] Re: Could use some bug tracking advice.

[Harvey White]

On Tue, 25 Aug 2015 11:47:06 -0700, you wrote:

>Harvey,
>
>Yeah, wow semaphores will *not* work! heh.
>
>So using sem_wait() / sem_post() introduces incredibly long stalls. Even
>when using a single process. The webserver which uses libmongoose wont even
>function. Hell I put a printf() in the front of my control loop, and that
>doesn't even work :/

Then you're not getting to the printf.

Ok, one possibility is that the system calls are taking lots of time.
Another possibility is that the wait time is giving you a problem.

If you understand the mechanism of a semaphore, then you can implement
your own in code.

Not sure what's going on.

Harvey

>
>Going to do some more digging, and see if I can somehow make this work.
>
>On Mon, Aug 24, 2015 at 6:32 PM, Harvey White 
>wrote:
>
>> On Mon, 24 Aug 2015 18:19:14 -0700, you wrote:
>>
>> >>
>> >> *I know the feeling.*
>> >>
>> >> * Good luck and don't hesitate to ask for more help, or at least
>> advice,*
>> >> * for whatever I can do.  Linux I can't really talk about, the*
>> >> * fundamentals I think I can.*
>> >>
>> >
>> >I think Linux in this context was not so important. I mean it is / was,
>> but
>> >I generally do ok with high level on topic discussions. So long as I know
>> >what my options are, everything is good.
>>
>> It's more of a general operating system issue, and that is fundamental
>> knowledge.  Personally, I don't see a problem, but the list moderators
>> haven't seemed to have a problem either, so that's ok.
>>
>> >
>> >*Ask either on the list or private email if you want.*
>> >>
>> >
>> >I don't mind asking here if that is fine with everyone. Technically, I
>> felt
>> >a little funny posting here, as it was semi off topic( in relation to the
>> >beaglebone ), but maybe the discussion helps someone else too ? If there
>> is
>> >a problem, then I have no issues moving to another forum.
>>
>> True, except it *is* to get the beaglebone working, and *is* an issue
>> that can bite people writing somewhat more complicated projects.
>>
>> I'd hope that it will help others, and for that matter, if someone
>> disagrees with what I've said, I'd welcome the discussion.
>>
>> Hopefully, the concepts will help with the more complicated projects
>> using any sort of beagle
>>
>> Harvey
>>
>> >
>> >On Mon, Aug 24, 2015 at 6:00 PM, Harvey White 
>> >wrote:
>> >
>> >> On Mon, 24 Aug 2015 17:40:33 -0700, you wrote:
>> >>
>> >> >Hey Harvey, and Walter
>> >> >
>> >> >Just kind of an update. Last night after our discussion I found a
>> really
>> >> >good resource / discussion of what fork() is and the different ways it
>> can
>> >> >be used. So with this information in mind along with our discussion
>> >> >yesterday it seems that what I want to do can indeed be done without
>> using
>> >> >POSIX shared memory( I had little doubt ) - *and* seemingly more
>> simple.
>> >>
>> >> That sounds good
>> >> >
>> >> >I'd still have to use a Semaphore - I think to keep the web server
>> >> callback
>> >> >from stalling my canbus routines. But I think that seems fairly
>> >> reasonable.
>> >> >
>> >>
>> >> That also sounds quite reasonable to do.  As your programs get more
>> >> complicated, you'll have to figure out how to interlock/protect/manage
>> >> resources.
>> >>
>> >> I have a project that manages a graphics engine (software), I2C slave
>> >> (ditto), heartbeat/errortask, I2C error reporting task, and the like;
>> >> and uses a FIFO, semaphores, queues and the like to protect resources
>> >> and manage memory.
>> >>
>> >> Probably a bit too complex, but it kinda grew that way.
>> >>
>> >>
>> >> >Still I may just implement semaphores into my current code to check it
>> >> out,
>> >> >but not sure when. Been a semi rough day, and I'm whooped . . .
>> >>
>> >> I know the feeling.
>> >>
>> >> Good luck and don't hesitate to ask for more help, or at least advice,
>> >> for whatever I can do.  Linux I can't really talk about, the
>> >> fund

Re: [beagleboard] Re: Could use some bug tracking advice.

[Harvey White]

On Mon, 24 Aug 2015 18:19:14 -0700, you wrote:

>>
>> *I know the feeling.*
>>
>> * Good luck and don't hesitate to ask for more help, or at least advice,*
>> * for whatever I can do.  Linux I can't really talk about, the*
>> * fundamentals I think I can.*
>>
>
>I think Linux in this context was not so important. I mean it is / was, but
>I generally do ok with high level on topic discussions. So long as I know
>what my options are, everything is good.

It's more of a general operating system issue, and that is fundamental
knowledge.  Personally, I don't see a problem, but the list moderators
haven't seemed to have a problem either, so that's ok.

>
>*Ask either on the list or private email if you want.*
>>
>
>I don't mind asking here if that is fine with everyone. Technically, I felt
>a little funny posting here, as it was semi off topic( in relation to the
>beaglebone ), but maybe the discussion helps someone else too ? If there is
>a problem, then I have no issues moving to another forum.

True, except it *is* to get the beaglebone working, and *is* an issue
that can bite people writing somewhat more complicated projects.

I'd hope that it will help others, and for that matter, if someone
disagrees with what I've said, I'd welcome the discussion.  

Hopefully, the concepts will help with the more complicated projects
using any sort of beagle

Harvey

>
>On Mon, Aug 24, 2015 at 6:00 PM, Harvey White 
>wrote:
>
>> On Mon, 24 Aug 2015 17:40:33 -0700, you wrote:
>>
>> >Hey Harvey, and Walter
>> >
>> >Just kind of an update. Last night after our discussion I found a really
>> >good resource / discussion of what fork() is and the different ways it can
>> >be used. So with this information in mind along with our discussion
>> >yesterday it seems that what I want to do can indeed be done without using
>> >POSIX shared memory( I had little doubt ) - *and* seemingly more simple.
>>
>> That sounds good
>> >
>> >I'd still have to use a Semaphore - I think to keep the web server
>> callback
>> >from stalling my canbus routines. But I think that seems fairly
>> reasonable.
>> >
>>
>> That also sounds quite reasonable to do.  As your programs get more
>> complicated, you'll have to figure out how to interlock/protect/manage
>> resources.
>>
>> I have a project that manages a graphics engine (software), I2C slave
>> (ditto), heartbeat/errortask, I2C error reporting task, and the like;
>> and uses a FIFO, semaphores, queues and the like to protect resources
>> and manage memory.
>>
>> Probably a bit too complex, but it kinda grew that way.
>>
>>
>> >Still I may just implement semaphores into my current code to check it
>> out,
>> >but not sure when. Been a semi rough day, and I'm whooped . . .
>>
>> I know the feeling.
>>
>> Good luck and don't hesitate to ask for more help, or at least advice,
>> for whatever I can do.  Linux I can't really talk about, the
>> fundamentals I think I can.
>>
>> Ask either on the list or private email if you want.
>>
>> Harvey
>>
>> >
>> >On Sun, Aug 23, 2015 at 9:44 PM, William Hermans 
>> wrote:
>> >
>> >> OK have a good one, thanks for the discussion.
>> >>
>> >> On Sun, Aug 23, 2015 at 9:11 PM, Harvey White 
>> >> wrote:
>> >>
>> >>> On Sun, 23 Aug 2015 20:18:26 -0700 (PDT), you wrote:
>> >>>
>> >>> >
>> >>> >>
>> >>> >> *Well, you're certainly right that the callback is messing*
>> >>> >> * things up.  If I assume the same callback, then the callback is*
>> >>> >> * certainly changing data.  If you can set the right breakpoint, you
>> >>> can*
>> >>> >> * tag the situation *if* the breakpoint also knows that the process
>> is*
>> >>> >> * reading from the CAN bus.*
>> >>> >>
>> >>> >> * Had you considered disabling that callback function until the
>> read*
>> >>> >> * from the CANbus is finished?  Would it be practical?  That's where
>> >>> the*
>> >>> >> * semaphore might help a lot.*
>> >>> >>
>> >>> >> * what variables could be common between the two routines?*
>> >>> >>
>> >>> >> * Harvey*
>> >>> >>
>> &

Re: [beagleboard] Re: Could use some bug tracking advice.

[Harvey White]

On Mon, 24 Aug 2015 17:40:33 -0700, you wrote:

>Hey Harvey, and Walter
>
>Just kind of an update. Last night after our discussion I found a really
>good resource / discussion of what fork() is and the different ways it can
>be used. So with this information in mind along with our discussion
>yesterday it seems that what I want to do can indeed be done without using
>POSIX shared memory( I had little doubt ) - *and* seemingly more simple.

That sounds good
>
>I'd still have to use a Semaphore - I think to keep the web server callback
>from stalling my canbus routines. But I think that seems fairly reasonable.
>

That also sounds quite reasonable to do.  As your programs get more
complicated, you'll have to figure out how to interlock/protect/manage
resources.

I have a project that manages a graphics engine (software), I2C slave
(ditto), heartbeat/errortask, I2C error reporting task, and the like;
and uses a FIFO, semaphores, queues and the like to protect resources
and manage memory.

Probably a bit too complex, but it kinda grew that way.


>Still I may just implement semaphores into my current code to check it out,
>but not sure when. Been a semi rough day, and I'm whooped . . .

I know the feeling.

Good luck and don't hesitate to ask for more help, or at least advice,
for whatever I can do.  Linux I can't really talk about, the
fundamentals I think I can.  

Ask either on the list or private email if you want.

Harvey

>
>On Sun, Aug 23, 2015 at 9:44 PM, William Hermans  wrote:
>
>> OK have a good one, thanks for the discussion.
>>
>> On Sun, Aug 23, 2015 at 9:11 PM, Harvey White 
>> wrote:
>>
>>> On Sun, 23 Aug 2015 20:18:26 -0700 (PDT), you wrote:
>>>
>>> >
>>> >>
>>> >> *Well, you're certainly right that the callback is messing*
>>> >> * things up.  If I assume the same callback, then the callback is*
>>> >> * certainly changing data.  If you can set the right breakpoint, you
>>> can*
>>> >> * tag the situation *if* the breakpoint also knows that the process is*
>>> >> * reading from the CAN bus.*
>>> >>
>>> >> * Had you considered disabling that callback function until the read*
>>> >> * from the CANbus is finished?  Would it be practical?  That's where
>>> the*
>>> >> * semaphore might help a lot.*
>>> >>
>>> >> * what variables could be common between the two routines?*
>>> >>
>>> >> * Harvey*
>>> >>
>>> >
>>> >Well this is where previous experience fails me. I've pretty much avoided
>>> >code related to threading in software. In the past. I do know of fork()
>>> and
>>> >roughly what it is capable of, and I know about threads, but not to
>>> >implement them in C on Linux. Or what can be done with them. Lets talk
>>> code
>>> >a minute.
>>>
>>> OK, as well as I can follow it.
>>>
>>> >
>>> >*IPC - Server - Reads from canbus*
>>> >int main(){
>>> >struct can_frame frame;
>>> >int sock = InitializeCAN("vcan0");
>>> >
>>> >statistics_t *stats = NULL;
>>> >
>>> >const long shm_size = sysconf(_SC_PAGESIZE);
>>> >
>>> >int shm_fd = shm_open("acme", O_CREAT | O_RDWR, FILE_PERMS);
>>>
>>> **NOTE:  the problem may be "acme", since we know that acme products
>>> are not effective against roadrunners.
>>>
>>> >if(shm_fd == -1)
>>> >HandleError(strerror(errno));
>>> >
>>> >const int retval = ftruncate(shm_fd, shm_size);
>>> >if(retval == -1)
>>> >HandleError(strerror(errno));
>>> >
>>> >shared_memory = InitializeShm(shm_size * sizeof(char), shm_fd);
>>> >close(shm_fd);
>>> >
>>> >while(1){
>>> >frame = ReadFrame(sock);
>>> >if(frame.can_dlc == FRAME_DLC)
>>> >stats = ProcessFastpacket(frame);
>>>
>>> right at this point, you have no protection against access and no
>>> interlocking.
>>>
>>> I'll have to give you pseudocode, because I don't know how to do this
>>> in Linux.
>>>
>>> In the init routine, before you set up either main as a
>>> process (I assume you do this).  Declare a semaphore:
>>>
>>> semaphore_handle shared_access; 

Re: [beagleboard] my metal detector development for beaglebone black

[Harvey White]

On Sun, 23 Aug 2015 16:51:01 -0700 (PDT), you wrote:

>hi guys i am wanting to build a new type of metal detector  which in it 
>self is quite complex task starting with little bits c/c++ code and tying 
>to keep it simple i need to wirite 7 values of either on or off to 1 gpio 
>but infact need to a total of 7 gpio's all as one cycle so i have set 
>patern of  on or off values across the 7 gpios  after that patern is 
>executed is anthoner fixed pattern is done 7 times which the whole thing 
>keeps repeating the pattern below shows the state of the switches s57-s64 
>the gpio's need to be turn on in that order to turn the transistors on if 
>some could hep i would be greatful

*if* you can write these 8 values as a single byte then it's just a
lookup table with an index.  That should get the entire 8 bits change
at one time.  This can happen in some processors, and not in others. I
don't know this particular processor at all, so I can't say that this
is possible.

it's a possibility, but you need to look at the processor
documentation to see if it can be done.  Again, I do *not* know this
processor at all, but it can be done in other processors depending on
how the I/O ports are mapped.

Your best bet is to look at the documentation on the GPIO pins and how
they can be changed.

Harvey

>
>
>S57 S58 S59 S60 S61 S62 S63 S64 onoffoffonn/aonn/aoff
>
>
>onoffoffonn/aoffn/aon
>offononoffonn/aoffn/a?
>
>
>
>
>
>
>
>
>offononoffoffn/aonn/a
>
>
>
>
>
>
>
>
>offoffononononoffoff
>offoffonononoffoffon
>offoffononoffononoff+

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

Re: [beagleboard] Re: Could use some bug tracking advice.

[Harvey White]

On Sun, 23 Aug 2015 20:18:26 -0700 (PDT), you wrote:

>
>>
>> *Well, you're certainly right that the callback is messing*
>> * things up.  If I assume the same callback, then the callback is*
>> * certainly changing data.  If you can set the right breakpoint, you can*
>> * tag the situation *if* the breakpoint also knows that the process is*
>> * reading from the CAN bus.*
>>
>> * Had you considered disabling that callback function until the read*
>> * from the CANbus is finished?  Would it be practical?  That's where the*
>> * semaphore might help a lot.*
>>
>> * what variables could be common between the two routines?*
>>
>> * Harvey*
>>
>
>Well this is where previous experience fails me. I've pretty much avoided 
>code related to threading in software. In the past. I do know of fork() and 
>roughly what it is capable of, and I know about threads, but not to 
>implement them in C on Linux. Or what can be done with them. Lets talk code 
>a minute.

OK, as well as I can follow it.

>
>*IPC - Server - Reads from canbus*
>int main(){
>struct can_frame frame;
>int sock = InitializeCAN("vcan0");
>
>statistics_t *stats = NULL;
>
>const long shm_size = sysconf(_SC_PAGESIZE);
>
>int shm_fd = shm_open("acme", O_CREAT | O_RDWR, FILE_PERMS);

**NOTE:  the problem may be "acme", since we know that acme products
are not effective against roadrunners.

>if(shm_fd == -1)
>HandleError(strerror(errno));
>
>const int retval = ftruncate(shm_fd, shm_size);
>if(retval == -1)
>HandleError(strerror(errno));
>
>shared_memory = InitializeShm(shm_size * sizeof(char), shm_fd);
>close(shm_fd);
>
>while(1){
>frame = ReadFrame(sock);
>if(frame.can_dlc == FRAME_DLC)
>stats = ProcessFastpacket(frame);

right at this point, you have no protection against access and no
interlocking.

I'll have to give you pseudocode, because I don't know how to do this
in Linux.

In the init routine, before you set up either main as a
process (I assume you do this).  Declare a semaphore:

semaphore_handle shared_access; // create semaphore
handle accessible to both processes.
semaphore_create (shared_access);   // create
semaphore   


then modify this next section to:

if(stats != NULL){
if (semaphore_take(shared_access), ) 
{
WriteToShm(shared_memory, stats);
semaphore_give (shared_access);
}
stats = NULL;
printf("%s", ReadFromShm(shared_memory));
}
   task_delay(n);

NOTE:   Process A hangs until it can "get" the semaphore; if Process B
has it, B can keep it only long enough to send the packet
>
>if(stats != NULL){
>WriteToShm(shared_memory, stats);
>stats = NULL;
>printf("%s", ReadFromShm(shared_memory));
>}
>}
>}/* main() */
>
>
>
>*IPC - Client / webserver*
>
>int main(void) {
>struct mg_server *server = mg_create_server(NULL, ev_handler);
>
>mg_set_option(server, "listening_port", "8000");
>mg_set_option(server, "document_root", "./web");
>
>printf("Started on port %s\n", mg_get_option(server, 
>"listening_port"));
>
>// POSIX IPC - shared memory
>const long shm_size = sysconf(_SC_PAGESIZE);
>int shm_fd = shm_open("file", O_CREAT | O_RDWR, FILE_PERMS);
>if(shm_fd == -1)
>HandleError(strerror(errno));
>
>const int retval = ftruncate(shm_fd, shm_size);
>if(retval == -1)
>HandleError(strerror(errno));
>
>shared_memory = InitializeShm(shm_size * sizeof(char), shm_fd);
>
>close(shm_fd);
>
>char id = 0x00;
>for (;;) {
>mg_poll_server(server, 10);
>  
then do the same here

if (semaphore_take(shared_access), ) 
{
if(shared_memory->sdata.data[19] != id){
 push_message(server,shared_memory->sdata.data);
id =
shared_memory->sdata.data[19];
}  
semaphore_give (shared_access);
}
task_delay (n clock ticks); 

semaphore_take gets the semaphore if and only if it's available.  It
does so in a thread safe manner.  the  is whatever value
the system uses to tell the process to hang.  You don't want the
process to wait and then just go.

Because each example here releases the semaphore (semaphore_give) if
and only if it could get it, and since giving and taking the semaphore
is thread safe, the two threads should be fine.

So your "consumer" thread can't check for valid data until there's
something there.   When it first starts up, it has to get bad (null)
data and throw that away, since you can't guarantee that one thread
starts before the other (unless you block the thread using a suspend,
but that's not really the best thing to d

Re: [beagleboard] Could use some bug tracking advice.

[Harvey White]

On Sun, 23 Aug 2015 19:00:21 -0700, you wrote:

>>
>>
>>
>>
>> *Now *that* should not happen, if it's a context change then you're
>> dealing with a different stack.  These calls should return to where they
>> were when the interrupt/call happened.*
>>
>>
>> * By changing the call table, I can see changing the priorities, but to
>> actually throw away interrupts and things that are on the stack makes no
>> sense.*
>>
>
>Actually you're 100% correct here. What I described can be done with
>embedded devices, but running bare metal code. *That* I've seen
>demonstrations for. Running Linux, the program would produce an exception
>most likely. Too much code on my brain right now . . .
>
>So, knowing my own code I do know what happens. When thinking about it for
>more than 2 seconds heh.
>
>
>   - Process is reading from the canbus, callback happens.
>   - callback function call pops onto the stack, effectively stalling the
>   canbus reads.
>   - callback does it's thing, pops off the stack.
Well, you're certainly right that the callback is messing
things up.  If I assume the same callback, then the callback is
certainly changing data.  If you can set the right breakpoint, you can
tag the situation *if* the breakpoint also knows that the process is
reading from the CAN bus.

Had you considered disabling that callback function until the read
from the CANbus is finished?  Would it be practical?  That's where the
semaphore might help a lot.

what variables could be common between the two routines?

Harvey

>   - canbus read resumes, sees the data it out of sequence, dumps the data,
>   and waits for a new packet set.
>   - rinse / repeat several times a second.
>
>The end result is that the canbus data never sees the light of day so to
>speak.
>
>On Sun, Aug 23, 2015 at 6:25 PM, Harvey White 
>wrote:
>
>> On Sun, 23 Aug 2015 17:57:58 -0700, you wrote:
>>
>> >Harvey,
>> >
>> >I guess I kind of put what I was trying to say badly. Probably more than
>> >once, as I was rereading some of my posts, and there re a few typos /
>> >incomplete words.
>>
>> That's ok.  I make misteaks too
>> >
>> >Anyway, what I mean by "not thread safe" in the context of libmongoose is
>> -
>> >Same thread. Or any mechanism ( perhaps fork(), and same executable
>> threads
>> >) that share a common stack. I'm not all that well versed in many Linux
>> API
>> >calls, but I do have a good many years of programming experience in
>> >multiple languages. Meaning: I can usually code my way out of a wet paper
>> >sack - given enough time  hehe ;)
>>
>> Right, same situation here in a sense, but I've been working my way
>> through writing programs that actually *run* under FreeRTOS, and there
>> have been surprises
>> >
>> >The rationale behind this behavior assuming I understand the library well
>> >enough is that a websockets needs to be reasonably quick, and offer
>> >asynchronous communications. And again this is my assumption . . .yeah
>> yeah
>> >murphy, and mother of all . . .  I get that ;) Problem is, libmongoose is
>> >roughly 10k lines of code, possibly more, and I really did not want to
>> >digest that much code from someone else - YET.
>> >
>>
>> That's the problem about using someone else's code.  If you code it,
>> you deal with the limits of your own ignorance.  If you use someone
>> else's code, then you deal with yours... and theirs.  Part of the
>> difficulty is knowing which is which.
>>
>> That's why in what I do for embedded systems, I use only FreeRTOS and
>> (perhaps) FatFS.  FreeRTOS has caused it's own share of problems, due
>> to some things they assume, and many more that I do
>>
>> >So the callback rate is adjustable. Another problem arises here. If the
>> >callback is too slow, it interferes with the whole control loop - Slows it
>> >down. Kind of a chicken or the egg situation overall.
>>
>> That's a digital control problem, sampled data systems, etc.
>>
>> >
>> >The reason why I posted on this problem, was that I was hoping I was going
>> >to get a simple answer like " hey dummie, you're forgetting to call
>> >fflush() . . ." or something simple like that. Which I know of, but do not
>> >completely understand. fflush() for this situation I do not think applies.
>> >but . . .
>>
>> Sorry that I cannot help you there.  In this situati

Re: [beagleboard] Could use some bug tracking advice.

[Harvey White]

erent stack.  These calls should return to where
they were when the interrupt/call happened.

By changing the call table, I can see changing the priorities, but to
actually throw away interrupts and things that are on the stack makes
no sense.



>This is actually relatively
>new to me as well. As with high level object oriented language this isn't a
>problem. At least I've never had this problem - But can see how this could
>in fact impact C++, which would really be C code in nature.

Except that the people who coded C++ improved it, and that can make a
difference.  I've written many lines of C code for embedded processors
(GCC C, and the MEGA or XMEGA processors) and have not run into this
kind of behavior.  It sounds like a context switch, which gives a
different stack, and then a failure to restore context, which *could*
explain that.  It's a bug, though, at least to me.

>
>Anyway I've seen demonstrations / explanations of this before, but never
>really experienced it first hand until a couple month ago. When first
>trying to implement libmongoose into my own code.

I'd be suspicious of libmongoose, if for no other reason than I do not
understand how a callback (as I understand it, calling a function by a
table lookup, done that lots) could mess up the system like that.
Granted, they are not OS calls, and should be within a thread, but
still.

>
>Anyway, I'm going to implement Semaphores tonight and see how well it
>works. I suspect that I'll run into similar problems I had with my own
>implementation ( binary file locking ), and see odd behavior - Such as
>missing data, and odd process stalling - But I'll find out.

I can only wish you luck on that one.  I can't see Linux or any
variety implementing the kind of behavior you describe, but that means
nothing to an implementation that does that very thing.

Process stalling is caused by deadlocks, or interrupt starvation,
where the process starves because higher priority processes keep
hogging the available time slots.  Those can be fixed

Please keep me informed on your progress, as I'm still puzzled about
this .

Thanks

Harvey

>
>On Sun, Aug 23, 2015 at 5:24 PM, Harvey White 
>wrote:
>
>> On Sun, 23 Aug 2015 16:32:03 -0700, you wrote:
>>
>> >>
>> >> *Linux (someone please correct me if I am wrong) *has* to be thread*
>> >> * safe.*
>> >>
>> >> * The problem I see is that you are not using the parts of the OS that*
>> >> * are designed to keep you from messing things up.*
>> >>
>> >>
>> >> *malloc, or perhaps a version that the OS uses that turns OFF*
>> >> * interrupts and deals with the memory manager in the chips, should
>> only*
>> >> * allocate memory within the program's space, or once that memory is*
>> >> * allocated, automatically assign it to that program.*
>> >>
>> >> * An operating system is about managing resources, giving them to a*
>> >> * program, and making the whole thing graceful.*
>> >>
>> >
>> >Harvey,
>> >
>> >You do understand what happens when you have a function that's on the
>> >stack, that uses local variables, when suddenly a callback interrupts that
>> >function call ? Not only does that function call cease to exist, but all
>> >local variable data is gone. What's more, the function does not even
>> >resume. As it's been popped off the stack.
>>
>> Hmmm, seriously enough, I've not seen that behavior and it doesn't
>> make all that much sense to me about how it works.
>>
>> I'd have thought that if you call another function, even if it's the
>> same in a recursive call *and* the function is reentrant, then I'd
>> expect everything on the stack to be where I left it.
>>
>> I have code that essentially calls a function based on a table entry
>> (of the desired function) that is referred to by an index.
>>
>> It works well.
>>
>> So this particular behavior is a bit odd to me, since it says that the
>> stack is not behaving the way I'd think it was.
>>
>> I'm not sure that this is behaving like a sensible call (even an
>> interrupt or context change).
>>
>> What's the rationale for this kind of behavior?
>>
>> >My comment about malloc() was
>> >tongue in cheek. As it would not even help. Anyway, there probably is a
>> >workaround for this situation that I'm currently not aware of.
>>
>> Depends on whether or not this is an expected behavior and why it
>> happens.
>>
>> Most of my experi

Re: [beagleboard] Could use some bug tracking advice.

[Harvey White]

On Sun, 23 Aug 2015 16:32:03 -0700, you wrote:

>>
>> *Linux (someone please correct me if I am wrong) *has* to be thread*
>> * safe.*
>>
>> * The problem I see is that you are not using the parts of the OS that*
>> * are designed to keep you from messing things up.*
>>
>>
>> *malloc, or perhaps a version that the OS uses that turns OFF*
>> * interrupts and deals with the memory manager in the chips, should only*
>> * allocate memory within the program's space, or once that memory is*
>> * allocated, automatically assign it to that program.*
>>
>> * An operating system is about managing resources, giving them to a*
>> * program, and making the whole thing graceful.*
>>
>
>Harvey,
>
>You do understand what happens when you have a function that's on the
>stack, that uses local variables, when suddenly a callback interrupts that
>function call ? Not only does that function call cease to exist, but all
>local variable data is gone. What's more, the function does not even
>resume. As it's been popped off the stack. 

Hmmm, seriously enough, I've not seen that behavior and it doesn't
make all that much sense to me about how it works.

I'd have thought that if you call another function, even if it's the
same in a recursive call *and* the function is reentrant, then I'd
expect everything on the stack to be where I left it.

I have code that essentially calls a function based on a table entry
(of the desired function) that is referred to by an index.

It works well.

So this particular behavior is a bit odd to me, since it says that the
stack is not behaving the way I'd think it was.

I'm not sure that this is behaving like a sensible call (even an
interrupt or context change).

What's the rationale for this kind of behavior?  

>My comment about malloc() was
>tongue in cheek. As it would not even help. Anyway, there probably is a
>workaround for this situation that I'm currently not aware of.

Depends on whether or not this is an expected behavior and why it
happens.

Most of my experience is with embedded microprocessors and FreeRTOS as
an operating system, although I have written a time slicing
cooperative operating system which did work, just more effort than I
wanted to do to make it pre-emptive.

I'm puzzled right now


>
>This is why libmongoose is not thread safe, and cannot coexist in the same
>executable as my canbus manipulation routines. This is standard behavior
>for libmongoose according to that I've read. Even the maintainer says it's
>not thread safe, if memory serves me correctly.
>

Ah, now if not thread safe, then uses static variables or volatiles,
which I can see.  That could be the answer, but I'm used to writing
either re-entrant code (down to the device drivers) or knowing whether
or not the routine is re-entrant and controlling access by semaphores
or mutexes as needed.

Mostly the non-reentrant code had to be initialized (i.e setting up
heap structures when first called), and the easiest way to do that is
to have a static variable for the heap structures.  Up to me to see
that it is not called in a re-entrant manner, since it will clobber
the heap structure's data on the second call.

Harvey

>
>On Sun, Aug 23, 2015 at 3:57 PM, Harvey White 
>wrote:
>
>> On Sun, 23 Aug 2015 14:51:04 -0700, you wrote:
>>
>> >OK so with all that in mind, I'm back to square 1. These processes can not
>> >share the same memory space. libmongoose seems to love stomping all over
>> >the stack, and I'm fairly sure it is not thread safe. Which is why I'm
>> >using two separate executables.
>>
>> Linux (someone please correct me if I am wrong) *has* to be thread
>> safe.
>>
>> The problem I see is that you are not using the parts of the OS that
>> are designed to keep you from messing things up.
>>
>>
>> >
>> >*OR* maybe I could go crazy and malloc() everything ? heheh no way ;)
>>
>> malloc, or perhaps a version that the OS uses that turns OFF
>> interrupts and deals with the memory manager in the chips, should only
>> allocate memory within the program's space, or once that memory is
>> allocated, automatically assign it to that program.
>>
>> An operating system is about managing resources, giving them to a
>> program, and making the whole thing graceful.
>>
>> Harvey
>>
>> >
>> >On Sun, Aug 23, 2015 at 2:41 PM, Harvey White 
>> >wrote:
>> >
>> >> On Sun, 23 Aug 2015 14:05:12 -0700, you wrote:
>> >>
>> >> >Walter,
>> >> >
>> >> >Thank you for your reply.
&g

Re: [beagleboard] Could use some bug tracking advice.

[Harvey White]

On Sun, 23 Aug 2015 14:51:04 -0700, you wrote:

>OK so with all that in mind, I'm back to square 1. These processes can not
>share the same memory space. libmongoose seems to love stomping all over
>the stack, and I'm fairly sure it is not thread safe. Which is why I'm
>using two separate executables.

Linux (someone please correct me if I am wrong) *has* to be thread
safe.  

The problem I see is that you are not using the parts of the OS that
are designed to keep you from messing things up.


>
>*OR* maybe I could go crazy and malloc() everything ? heheh no way ;)

malloc, or perhaps a version that the OS uses that turns OFF
interrupts and deals with the memory manager in the chips, should only
allocate memory within the program's space, or once that memory is
allocated, automatically assign it to that program.

An operating system is about managing resources, giving them to a
program, and making the whole thing graceful.

Harvey

>
>On Sun, Aug 23, 2015 at 2:41 PM, Harvey White 
>wrote:
>
>> On Sun, 23 Aug 2015 14:05:12 -0700, you wrote:
>>
>> >Walter,
>> >
>> >Thank you for your reply.
>> >
>> >I've examined pretty much all of SYSV and POSIX IPC mechanisms. I'm no
>> >expert here, as this is really my first go with anything IPC, and pretty
>> >much my first "major" application running on Linux.
>>
>> Which means, perhaps, the first application where the OS is a real
>> factor.
>> >
>> >Pipes may not be fast enough for what I'm trying to accomplish. To keep an
>> >explanation short. I'm only tracking one PGN. A PGN for fastpackets is a
>> >set of data items in this case. For this one PGN I'm dealing with 3 items
>> >in data ( voltage, current and frequency ), but program wide I have to
>> keep
>> >track of much more. This PGN is also only one of of roughly 20. WIth most
>> >PGNs issuing data sets of varying length 2 times a second . . .
>>
>> The problem may be more of "how much data and how long to process it"
>> rather than the frequency of the data itself.
>>
>> You are correct to consider context switching time.
>>
>> >
>> >
>> >It may be I'll have to somehow rate limit the data I'll be dealing with. I
>> >did consider POSIX Message queues, but according to what I've read. POSIX
>> >shared memory is the fastest of all IPC mechanisms, and while I do agree
>> >that it is not very easy. Personally, I think shared memory is easy now
>> >that I understand a lot of it. At minimum, it's not very hard to under the
>> >idea, and implement it in code. Semaphores, mutexes, and threads however I
>> >do find a bit intimidating. At minimum, I personally think they're overly
>> >complex.
>>
>> Hmmm, perhaps not quite that intimidating.
>>
>> A thread is a path of execution.  A single program consisting of a
>> loop and a single interrupt has two threads.
>>
>> Threads share common resources, data, address space.  It's up to you
>> to make them well behaved about what changes what and why That's
>> why microprocessors save the registers on the stack for an interrupt.
>>
>> Processes are threads with isolated resources.  Each process ideally
>> thinks that it is the only thing running in a processor, and data just
>> "magically" appears.  The OS's job is to keep the processes separate.
>>
>> Mutexes and semaphores are similar, and are synchronization mechanisms
>> between either threads or processes.  Please look up the definition
>> and explanation of "critical section" in programming.
>>
>> The idea is to have a flag that can be changed without interference
>> from another process, or for that matter, can be read without
>> interfering with another process.  This could be a complete message.
>>
>> The mutexes and semaphores serve to synchronize two processes which,
>> by the very nature of an operating system, *cannot* be guaranteed to
>> by synchronous.
>>
>>
>> >
>> >I have though about a lot of different approaches, and I'm not saying my
>> >approach won't change. This is just where I am right now. Stumbling about
>> >learning the various Linux API's / libraries. Using, and understanding
>> >fork() is on my TODO list, I just have not made it there yet. These two
>> >processes are actually two separate executables. I am a bit worried about
>> >process context switching though. I mean I'm sure I am inuring some
>> p

Re: [beagleboard] Could use some bug tracking advice.

[Harvey White]

 gcc -Wall, gcc will warn. I have no errors or warning when compiling.
>>
>> 3) if both A and B access Internet devices (over the same interface
>> I'd guess), what stops the data collision between process A and
>> process B?  What protects that Internet resource?  What is the result
>> if both A and B read a status register at the same time (in the
>> hardware)?
>>
>> No. I guess more correctly they are socket devices. Both using Linux
>> network sockets. socketcan for CANBus, and standard Linux sockets for
>> ethernet. The web libraries I did not write. It's libmongoose.
>>
>> On Sun, Aug 23, 2015 at 1:06 PM, Harvey White 
>> wrote:
>>
>>> On Sun, 23 Aug 2015 11:44:13 -0700, you wrote:
>>>
>>> >Ok. In my case however -
>>> >
>>> >Process A writes to shared memory only.
>>> >Process B Reads from shared memory only.
>>>
>>> Ok, so that eliminates one form of data corruption.
>>> >
>>> >As it stands Process B starts off with a variable set to 0x00. then
>>> >compares this to a byte position in the file. When Process B first
>>> starts,
>>> >this comparison will always fail. Process B then copies the contents of
>>> the
>>> >file, sets the variable to this value to the value at the byte position.
>>> >Then sends the data out over a websocket.
>>>
>>> Ok:
>>> 1) what stops process A from writing to the shared buffer if process B
>>> is reading it?
>>>
>>> 2) what keeps B from getting an incomplete or inaccurate value from
>>> process A for the byte position?  is it a byte variable or is it an
>>> integer?  Does the processor write this as an integer in one
>>> uninterruptible process?
>>>
>>> 3) if both A and B access Internet devices (over the same interface
>>> I'd guess), what stops the data collision between process A and
>>> process B?  What protects that Internet resource?  What is the result
>>> if both A and B read a status register at the same time (in the
>>> hardware)?
>>>
>>> Harvey
>>>
>>>
>>>
>>> >
>>> >On the next iteration of the loop cycle. Process B then reads this value
>>> >again, makes the comparison - which will likely succeed. The loop cycle
>>> >then continues until this comparison fails again. Where the logic process
>>> >repeats. It's pretty simple - Or so I thought.
>>> >
>>> >The reasoning for this development model is simple. Code segregation.
>>> Code
>>> >in process B does not play well with the code in process A. They're both
>>> >accessing network devices, and when it happen simultaneously - Data gets
>>> >lost. Which happens more often than not.
>>> >
>>> >On Sun, Aug 23, 2015 at 9:39 AM, Harvey White 
>>> >wrote:
>>> >
>>> >> On Sun, 23 Aug 2015 08:52:53 -0700, you wrote:
>>> >>
>>> >> >Hi Harvey,
>>> >> >
>>> >> >Thanks for the response. I think the biggest question in my mind is -
>>> Ok,
>>> >> >so perhaps I have a synchronization problem that rears it's head once
>>> in a
>>> >> >while. But is this really that much of a problem which may cause both
>>> >> >processes to stop ?
>>> >> >
>>> >> >A sample here and there once in a while that does not display,
>>> because it
>>> >> >is malformed does not bother me. The processes stopping - does. I can
>>> not
>>> >> >see how this could be causing the processes to stop. However . . . I
>>> >> >honestly do not know one way or the other.
>>> >>
>>> >> Process A: while process B is busy, wait, then read from process B
>>> >>
>>> >> Process B: while process A is busy, wait, then read from process A
>>> >>
>>> >> Classic deadlock.
>>> >>
>>> >> Process A: wait for permission to read special area, read, then wait
>>> >> outside that permission area.  No restrictions on process B except
>>> >> when accessing special area (which happens infrequently) .
>>> >>
>>> >> Process B: wait for permission to read special area, read, then wait
>>> >> outside that permission area.  No restrictions on process A except
>>> >> when accessing special a

Re: [beagleboard] Could use some bug tracking advice.

[Harvey White]

On Sun, 23 Aug 2015 13:42:29 -0700, you wrote:

>>
>> *1) what stops process A from writing to the shared buffer if process B*
>> * is reading it?*
>
>
>Nothing. I assume that writes are slower, or at most as fast as reads. Both
>reads, and writes are done using a mmap'd pointer.

Murphy says that you cannot guarantee this.
>
>*2) what keeps B from getting an incomplete or inaccurate value from*
>> * process A for the byte position?  is it a byte variable or is it an*
>> * integer?  Does the processor write this as an integer in one*
>> * uninterruptible process?*
>>
>
>Aside from the fact that the byte position I'm testing here is a source ID,
>of two different devices. Nothing. They do come in - in order one after the
>other however. This is not permanent however. When I start tracking more
>data, for one set of data this will still work. But not for other sets of
>data. Write / read type is  char. No way really to get this wrong as with
>gcc -Wall, gcc will warn. I have no errors or warning when compiling.
>

OK, assumption is that they are sequential.  Depends on what the
process switching time is and phase of the moon.  My paranoid
assumption is that they are not necessarily sequential and can occur
at any time in relationship to each other.

char is ok, you don't get corrupted values, but you may get the "last"
value rather than the current one unless you interlock the two tasks.



>3) if both A and B access Internet devices (over the same interface
>I'd guess), what stops the data collision between process A and
>process B?  What protects that Internet resource?  What is the result
>if both A and B read a status register at the same time (in the
>hardware)?
>
>No. I guess more correctly they are socket devices. Both using Linux
>network sockets. socketcan for CANBus, and standard Linux sockets for
>ethernet. The web libraries I did not write. It's libmongoose.
>

Ok, do you know if these functions are thread safe?

I think that's what's giving you problems, the programming is not
thread aware or thread safe.

Harvey

>On Sun, Aug 23, 2015 at 1:06 PM, Harvey White 
>wrote:
>
>> On Sun, 23 Aug 2015 11:44:13 -0700, you wrote:
>>
>> >Ok. In my case however -
>> >
>> >Process A writes to shared memory only.
>> >Process B Reads from shared memory only.
>>
>> Ok, so that eliminates one form of data corruption.
>> >
>> >As it stands Process B starts off with a variable set to 0x00. then
>> >compares this to a byte position in the file. When Process B first starts,
>> >this comparison will always fail. Process B then copies the contents of
>> the
>> >file, sets the variable to this value to the value at the byte position.
>> >Then sends the data out over a websocket.
>>
>> Ok:
>> 1) what stops process A from writing to the shared buffer if process B
>> is reading it?
>>
>> 2) what keeps B from getting an incomplete or inaccurate value from
>> process A for the byte position?  is it a byte variable or is it an
>> integer?  Does the processor write this as an integer in one
>> uninterruptible process?
>>
>> 3) if both A and B access Internet devices (over the same interface
>> I'd guess), what stops the data collision between process A and
>> process B?  What protects that Internet resource?  What is the result
>> if both A and B read a status register at the same time (in the
>> hardware)?
>>
>> Harvey
>>
>>
>>
>> >
>> >On the next iteration of the loop cycle. Process B then reads this value
>> >again, makes the comparison - which will likely succeed. The loop cycle
>> >then continues until this comparison fails again. Where the logic process
>> >repeats. It's pretty simple - Or so I thought.
>> >
>> >The reasoning for this development model is simple. Code segregation. Code
>> >in process B does not play well with the code in process A. They're both
>> >accessing network devices, and when it happen simultaneously - Data gets
>> >lost. Which happens more often than not.
>> >
>> >On Sun, Aug 23, 2015 at 9:39 AM, Harvey White 
>> >wrote:
>> >
>> >> On Sun, 23 Aug 2015 08:52:53 -0700, you wrote:
>> >>
>> >> >Hi Harvey,
>> >> >
>> >> >Thanks for the response. I think the biggest question in my mind is -
>> Ok,
>> >> >so perhaps I have a synchronization problem that rears it's head once
>> in a
>> >> >while. But is this really that much of a problem which may

Re: [beagleboard] Could use some bug tracking advice.

[Harvey White]

On Sun, 23 Aug 2015 11:44:13 -0700, you wrote:

>Ok. In my case however -
>
>Process A writes to shared memory only.
>Process B Reads from shared memory only.

Ok, so that eliminates one form of data corruption.
>
>As it stands Process B starts off with a variable set to 0x00. then
>compares this to a byte position in the file. When Process B first starts,
>this comparison will always fail. Process B then copies the contents of the
>file, sets the variable to this value to the value at the byte position.
>Then sends the data out over a websocket.

Ok:
1) what stops process A from writing to the shared buffer if process B
is reading it?

2) what keeps B from getting an incomplete or inaccurate value from
process A for the byte position?  is it a byte variable or is it an
integer?  Does the processor write this as an integer in one
uninterruptible process?

3) if both A and B access Internet devices (over the same interface
I'd guess), what stops the data collision between process A and
process B?  What protects that Internet resource?  What is the result
if both A and B read a status register at the same time (in the
hardware)?

Harvey



>
>On the next iteration of the loop cycle. Process B then reads this value
>again, makes the comparison - which will likely succeed. The loop cycle
>then continues until this comparison fails again. Where the logic process
>repeats. It's pretty simple - Or so I thought.
>
>The reasoning for this development model is simple. Code segregation. Code
>in process B does not play well with the code in process A. They're both
>accessing network devices, and when it happen simultaneously - Data gets
>lost. Which happens more often than not.
>
>On Sun, Aug 23, 2015 at 9:39 AM, Harvey White 
>wrote:
>
>> On Sun, 23 Aug 2015 08:52:53 -0700, you wrote:
>>
>> >Hi Harvey,
>> >
>> >Thanks for the response. I think the biggest question in my mind is - Ok,
>> >so perhaps I have a synchronization problem that rears it's head once in a
>> >while. But is this really that much of a problem which may cause both
>> >processes to stop ?
>> >
>> >A sample here and there once in a while that does not display, because it
>> >is malformed does not bother me. The processes stopping - does. I can not
>> >see how this could be causing the processes to stop. However . . . I
>> >honestly do not know one way or the other.
>>
>> Process A: while process B is busy, wait, then read from process B
>>
>> Process B: while process A is busy, wait, then read from process A
>>
>> Classic deadlock.
>>
>> Process A: wait for permission to read special area, read, then wait
>> outside that permission area.  No restrictions on process B except
>> when accessing special area (which happens infrequently) .
>>
>> Process B: wait for permission to read special area, read, then wait
>> outside that permission area.  No restrictions on process A except
>> when accessing special area (which happens infrequently) .
>>
>> Since the waiting is outside that special area, and the processes are
>> not allowed to hog the special area (and block the other process),
>> then neither process can block the other except for a very brief time.
>>
>> The implication is that the process check and access special area
>> takes a very small time, and the wait/do something else part takes a
>> longer time.
>>
>> Harvey
>>
>> >On Sun, Aug 23, 2015 at 8:43 AM, Harvey White 
>> >wrote:
>> >
>> >> On Sun, 23 Aug 2015 08:25:02 -0700, you wrote:
>> >>
>> >> >HI Przemek,
>> >> >
>> >> >*Since this involves two processes that as you say stop
>> simultaneously,*
>> >> >> * I'd suspect a latent synchronization bug. You don't say how you*
>> >> >> * interlock your shared memory,  but one possibility is that your
>> >> reader*
>> >> >> * code gets stuck because you overwrite the data while it's reading
>> it.*
>> >> >> * Debugging this type of thing is tricky, but maybe write a state*
>> >> >> * machine that lights some LEDs that show the phases of your*
>> >> >> * synchronization process, and wait to see where it's stuck.*
>> >> >
>> >> >
>> >> >Currently, I have no synchronization. At one point I was using a byte
>> in
>> >> >shared memory as a binary stopgap, but after a while it was not working
>> >> >predictably. Now, I'm re-reading documentation on POSIX semaphores, an

Re: [beagleboard] Could use some bug tracking advice.

[Harvey White]

On Sun, 23 Aug 2015 08:52:53 -0700, you wrote:

>Hi Harvey,
>
>Thanks for the response. I think the biggest question in my mind is - Ok,
>so perhaps I have a synchronization problem that rears it's head once in a
>while. But is this really that much of a problem which may cause both
>processes to stop ?
>
>A sample here and there once in a while that does not display, because it
>is malformed does not bother me. The processes stopping - does. I can not
>see how this could be causing the processes to stop. However . . . I
>honestly do not know one way or the other.

Process A: while process B is busy, wait, then read from process B

Process B: while process A is busy, wait, then read from process A

Classic deadlock.

Process A: wait for permission to read special area, read, then wait
outside that permission area.  No restrictions on process B except
when accessing special area (which happens infrequently) .

Process B: wait for permission to read special area, read, then wait
outside that permission area.  No restrictions on process A except
when accessing special area (which happens infrequently) .

Since the waiting is outside that special area, and the processes are
not allowed to hog the special area (and block the other process),
then neither process can block the other except for a very brief time.

The implication is that the process check and access special area
takes a very small time, and the wait/do something else part takes a
longer time.

Harvey

>On Sun, Aug 23, 2015 at 8:43 AM, Harvey White 
>wrote:
>
>> On Sun, 23 Aug 2015 08:25:02 -0700, you wrote:
>>
>> >HI Przemek,
>> >
>> >*Since this involves two processes that as you say stop simultaneously,*
>> >> * I'd suspect a latent synchronization bug. You don't say how you*
>> >> * interlock your shared memory,  but one possibility is that your
>> reader*
>> >> * code gets stuck because you overwrite the data while it's reading it.*
>> >> * Debugging this type of thing is tricky, but maybe write a state*
>> >> * machine that lights some LEDs that show the phases of your*
>> >> * synchronization process, and wait to see where it's stuck.*
>> >
>> >
>> >Currently, I have no synchronization. At one point I was using a byte in
>> >shared memory as a binary stopgap, but after a while it was not working
>> >predictably. Now, I'm re-reading documentation on POSIX semaphores, and
>> >creating a semaphore in shared memory, instead of using a system wide
>> >resource.
>>
>> Then you have two things that happen with no predictable time
>> relationship to each other at all.
>>
>> You could be writing part of a multibyte message when trying to read
>> that message with another process.
>>
>> A binary semaphore controls access to the shared (message) resource.
>> Checking the binary semaphore generally involves turning off
>> interrupts so that the other process can't grab control during the
>> check code.  If you have two separate processors, you still need to
>> deal with the same thing, not so much interrupts, but permission to
>> access.  The semaphore read/write must be atomic, and the access must
>> be negotiated between the two processors (generally happens in
>> hardware for two processors, happens in software for two processes
>> running on the same processor).
>> >
>> >*I'd definitely look at this malformation---it could be the smoke from*
>> >> * the real fire. Or not. In any case, this one should be easier to*
>> >> * find---just wait for the message, inspect the data in firebug, and*
>> >> * write a checker routine, inspecting your outgoing data, that watches*
>> >> * for this type of distortion. *
>> >
>> >
>> >The first thing that comes to mind here, which I forgot to add to my post
>> >last night is that I am not zeroing out the shared memory file before
>> >usage. I know this is bad . . .but am not convinced this is what the
>> >problem is. However since it is / can be a one line of code fix. I will do
>> >so. The odd thing here is that I get maybe 1-2 notifications an hour - If
>> >that. Then it is inside the actual json object ( string pointer - e.g.
>> char
>> >*buffer ) - not outside.
>> >
>> >What does all this mean to me. The first impression that I get out of this
>> >is that it is a synchronization issue. I'm still not convinced though . .
>> .
>> >
>>
>> analyze the code to see what happens if one process is writing while
>> the other is reading.
>>
>> 

Re: [beagleboard] Could use some bug tracking advice.

[Harvey White]

On Sun, 23 Aug 2015 08:25:02 -0700, you wrote:

>HI Przemek,
>
>*Since this involves two processes that as you say stop simultaneously,*
>> * I'd suspect a latent synchronization bug. You don't say how you*
>> * interlock your shared memory,  but one possibility is that your reader*
>> * code gets stuck because you overwrite the data while it's reading it.*
>> * Debugging this type of thing is tricky, but maybe write a state*
>> * machine that lights some LEDs that show the phases of your*
>> * synchronization process, and wait to see where it's stuck.*
>
>
>Currently, I have no synchronization. At one point I was using a byte in
>shared memory as a binary stopgap, but after a while it was not working
>predictably. Now, I'm re-reading documentation on POSIX semaphores, and
>creating a semaphore in shared memory, instead of using a system wide
>resource.

Then you have two things that happen with no predictable time
relationship to each other at all.

You could be writing part of a multibyte message when trying to read
that message with another process.

A binary semaphore controls access to the shared (message) resource.
Checking the binary semaphore generally involves turning off
interrupts so that the other process can't grab control during the
check code.  If you have two separate processors, you still need to
deal with the same thing, not so much interrupts, but permission to
access.  The semaphore read/write must be atomic, and the access must
be negotiated between the two processors (generally happens in
hardware for two processors, happens in software for two processes
running on the same processor).
>
>*I'd definitely look at this malformation---it could be the smoke from*
>> * the real fire. Or not. In any case, this one should be easier to*
>> * find---just wait for the message, inspect the data in firebug, and*
>> * write a checker routine, inspecting your outgoing data, that watches*
>> * for this type of distortion. *
>
>
>The first thing that comes to mind here, which I forgot to add to my post
>last night is that I am not zeroing out the shared memory file before
>usage. I know this is bad . . .but am not convinced this is what the
>problem is. However since it is / can be a one line of code fix. I will do
>so. The odd thing here is that I get maybe 1-2 notifications an hour - If
>that. Then it is inside the actual json object ( string pointer - e.g. char
>*buffer ) - not outside.
>
>What does all this mean to me. The first impression that I get out of this
>is that it is a synchronization issue. I'm still not convinced though . . .
>

analyze the code to see what happens if one process is writing while
the other is reading.  

The error rate may be just a measure of how frequently this happens.

Harvey


>Also, for what it's worth. I'm using mmap() and not file open(), read(),
>write(). So the code is very fast.
>
>On Sun, Aug 23, 2015 at 6:40 AM, Przemek Klosowski <
>przemek.klosow...@gmail.com> wrote:
>
>> On Sun, Aug 23, 2015 at 1:31 AM, William Hermans 
>> wrote:
>> > So I have a problem with some code I've been working on for the last few
>> > months. The code, which is compiled into two separate processes suddenly
>> > stops working. No error, nothing in dmesg, nothing in any file in
>> /var/log
>> > period. It did however occur to me that since rsyslog is likely or
>> possible
>> > disabled.
>> >
>> > What my code does is read from the CAN peripheral. Form extended packets
>> out
>> > of the CAN frames( NMEA 2000 fastpackets ), and then writes the data
>> into a
>> > POSIX shared memory file ( /dev/shm/file ).
>>
>> Since this involves two processes that as you say stop simultaneously,
>> I'd suspect a latent synchronization bug. You don't say how you
>> interlock your shared memory,  but one possibility is that your reader
>> code gets stuck because you overwrite the data while it's reading it.
>> Debugging this type of thing is tricky, but maybe write a state
>> machine that lights some LEDs that show the phases of your
>> synchronization process, and wait to see where it's stuck.
>>
>> > The second process simply reads
>> > from the file, and shuffles the data out over a websocket in json / human
>> > readable form. The data on the webside of things is tested accurate,
>> > although I do occasionally get a malformed json object warning from
>> firefox
>> > firebug.
>>
>> I'd definitely look at this malformation---it could be the smoke from
>> the real fire. Or not. In any case, this one should be easier to
>> find---just wait for the message, inspect the data in firebug, and
>> write a checker routine, inspecting your outgoing data, that watches
>> for this type of distortion.
>>
>> --
>> 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.
>> 

Re: [beagleboard] Re: What should I begin with the C language pru

[Harvey White]

On Fri, 21 Aug 2015 14:15:52 -0700 (PDT), you wrote:

>From what I understand from the comments of CNC writers, even Linux
(unless the kernel has been tweaked to allow this) does not allow real
time response.

Windows certainly not, Linux has to be specially engineered (IIRC) to
give you *accurate* real time response and freedom from extraneous
events.

What you need is hardware doing this, with software in control.  I
might suggest an FPGA or a CPLD,   You could also put another
processor in the mix, be it internal or external on a cape, and let it
do the work.  It would have to be specifically programmed to do this
particular task within the timing requirements you have.

Otherwise, the OS does what it wants to do, when it wants to do it,
and your request is in a queue... somewhere..

Harvey


>
>
>On Wednesday, August 19, 2015 at 12:06:08 PM UTC-5, Carlos Novaes wrote:
>>
>>
>> I tend to agree with that most of the time. Maybe I am biasing my question 
>> on a limited experience with PRU applications. 
>> From my point of view PRU are good for relatively simple tasks, that 
>> should be fast and kept independent from ARM and the OS load. C seems to be 
>> a logic choice for the majority of the cases, but if (and here I beg to my 
>> only experience with PRU), there are some critical timing involved, like 
>> ensuring some actions are performed periodically. Is it possible and simple 
>> to keep track of the execution time (the number of pru clock cycles) a 
>> piece of code written in C takes to execute?
>>
>
>I think there are a couple of standard things people tend to need from 
>micros like this:
>
>1.) I need something to happen quickly and regularly below the threshold of 
>_Hz / KHz / MHz.  They may not need the timing of anything within that 
>to be perfectly predictable, it just needs to happen fast enough.   That is 
>something I prefer to do in C if I can.   I simply need the activity to 
>take place more regularly than Linux can get it done.   8K is not much 
>memory to do a ton of stuff in so the program needs to be relatively 
>simple.C can do simple pretty well.   ASM makes the simple complex on 
>it's own.
>
>2.) I need this to happen exactly 200ns after that happens and then I need 
>to repeat that again in 30ns.   This is where ASM starts to win.   You can 
>mess with C to get that to happen but then it starts to look easier to just 
>write the thing in ASM since the timing is straight-forward.   Stuffing ASM 
>inline with the C code is possible too if the rest of the program makes 
>writing it all in ASM daunting.   But there I see ASM as an easy way to get 
>the timing needed as long as you can stand the tedious nature of getting 
>anything done in ASM.

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

Re: [beagleboard] Add DTS for MikroBus Cape for BBB

[Harvey White]

On Mon, 3 Aug 2015 19:57:03 -0700 (PDT), you wrote:

>the following command line does indeed instantiate the 24c256 eeprom 
>special file.
>
>root@beaglebone:~# echo 24c256 0x50 > /sys/bus/i2c/devices/i2c-1/new_device 
>
>While using this definition to write to a 24c01 did seem to work, it seems 
>that once I wrote past the last byte it started over writing the contents 
>at the beginning again (No errors reported). Defining a new device as a 
>24C01 gets everything aligned size wise.

Right.  To be expected.  The larger chip has a 128 byte page size, and
that's the size of the whole 24C01.  The 24C01 has a page size of 16
or 32 (think it's 16).  What ought to happen is that you will wrap in
an absolute page of 16 (0-16, 17-32, etc) when you write at say
location 8 and try to do 16 bytes, it writes the upper 8, wraps to the
lower 8, and never tells you) (nasty).

The driver will split things up based on the absolute address, so
you'd get a write on 8-15, then a second one from 16 to 23.   That
works.

Specifying a larger chip simply let's it try to write that page size
as an entire block, rather than breaking it up.

if the driver knows about chip sizes, then someone did their job right
and you just need to know the chip type to figure out what the chip
really is.   Good job.

>
>Anyways, the click boards sound like a fun effort. I'm going to start with 
>their MPU 9DOF IMU board. Bosch has a device- a BNO0055 that implements 
>euler angles or quarternions. It would be nice to implement that as well 
>otherwise I'll have to do that on the ARM FP. Hope it can keep up.
>
>Thanks for your help Harvey!

Glad to help.  Convenient that I had to solve the problem so I
remembered the details.

Harvey

>
>Best,
>Mike
>On Saturday, August 1, 2015 at 9:35:36 PM UTC-7, Harvey White wrote:
>
>> On Sat, 1 Aug 2015 19:43:42 -0700, you wrote: 
>>
>> >Sounds like the two of you have it "surrounded". Good info Harvey :) 
>>
>> Thanks.  Came from deciphering the data sheet and figuring out what 
>> they *really* meant. 
>>
>> I do a similar thing as the capes with an Xmega design (got a bunch of 
>> them, and they come in packages I can deal with).  Some pin 
>> multiplexing is done, but the configuration EEPROM is used as a system 
>> resource to any other processor in the system (it's multiprocessor by 
>> intent), and additional data storage when needed.  Much of the 
>> configuration data is in the processors EEPROM store, which allows a 
>> graphics board (generic, supports 128x64 up to VGA with the same chip) 
>> to be built for a particular display, keep the programming "off site" 
>> and have the programming updated without losing the customization. 
>>
>> Internal EEPROM can be memory mapped and is thus easier to access. 
>>
>> AT24C driver should work for just about any of the chips. 
>>
>>
>> Harvey 
>>
>>
>> > 
>> >On Sat, Aug 1, 2015 at 7:16 PM, Harvey White > > wrote: 
>> > 
>> >> On Sat, 1 Aug 2015 18:27:14 -0700 (PDT), you wrote: 
>> >> 
>> >> >I have a quick question about supported i2c eeprom types. 
>> >> > 
>> >> >From the user side is there a way to query/list supported types (ie. 
>> >> >24c256)? 
>> >> 
>> >> The 24C256 is 32K * 8, and as such, needs a 16 bit address.  This 
>> >> particular chip ignores the most significant bit of the address.  With 
>> >> this same addressing model, the maximum capacity would be 64K, which 
>> >> would use all 16 bits, and would be a 24C512. 
>> >> 
>> >> The 24C1024 will need 3 address bytes, not two, and unless the driver 
>> >> knows to put in that third address byte, the maximum addressable range 
>> >> is 64K. 
>> >> 
>> >> Further, there are several ways of writing data, either page mode or 
>> >> byte mode.  Byte mode needs an address for each byte.  Page mode must 
>> >> be written so that the data does NOT cross an absolute page boundary, 
>> >> otherwise it wraps without an error and you get bad data written. Page 
>> >> size does vary amongst the various chips in the family.  You write a 
>> >> page (or part of a page) without wrapping, and then the chip refreshes 
>> >> and writes the new page. 
>> >> 
>> >> Reading must be done by starting a write (chip address and 16 address 
>> >> bits), a repeated start, and then the chip address as read.  Data can 
>> >> be read as long as the read sequence is active, page 

Re: [beagleboard] Add DTS for MikroBus Cape for BBB

[Harvey White]

On Sat, 1 Aug 2015 19:43:42 -0700, you wrote:

>Sounds like the two of you have it "surrounded". Good info Harvey :)

Thanks.  Came from deciphering the data sheet and figuring out what
they *really* meant.

I do a similar thing as the capes with an Xmega design (got a bunch of
them, and they come in packages I can deal with).  Some pin
multiplexing is done, but the configuration EEPROM is used as a system
resource to any other processor in the system (it's multiprocessor by
intent), and additional data storage when needed.  Much of the
configuration data is in the processors EEPROM store, which allows a
graphics board (generic, supports 128x64 up to VGA with the same chip)
to be built for a particular display, keep the programming "off site"
and have the programming updated without losing the customization.

Internal EEPROM can be memory mapped and is thus easier to access.

AT24C driver should work for just about any of the chips.


Harvey


>
>On Sat, Aug 1, 2015 at 7:16 PM, Harvey White  wrote:
>
>> On Sat, 1 Aug 2015 18:27:14 -0700 (PDT), you wrote:
>>
>> >I have a quick question about supported i2c eeprom types.
>> >
>> >From the user side is there a way to query/list supported types (ie.
>> >24c256)?
>>
>> The 24C256 is 32K * 8, and as such, needs a 16 bit address.  This
>> particular chip ignores the most significant bit of the address.  With
>> this same addressing model, the maximum capacity would be 64K, which
>> would use all 16 bits, and would be a 24C512.
>>
>> The 24C1024 will need 3 address bytes, not two, and unless the driver
>> knows to put in that third address byte, the maximum addressable range
>> is 64K.
>>
>> Further, there are several ways of writing data, either page mode or
>> byte mode.  Byte mode needs an address for each byte.  Page mode must
>> be written so that the data does NOT cross an absolute page boundary,
>> otherwise it wraps without an error and you get bad data written. Page
>> size does vary amongst the various chips in the family.  You write a
>> page (or part of a page) without wrapping, and then the chip refreshes
>> and writes the new page.
>>
>> Reading must be done by starting a write (chip address and 16 address
>> bits), a repeated start, and then the chip address as read.  Data can
>> be read as long as the read sequence is active, page boundaries are
>> not significant here.  If no address is provided, the previous address
>> is used as a start and automatically incremented each byte read.
>>
>> So basically, 24C01, 24C02, 24C04, 24C08, 24C16, 24C32, 24C64, 24C128,
>> 24C256 and 24C512 can all be handled with 16 bit addresses.  The
>> 24C1024 and above need the 24 bit address driver.  If the driver knows
>> the page size, then all of these chips can be written by the same
>> driver.  Reading can handle any of these chips.
>>
>> Had to write a driver for these chips a few weeks back.
>>
>> Pretty much anything in the 24C series below a 24C1024 can be read and
>> written by the same driver if you know the parameters.  1024 and above
>> can be handled if the driver is smart enough.
>>
>> No idea how the existing driver is written, but this is what's
>> involved.
>>
>> Harvey
>>
>>
>> >Conversely, is there a way to define a new type from user space and add
>> it,
>> >maybe through i2c-1/new_device?
>> >
>> >Documentation other than the SRM?
>> >
>> >Thanks!
>> >
>> >
>> >On Thursday, July 30, 2015 at 8:42:05 AM UTC-7, Michael Carr wrote:
>> >>
>> >> Hi Robert, Jason and William,
>> >>
>> >> Sorry for not pulling the device tree files, I've been out of town. I
>> hope
>> >> the files help someone in the future if they purchase a mikroBus cape.
>> >>
>> >> This morning I found that the mikroBus cape is using a Microchip 24AA01
>> >> (1K, 128 x 8) eeprom not a 24C256. Two questions came to mind after I
>> found
>> >> this out.
>> >>
>> >> 1.) The Microchip 24AA01 doesn't use A0 ~ A2 (Don't Care). Responds to
>> any
>> >> 0x5X address. Potential cape addressing conflicts here.
>> >> 2.) The non-B version clock is limited to 100Khz.
>> >>
>> >> Is the default clock for i2c bus 1 > 100khz? Ex. 400Khz 1000Khz? Can I
>> >> force it to 100 Khz?
>> >>
>> >> Yep, having problems writing to the eeprom. The schematics don't agree
>> >> with the delivered board.
>> >> L

Re: [beagleboard] Add DTS for MikroBus Cape for BBB

[Harvey White]

On Sat, 1 Aug 2015 18:27:14 -0700 (PDT), you wrote:

>I have a quick question about supported i2c eeprom types.
>
>From the user side is there a way to query/list supported types (ie. 
>24c256)?

The 24C256 is 32K * 8, and as such, needs a 16 bit address.  This
particular chip ignores the most significant bit of the address.  With
this same addressing model, the maximum capacity would be 64K, which
would use all 16 bits, and would be a 24C512.

The 24C1024 will need 3 address bytes, not two, and unless the driver
knows to put in that third address byte, the maximum addressable range
is 64K.

Further, there are several ways of writing data, either page mode or
byte mode.  Byte mode needs an address for each byte.  Page mode must
be written so that the data does NOT cross an absolute page boundary,
otherwise it wraps without an error and you get bad data written. Page
size does vary amongst the various chips in the family.  You write a
page (or part of a page) without wrapping, and then the chip refreshes
and writes the new page.

Reading must be done by starting a write (chip address and 16 address
bits), a repeated start, and then the chip address as read.  Data can
be read as long as the read sequence is active, page boundaries are
not significant here.  If no address is provided, the previous address
is used as a start and automatically incremented each byte read.

So basically, 24C01, 24C02, 24C04, 24C08, 24C16, 24C32, 24C64, 24C128,
24C256 and 24C512 can all be handled with 16 bit addresses.  The
24C1024 and above need the 24 bit address driver.  If the driver knows
the page size, then all of these chips can be written by the same
driver.  Reading can handle any of these chips.

Had to write a driver for these chips a few weeks back.

Pretty much anything in the 24C series below a 24C1024 can be read and
written by the same driver if you know the parameters.  1024 and above
can be handled if the driver is smart enough.

No idea how the existing driver is written, but this is what's
involved.

Harvey


>Conversely, is there a way to define a new type from user space and add it, 
>maybe through i2c-1/new_device?
>
>Documentation other than the SRM?
>
>Thanks!
>
>
>On Thursday, July 30, 2015 at 8:42:05 AM UTC-7, Michael Carr wrote:
>>
>> Hi Robert, Jason and William,
>>
>> Sorry for not pulling the device tree files, I've been out of town. I hope 
>> the files help someone in the future if they purchase a mikroBus cape.
>>
>> This morning I found that the mikroBus cape is using a Microchip 24AA01 
>> (1K, 128 x 8) eeprom not a 24C256. Two questions came to mind after I found 
>> this out.
>>
>> 1.) The Microchip 24AA01 doesn't use A0 ~ A2 (Don't Care). Responds to any 
>> 0x5X address. Potential cape addressing conflicts here.
>> 2.) The non-B version clock is limited to 100Khz.
>>
>> Is the default clock for i2c bus 1 > 100khz? Ex. 400Khz 1000Khz? Can I 
>> force it to 100 Khz?
>>
>> Yep, having problems writing to the eeprom. The schematics don't agree 
>> with the delivered board.
>> Looks like they intended to use the 24C256 but in manufacturing they used 
>> the 24AA01 instead.
>>
>> Mike
>>
>>
>> On Monday, July 27, 2015 at 10:27:54 AM UTC-7, RobertCNelson wrote:
>>>
>>> Thanks! Pushed as part of: 
>>>
>>>
>>> https://github.com/RobertCNelson/bb-kernel/commit/c43f83c076c30cfbd98d4c00f962ca22a9563933
>>>  
>>>
>>> On Thu, Jul 16, 2015 at 10:59 AM, Michael Carr  wrote: 
>>> > Hi Robert, 
>>> > 
>>> > I've ordered a MikroBus cape from MikroElektronica. They have a device 
>>> tree 
>>> > source file to support the cape. May I pass it along to you to add to 
>>> > github? 
>>> > 
>>> > The eeprom on the card is empty and I will need to generate the 
>>> contents. 
>>> > Does anyone have a tool to create/read/write eeprom contents via 
>>> cloud9? I 
>>> > tried running eeprom-web.js and I get a cloud9 error. 
>>> > 
>>> > Thanks, 
>>> > Mike 
>>> > 
>>> > -- 
>>> > 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. 
>>> > For more options, visit https://groups.google.com/d/optout. 
>>>
>>>
>>>
>>> -- 
>>> Robert Nelson 
>>> https://rcn-ee.com/ 
>>>
>>

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

Re: [beagleboard] What happens on read/write conflict on the PRU scrartchpad?

[Harvey White]

On Sat, 1 Aug 2015 14:17:45 -0700 (PDT), you wrote:

>The way you put it made complete sense. Probably I will do it with some 
>interruption handling, better safe than sorry.
>But being a hardware guy, this raises a philosophical question: Why handle 
>the case when two simultaneous writes are performed and don't even care in 
>this other case? Maybe because there are interruptions to handle this? 
>Well, then why not just use this same interrupts to also block the 
>simultaneous writes?

However well (or not) it is handled in hardware, the problem is well
known in operating systems, which have two (or more) effective
simultaneous processes going on at the same time.  Synchronization
between processes becomes critical under certain circumstances.  You
may have that kind of problem.

Consider what happens when you write a string of bytes/words rather
than a single one.  What happens if that's interrupted halfway
through?  In an operating system, it can happen.  

Harvey


>
>Le samedi 1 août 2015 17:59:16 UTC-3, William Hermans a écrit :
>>
>> *The 15ns are important as long as my third guess is proved to be 
>>> impossible. This conflict is unlikely to happen and so I can live with 
>>> either a 5ns jitter or a repeated sample. But I can not allow for a 
>>> corrupted reading that may even interpret a signal to shutdown my pwm 
>>> module. *
>>>
>>
>>  
>> And this is what could happen if one PRU is reading while another is 
>> writing.
>>
>> As far as blocking / non blocking. I honestly do not know. But is my 
>> instinct that if it is not explicitly mentioned as being a blocking call - 
>> It will be non blocking.
>>  
>>
>> On Sat, Aug 1, 2015 at 1:40 PM, Carlos Novaes > > wrote:
>>
>>> Hi Willian,
>>> Thank you for your insights.
>>>
>>> I am thinking how to write a test code to determine exactly what happens, 
>>> but it is not as trivial to me.
>>>
>>> The point with POSIX shared memory is, on my understanding, valid until 
>>> some extent. It takes one cycle for the PRU to read from or write to the 
>>> scratch pad register. That is just one cycle to back up the entire (or 
>>> partial) contents of the registers and another cycle to get them back (on 
>>> the same or on the other PRU). 
>>>
>>> To clarify, my first guess is that PRU0 wil be blocked until PRU1 
>>> complete the writing, so it wil read in two cycles. The effect on the pwm 
>>> outputs will be a 5ns jitter.
>>>
>>> The 15ns are important as long as my third guess is proved to be 
>>> impossible. This conflict is unlikely to happen and so I can live with 
>>> either a 5ns jitter or a repeated sample. But I can not allow for a 
>>> corrupted reading that may even interpret a signal to shutdown my pwm 
>>> module. 
>>> Well, I am just trying to push the PRU to its limits and got four pwm (10 
>>> bits) and three output pins driven at 19531 samples per second with no 
>>> software induced jitter (every execution path takes exactly the same time, 
>>> so any jitter is hardware related). By including the interrupt control the 
>>> sample rate will drop to 15024 samples per second or a little less. Of 
>>> course this is all in vain if I cannot get the ARM running at 1GHz to 
>>> process the inputs and generate a control action at this rate even with a 
>>> high priority task.
>>>
>>>
>>>
>>>
>>> Le samedi 1 août 2015 15:35:24 UTC-3, William Hermans a écrit :

 Hey Carlos,

 So, let me say up front that I have zero hands on with the PRUs. But 
 have experienced something similar recently with Linux shared memory using 
 mmap. Which *may* not be as fast as the PRU's but was fast enough to 
 produce output fast enough to "flood" out / crash firefox within seconds.


 *Will PRU0 or PRU1 stall and wait for the other to complete the access?*
> * Will PRU0 read the previous data?*
> * Will PRU1 read corrupted data?*


 I would think that neither of these cases would be desirable. But in the 
 case of the second and third question, both could be possible - e.g. 
 undefined behavior. In the first question I'm not sure what you mean 
 exactly, but I did again experience something similar with POSIX shared 
 memory.

 To explain further. Two processes, one reading, one writing. The process 
 doing the writing has more to do and hence is not as fast as the reading 
 process. In this case, the reader literally locked out the writer, since 
 it 
 was able to access the file so fast. The end result was that the writer 
 process was able to write to this memory once, after which is was 
 completely locked out but the reader process.

 *PRU0 will send a interrupt to PRU1 every time it read the scratchpad. 
> Also I can let PRU1 interrupt PRU0 to signal that the new data are ready, 
> but doing so will waste at least two or three cycles. *  


 Is ~ 15ns that important ? versus not knowing what may happen?

 Anyway, t

Re: [beagleboard] Question about applying voltage to an unpowered BBB.

[Harvey White]

On Mon, 27 Jul 2015 00:18:48 -0700 (PDT), you wrote:

>
>Alright, I know that there are a lot of discussions on here about this 
>topic, and I have read through them, but I am still a bit confused about 
>this line in the manual:
>NOTE: DO NOT APPLY VOLTAGE TO ANY I/O PIN WHEN POWER IS NOT SUPPLIED TO THE 
>BOARD. IT WILL DAMAGE THE PROCESSOR AND VOID THE WARRANTY.
>NO PINS ARE TO BE DRIVEN UNTIL AFTER THE SYS_RESET LINE GOES HIGH.
>
>I am working on a project that will involve me using multiple sensors with 
>the BBB that are powered from another source. One of those sensors is a GPS 
>that spits out data as long as it is powered, but the others only send data 
>after they have received a request. Here are my questions:

Opinions follow:

>
>1. Based on that statement, it is my understanding that if the GPS I'm 
>using is powered and the BBB is not, then the BBB will be damaged. Is this 
>accurate?

That's what it says.

>2. What if the board and all the sensors are powered from the same source 
>controlled by a single switch? Will this damage the board when I flip on 
>the switch?

The problem could be if the sensor power comes up before the board is
fully powered up, and that would be a problem.

>3. What if I power all the sensors from the board itself so that it is 
>impossible for them to receive power before the board does? Will this 
>damage the board?

Better solution, and is only based on the board's capability of
supplying the power.  This is how the capes operate, IIRC.

Another possibility is to have external power for the sensors
controlled by either a relay or a solid state switch, biased so that
the switch is off unless a voltage is applied to the switch control
pin.  

This allows the sensors to be shut down for lower consumption if
needed (or if useful), but does give you rather complete power control
over the sensors.  I'd use a bidirectional driver with separate power
lines (normally used to do level translation).  IIRC those chips do
not drive with power off on one side.  This not only protects the
processor, but gives you some additional buffering.

Harvey


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

Re: [beagleboard] Reading the ADCs with C Code

[Harvey White]

On Mon, 13 Jul 2015 13:04:05 -0700 (PDT), you wrote:

>
>Hey Everyone,
>
>I'm using the Beaglebone ADC on AIN0 (P9-39) to monitor a high voltage. 
>I've used a divider (1/100) to put it within the 1.8V range of the ADC.I am 
>using the cape overlay BB-ADC suggested by Derrick Molloy in Exploring BB. 
>I've measured the voltage at the pin while using "cat 
>/sys/devices/ocp.3/helper.12" and it agrees with my multimeter measurement 
>at the pin. It seems the helper gives a direct mV value. They agree. 
>Awesome!
>
>I'm trying to use this same technique with my C code, but for some reason 
>I'm getting weird values from my read function. I think it has something to 
>do with reading two bytes from the 12 bit ADC converter. I'm thinking I'm 
>getting some junk on the end or the beginning, but masking and getting rid 
>of the first or last 4 bits does not get the number I received from the 
>cat'ing the helper device.
>
>Am I reading this wrong with my code?  Does anyone have any ideas to get 
>the correct 12 bits?

Several generic things may be bothering this:

1) you have interrupts enabled and you're getting a task switch during
the read.  Solution:  Make the read atomic.

2) the register order can be wrong.  Some processors require a
specific order to read 8 bit registers.  If this processor has that
same problem and you're not reading the entire register at one gulp,
then that can be a problem.  This should be compensated for in the
compiler, though, so interrupts enabled could be more of a problem.

Harvey


>
>Thanks! I think I gave enough information below.
>
>*Test Code:*
>
>#include 
>#include 
>#include 
>#include 
>#include 
>#include 
>#include 
>#include 
>#include 
>#include 
>#include "DDC2.h"
>
>
>int main ( int argc, const char *argv[] )
>{
>float voltage;
>voltage = atof ( argv[1] );
>set_high_voltage ( voltage );
>read_raw_high_voltage ( );
>return 0;
>}
>
>*Read Function:*
>
>/***
>* Function- read_high_voltage
>* Description- Reads the ADC on AIN0 and returns the measured value of the
>* high voltage.
>/
>int read_raw_high_voltage(void)
>{
>uint16_t fd;
>uint16_t value;
>uint16_t value1;
>uint16_t value2;
>//Open "analog0=/sys/devices/ocp.3/helper.12/AIN0"
>if ( ( fd = open ( analog0, O_RDONLY) ) < 0 )  
>  {
>  perror ("SPI: Can't open device.");
>return -1;
>}
>read ( fd, &value, 2);
>value1=value & 0x0FFF;
>value2=value>>4;
>printf ("All Bits=%d\n", value);
>printf ("Bits 0-12=%d\n", value1);
>printf ("Bits 4-16=%d\n", value1);
>return(0);
>}
>
>*From Command line:*
>
>./test 60
>
>*Output:*
>
>Voltage Given=60.0
>All Bits= 14389
>Bit 0-12=2101
>Bit 4-16=899
>
>Measured Voltage from Multimeter= 600mV (measured after 1/100 voltage 
>divider)
>
>Cat from the helper device = 587

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

Re: [beagleboard] Industry Standard?

[Harvey White]

On Thu, 9 Jul 2015 13:10:56 -0700 (PDT), you wrote:

>Do any of the Beagle Boards, or any other single-board computer for that 
>matter, come in any kind of industry standard form factor?  Management 
>keeps asking "What if beagle board goes bankrupt", and it would make my 
>life easier if I could answer "We can always switch to brand X since it has 
>the same form factor and connectors" ...

The only ones I've seen, in my somewhat limited experience, are boards
designed to plug into a PC bus, such as the XT or AT slot SBC's.  If
you wish a guaranteed complete and forever guarantee of compatibility,
then I think you're looking at either eventually designing your own
board to a specific form factor, or designing your own board
completely.  

Perhaps you might consider one of the popular "standards", use an
existing board while working on your own, and at least be able to use
an existing population of capes/shields/daughterboards, etc.

Harvey

>
>Thanks,
>Chris

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

Re: [beagleboard] Problemas para comunicar com o Baud Rate 5760

[Harvey White]

On Thu, 9 Jul 2015 09:39:28 -0700 (PDT), you wrote:

>The pump has closed protocol and communicates via current loop, use a 
>serial loop converter to communicate. I have an application that works that 
>way with several pumps market the only problem with this is the BAUDRATE. 
>Does anyone know how to configure the serial port to work with BAUDRATE of 
>5760? This is my only doubt.

5760 is not standard...  could it be 57600?

Otherwise there is a baudrate register that must be adjusted.

Harvey

>
>Em quinta-feira, 9 de julho de 2015 12:13:15 UTC-3, Wulf Man escreveu:
>>
>>  paste a link to this fuel pump
>>
>>
>> On 7/9/2015 7:57 AM, Marlon Cesar Pilonetto wrote:
>>  
>>  The baud rate the fuel pump uses is 5760 and I am unable to communicate 
>> with her through my application. The same application on fuel pumps with 
>> baud rate 9600 works perfectly .
>>
>>
>> Em quarta-feira, 8 de julho de 2015 14:23:33 UTC-3, Wulf Man escreveu: 
>>>
>>>Standard baud rates supported by most serial ports: 
>>> 110  
>>> 300 
>>> 600  
>>> 1200 
>>> 2400  
>>> 4800 
>>> 9600  
>>> 14400 
>>> 19200  
>>> 28800 
>>> 38400  
>>> 56000 
>>> 57600  
>>> 115200   
>>>
>>>   Standard baud rates supported by some serial ports: 
>>> 128000  
>>> 153600 
>>> 230400  
>>> 256000 
>>> 460800  
>>> 921600   
>>>
>>> is your baud rate somewhere in this chart ?
>>>
>>>
>>>
>>> On 7/8/2015 7:20 AM, marlon.p...@gmail.com wrote:
>>>  
>>>  Hello,
>>>
>>>  Excuse my lack of knowledge on the subject as it is the first time I am 
>>> working with BEAGLEBONE. So I'm trying to communicate with a fuel pump that 
>>> has a BaudRate of 5760'm using node js in my application. However I can not 
>>> even configure the serial port with this BaudRate, can anyone help me with 
>>> this please.
>>>  -- 
>>> 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.
>>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>  

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

Re: [beagleboard] Overvoltage Protection on ADC

[Harvey White]

On Mon, 6 Jul 2015 21:09:36 -0700 (PDT), you wrote:

>I would like to use the BBB to measure the voltage on two battery banks (12V 
>and 24V). The batteries can go well above the nominal voltages however to 15 
>and 30 volts at max respectively. In addition to using a resistive voltage 
>divider to step down the voltages to the 1.8V required by the ADC is there a 
>way to ensure that the voltage never excedes 1.8? I've been reading around 
>about zener diodes and it seems like they would work, but I'm not quite sure 
>about the implementation. Any advice?

If you run the voltage through a non-inverting op amp that is powered
at 1.8 volts + and ground, then the output voltage can never exceed
the supply voltage.  The op amp should be capable of rail to rail
operation.

The problem with zeners and straight diodes is that the voltage can
exceed the nominal voltage if there is too much (not likely here), but
also that the impedance of the diode must be compensated for.

Also make sure that the measurement range (depending on reference and
ADC setup) does not saturate before your maximum desired voltage.  I
suspect that 1.0 volts maximum may be typical.  (It is on an Xmega
depending on the choice of reference).

Harvey

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

Re: [beagleboard] Re: Is BBB compatible with Arduino Sensors?

[Harvey White]

On Tue, 30 Jun 2015 15:47:27 +0300, you wrote:

>Well, I get that BBB is a lot more powerful than Arduino (UNO) and I have
>no doubts about that. Frankly speaking, that's the reason I am into this
>BBB kind of thing. I was wondering if I could *reuse* my arduino uno
>compatible sensors i.e. with BBB. That would really be a kick start for a
>beginner like me.


Arduinos are designed as a 5 volt system, which means that the
peripherals are as well (the shields).

You can't connect them directly to the processor, not when the shield
is powered from 5 volts.

Some chips and chipsets on the shield may work at 3.3 volts.  Those
can be directly connected to any pin except the ADC pins.  

If the chips only work at 5.0 volts, you will need a level shifting
chip (see level translators at TI.com).  Series resistors do not work,
it's not a matter of current, it's a matter of voltage.  Use a chip.
you might be able to use a resistive voltage divider, but it will cost
you speed.  Best to use the chip.

This does not address ADC pins.  The A/D pins on a MEGA are good for 0
to 5 volts.  On an XMEGA, good from 0 to 3.3 volts.  5 or 3.3 being
the nominal supply voltage, don't exceed VCC on the chip.

The ARM processor pins are good to a maximum of 1.8 volts.  You'll
have to adjust that, too.

What I'd suggest (and there might be one, or you'd have to design it),
would be a cape that does level translation and ADC buffering (op
amps, but don't run the op amp from more than 1.8 volts and make sure
it will do rail to rail on the outputs).  The cape can have pinouts
for the arduino shield.  Even then, you have to pick which pins will
be inputs and outputs, since most chips do groups of 8 or 16.  There
is a 1 bit level translator, though.  

the level translators will go from almost any voltage up to 5.5 to any
other voltage up to 5.5... They'll go both ways.

Harvey

>
>And which programming language would be best. I know C only and trying to
>learn Python on my own. I am open to any suggestions.
>
>On Tue, Jun 30, 2015 at 3:53 AM, Bruce Boyes  wrote:
>
>> The BBB is quite a different beast from Arduino (and there are many of
>> those; I assume you mean one of the simpler ones such as 'Uno'). Arduino is
>> simple to use, like a bicycle. It's great when that is what you need. BBB
>> is more like a powerful motorcycle - lots more capability but a step or ten
>> up in complexity... and learning curve. BBB has a pretty complete operating
>> system capability (I use Ubuntu 14.04) which the simpler Arduinos lack. BBB
>> has ethernet, HDMI, etc baked in which Arduino does not, and the simpler
>> Arduinos can't realistically add that. The more complex Arduinos can, but
>> then you get to about the same price point as BBB and you arguably have a
>> kludge. I don't mean any of this disparagingly, just that the "best"
>> solution for you depends... on what you are trying to do, and a lot of
>> other factors. Personally I like BBB for some applications where you want
>> Linux, HDMI, Python, etc, and Teensy 3.1 for smaller ones. They are all
>> tools - pick the one you like best or that fits your needs best.
>>
>> You'd hope, this being 2015 (and not 1995) that there would be some *standard
>> and portable* way to have hardware device drivers you could use anywhere.
>> There are some efforts in that area such as Pingo
>>  but this issue is gnarly...
>> figure out a good solution and you'd have a great business. The use of I2C
>> and SPI as common hardware interfaces has helped a lot but there is a long
>> way to go until all sensors could be "plug and pray" on any hosting system.
>>
>> BBB also has the PRUs  which seem
>> like a solution for any number of special realtime interface issues. And
>> the BBB community is pretty great too! Mr Kernal, Robert Nelson
>> , and Mr Beagleboard
>> (Gerald Coley) and a ton of others are working hard to make BBB great.
>> Adafruit is also a good source of BBB parts and tutorials
>> 
>> .
>>
>> Welcome to the community!
>>

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

Re: [beagleboard] Driving LEDs

[Harvey White]

On Mon, 15 Jun 2015 18:14:57 -0700 (PDT), you wrote:

>Is there a reason a particular reason that the LED examples connect the 
>current limiting resistor to GND and light the LED with a logic high state on 
>the pin?
>
>I'm more used to TTL open collector where the current limiter goes on VCC and 
>you drive the pin low.  Are the GPIO pins on the BBB able to provide the same 
>current in both states?  My digital logic knowledge is somewhat dated.


CMOS and HC logic have symmetric pullups and pulldowns.  TTL used to
have about 16 ma pulldown (saturating transistor), and about 1 ma up.
TTL did not need a stiff pullup, all it had to do was supply back bias
diode leakage for all the inputs it was driving, but the pulldown had
to sink 1.6 ma per input, so you got 20 pullups and 10 pulldowns.  

Harvey

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

Re: [beagleboard] UART connection BBBlack UART4 to Raspberry Pi-2

[Harvey White]

On Tue, 12 May 2015 21:34:51 -0500, you wrote:

>I trust that I might save the time of others who want to connect UART4 to
>the Pi-2 UART:  It is required to connect the ground of both boards.

Generally, two electronic systems talking to each other over wires
(not fiber optics, and not ethernet, which uses isolation techniques)
will need a common ground.

This is especially true of either parallel port driven projects, or
serial (I2C, SPI, CAN, RS-232, to name a few styles).

MIDI uses isolation techniques.

Just as when you measure a voltage, you need to measure with reference
to something (typically a ground point), the other circuits that
respond to that voltage need the same (and common) reference point.
This is true unless there have been fairly special techniques used to
bypass that need.

Remembering this can save you lots of difficulty, however, when in
doubt about connections, ask.

Harvey


>
>-- 
>
>Bill Barnett

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

Re: [beagleboard] BeagleBone Black connect to ultrasonic sensor Hcsr04

[Harvey White]

On Thu, 07 May 2015 11:45:01 -0500, you wrote:

>The sensor is expecting a 5V signal on the trigger input and generates a 
>5V signal on echo.
>You are feeding a 3.3V signal from the BBB and accepting a 5V signal 
>from the sensor.
>Will the output of the BBB, 3.3V, be seen as a 5V input by the sensor?

The cmos threshold is 75% of VCC, so 25% of 5 volts is 1.25 volts,
which gives a desired 1 threshold of 3.75 volts on the sensor.

Not likely to see the signal as a 1.

>Will the 5V signal from the sensor fry the gpio pin which is expecting a 
>max voltage of 3.3V?

Yes.  See the warnings in the manual.

>This is just looking at the voltages and not considering currents, dig 
>out the spec sheets for the sensor to see what the voltage/currents are 
>that it is expecting.

>The MOSFET level shifters will transform the 3.3V to 5V and vice versa.
>Transistors/resistors will do the same operation.

TI (and others) make unidirectional (can be switched for direction)
level translators that protect both sides of the load and translate
logic levels.   The part number (typical) is something on the order of
74LVC8T245, IIRC.  I'd recommend them highly.  There are DIP packages
more suitable for breadboards.

Transistors can work, as can resistors, but the packaged device is a
neater solution.

Harvey

>Chad
>
>
>On 5/7/15 10:45 AM, claudiu claudiu.fu...@yahoo.com wrote:
>> Well yes i do know that the BBB is a 3.3v with a 4-6 mA output. 
>> Therefore I have used the following configuration:
>> |* TRIGGER   P8_12 gpio1[12] GPIO44  out pulldownMode: 7
>> * ECHO  P8_11 gpio1[13] GPIO45  in  pulldownMode: 7 *** with 
>> R 1KOhm
>> * GND   P9_1 or P9_2GND
>> * VCC   P9_5 or P9_6VDD_5V(from BBB)
>> |
>> |but am I right ? |
>>
>> On 7 May 2015 at 16:23, doog > > wrote:
>>
>>
>> On Thursday, May 7, 2015 at 1:44:57 AM UTC-7, claudiu  wrote:
>>
>> For the sensor's VCC im using the VDD_5V from BBB. 
>>
>>
>> and you do know that the BBB is a 3.3v device so level shifting is
>> probable?
>>
>> Doug
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to a topic in
>> the Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/beagleboard/Cd9xj0AabcU/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email
>> to beagleboard+unsubscr...@googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google 
>> Groups "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send 
>> an email to beagleboard+unsubscr...@googlegroups.com 
>> .
>> For more options, visit https://groups.google.com/d/optout.

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

Re: [beagleboard] Monitoring Switches to Make Sure They are Pressed in Correct Order with Node.js

[Harvey White]

On Sat, 25 Apr 2015 00:44:18 -0700 (PDT), you wrote:

>Hello,
>
>I am currently working on a project that involves using switches (handled 
>the same was as a button) and node.js. I am stuck on a part that involves 
>making sure the switches are pressed in the correct order. There is an Up 
>switch and a Down switch.
>
>The things I need to do:
>
>- The Up switch needs to be the first switched pressed, if the Down switch 
>is pressed first I need to print an error (console.log will do)
>- The Up switch cannot be pressed two or more times in a row without having 
>a Down switch press in between, if there are two or more Up switch presses 
>in a row it will result in printing an error.
>- The Down switch cannot be pressed two or more times in a row without 
>having an Up switch press in between, if there are two or more Down switch 
>presses in a row it will result in printing an error.
>
>Any help I can get would be greatly appreciated! I have been stuck on this 
>for quite a while and I know it shouldn't be hard its just not coming to me 
>very easily. Everything I have tried so far as been unsuccessful. 

Flow chart this.  You will need a routine that sets a boolean variable
when a key has been pressed, or a method of checking when the key has
been pressed.

A flow chart will give you the program flow, 

Example as a start, using words...

Initialize all switches to not pressed.

is switch pressed?  if not, loop on this question

is switch UP switch, if yes, go to next statement, if no print error
// up has to be first

is switch DOWN switch, if yes, go to DOWN, if not, go to next
statement

is up switch already pressed?  if so, print error.  if not, go to next
statement

 code here to handle up switch press and then reset up switch
pressed and go back to looking for switch pressed

DOWN:
is down switch already pressed?  if so, print error, if not, go to
next statement

. etc




Harvey



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

Re: [beagleboard] Boot Freezes with a single P8-P9 connection; reproduced on two boards

[Harvey White]

On Thu, 23 Apr 2015 20:02:03 -0400, you wrote:

inputs are not inputs are not inputs as far as loading goes.

if I connect an instrument with a 50 ohm impedance to a TTL/CMOS gate,
then it's going to see low at that gate input, even though they are
all inputs.  Different logic series gates look like different things
at the inputs.  Those inputs affect the other inputs.  

The GPIO current out is not the issue, it's what the GPIO input sees
when the circuit is booted that determines what happens.  

Harvey


>If they cause the BBB to not boot, by hooking an input to them, I would 
>argue they should never have been brought out to the header, and that 
>examples of how to handle this sensitivity while still making use of the 
>header pins should be more readily available. The documentation on this 
>sensitivity appears to be a single poorly written paragraph in the SRM 
>which only states they should not be driven (actually 3 lines only in 
>section 7.12.1 following Fig 58; to be specific: "/If you plan to use 
>any of these signals, then on power up, these pins should not be driven. 
>//If you do, it can affect the boot mode of the processor and could keep 
>the processor from //booting or working correctly/." I can't see this 
>addressed anywhere else in the documentation). It should state that not 
>even inputs can not be connected to these header pins. There is no 
>documentation that I can see on why they were even brought out to the 
>header. Issues like this make other alternatives to using the BBB's look 
>more attractive (such as the new PI). At a minimum, this will cost us 
>another 4 lost weeks and $2K for new populated boards for another 
>iteration on our cape. Very frustrating, and I would argue both poor 
>design and poor documentation. Looking at the schematic, it appears the 
>existing load on each pin is 2 100K resistors? If this is correct, I 
>would not call this "well loaded" when a typical gpio output current is 
>4-6mA.
>
>On 15-04-23 02:08 PM, Gerald Coley wrote:
>> ANY load can affect how they are read. These pins are already well 
>> loaded as it is. If you want to use them, use a buffer to isolate them 
>> until after the processor is running.
>>
>> Gerald
>>
>>
>> On Thu, Apr 23, 2015 at 12:20 PM, Bit Pusher > > wrote:
>>
>> This is not clear as they are connected to other inputs which I
>> would normally think means they are not being driven. Is there a
>> definition you can give a link to defining what driven is? Also,
>> can you supply a link of how to control and what are the mux
>> defaults before boot? Thank you.
>>
>>
>> On Thursday, April 23, 2015 at 12:29:26 PM UTC-4, Wulf Man wrote:
>>
>> you are messing with the boot pins. its been stated here 100s
>> of times you cannot do anything to these pins before board boots.
>> check the BBB schematic and the using the bbb board guide.,
>>
>>
>> On 4/23/2015 9:09 AM, Bit Pusher wrote:
>>> I have found a reproducible boot freeze (on two boards);
>>> could someone else possibly check; it's very easy to try.
>>> No connections besides power plug and one (or two) wires from
>>> header P8 to P9
>>> Scenario 1: connect P8-43 to P9-30, plug in power, only power
>>> light comes on and BBB does not boot up
>>> Scenario 2: connect P8-44 to P9-28, plug in power, only power
>>> light comes on and BBB does not boot up
>>> Scenario 3: connect both P8-43 to P9-30 and P8-44 to P9-28,
>>> plug in power, power light and all 4 LEDs come on steady and
>>> BBB does not boot up.
>>>
>>> Discussion:
>>> 1) doing these tests numerous times on 2 BBB's did not hurt
>>> either one of the boards I have, but this behavior is so
>>> strange that it might be risky; please don't be upset with me
>>> if it hurts your board.
>>> 2) uname -a gives Linux beaglebone 3.8.13-bone70 #1 SMP Fri
>>> Jan 23 02:14:42 UTC 2015 armv7l GNU/Linux. My OS version is
>>> Debian wheezy 7.8
>>> 3) without wires connected, after booting and doing a
>>> >sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins shows
>>> ...
>>> pin 42 (44e108a8) 002f (this is P8-43 in mode 7 which
>>> should be gpio2_8)
>>> pin 43 (44e108ac) 002f (this is P8-44 in mode 7 which
>>> should be gpio2_9)
>>> ...
>>> pin 102 (44e10998) 0027 (this is P9-30 in mode 7 which
>>> should be gpio3_17)
>>> pin 103 (44e1099c) 0027 (this is P9-28 in mode 7 which
>>> should be gpio3_16)
>>>
>>> Therefore at boot, pins P8-43 and P8-44, without applying
>>> device trees, are both configured as inputs with pull-downs;
>>> pins P9-30 and P9-28, without applying device trees, are both
>>> configured as inputs with pull_up/pull_down's disabled.
>>

Re: [beagleboard] Moving the HDMI port

[Harvey White]

On Mon, 20 Apr 2015 11:17:38 -0700, you wrote:

>you do that and there is a chance that nothing will work. you will be
>playing with the timing of things.

There are active cable extenders and HDMI extenders that might solve
the problem.  Depends on the amount of space in the case.

I'd also suggest making extender cables if at all possible for USB and
Ethernet.  Much easier to unplug and put in a new board than desolder
and hardwire extension connectors to a BBB.

Harvey
>
>
>On 4/20/2015 11:08 AM, Mr John H. Smith wrote:
>> Hello All,
>>
>> I want to use the BeagleBone Black inside a case, however the ports
>> (USBs, Ethernet and HDMI) are not in the correct places to be
>> connected to the outside world. While I'm comfortable with desoldering
>> the Ethernet and USB connetors to extend those, I'm not so sure about
>> the hdmi. With 19 wires and tighter impedance control can anyone point
>> to an example where some desoldered and extended the port via a cable.
>>
>> Caio
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google
>> Groups "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to beagleboard+unsubscr...@googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.

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

Re: [beagleboard] Re: How to get serial debug information in Beaglebone black

[Harvey White]

On Thu, 16 Apr 2015 23:33:14 -0700 (PDT), you wrote:

>Oh, Lord.. I wasted one whole day trying to figure this out. Turns out I 
>connected Rx to Rx and Tx to Tx.

Find an RS-232 LED monitor.  You want something that monitors the
state of each line, and shows you a red or green light depending on
the state of the line.  I have seen them in 25 pin versions, but you'd
likely want a 9 pin version.

Connecting that up to each device in turn shows you which line is
drive, and which is not.

There's DTE (Data Terminal Equipment) and DCE (Data Communications
Equipment) (IIRC), they have different signals on different pins,
since the original idea was that they'd be able to be wired pin to pin
to function.  DTE was supposed to be a terminal of some sort, DCE was
the external modem.

Now that your computer could be both, there's a connection problem.

Been there, done that.

Harvey


>Thank you, Dale Schaafsma.
>
>On Wednesday, September 11, 2013 at 11:33:36 PM UTC+5:30, Dale Schaafsma 
>wrote:
>>
>> You need to connect to J1, not P9...see the SRM (System Reference Manual) 
>> at 
>> http://circuitco.com/support/index.php?title=BeagleBoneBlack#Hardware_Files
>> Make sure cable's RX is connected to BBB's TX and cable's TX is connected 
>> to BBB's RX.
>> -Dale
>>
>> On Tuesday, September 10, 2013 11:10:54 PM UTC-5, cerry wang wrote:
>>>
>>>
>>> I'm new in beaglebone black. I know in original version beaglebone, I can 
>>> get serial debug information just plugging mini usb to pc. But Beaglebone 
>>> black can't. I search from 
>>> http://circuitco.com/support/index.php?title=BeagleBone_Black_Accessories 
>>> and try to use Adafruit 4 Pin Cable (PL2303) by plugging green line to 
>>> P9-4, white line to P9-5, black line to GND. I use putty trying to get 
>>> serial information but I can get only much of disorder and non-meaningful 
>>> characters just like setting wrong baud-rate. But I don't know why I set 
>>> 115200 in putty and it work in original version beaglebone. How can I get 
>>> right serial debug information in Beaglebone Black. 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] [OT]: In search of an HDMI portable monitor for my BBB

[Harvey White]

On Sun, 12 Apr 2015 16:04:02 +0200, you wrote:

>
>Hi Harvey, 
>
>thanks for your reply!
>
>...I was asking for the brand you are using...
>Finding any hdmi on ebay is not a problem.

Ah, ok, well.

In the great Chinese tradition, it doesn't have a brand name.

However: it is marked LA.M V29.P
and
LQ-RE01-150-116-L01
and
LQLAMV29P15061098

Good luck on that one...

Harvey

>
>Thanks anyway! :)
>Best regards,
>mcc
>
>
>Harvey White  [15-04-12 15:52]:
>> On Sun, 12 Apr 2015 06:50:38 +0200, you wrote:
>> 
>> >Hi Harvey,
>> >
>> >than ks for you reply!
>> >
>> >Any names, brands, number...anything else than "China"
>> >for which I can google for?
>> Here's one
>> 
>> http://www.ebay.com/itm/HDMI-VGA-2AV-Remote-Lcd-controller-Board-VS-TY2662-V1-work-for-lots-of-LCD-panel-/180979602491?pt=LH_DefaultDomain_0&hash=item2a2339943b
>> 
>> 
>> and here's another
>> 
>> http://www.ebay.com/itm/TV-PC-HDMI-CVBS-RF-USB-AUDIO-driver-Board-For-DIY-Monitor-Televison-1920-1080/251869640598?_trksid=p2047675.c15.m1851&_trkparms=aid%3D222007%26algo%3DSIC.MBE%26ao%3D1%26asc%3D30084%26meid%3D10249753d3a24e23bc3d46d17f4a0429%26pid%3D15%26rk%3D2%26rkt%3D6%26sd%3D181044221632&rt=nc
>> 
>> 
>> The second one is more like the one I have.  
>> 
>> I have no experience with either of these sellers, nor the top one.
>> 
>> I used HDMI to LCD Panel as a search term on ebay.
>> 
>> Harvey
>> 
>> >
>> >Best regards,
>> >mcc
>> >
>> >
>> >
>> >Harvey White  [15-04-12 06:44]:
>> >> On Sun, 12 Apr 2015 04:43:12 +0200, you wrote:
>> >> 
>> >> >Hi,
>> >> >
>> >> >since the BBB offers an HDMI connector I am looking for
>> >> >a portable HDMI monitor which works with the BBB and
>> >> >offers audio.
>> >> >
>> >> >Are there any recommendations (or the opposite: Monitors,
>> >> >which better to leace alone...)?
>> >> 
>> >> There are a number of boards available from China which run from 12
>> >> volts DC, and use a laptop display (or equivalent) as an output
>> >> device.  They're probably about 30 euros in price, have an HDMI input,
>> >> (haven't tried mine yet) and have to be custom ordered for a
>> >> particular laptop panel.  VGA or SVGA resolution would be about right,
>> >> Mine is running on a 640 x 480 7 inch display that I obtained locally,
>> >> and was also bought locally.  (about 55 USD at a local surplus store
>> >> in the states...).
>> >> 
>> >> Some of them have audio, and are baseband monitors as well...
>> >> 
>> >> This might be what you'd need.
>> >> 
>> >> Harvey
>> >> 
>> >> >
>> >> >Thank you very much in advance for any help!
>> >> >Best regards,
>> >> >mcc
>> >> 
>> >> >
>> >> >PS: Best would be if available in germany... :)
>> >> 
>> >> -- 
>> >> For more options, visit http://beagleboard.org/discuss
>> >> --- 
>> >> You received this message because you are subscribed to the Google Groups 
>> >> "BeagleBoard" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send an 
>> >> email to beagleboard+unsubscr...@googlegroups.com.
>> >> For more options, visit https://groups.google.com/d/optout.
>> >> 
>> 
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>> 

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

Re: [beagleboard] [OT]: In search of an HDMI portable monitor for my BBB

[Harvey White]

On Sun, 12 Apr 2015 06:50:38 +0200, you wrote:

>Hi Harvey,
>
>than ks for you reply!
>
>Any names, brands, number...anything else than "China"
>for which I can google for?
Here's one

http://www.ebay.com/itm/HDMI-VGA-2AV-Remote-Lcd-controller-Board-VS-TY2662-V1-work-for-lots-of-LCD-panel-/180979602491?pt=LH_DefaultDomain_0&hash=item2a2339943b


and here's another

http://www.ebay.com/itm/TV-PC-HDMI-CVBS-RF-USB-AUDIO-driver-Board-For-DIY-Monitor-Televison-1920-1080/251869640598?_trksid=p2047675.c15.m1851&_trkparms=aid%3D222007%26algo%3DSIC.MBE%26ao%3D1%26asc%3D30084%26meid%3D10249753d3a24e23bc3d46d17f4a0429%26pid%3D15%26rk%3D2%26rkt%3D6%26sd%3D181044221632&rt=nc


The second one is more like the one I have.  

I have no experience with either of these sellers, nor the top one.

I used HDMI to LCD Panel as a search term on ebay.

Harvey

>
>Best regards,
>mcc
>
>
>
>Harvey White  [15-04-12 06:44]:
>> On Sun, 12 Apr 2015 04:43:12 +0200, you wrote:
>> 
>> >Hi,
>> >
>> >since the BBB offers an HDMI connector I am looking for
>> >a portable HDMI monitor which works with the BBB and
>> >offers audio.
>> >
>> >Are there any recommendations (or the opposite: Monitors,
>> >which better to leace alone...)?
>> 
>> There are a number of boards available from China which run from 12
>> volts DC, and use a laptop display (or equivalent) as an output
>> device.  They're probably about 30 euros in price, have an HDMI input,
>> (haven't tried mine yet) and have to be custom ordered for a
>> particular laptop panel.  VGA or SVGA resolution would be about right,
>> Mine is running on a 640 x 480 7 inch display that I obtained locally,
>> and was also bought locally.  (about 55 USD at a local surplus store
>> in the states...).
>> 
>> Some of them have audio, and are baseband monitors as well...
>> 
>> This might be what you'd need.
>> 
>> Harvey
>> 
>> >
>> >Thank you very much in advance for any help!
>> >Best regards,
>> >mcc
>> 
>> >
>> >PS: Best would be if available in germany... :)
>> 
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>> 

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

Re: [beagleboard] [OT]: In search of an HDMI portable monitor for my BBB

[Harvey White]

On Sun, 12 Apr 2015 04:43:12 +0200, you wrote:

>Hi,
>
>since the BBB offers an HDMI connector I am looking for
>a portable HDMI monitor which works with the BBB and
>offers audio.
>
>Are there any recommendations (or the opposite: Monitors,
>which better to leace alone...)?

There are a number of boards available from China which run from 12
volts DC, and use a laptop display (or equivalent) as an output
device.  They're probably about 30 euros in price, have an HDMI input,
(haven't tried mine yet) and have to be custom ordered for a
particular laptop panel.  VGA or SVGA resolution would be about right,
Mine is running on a 640 x 480 7 inch display that I obtained locally,
and was also bought locally.  (about 55 USD at a local surplus store
in the states...).

Some of them have audio, and are baseband monitors as well...

This might be what you'd need.

Harvey

>
>Thank you very much in advance for any help!
>Best regards,
>mcc

>
>PS: Best would be if available in germany... :)

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