On 25/04/13 19:13, David Bagby wrote: > 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 > > following on from using the beaglebone . i have some spare bare unpopulated replicape pcb's , if anyone wishs to use for lcnc use if it helps i have not built one as yet , and the workloads increasing !
anyone interested in a board let me know , 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
