Back Context: BBB alt. to RPi
At the time when I'd first read of the RPi Compute module, I was at least vaguely familiar with some couple of concepts in designs and application of single board computers. I'd heard of RPi, it's seemed both novel and popular, to my point of view. The concept of a single board computer being available for a SO-DIMM bus,[1] it struck me initially as it being a concept that could lend of the single board computer design, towards applications in parallel computing.It was altogether a new and novel concept, to me -- reusing a RAM bus for communication with a single-board computer?
Summary of Design: Supercluster, The
Ideally, if not only hypothetically, a printed circuit board (PCB) could be defined with multiple SO-DIMM slots -- or other bus slots -- for communicating between multiple peer SBCs. A single master peer SBC could be applied to the same PCB, as primarily for the master peer to serve as a sort of device controller, in communicating with the submodule peers via I2C over the SO-DIMM bus, or other digital bus technology. The master peer SBC on the multi-SO-DIMM PCB could itself communicate with any components external to the PCB -- the master peer serving as a sort of controller -- with the PCB module itself being a submodule within a broader computing system.This design, in effect, would define a sort of tree-like hierarchy for such SBC modules -- moreover, with an opportunity for "pass through" in the master peer, such that other modules, external to the single PCB, could communicate directly with any submodule peers on the PCB, in a parallel computing model. In its wire protocol, then, the design could incorporate a novel multi-master I2C protocol, such that could be designed specifically for this "Supercluster" concept -- I2C being the wire protocol I had thought might be appropriate for the design of such a thing.
In the application layer, the design would incorporate a set of CORBA interface definitions -- essentially, such that the communications to/from each SBC module would be managed via a CORBA protocol, that extending CORBA GIOP specifically for the unique I2C protocol -- something like an I2C IOP, as alternate to the Internet IOP (IIOP) extension of GIOP, with the I2C IOP instead using I2C device addresses, as alternate to IPv4 host addresses, for device addressing in the protocol. Each supercluster board could itself be defined with a unique bus address, in the same protocol -- if not rather, to identify each supercluster board, in any context external to the supercluster board, by using the I2C device address of the master peer on the supercluster board -- thus, defining a sort of simple '
Why: Preferring BBB in lieu of RPi, in Design of Supercluster, The
Earlier on, in the design of that -- albeit, that nonetheless naive -- thesis concept, I think, I had valiantly defended my thesis in social networking, that the SO-DIMM design of the RPi Compute Module (1) could be of relevance for designing a "Raspberry Pi Supercluster" design for parallel computing, and (2) that simply, it is relevant. Candidly, I'm still a bit mystified if it could seem like a concept one should have to defend.Later -- having since abandoned most "chat" venues, in social networking -- I began to read more about the limitations in regards to the Broadcom's purported lack of public documentation about the BCM2835 -- the BCM2835 being used as a primary microcontroller unit (MCU) on RPi platforms. To my best understanding, it seems that Broadcom has since published some sort of a datasheet, however -- presumably at some time since I last read of any "updates," in that particular context, or at least at a time before the "updates" I had read were themselves "updated" -- specifically, noting [4]
Around the matter of the BCM2835's datasheet, and with my frankly being of a yen to avoid populist venues, I've begun to focus more on developing with the BeagleBone Black platform (BBB) -- my having a definite appreciation for that the BBB is platform is thoroughly documented, in legally open documentation, from the design documents for the BBB SBC itself,[5] to even insofar as Texas Instruments' (TI) AM335x Sitara, an ARM Cortex A9 MCU[6] -- and its PRU-ICSS submodules.[7]
Onto the OS Layer - Towards application of a Linux RTOS for Supercluster, The
So, in "Fast forwarding" this contextual narrative to a present matter, "in short," I've decided to focus primarily on the BeagleBone Black platform and its TI AM3358 MCU -- presently, to no lengthy sidebar about RTOS designs, though I think there are some notes that I might like share, at that, as with regards to RTOS kernel designs, moreover TimeSys LinuxLink and TimeSys' developer support for developing discrete RTOS applications of the BBB platform.[8] Of course, that all kind of goes out the window, if my simple notes here would be thought to be of any interest to Qatari Hackers, in any long sidebar about things that don't make world peace.
Sidebar: Not for Proponents of Endless War
Assuming, then, that this is not to be misinterpreted as if it was whatsoever applicable for militant opponents of Israel, and not either for militant separatists in the lattitudes of Asia Major -- ostensibly, including opponents of Russia, there -- my being at least vaguely familiar with some of the volatility in the social network, online, and hostility in the real world "Not online", then before my life's time is wasted entirely if only in addressing people's own spiteful regards, if not also so many convenient "Straw man" arguments, so easily "Tossed around," in so much of "The real world" as ever ventures to develop any items of content, online -- with no lengthy dissertation, here, to my own appreciation of Pres. Eisenhower's comments in his Farewell Address, as then President of the US, and its relevance with regards to international military cooperatives developed during the Cold War -- of a time in world history, when the "Military Industrial Complex" was veritably enshrined, ostensibly then as a defensive measure preventative of global nuclear holocaust, more literally in matters of policies of national nuclear deterrence, in that horrendous brinksmanship ever one step short of global catastrophe and subsequent "Nuclear Winter" outcomes, but fortunately ever stayed of its wiser agents and agencies -- and of the world as before the catastrophic events of September 11, 2001, this world where nonetheless there is still an INTERPOL, and still are some bastions of peace -- inasmuch, if one may endeavor to extend beyond any outcomes of an Armageddon , real and/or invented -- perhaps one might not think as if it was the last significant event in one's life, to be treated to a cup of tea by a team of Kurdish guards.
Complexity -- better a topic for discrete theories in mathematics, nonlinear dynamics, and nondeterministic systems (NDS) theories -- certainly.
Backplanes, sans Hooligans
Considering that the ECT-125 course is focusing primarily about qualities of inductance and capacitance in analog circuits, and that I'd once read a note with regards to capacitance in PCB layouts[9], then when reading up for research in a forum response, last night, I found an article, a resource published by Quabbin(R) Wire and Cable Co. Inc, an article effectively enumerating some relevant electronic characteristics of cabling and wiring, in electrical systems [10]. Certainly, those characteristics of electronic systems would be no less relevant, in a microscopic context -- as, in a sense, with regards to small traces in PCBs and smaller traces, in microchip designs -- no less relevant than in a macroscopic context of cables and wires.In then addressing a matter my own naivete, in some brief and candid reflection, I endeavored to read up more about the concept: Backplane.
As was after some brief research -- towards the end of the first session of courses, this semester at DVUO -- I'm afraid I'd develop a concept of a Backplane as if there could be any sort of a backplane simply comprised of rudimentary, bare copper straps, in what -- strangely -- might resemble more an item from a bleak and torturous dungeon, however, more than any sort of a realistic design in a digital computing system.
I'm certain, now, that I'd simply misinterpreted a certain diagram that I'd read, like as if a "Broad arrow" in any way indicated a "Surface area of a copper conductor." To my best present recollection, I'd seen somesuch diagram, sometime when I was reading up about I2C[7]
So, last night, in my then having observed some of the obvious naivete of that concept, I then proceeded to do some more studying -- that, in the "reading up" part of so much homework, rather studying -- in a sense, research, as namely about digital backplane design.
Towards a Concept of SHB as Backplane
My own study had not begun with this exact item, though I would denote it as the first item in this portion of my short summary, here: There's an article about backplane design, at Wikipedia, the Free Encyclopedia.[11]One of the items that I think is of particular note, in that article -- and namely, as with regards to a concept by which I had found the Wikipedia article, in looking for some more description after another item that I'd found, last night: There's something of a set of industry standards defined as with regards to backplane design, in a context of single board computing, namely PICMG standards 1.0, 1.1, 1.2, and 1.3.[11][12], as would be relevant to a concept of System Host Board (SHB) design, and SHB as backplane, in applications of single board computing[11]. The last in that list of those PICMG standards, there, is also related to a concept, SHB Express.[13]
Presently, I've not been able to locate any exact designs for an SHB Express implementation using the TI AM335x or other editions of the TI Sitara MCUs. I've not either begun to read the actual PICMG standards, as yet. I only wish to denote those resources as reference items, here.
Towards "That Popcorn Moment," in Regards to: System on Module (SOM) Concepts, TI Sitara MCUs, ARM Architectures, RISC Instruction Sets, and MIT CADR
Towards a further, perhaps related concept, as in regards to applications of single-board computer MCUs: As of this morning, I've found a few System on Module (SOM) designs incorporating various editions of the TI Sitara MCU design. Of course, I'm biased towards the Sitara, due to that it's the same brand of MCU as used on the BeagleBone Black -- that ultra-affordable development kit, erstwhile that I've denoted as BBB here. The Sitara, being an ARM MCU, uses an ARM instruction set -- therefore a RISC instruction set. At that point, it might bear some relevance furthermore with regards to the old MIT CADR processor.If my bias about the Sitara might be not only sentimental, then, I certainly hope it may be fortuitous if -- as a young software and systems developer -- I would focus primarily on the TI Sitara MCU architecture including the TI AM335x and the TI AM437x.
In some short searching, I've found a couple of System on Module (SOM) designs using Sitara MCUs -- in likewise, a short list, moreover with a bit of informative tail recursion:
- iWave RainboW-G12M DM816x Q7 SOM, with related iWave RainboW-G12D AM389x/DM816x Development Kit
- DAVE's Lizard AM3517/AM3505 SOM
- Comprehensive list of Sitara ARM MPU SOM/SBC, at the Texas Instruments Wiki
In considering the matter of capacitance and electrical reactance in circuit traces, it's my impression that "the SBC as SoM design" might seem to be more ideal, for some applications, contrasted to relatively common "SBC on SO-DIMM" design -- that, for instance, the iWave G12M offers a smaller, therefore certainly less reactive edge interface than what I presume an SBC on SO-DIMM card might offer. In my opinion, the smaller interface of the G12M would be closer to ideal, for the G12M's application as a modular computing element.
Candidly, then: I would like to define a BeagleBone SOM edition -- if only sans political concerns, such as with regards to contemporary events in world news.
The SOM BB would be designed so as to continue with design concepts represented in the BeagleBone Black, although -- in my opinion -- the SOM BB should be considered with its baseboard, as in regards to how the BBB design could be effectively revised for the different architecture.
The SOM BB would not, itself, require so many conventional I/O interfaces. The interfaces for SD storage, Ethernet/FastEthernet, HDMI, USB, those could be placed on the SOM's baseboard.
The baseboard could also be defined with with conventional GPIO headers, placed so as to accommodate the conventional BeagleBone Cape. Ideally, the GPIO headers would be geometrically elevated above the SOM socket and SOM board, sufficient to accommodate the respective Capes.
Furtheremore, a digital voltage controller could be added, with an additional header for interfacing with Arduino shields -- thus, adding a bit more of extensibility to the design.
My being a novice student of electrical engineering, I could only guess if perhaps an Atmel chip might be sufficient as an independent microcontroller for the baseboard itself, something effectively to "Bounce" I/O from the respective hardware bus onto the SOM board.
In its edition one, the baseboard would contain one socket, for exactly one SOM board.
The design of the baseboard should be accompanied with SysML diagrams, sufficient for illustrating the component architecture of the SOM baseboard and its interfaces to the SOM board, itself. In a broader sense of design, the baseboard and the SOM board may be approached so as to present an opportunity for study, as with regards to how a SOM programmed with the SOM board could be applied, alternately, in special purpose digital systems -- for instance, to a usage case with such a SOM board being applied as a "Cubesat Brain".
I would reference, primarily, the iWave G-12M as an inspiration to the design of the SOM board itself. The G-12M features a compact form factor, with a small edge interface, certainly sufficient to accommodate the small space of a Cubesat, in the Cubesat usage case.
A second usage case could be defined for the hypothetical BB SOM board, as the BB SOM board being applied in a network service context, namely as a compact network gateway device providing the functionality of conventional Linux features such as the Linux kernel's netfilter modules, routing subsystem, traffic shaping qualities, and TCP congestion control modules. In that usage case, SOM boards could be "Cold swapped" for updates to the network gateway's firmware and software components, with minimal network downtime.
A third usage case could be defined for the BB SOM board, in a context of desktop computing. If the novelty of the design might be sufficient to carry this by, candidly I would prefer that that usage case would make a demonstration of Linux Mint for modular applications in single-CPU desktop computing.
Later usage cases could be defined for applications in parallel computing -- as to define a Beowolf cluster of SOM modules, with a multi-SOM baseboard -- ostensibly, towards protyping a system for locating stellar reference points, within the Sloan Digital Sky Survey, using simple fourier transforms or other mathematical signal domain processing models.
In a context of application/network/data/user security, a branch of the SOM design could be developed, at some point in time, for integrating a Trusted Platform Module (TPM) into the SOM and the SOM baseboard. That could be accompanied with a development of a usage case for the SOM board as a VPN interface provider -- namely, using strongSwan as the VPN service implementation on the SOM board.
Ed. Note: Regarding TPM applications in VPN configurations, see also: BeagleBone CryptoCape; strongSwan.
Temporary Conclusion
That, then, is my primary academic thesis concept, in its current state -- with such concerns about world peace and online politics notwithstanding.In summary: Pending further progress in academic studies, I would wish to focus on developing a system on module edition of the BeagleBone Black platform -- focusing primarily on those usage cases that I've denoted in the previous.
Though my bias towards the TI Sitara MCU might seem arbitrary, in a sense of convenience, however with regards to the Sitara MCU's PRU-ICSS modules being applicable for independent I2C signal processing, candidly I wonder if it might prove to be not only arbitrary, as a design choice?
Works Consulted
[1] Raspberry Pi Blog. Raspberry Pi Compute Module: new product![2] Embedded Linux Wiki. RPi Hardware
[3] Embedded Linux Wiki. Beagleboard: BeagleBoneBlack
[4] Embedded Linux Wiki. BCM2835 datasheet errata
[5] Circuit Co. Design and Document files for the BeagleBone Black from BeagleBoard.org
[6] Texas Instruments. AM33588 Sitara Processor
[7] Digital Spelunk 42. Resource Note - Digital Serial Bus Technologies - I2C
[8] Digital Spelunk 42. Notes onto RTOS Linux
[9] Microchip Forums. I2C On a Backplane?
[10] Quabbin(R) Wire and Cable Co. Inc. Tech Brief - Why is Cable Capacitance Important for Electronic Applications?
[11] Wikipedia Advanced. Backplane
[12] Wikipedia Advanced. PICMG
[13] Wikipedia Advanced. PICMG 1.3
