Supercluster, The // Design Update, A // Towards System on Module Concepts for BBB

Last night, around a discussion in a private, online forum in the DeVry University Online (DVUO) Electronics and Computing Technology (ECT) program -- a discussion, namely with regards to applications of parallel resistive/inductive/capacitive (RLC) circuit designs in ECT-125, this semester -- I began a "Research arc," which I would like to presently describe. That was in continuing with a certain thesis development project, as with regards to -- broadly -- applications in parallel computing. I've been proceeding along in this thesis development project, since sometime after I'd read of the Raspberry Pi (RPi) Compute module  in its SO-DIMM form factor, then later purchased a BeagleBone Black (BBB) at Radio Shack, in fact.

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 ':' address model onto the underlying I2C protocol, such that would then be extended kernel space drivers and a CORBA implementation, perhaps The ACE ORB.

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

Resource Note - Digital Serial Bus Technologies - I2C

In a context of digital electronics, a brief couple of resources bout the I²C serial bus protocol:

• Intefacing with the Linux kernel
• i2c-tools - I²C Tools for Linux
• libsoc
• Generic kernel interfaces
• ioctls
• Does not depend on i2c-tools
• See also 
• Benchoff, Brian.Speeding Up BeagleBone Black GPIO A Thousand Times. 2013
  
• Direct I/O onto /dev/mem to enable the SPI0 module clock, prior to GPIO I/O

• Blozis, Steve and Jean-Marc Irazaba. I²C Logic Family Overview . Philips. 2004
• Extensive presentation, even in its "slide format"
• Provides a thorough technical overview about I²C as a serial bus protocol
• Contains some useful "Best practice" advice, e.g. with a reference to the NXP P82B96 Dual bidirectional bus buffer

  

