Hi Charles,
On 4/25/2013 5:55 AM, Charles Steinkuehler wrote:
> On 4/24/2013 9:27 PM, David Bagby wrote:
>> Charles: Am I correct to assume that your LCNC stepgen PRU code is
>> configured to use the same BBW pins as the BeBoPr (I think I remember
>> reading that you were using that for prototyping)?
> I am initially working on a machine configuration for the BeBoPr (which
> I have in-hand) and Replicape pinouts. I am trying to make the
> low-level PRU code flexible so you can assign I/O pins at run-time, and
> match whatever cape or home-brew hookup you're using.
Ok, that's what I thought - I wanted to check my assumption.
I'm thinking that we could get there (dynamic pin configuration) in phases -
see below.
>> If so, I suspect that we're going to find that there are some BBB pin
>> challenges to consider.A quick look at the BBB schematics shows that a
>> fair number of the pins in use by the BeBoPr and Replicape PRU
>> configurations overlap with the LCD/HDMI pin set on BBB P8. That implies
>> at least some changes will likely be needed to move LCNC from BBW to BBB
>> (with the current pin mappings, to run LCNC on a BBB I think it would be
>> necessary to disable the HDMI support in the BBB).
>>
>> Are these questions already figured out or do these topics still need to
>> be worked through?
> I have spent a good chunk of the last couple days reviewing the recently
> released docs on the BBB. Executive summary: I'm not worried.
High level: "me neither"; :-)
> Although as you noted, without some pin shuffling the HDMI output will
> have to be limited (likely completely disabled with the BeBoPr). But
> the original 'Bone doesn't have HDMI output at all, so it's no worse
> than before.
In another post in this thread you also wrote:
"The I/O pins used are configurable at runtime, but currently only PRU
I/O pins are supported. I am going to add support for the PRU to
directly drive GPIO pins, so basically any pin on the chip could be used
with appropriate I/O mux setup."
That would be a valuable enhancement. I had not realized that the current code
only used PRU accessible pins.
I've some additional ideas I'd like to explore & see what interest there may be
-
My interests are around LCNC on an embedded system. I've been eagerly
following the work you've been doing with the BBW.
It's no surprise that LCNC on an embedded platform can be different
from LCNC on a PC.While LCNC on a PC is great, and I see that continuing
to be a core supported platform, I'd also like to see PC platform
assumptions not be constraining limitations for embeded system usage. I
think that some of Michael's restructuring proposals will help with this
over time.
WRT to the topic at hand, embedded platform CNC approaches tend to be a
bit closer to the hardware. Beaglebones are an example: On this
platform, hdw being used by LCNC is being initialized at OS boot time,
not at LCNC start time.
Here's an outline of the BB boot sequence:
(The following is what I think I currently understand -- details could
still be incorrect. I'm iteratively looking at multiple topics to figure
this out - if someone spots an error, or a silly assumption, please
educate me further. )
1)power up
2)OS boot process
a.Hardware init
i.BBB specific OS code looks for Capes (& Cape EPROMs)
(this is where the kernel version seems to matter as BBB requires device
tree support, that BBW doesn't).
1.OS Configures pins according to EPROM data on cape
a.Theory: BeBoPr and Replicape implicitly assume default BBW pin setup
(I've not verified this yet as I haven't found cape EPROM contents for
the boards)
b.Implication: these capes won't work on BBB w/o changes (pin conflicts).
c.Frankly the tech details of this are a bit moot when you can't buy the
capes...
d. ... and we need some physical connection ability from the BBs to the
rest of the world.
3)LCNC started
a.LCNC Init - Current sequence:
i.LCNC loads PRU code etc
1.LCNC software on BBW is assuming a default BBW pin
config (established during OS boot process).
ii.Assertion: We need a different assumption for BBB...
1.Treating BBB as BBW by "not using HDMI" does not seem
to be an easy option
a.(disabling HDMI appears to be a sftw+hdw job -- not a
pure software one; some hdw signals have tobe held in certain states
during POR etc.).
b.That implies a cape is needed to convert a BBB pin out
into a BBW pin out. It seems a bit silly to build a cape just to do that.
2. Issue: what assumptions to use re BBB pin out?
3.Enabler: Some consensus on a BBB Pin config that
could be used to jump start further BBB work and allow more folks to
participate in LCNC on BB development.
a.We're are kind of stuck when no interface capes are
easily available.
b.Future enhancement: Hal could learn more about BBB platform and
dynamically rearrange pin mappings and mux modes.
i.More complexity -- would have to consider interactions with multiple
capes etc.
ii. It seems preferable not to make this a LCNC on BBB prerequisite.
Idea:
I'd like to see a simple BBB cape that would
A)Implement a simple, assumable, BBB pin mapping that could be used by
LCNC Hal for BBB.
B)Sets up the BBB pins at OS boot time (via Cape EPROM info).
C)Lets us simply connect a BBB to readily available external hardware
(e.g. Break out boards).
This would enable the creation of a low cost BBB cape that could be used
for LCNC on BB (BBW or BBB) development.I'm thinking the goal should be
to keep it as simple and low cost as possible. This would enable
creation of a BBB cape that enables more people to play with LCNC on a
BBB (it would also work fine in a BBW). I specifically think of this as
a "LCNC proto cape", simpler than a BeBoPr or Replicape as it would NOT
include motor drivers etc.
If there is interest in this approach, I'll follow up with a minimal
signal support proposal in the form of a straw man for people to comment
on.As a first cut, I'd try to see what we can do using a BBB pin mapping
that still allows use of the eMMC and HDMI features of the BBB.
Dave
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
