Dave, Thanks for all the great information!
I especially like your idea of thinking of the BBB as a BBW with an eMMC/HDMI cape on it. Ian On May 5, 2013, at 2:52 PM, David Bagby <[email protected]> wrote: > Hi Ian, > > I read your post (and the IRC conversation log that Michael pointed to a > couple of days ago) and I too suspect that a 46 char string is probably not > the preferred interface for setting Pin states or mux modes on a Bone board. > > The use of a 46 char string tends to lead one to set 46 pins at a time, as a > set.With the string approach it's a bit inconvenient to just set IO pin #s 5, > 17 and 23 (#s made up as an example) while ignoring any other pins you don't > want to alter. > > Some recent Bone cape design work has made some desirable Bone based system > layer divisions apparent to me. We need to continue to think of the embedded > hardware and software system in common layers. SoC projects can lead one to > think of a flat lump architecture which can be misleading. > > I'm thinking that the most common need (within HAL) will be to set the state > (as in on/off, not the mux mode) of an individual (Bone P8 or P9) pin; > Followed by the need to set an arbitrary set of pins which are presented to > HAL by a specific bone cape.__ > > Perhaps I'm reading to much between the lines, the IRC log made me wonder if > the 46 Char string approach might be being driven by an idea that HAL is in > control of "the hardware"? > > In some sense HAL *is* in control (of _some _hardware) and in other senses it > isn't. A key issue is defining what "the hardware" is that is being _used_ by > Hal and is therefore "under control" of LCNC.... > > Ifind it helpful to keep a hardware/OS/Application layering model in mind. > Let me elaborate briefly;I'll end up describing a general model that I think > will work for thinking about LCNC on an embedded hardware platform and I'll > use the Bone as the conversational example. > > For a Bone based embedded system, there are a few basic hardware building > blocks to consider. A Bone embedded hardware system basically consists of a > Bone board (BBW or BBB as of today) and 0 to 4 hardware capes attached to the > Bone board. > > We know that the Bones have the usual SoC situation where the SoC has many > more internal signals than they have physical IO pins. In the case of the > AM335x, there are multiple (7) signals that can be used on a "GPIO" pin (only > one signal can be mapped to a pin at any given instant). The required signal > multiplexing allows a great deal of flexibility in terms of coupling internal > SoC capability to the outside world. The cost is that one can't have any pins > be anything, at any time, in any combination that someone might want them to > be. So we have to choose what signal gets used on what pin. > > _"We" in that sentence is *not* solely LCNC..._ > > Both the Bone boards and the Bone capes are involved in utilizing the > multiplexed pins. In the Bone systems, the Bone board and the capes all have > eproms with info that specifies what pins each hardware module is using. The > OS is the entity that uses this information and sets up the pin mux states of > the SoC (during the boot processes). Along the way, the OS has to handle pin > use conflict resolution etc. > > The important point is that this process will have been done *before* LCNC is > ever started up. Therefore, the pins LCNC finds available for it's use upon > startup are a function of what hardware modules are plugged together at boot > time. > > It is important for us as a group to understand this (Ian, I think you do > from reading the IRC logs; permit me some latitude here as I'm writing a bit > for the benefit of readers that may not understand this)._I assert that > LCNC's HAL layer CAN NOT just decide to "Own" all the Bone IO Pins. _ > > Setting pin modes to incompatible combinations can literally lead to burned > out electronics (one does not want multiple hardware modules driving the same > signals)._It is neither safe, nor desirable, for LCNC to attempt to "take > over" all the physical IO pins of the Am335x._ > > So how could we think about which parts of this embedded system are owned by > what entity? > > From an LCNC perspective, I suggest that we model the Bone system as _always > having two components_: > > 1)A base SoC (Bone) board AND > > 2)A LCNC hardware interface (Bone cape). > > ** > > *LCNC would only deal with an interface defined by the Cape and within LCNC > we should create HAL modules that _only deal with the pins and signals > presented_ for use by LCNC by that specific Cape.* > > Let's play with some example combinations to see how well this model works -- > > *Example 1: * > > Base Bone = BBW > > Cape = a CNC interface case. > > The BeBoPr (and the Replicape) are existing examples of CNC interface capes. > Each made design time choices as to what signals they wanted to utilize from > the BBW and how they would physically and electrically present those signals > for use. > > The BeBoPr and Replicape design choices appearaimed at driving extrusion > printers; Other use cases would probably make different trade offs. > > What's common here is that physically and electrically, these boards are > designed such that "inputs are inputs" and "outputs are outputs". The signal > direction is fixed at hardware design time and it can not be changed at run > time by just altering the pin mux mapping mode from In to Out. The hardware > and software configurations have to match. > > Creating a LCNC Hal module that is the "BeBoPr" module is a good way to > encapsulate the implicit knowledge of what signals the BeBoPR presents for > use by LCNC and what the configuration restrictions are for that interface > combination. A Cape interface module should nicely define what capabilities > are available for use by LCNC's Hal layer. > > *Example 2: * > > Base Bone = BBW > > Cape = "transparent cape" > > Except for a hardware guy doing bench testing/development (like I am at the > moment), I don't expect that anyone will be interfacing CNC controls directly > to a bare BBW (due to IO levels, drive limitations and the danger of blowing > up the SoC by doing bad things to pins that lead directly into the chip). > > However, if they did, we can model this as a "transparent cape" that simply > presents to LCNC the BBW signals (as they have been setup by the OS prior to > LCNC starting). > > *Example 3:* > > A BBB can be thought of as > > Base Bone = BBW > > Cape = "BBW to BBB changes cape" > > An easy way to understand the changes between the BBW and the BBB is to think > of the BB as a BBW + a BBB conversion cape. In fact, from an IO viewpoint > that is effectively what the BBB is. The BBB uses two sets of BBW signals > (eMMC and LCD) to drive hardware added to the BBW design. > > *Example 4:* > > Base cape = BBB > > Cape 1 = Comms cape (Example: Wi-Fi or Canbus or...) > > Cape 2 = LCNC Interface cape > > Now consider a case where there are two (or more) capes. > > Cape 1 in this example is implementing and providing communication facilities > to the overall embedded system. Wi-Fi would be a common example. > > What is important here is that this cape has had it's hardware initialized by > the OS, it up and running and is in active use -- and it has been in use long > before LCNC was started.LCNC should not have any knowledge (at any level > internal to LCNCN) of the functions of this cape. While LCNC could (but > should not) twiddle the SoC register bits that control this cape, those bits > have to remain untouched by whatever LCNC may be doing. > > The fact that providing SOC register access is necessary to create a Hal Cape > module, means that the ability to twiddle non-cape register bits exists. It > does NOT mean that the ability should be used in appropriately. > > Cape 2 is supplying CNC interface signals for control/use by LCNC. > > We will assume that there is a corresponding LCNC module that let's LCNC have > access to the CNC Cape hardware. *That module should only access the SoC > register bits that are presented to LCNC by the hardware/module combination.* > > Those are by definition the only SoC signals that Hal knows about. I see Hal > as a consumer of signals defined by a Cape module and the rest of LCNC uses > the Cape module's "goesintos" and "goesoutas". > > It is critical to system operations that Hal modules resist any temptation to > become the OS.I am saying that it is *not* Hal's job to manage all SoC IO > pins; Hal is not the OS and should not try to be. > > *LCNC vs non-LCNC Embedded System Division:* > > From the OS viewpoint, LCNC is an application program. That means that the OS > will have done it's hardware initialization work *before* LCNC (and hence > Hal) ever gets started.From the LCNC perspective the pin mux state that LCNC > sees when it is started is a complex function of the hardware modules that > are present and the states already set by the OS. > > *Within LCNC we should create HAL modules that _only deal with the pins and > signals presented_ for use by LCNC by that specific Cape via it's Hal Cape > module.* > > ** > > *Further, these cape specific Hal modules should not present raw SoC signals > to the rest of LCNC. *Bone Cape Hal modules should only present "CNC signals" > to the rest of LCNC.E.g. > > ·Don't present "ehrPWMm2A" to LCNC, instead present "spindle speed signal"; ** > > ·Don't present GPIO1[5] to LCNC, present "Coolant relay ON/OFF" (or at most > "Cape IO #4".** > > ** > > Within a Hal cape module, it will be necessary to be able to set Embedded SoC > specific register bits. Having a SoC platform specific utility library that > does this will be of assistance to people wanting to write Cape Hal modules. > However this would (I hope) never be used outside of a cape and SoC specific > Hal module. > > This leads me to believe that the fundamental operation that is needed is > > 1) Set/reset the state (on/off) of a (single) IO pin. > > 2) Set the state of a subset of the IO pins presented by a cape. > > (I expect the need to set the actual mux mode of an Am335x pin to be an > exception rather than a common need since the mux modes will already be set > up by the OS.Even if needed to dynamically reconfigure a cape board that can > deal with bidirectional signals lines, it will only be needed _inside_ a Cape > Hal module. ) > > Therefore I think that a IO bit oriented interface would be preferred over a > string that sets many (46) or all the SoC pins at once.A IO Pin orientation > just seems to better fit the way I perceive the building block as > interacting. The coding (spelling) of such a bit oriented approach is of > course programming language dependent. I'm just trying to communicate why I > think the weighting should be skewed toward "IO Bit" rather than "SoC > register". > > To assist in understanding the Am335x pin groupings, I have attached a > version of a spread sheet we developed a while ago that shows the AM335x pins > and signals. You may find this helpful in that it does two useful things: > > 1)It clearly shows the pin groups where usage changed between the BBW and > BBB, and > > 2)It shows ALL the possible pin signals for the Am335x SoCs in terms of the > Bone P8 and P9 headers. The Bone SRMsdo not identify the pin mux combinations > that are reserved by the Am335x TRM, nor do they show the PRU signals which > are of primary interest to us for LCNC purposes. > > My sheet does not have the register offset values in it, so a little spread > sheet merging exercise may be useful. > > LCNC folks are welcome to use this sheet if they find it helpful (Charles, > this already includes the SoC pin names and numbers). > > The spread sheet file is an excel 2003 format file -- I think that opens fine > in clones like Open Office. If not let me know and I can probably export it > into another file format. > > Dave > > <BBone Am335x Expansion Connector > Mappings.xls>------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite > It's a free troubleshooting tool designed for production > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2_______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