•  Blozis, Steve and Jean-Marc Irazaba. I²C Manual. Philips. 2003
• Provides an overview and comparison onto other serial bus protocols
• UART
• SPI
• CAN
• USB
• IEEE-1394 Firewire
• SMBUS
• A survey of individual connectors for cables in circuits using those protocols is available from Western Digital: WD Interface Guide (HTML)  (PDF)
•  Thorough explanation of theory and technology represented in the I²C serial bus protocol
• Observe that the I²C serial bus, in bidirectional bus operation, may be operated at one of three individual rates of clock timing -- maximum clock rates:
• 100 kbit/s (Standard-mode / Sm)
• 400 kbit/s (Fast-mode / Fm)
• 1 Mbit/s (Fast-mode Plus / Fm+
• 3.4 Mbit/s (High-speed mode / Hs-mode)
• In unidirectional bus operation, the bus may be operated in Ultra Fast-mode (UFm) at a maximum clock rate of 5 Mbit/s
• A multi-master I²C  protocol, effectively, would require a bidirectional mode of I²C bus operation

• Topic: Using I²C functions on contemporary single board computer platforms
• I²C on Raspberry Pi (RPi)
• Magda, Yury. Raspberry Pi Measurement Electronics: hardware and software. Second edition (Kindle). 2014
• uses i2c-tools (see previous items)
• Note that the RPi uses a Broadcom BCM2835 as a microcontroller munit (MCU). 
• Lacking further documentation about the I²C  interface(s) on the BCM2835 , the lack of availability of the BCM2835 data sheet may effectively serve to limit any I²C development on the RPi
• See also: Discussion in RPi forums
• Alternately: The BCM2835  may be found to publish interfaces for SPI and USB 2, as made avaialble via the RPi board. USB in particular is used on the RPi board.
•  I²C on the BeagleBone Black (BBB)
• PRU-ICSS modules on the TI Sitara MCU (ie. TI AM3358)
• See also: BBB - Working with the PRU-ICSS/PRUSSv2, Element 14 Community 
• Note: PRU-ICSS may be capable of only Standard-mode (100k) or Fast-mode (400k) I2C. See  Technical Reference Manual (AM335x) p. 4484 noting the specification of 100k or 400k
• Block view: Two PRU-ICSS modules in each TI Sitara MCU; One TI Sitara MCU to on each BBB. 
• See also: 
• System Refertence Manual (SRM) for BeagleBone Black. CircuitCo
• AM3358 Technical Documents. Texas Instruments.
• Data sheet for AM3358 
• Pinmux utility
• User Guide (AM335x) 13 pp.
• Note the section about interrupt events, including "INT_STS2_REG.GPIO_R/F_IT"
• Technical Reference Manual (AM335x) 1566 pp.
• Note specifically, sublcause 9 of the manual, Control Module through to subclause 9.2.2.1, Mode selection, concerning the two-bit MUXMODE field and its specifier values
• Note also subclause 4 of the manual, which is dedicated to the PRU-ICSS
• Note, thirdly, subclause 21.3.15 of the manual, How to Program I2C - using the PRU-ICSS function set
• For I²C development with the BBB and other TI Sitara (AM335x) platforms, it may be feasible to use the I²C features of one or both of the PRU-ICSS modules on the AM335x device, rather than reconfiguring the pimux of the primary ARM(R) Cortex A8 MCU via SYSBOOT
• References onto broader theory
• Bosworth, Edward L.  Introduction to Computer Organization (CPSC 2105). 2012
• Knight, Thomas, et al. CADR (MIT AI Memo 528)
• PRU-ICSS. Texas Instruments
• Hardware information (individual microcontrollers' product pages)
• Software information
• Getting Started Guide (PRU-ICSS)
• Recommends software packages for the development environment
• Code Composer Studio (CCS) v6
• See also: CCS for Sitara ARM
• NON-FREE (cf. DFSG)
• PRU Code Generation Tools (add-on, might be available via CCS UI)
•  PRU-SWPKG (see subsequent items) 
• Header files (PRU-ICSS) 
• PRU-ICSS Remoteproc Driver (Linux) (e.g LinuxLink RTOS on BBB)
• PRU-ICSS Rpmsg Driver (Linux) (e.g LinuxLink RTOS on BBB)
• See also: Linux EZ Software Devleopment Kit (EZSDK) for Sitara(tm) Processors . Texas Instruments
• NON-FREE (DFSG)  - Based on Code Composer Studio (CCS)
• Programmable Realtime Unit Software Development. Texas Instruments
• PRU Assembly Reference Guide
• PRU Assembly Instructions
• Notice the "Wait until bit set" and "Wait until clear" functions, each available for polling a status bit in a PRU register
• Advanced PRU Assembly Topics
• Debugging PRU Assembly Code
• PASM Tool
• PRU Linux Loader 
• Usage: Load assembler program into independent PRU memory area
• cf. PRU-ICSS Remoteproc driver (load time); see also: Rpmsg driver (runtime)
• See also: app_loader source code, beagleboard community
• PRU Software Support Package
• Specifically, the PRU-SWPKG edition (actively maintained) (x86 32 bit. For advice about installing 32 bit support on amd64 Ubuntu, see advisory note)
• PRU-SWPKG [Tools Platform]
• Depends on Code Composer Studio (CCS) [Tools Platform] a non-free component (cf. DFSG)
• PASM [Toolchain Component]
• FOSS (DFSG Compliant)
•  PASM (AM335X PRU) Source code available via beagleboard community at GitHub
• See also: LinuxLink embedded Linux Development Center for TI AM335x Sitara [Tools Platform, RootFS, Kernel]
• compatibility onto PASM - ?
• one of GNU libc / uClibc [compiler toolchain]
• Alternately, see also: Linaro Toolchain (BBB) (cf. TI EZSDK)
• A single PRU-ICSS module may provide access to an I²C bus, across the full range of available rates of clock timing in the I²C specification
• Driver support
• Integrating the PRU-ICSS within userspace software : ?
• Patching i2c-tools ? libsoc ?
• Integrating the PRU-ICSS within kernel drivers: 
• Module uio_pruss and BBB device tree updates
• See also, previous items (Remoteproc, Rpmsg drivers )
• Sitara Linux SDK
• Availability (???) see Linux EZ Software Devleopment Kit (EZSDK) for Sitara(tm) Processors  (???)  
• Refer to Release notes in ... ??? PRU-SWPKG ???
• ??? AM335x SDK BSP Source Code (???) 
• See also: BeagleBone PRU Notes, Embedded Linux WIki
• Accessing the  I2C interfaces (three available?) on the primary TI Sitara MCU module
• See also: BBB SRM
• Processor mode switching, Pinmux configuration
• uBoot
• Microinstructions for processor mode switch?
• SYSBOOT 
• See also: BeagleBone I2C2 Enable, Embedded Linux Wiki
• See also: Notes onto RTOS Linux, DSP42.
• Specifically, Timesys LinuxLink provides direct support for LinuxLink RTOS on the BeagleBone Black platform. Links and more are available at the other article

Notes onto RTOS Linux

Personally, I'm not one to make any sort of lengthy association between culture and computing. It's my point of view that a computer is a practical thing -- nothing of "style" or of too much of conversation, to me. I also don't talk for long about my car, or my experiences in driving, or my experiences in operating heavy engineering equipment. Those are all practical things, to my point of view. If I might have any sort of a "style" about computing, regardless, I suppose "Tight lipped" would be the label that I would prefer, at that -- "Tight lipped" as contrasted to my sometimes bouts of rambling inconherently, and likewise of writing, though without a great sense of structure.

I understand that as I would continue to pursue a course of formal, academic study in computing and -- correspondingly -- a study in digital electronics, that I should wish to learn to develop a normative style of writing, then -- such that I would not be thought to be inept at communication, at least, though I am inept in much of "Style," I think. It's on the premise of computing being a practical thing, to me, that I endeavor to not be "Self conscious" about writing about computing -- even when I am writing without a great sense of structure or of focus.

If I would begin to write with more of a sense of structure and/or a sense of focus, then, I think it could go well if I was to begin to write about a single, linear process in development. At that, the first thing that comes to mind that I would like to write about: A manner of study, with regards to applications of the Linux kernel in realtime systems on thin client platforms. Of course, that in itself might not be so much of a simple topic to write about. If there is even a single vocabulary to the concept, I have not learned it yet, and if there is single, discrete set of technologies to the applications of such a concept, realtime systems on thin client platforms, I have not found that set of single, discrete technologies, as yet. Candidly, being a student, I have found at least a small assembly of hetereogenous components, some of which share some common qualities -- for instance, that a BeagleBone Black and an Arduino board can both conduct communications using the I2C protocol,  and that the Altera Cyclone III on eSOC FPGA board manfucatured for DeVry University students (a group which I am currently one of)  .... that it has IO headers at least, though he eSOC 3 is currently lacking any kind of a user manual, schematic, or other design documents, and therefore there's not much I can do with it.

In a practical regards, I think that a realtime Linux platform could be of some interest with regards to parallel computing models using single board computers, if not furthermore of Cubesat design -- neither of which would seem to be hot topics in "the consumer market," at this time, however. I'm sure that there could be an app made for news about it -- maybe it could be more popular, then. Certainly, it's a bit more complex than what can be developed on a mobile phone.

In all that complexity, perhaps there are some discrete qualities, however -- such that one may endeavor to "Snapshot," in a manner of writing -- resources, such as:

• Article: Jones, M. Tim. Anatomy of real-time Linux architectures. IBM Developerworks. 2008
•  In a structural view: The article denotes three primary types of Realtime Linux kernel, namely: Thin-kernel; Nano-kernel; Resource kernel. The article also describes the baseline architectures of the Linux 2.4 and Linux 2.6 kernels.
• Project: ADEOS Project
• ADEOS was denoted under the nano-kernel architecture, in the article published by IBM (Jones op. cit.)
•  ADEOS publishes an interesting article, in sort of crossing domains between SMP and cluster computing, namley in a context of a nano-kernel architecture
• Realtime Linux distribution:  Timesys LinuxLink
• This item, in particular, has really "Caught my attention," this week. I denote it, here, as a realtime linux distribution considering that it is an apparent descendant of a Linux distribution denoted in "that IBM article" (Jones op. cit.) namely, Linux/RK, denoted there as a realtime Linux distribution implementing a resource kernel model
• The Linux/RK project page, itself, makes reference to a number of additional resources, describing concepts of the architecture of a resource kernel model as implemented in Linux/RK. (Note that the resources are dated around 2001, and are available in Postscript format, but may be converted to PDF format with some GPL licensed tools such as 'ps2pdf', cf. Cygwin)
• In a practical regards, I've noticed that the Timesys web-based Build Factory provides support for the BeagleBone Black single-board computer and the TI Sitara microcontroller unit used on the BeagleBone platform. I'm well impressed, moreover, to see how well architected the Timesys Build Factory is. I've compiled a single build with it, and have yet to install that to my BeagleBone Black, but I look forward to that -- though catching up on some other  items, in the meanwhile.
• This item, in particular, I think I may be able to incorporate into a senior project. Though the project would be focusing primarily on developing an I2C I/O model using the BeagleBone Black, but with there being a solid baseline OS avaialble -- namely, LinuxLink -- as already catered towards realtime and embedded systems, that substantial bit of existing work could simply help -- by a long shot -- in defining a modular design, in the project.
• For a bit of historical context, there's an article about Timesys' original Linux/RT, at the Linux Journal
• Lazenby, Daniel. TimeSys Linux/RT (Professional Edition). Linux Journal. 2000
• Standard: POSIX 1003.1
• Resource:  Navet, Nicolas. Scheduling under Posix 1003.1b. INRIA. 2005
• Resource: POSIX 1003.1 FAQ. Open Group. 2013

 From there, the snapshot begins to focus more on the development environment, less on the OS itself.

•  Virtualization platform (x86 architectures): Virtualbox
• My having recently begun to develop a Windows 8.1 desktop on an x86 (amd64) PC, such that uses a UEFI architecture in its boot process -- that, adding some distinct complexity for any sort of a "Dual boot" configuration -- and the same PC has an intel graphics card that doesn't work ideally well, on Mint LMDE, "Out of the box", it's therefore my impression that Virtualbox provides a "Nearest to ideal" methodology, then, for both developing software in the Linux environment and continuing with the typically Microsoft Windows-dependent lab materials in the courses at DeVry University Online (DVUO)
• I've installed Linux Mint (LMDE edition 201403) into that Virtualbox image, and have begun to use that desktop as an overlay onto my Microsort Windows 8.1 desktop. 
• Virtualbox provides a nice seamless view mode for graphical applications in compatible Virtualbox virtual guest instances. When Virtualbox is using the seamless mode -- as for displaying GUI applications running directly in the compatible virtual guest instance -- it makes for a relatively smooth integration with the virtual host PC desktop
• There are some limitations -- such as namely:
• That the desktop menu of the virtual guest instance is inaccessible in seamless mode. However, there are some quick hotkeys that Virtualbox provides for changing the view mode, such that allows for access to the desktop men, as in fullscreen view mode.
• That it does somewhat "lag the PC", it being a virtual OS image for an OS that would typically be installed directly onto "Bare metal" hardware
• Those are, effectively, the only limitations I can observe of that configuration
•  Of course, it would also work "Swell" with the build factory image created by the Timesys web-based Build Factory
• Virtualbox can be easily configured to provide "pass through" I/O for USB devices, such as would allow for the BeagleBone to be configured directly via USB from within the Virtualbox virtual guest instance
• With or without an X.org window server running in the Virtualbox virtual guest image, Virtualbox nonetheless provides a framework for a full Linux development environment, without the characteristically "hairy" qualities of the process of installing a second bootable OS diretly onto a PC that uses UEFI.
•  The virtual media device as used by Virtualbox for its machine and block storage device emulation procedures, that media device is essentially contained within a single virtual media image, such that can easily be backed up and/or relocated to another PC.
• Advice: To use Samba and CIFS instead of the Virtualbox "Shared folder", for sharing files between the Virtualbox virtual guest image and the virtual host OS.
• "Some limitations would apply"
• Programming Language: Common Lisp
• This topic necessarily would entail a number of distinct sub-topics, such as at least one topic for each Common Lisp implementation being used in a single Common Lisp development environment. 
• Of course, one cannot simultaneously use every Common Lisp implementation that exists. Personally, I wish to focus on:
• Steel Bank Common Lisp  (SBCL) 
• towards: Defining a "New" Lisp OS
• Focusing on platforms:
• amd64
• armhf (where applicable, else armel)
• See also: Connors, Jim. Is it armhf or armel?. Jim Connors' Web Log. 2013
• Shell command: readelf -A /proc/self/exe | grep Tag_ABI_VFP_args
• NOTE: The distro might be compiled as armel, though the MCU might support armhf features, regardless
• Clozure Common Lisp (CCL)
• towards: A Common Lisp implementation providing close integration of existing software components on the Linux platform -- typically via FFI -- including the Linux Kernel itself
• Concept: MPI
• Resource: ParGCL, another Common Lisp implementation
• Concept: I2C
• Short summary: Standard I/O protocol for digital electronics devices onto a common digital signal bus
• Supported in the two PRU-ICSS modules in the TI Sitara MCU (cf. BeagleBone Black)
• Concept: CORBA
• Short summary: Platform-neutral architecture for remote data procedures and remote procedure calls within heterogenous networks
• Concepts: CORBA GIOP, CORBA IIOP
• Concept: CORBA IDL

 That, then, would effectively serve to complete the "Snapshot," this morning -- the "Snapshot" amended, then, with subsequent updates.

Towards a TWI+PCI Implementation of IBM's Token Ring Network Architecture

The following is a verbatim copy of a response I'd written for a private discussion forum at an online university, this day. The discussion, essentially, was towards a comparison and contrast of a number of network technologies applied at "Layer 0" of the OSI seven layer model. My response, in this item, focuses specifically about token passing, as used in each of FDDI networking and in token ring networking, among all available digital systems interconnects. 

The topic of token ring networking has particularly caught my attention as a developer, considering the possibility of refactoring the technology for application onto I2C interconnets, for application ostensibly within a parallel computing model incorporating CORBA. In my response, after the items about token passing in token ring networking, I've begun "taking some notes," towards such an ostensible redesign of token ring networking for a parallel computing model onto I2C and PCI interconnects.


Token access, or token passing is a network flow control technique used in token-ring networks. The technologies for token ring networking were originally developed by IBM, in the 1970's , and may still be applicable in some network environments -- for instance, where network fault tolerance is a high priority, such as in networked industrial automation and measurement environments.

A token ring network utilizes a star topology, in which a multistation access unit (MAU) provides ports for eight individual hosts, additionally one port for a ring in cable and one port for a ring out cable. Effectively, the MAUs are connected in a ring, with individual hosts each connected to a single MAU. Infoar as it being a "star" network topology, geometrically it's not exactly like the conventional multi-connected, five-pointed star, might seem perhaps more like a ring with "leaf" nodes.

On a token ring network, after the network is initialized and an active monitor station determined on the network,  an electronic token is sent onto the network and transferred from station to station, until arriving at a station that has data to send on the network. 

At the sending station, a single bit in the token frame is changed before retransmit, thus transforming the token frame into a start-of-frame sequence for an information frame. Information is then appended to the start-of-frame sequence, that information necessarily including an address of a specific format (byte?) identifying the intended receiving station for the token. 

The information frame is then transmitted onto the network, and successively retransmitted -- whether along the MAUs only? or entirely from host to host --  until arriving at the intended receiving station. The receiving station then copies the information frame, sets two bits in the information frame to indicate that it has received the information, and will retransmit the information frame. The information frame then continues around the network until arriving at the original sending station. 

Due to the application of the token passing technique, data collision is effectively not a concern on a token ring network


Network token passing is also used in FDDI networking

Works referenced:
[1]  Cisco DocWiki Token Ring/IEEE 802.5 [2] CTDP  Token RIng.  The CTDP Network Certification Reference Version 0.6.2 

On a sidebar, with regards to developing a concept for an academic thesis ostensibly with regards to parallel computing: Token ring networking could be considered for a design of an I2C network. I2C is a "Wire protocol" available via interfaces in some single-board computing platforms and the Arduino microcontroller platform. In that regards, I would propose some notes, which I will presently try to extend on, in draft editions of this comment

• An I2C implementation of a token ring methodology would not necessarily require an application of an MAU, per se.
• I've not studied up about a lot of the details of I2C and the corresponding TWI protocol, however I've read that each utilizes some sort an addressing format, and a sort of centralized, single "master" design, fundamentally, in which one I2C device is a single "master" device, and would indicate via synchronization with clock signals, the address of an intended "receiving" device, before sending data to that receiving device. All devices on the I2C network would be, effectively, "Listening" at all times, no the I2C network, to detect when the "master" device indicates that a datum is to be sent on the network, and to indicate the peer address of the device to which the datum is to be sent, then to indicate the end of the transmission to that device. (Of course, I should wish to review an exacting, authoritative reference about I2C and/or TWI, at that. I've been of a presumption that it would allow for a "Multi-master' protocol to be defined -- focusing on TWI -- however, I'm not certain of how that might be approached in the exact "Wire protocol.") 
• The ostensible I2C token ring implementation could be designed such that it would be a "Signle mastering" protocol, in which the single "master' device would be the active monitor station of the I2C Token Ring 
• Each device on the I2C token ring network would need exactly two I2C interfaces, such that one would be the device's on I2C or rather, "TWI ring in" and the other, the "TWI ring out"
• Termination of a TWI ring network : If it was implemented in a pre-designed hardware configuration, the hardware could be designed such that it would define a "Built in ring". I need to study more about I2C or TWI, to specify how that could be approached, in a high-level view of the wiring. 
• Extensibility of a TWI ring network: The Monitor/Master device could be defined effectively as to provide exactly two ring network interfaces -- one for an "on board' ring, and one for an "on PCI bus" ring, if the hardware of the device network was implemented with a PCI interface on a single PCB. Then, each PCB should need to be identified with a "board number," as well as each I2C device on the PCB being identified with a "Device number", thus creating effectively a two-part addressing protocol for messages across the entire TWI "ring" including devices on other PCBs
• Termination of a ring network as designed onto TWI + PCI interfaces: On the PCI interface, the network could be designed more like an IBM token ring network, insofar as that a single "active monitor" would identify itself, and the other PCBs on the network would be designed as to acknowledge the designation of the "active monitor". 
• Once the networking and addressing protocols would be specified, then it could be possible to develop a peer-to-peer or client-server application on the network, e.g using the existing work of the CORBA specifications, specifically focusing on GIOP ostensibly for extension onto any single static-model TWI/PCI Token Ring Network, ostensibly for developing a parallel computing model such as could be implemented within a single PC architecture, using conventional PC peripheral interfaces including PCI.
• It might seem unorthodox, in some ways -- if not altogether unoriginal -- if simply for it being an extension of existing electronics protocols. Of course, if it could be towards the development of a useful parallel computing model, then certainly one would wish to inquire as to what parallel computing could be used for, in real-world applications within contemporary enterprise. Personally, I'm more concerned about the hardware design, at this time. I think it could be useful in an artificial neural network design, but I've not read a lot about that, and neither about statistical computing.

Modeling the LispM – Quartus II and CADR, an Outline

Ed. Note: This article should subsequently be updated for modeling of the CADR schematic, using Xilinux ISE Web Pack, and the Papilio FPGA platform -- ideally, then to develop an I2C bus as initial extension onto the original CADR design, such that the I2C bus could be operated via the GPIO headers on the Papilio platform, in communicating with one or more other devices on the same I2C backplane. See also: TI PRU Cape for the BeagleBone platform.

CADR

• Lisp Machine
• Developed at MIT (circa late 1970's, early 1980's)
• Predecessor machine was CONS
• Described in public domain (?) AI Memos originally published by the MIT AI Lab
• Design
• Schematics
• Wiring/Pinouts
• Peripherals incl. Chaosnet network interface
• Designed in an era when integrated circuit (IC) technology was implemented primarily in applying techniques of transistor-transistor logic (TTL)
• ICs composed of circuits of bijunction transistors, resistors, capacitors, packaged in multiple elements within individual integrated circuit modules (e.g four SEL-D FF elements to one 25S09 IC)
• Standard (?) TTL logic/voltage bounds
• high/low, min/max voltage ranges on each of TTL circuit element input and output
• "Nondeterministic" voltage ranges (voltage high/low unspecified) on input and output
•  Logically combined voltage input/output differentials
• (?) Specified voltage ranges may vary by point of reference, outside of manufacturers' actual data sheets
• Principles and metrics of voltage, current, and IC fanout
• Circuit power consumption
• Clock frequencies
• Circuit fanout
• Contrast: CMOS (cf. MOSFET transistors)
• Four microinstructions
• ALU
• BYTE
• DISPATCH
• JUMP
• Memory, storage, display, and networking peripherals – applied to, if not furthermore in extensions of technologies available in the epoch of CADR's design

Quartus II

• Developed by Altera
• Focused primarily towards design, simulation, and application of FPGA platforms
• May be used for design and simulation of non-FPGA platforms
• Documentation: [Q2] Quartus II Handbook, PDF edition
• Quartus II Web Edition
• Available for free download and install
• Application Use Cases may include
• Block diagram definition
• Waveform simulation
• Device programming (e.g System on Chip devices, Altera FPGA programming)
• Student lab exercises, at DeVry University Online
• Modeling of Integrated Circuit (IC) logical profiles (e.g ideal 25S09 SEL-D FF)
• Modeling of ICs as manufactured – historically and/or contemporarily – modeling in IC material profiles (e.g AM25S09 or low-power logical equivalent) as in material limitation of the ideal logical profile of any single IC element (e.g 25S09)
• See also: Newton's contrast of geometry and mechanics, in the Principia
• Quartus is a platform combining a significant number of tools for Electronic Design Automation (EDA)
• Some individual tool components in Quartus are implemented as to support standardized hardware definition languages, including:
• Verilog
• VHDL
• EDIF
• Quartus Qsys system files
• May be used to model, in each, an IC used in the original CADR schematic
• Refer to: 
• [Q2], p. 270, Creating Qsys Components
• [Q2], p. 274, Creating Qsys Components in the Component Editor
• Note that the components will be HDL-based, deriving from the Unlambda CADR Verilog Files
• Some new Verilog files required
• e.g to combine four ff_dsel modules into one (new) 25S09 module

  `include "ff_dsel.v"
  
  module m25S09(s,cp,d0a,d0b,d1a,d1b,d2a,d2b,d3a,d3b,q0,q1,q2,q3);
      input s,cp,d0a,d0b,d1a,d1b,d2a,d2b,d3a,d3b;
      output q0,q1,q2,q3;
  
      ff_dsel d0(q0,d0a,d0b,s,cp);
      ff_dsel d1(q1,d1a,d1b,s,cp);
      ff_dsel d2(q2,d2a,d2b,s,cp);
      ff_dsel d3(q3,d3a,d3b,s,cp);
  endmodule
  

• must be determined per each individual IC defined in the schematics
• Qsys IC component definitions may be combined within the Qsys System File editor
• Refer to [Q2],, p. 195, Creating a Qsys system

Modeling CADR in Quartus II

• Primary references
• Public-Domain CADR Lisp Machine schematics, wiring, and design documents, published originally in MIT AI Memos
• Available via Archive.org, Bitsavers MIT collection
• Search: "CADR"
• Search: "CONS"
• IC manufacturers' data sheets (archived)
• Supporting resources
• Verilog files for CADR, as published by Unlambda.com
• Developer Notes:
• Licensing not specified, assumed "Public domain"
• Does not provide an exact model of the schematic – for instance, four Unlambda CADR Verilog ff_dsel (shared sel, clk pins) to each 25S09
• CADR may be modeled, alternately, in other hardware defintion languages
• NGSPICE defines a standard D flip-flop element, unbuffered. When defined in a module with buffer, then it might be compatible with Unlambda CADR Verilog ff_dsel and likewise, the original 25S09 IC logical profile.

Notes – Serial Protocols

On one ambitious day, shortly ago, I'd found some resources in technical academia online, namely as with regards to serial "wire protocols" developed in digital electronics. I'd like to share that small part of my student notes outline, here, that I think I should wish to make reference to that outline, later on, and that this small outline could be of any interest to the arbitrary reader.

Ed. Note: I'd cut and pasted the following outline from within my own student notes, originally on a mobile tablet computer. I'd used the uxWrite app, on an iOS mobile tablet, for these notes. The uxWrite app, effectively, ensured that the text I'd copied from the uxWrite app was represented in Markdown format, when it was pasted into the 'blog entry, in the blogTouch app. A study of application cut/paste protocols would be left as an exercise to the reader, as would the reformatting of this outline into HTML format, immediately.

  - Serial Peripheral Interface (SPI)

      - “Three wire” protocol (Clock, SOMI, SIMO) \[eLinux:BBSPI\]

      - Microelectronics

  - UART, USART \[Durda\]

      - UART: Universal *Asynchronous* Receiver/Transmitter

      - USART: Universal *Synchronous-Asynchronous* Receiver/Transmitter

      - Synchronous Rx/Tx between single sender and single receiver

          - Clock signal provided by sender

          - “Strobe” signal

      - Asynchronous Rx/Tx

          - “Start bit”

      - As UART protocols \[Durda\] RS232, EIA232 \[Strangio\]

          - EIA232

              - Update of RS232

              - Conventionally, uses a modem interface

              - 22 pin (including ground) serial protocol with flow control and secondary data channel (e.g used for retransmit after parity error) using DB25 connectors

              - 9 pin (including ground) serial protocol with flow control, using DB9 connectors

  - PWM

  - I2C \[Magda\]

      - Multiple devices per I2C channel

      - “Two wire” protocol (SCL, SDA)

      - ***Compare***: TWI \[[Wikipedia](http://en.wikipedia.org/wiki/I%C2%B2C)\]

  - Serial ATA \[Lee\] (SATA)

      - 1.5 Gb/s, 3 Gb/s, 6 Gb/s

  - PCI Express \[Lee\] (PCIe)

      - PCIe 2 : 5 Gb/s

      - PCIe 3 : 8 Gb/s

Works referenced:

\[eLinux:BBSPI\] Embedded Linux Wiki. *BeagleBoard/SPI*. 2013. [Available (HTTP)](http://elinux.org/BeagleBoard/SPI). Accessed 9 May 2014

\[Durda\] Durda, Frank. *Serial and UART Tutorial*. 2014. [Available (HTTP)](https://www.freebsd.org/doc/en/articles/serial-uart/). Accessed 9 May 2014

\[Strangio\] Strangio, Christopher E. *The RS232 Standard, A Tutorial with Signal Names and Definitions*. 2012. [Available (HTTP)](http://www.camiresearch.com/Data_Com_Basics/RS232_standard.html). Accessed 9 May 2014

\[Magda\] Magda, Yury. *Raspberry Pi Measurement Electronics: Hardware and Software*. 2014. Kindle edition.

\[Palermo\] Palermo, Samuel. *High-Speed Serial I/O Design for Channel-Limited and Power-Constrained Systems*.

\[Lee\] Lee, Edward W. *High-Speed Serial Data Link Design and Simulation.*