Monday, June 30, 2014

Resource Note - Digital Serial Bus Technologies - I2C

In a context of digital electronics, a brief couple of resources bout the I2C serial bus protocol:
  • Blozis, Steve and Jean-Marc Irazaba. I2C Logic Family Overview . Philips. 2004
    • Extensive presentation, even in its "slide format"
    • Provides a thorough technical overview about I2C 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. I2C 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 I2C serial bus protocol
    • Observe that the I2C 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 I2C  protocol, effectively, would require a bidirectional mode of I2C bus operation

Sunday, June 29, 2014

Towards defining a standard-compliant, vendor-neutral metamodel for digital electronic components, "Nothing Too Ambitious"

Personally, I'm a fan of UML and SysML. I've read the Object Management Group (OMG) specifications for UML, MOF, XMI, and broader MDA, and have read about some of SysML's practical applications, in the book, A Practical Guide to SysML: The Systems Modeling Language, by Sanford Friedenthal. For UML, SysML, and BPMN modeling, I think Modelio is particularly suitable. Alternately, Eclipse Papyrus has some interesting features for model definition, also.

It's my understanding that Modelio is implemented primarily in C++, and Eclipse, primarily in Java. MOF and UML effectively extend on XML Schema Datatypes (XSD) so it's not an innately language-centric framework, however. Of course, insofar as how XMI is applied within specific modeling platforms,, there are broad differences between platform vendors' own implementations of the standard. However, pretty much all of it is encoded in XML, and encoded according to a normative model serialization methodology, in each respective modeling tool vendor platform. Certainly, some vendors have focused a lot on code generation -- Modelio can even do "Round trip" analysis on Java class file definitions. The "XMI part," however, might seem to be pretty much ad hoc, per each vendor's implementation, but nonetheless it's all information structured in XML.

My now gaining some simple practical experience with regards to electronics design automation (EDA) tools -- such a Altera Quartus II Web Edition -- as a student of DeVry University Online, moreover in endeavoring to "Look ahead" towards developing any single thesis concept for the inevitable "Senior project," for a deadline sometime down the proverbial road of academic progress, and as being presently in a week's break between a semester's two sessions with DVUO, I've been taking some time to compile some more research resources, and to sketch out some simple notes for possible software and electronics design projects for "the months ahead," before I'll have completed the initial associates degree. Sure, I am "that much of an undergrad," formally.

While conducting some such focused research, last night, I'd noticed that a few JEDEC standards were referenced from the Altera Cyclone III Device Handbook (p. 6-12 / PDF p. 110) -- that there are a select number of JEDEC JESD standards referenced, there, as in regards to compatibility onto standards for CMOS/LVCMOS, TTL/LVTTL, and PCI voltage ratings. As a student of DVUO's ECT programs, personally I now own an eSOC3 board with a Cyclone III FPGA device installed on the same. Sure, the board doesn't have any design documents available for it, so I might not be able to make any use of the thing, now that the initial ECT-114 class is complete. At least, there might be some proverbial "Mileage" in the actual manual for the FPGA device, itself. (Maybe sometime, I could simply desolder the thing and put into a normal proto-board. To return to the present matter, however...)

After further searching online, this afternoon -- namely, having searched the dynamic, "world wide virtual library" to learn if there would be something in regards to standards for functionally individual logic gates, such that could serve as a normative, vendor-neutral reference, towards developing a sort of object-oriented hardware definition model for modeling digital logic systems in Common Lisp -- I'd found,  specifically, JEDEC JESD 75-5, ON/QFN PACKAGE PINOUTS STANDARDIZED FOR 1-, 2-, AND 3-BIT LOGIC FUNCTIONS. I think it's quite a nice little reference manual, the same, though I've noticed now that it's a specification specifically about integrated circuits packaged in QFN format and other Small Outline (SO) formats. I'd noticed the item, firstly, in that it provides a nice, enumerated list of standard logical functions in manufactured integrated circuits, such as the dual input digital AND gate, some couple of types of digital logic inverter, and the inevitable "D Flip-Flop" (DFF)

Focusing on the matter of the enumerated set of logical functions, in that document: Certainly, JESD 75-5 does not, itself, define the exact functional behaviors of those standard circuit elements (AND, NOT, and the DFFs) -- such as would be indicated in a truth table for each, such that, of course, one might find in most manufacturer's data sheets. Inasmuch, JESD 75-5, itself, does not specify any exact, practical applications for those circuit elements. However, I think it's helpful that they at least have assigned some standard nomenclature to the same logical circuit functions enumerated in the document -- at least in their QFN and SON packaging (?) -- including AND, DFF, and inverter circuits. If perhaps it could also serve in making a simple, enumerated list of those logical functions thusly standardized, then personally I think it could be of interest towards defining a vendor-neutral schematic model.

I think, the set of JEDEC documents is certainly nicer to see than an old edition of MIL-STD 1562 (not classified), as far as standardization in digital electronics.

So, evidently there are vendor-agnostic standards for those digital logic "things". I think that's reassuring. However, noticing that JESD 75-5 refers to digital circuit elements manufactured specifically in QFN or SON packaging -- with definitions in the document, describing the characteristics of the same -- perhaps such a foremost reference as I was looking for.

It seems that the effective, contemporary "roots" of the JEDEC digital electronics standardization tree -- so to speak -- would be defined in JEDEC JEP95, across a number of categories such as for standard qualities of diodes, transistors, and microelectronics. I'm sure it might not seem so interesting, however, if outside of the possibility of defining a software meta-model for an effective, standardized representation of those same qualities as standardized in JEDEC '95 -- a meta-model as in reference to OMG SysML, UML, and MOF -- towards defining a vendor-neutral EDA platform, moreover, ideally extending on existing free/open source software components.

JEP95 defines, in the JEP95 Microelectronics Outline (MO) Device Type (DT) index, a broad index of standard categories for integrated circuit packaging, like in a sense of socket formats -- not the carrier packaging apparently the topic of the CO and CS indexes in JEP95 -- rather, the socket packaging of circuits as would be installed onto a printed circuit board (PCB). Some of the items in that index may seem "outdated" -- such as the Quad In-Line (QUIP) socket format -- an IC socket format that was used, "once upon a time," in some Intel components in the iAPX 432 midromainframe (circa 1981). However, if technology may be regarded more as a function of science and engineering, without too much of an emphasis on "treandiness," the term "Outdated" would not seem to have much of a sense of relevance, in the simply technical view.

So, in reading the JEP95 MO//DT index as an index of socket formats, it may serve to inform a model for application in computer aided design and drafting (CADD) in electronic design automation (EDA). However, in itself, JEP95 does not define any of the functional qualities of integrated circuits.

JEP95 is referenced from JESD 75-5. Perhaps there may be something similar to JESD 75-5 but more specifically about DIP and SMD formats for TTL and CMOS circuit elements? I should update my notes, here, sometime after researching that matter, further.

Notably, in furthermore:
  • JEDEC also publishes a nice, formal dictionary of technical terms: JESD 88
  • JESD 30F - Descriptive Designation System for Semiconductor-Device Packages, none closer to a functional description but of more interest for the definition of a generic, vendor-neutral digital circuit component metamodel, for application within a digital circuit design environment. JESD30F is another JEDEC JC-10 specification
  • JESD 75-4, contextually similar to JESD 75-5 but defined about BGA packaging
  • JEDEC JC-40, Digital Logic, JEDEC Committee
    • The BGA-focused JESD 75-<N> standards, as published under JC-40, might serve to define something of a normative reference base, towards a baseline digital logic model, in bit ranges of 1, 2, 3, 8, 16, 18, 20 and 32 bits.
Additionally, Texas Instruments publishes a number of reference resources. all a bit market-focused certainly:
  • Logic Cross-Reference from Texas Instruments (313 pp. PDF) focused on individual integrated circuit types
  • Selection and Solution Guides, an index of reference resources
  • The Little Logic Guide (25 pp. PDF)
    • Terminology (pp. 5-6)
      • CBT: Bus Switch
      • CBTLV: Low-Voltage Bus Switch
      • CB3T: Low-Voltage Translation Bus Switch
      • LVC: Low-Voltage CMOS (1.65 V to 5.5V, or 1.8V to 5.5V depending on product range)
      • AUC: Advanced Ultra-Low-Voltage CMOS
      • AUP: Advanced Ultra-Low-Power CMOS
    • Indexes:
      • Single-gate logic functions, pp. 9-11. "G" numbers corresponding to JESD 75-4 (e.g 1G00, 1G02) with some omissions (e.g 1G05) and some additions (e.g 1GX04 Crystal Oscillator Driver)
      • Dual-gate logic functions, pp. 12-13
      • Triple-gate functions, p. 14
      • Single-switch functions, p. 14
      • Configurable functions, p. 15
      • Voltage translation functions (single-supply and dual-supply), pp. 15-16
      • LVC devices (competitor xref) pp. 17-19
      • AUC devices (competitor xref)  p. 19
      • Signal-switch devices (competitor xref), p. 20
      • AUP devices (competitor xref), pp 20-21 
        • low power logic functions. see Logic Guide p. 15
      • AHC and AHCT devices (competitor xref), p. 21
      • Configurable devices and AUP1T translators, p. 22
  • The Logic Guide (125 pp. PDF)
    • AUP devices, p. 15
      • low power logic functions
      • mobile device applications
    • GTLP and VME devices, p. 29
      • Optimal backplanes
      • I2C, PCI, ...
    • Product index begins at p. 31
  • Hamilton, William. Lectures on metaphysics and logic. ed. Henry Mansel, and John Veitch. W. Blackwood and Sons (Edinburgh). 1874
    • Notably, no references to Boole or De Morgan
    • Syllogisms, philosophical logic

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
  • 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
  • Standard: POSIX 1003.1
 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 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.

Saturday, June 28, 2014


 ED. NOTE: I'd cut and pasted this from my own response, tonight, in an online forum.

Considering the OSI seven layer model: There may be some applications possible for existing fiber optic "layer 1" technologies, therein using  a sort of "different" optical media, though, namely in real "Outer space," moreover in a context of the emerging privatization of "Outer space," as around such as Richard Branson's Virgin Galactic and SpaceShip Two, the latter's "home spaceport" being located near Las Cruces, New Mexico.

Observing the web site of the NASA LLCD  project, specifically, NASA has begun to develop technologies such that may be suitable for high-throughput communication between satellites, using a digital encoding on optical signals, in real "outer space." Of course, there would also be some complex satellite positioning algorithms being required, in the same -- the network being absent of an effective "cable" between each of the respective light-signal endpoints -- that the system appears to function in a manner broadly analogous to a hypothetical system of a flashlight (or rather, a laser) and a lens, each in a digital circuit, moreover absent of intervening "air".

If the optical networking technologies used in the LLCD project might be -- in some ways -- analogous to conventional fiber optic media, then, and if the same technologies may be suitably miniaturized, perhaps such a possibility could be recognized commercially, and applied towards further production of that technology. Of course, it might not be viable for a "mass market," but it might be useful for application in further development of some emerging technologies -- such as, ostensibly, towards asteroid mining at orbital lagrange points above low earth orbit. No doubt, such systems as could be used in a by-in-large automated orbital asteroid mining system, those systems could function without continuous optical networking, but certainly it would not be a bad thing if a constant optical network was available as among the respective "mining satellites", and wherever the main "mining control people" would be, whether in orbit or (ostensibly with a repeater between the optical network and a radio network) on the ground.

Conceivably, if it may be possible to build the further OSI layers on top of that optical media, then -- perhaps, as in implementing an existing TCP/IP stack effectively onto such networking media, as could be approached in using Cisco's IOS and its QNX RTOS baseline, or an RTOS Linux implementation -- then, it might even be possible to implement CORBA in real "outer space". Of course, it would also need a suitably resilient digital electronics platform, for such a networking system to function continuously, in orbit.

Maybe one day, there could be CIsco routers in real "outer space."

Towards Boolean Logical Procedures in CLtL2

The following Common Lisp function provides a functional representation of a schematic for a digital logic circuit of three inputs and one output.
(defun foo (a b c)
               (labels ((inv (m) (ecase m (0 1) (1 0)))
                      (f1 () (boole boole-and a b))
                      (f2 () (boole boole-and (inv b) c)))
                 (values (inv (boole boole-ior (f1) (f2))))))
  • Common Lisp does not define a monadic boolean compliment function.
    • There are diadic boolean compliment operations available via the BOOLE function -- two of which, each one operating on only a single data value provided of the two arguments to the BOOLE function.
    • Why doesn't CLtL2 define a monadic boolean compliment function?
  • In the illustration, the INV function provides a switched implementation of an effective monadic boolean compliment function 
    • Is it not possible to define a more efficient monadic boolean compliment function, in actual machine code?
    • Argument and return value types: CL:BIT
  • The set of procedures provided by the CLtL2 BOOLE function may be represented, in each, with an inline function requiring of only two arguments and constrained in its argument types and return values exactly onto the data type CL:BIT
    • When compiled, each such function might provide a trivial interface onto the implementation's own machine-specific encoding for each of the specific BOOLE procedures
    • Observing DeMorgan's theorem, those implementation-specific implementations of the respective BOOLE procedures may be reviewed, in each, for its respective implementation-specific compiler optimizations -- thus creating a nice "Usage case" for studying implementation-specific procedures and methodologies for defining compiler optimizations onto specific implementations of CLtL2
  • The methdology of defining a single function to represent each logical element in a circuit, such that the function accepts as many inputs as the circuit element has input pins, and returns as many values as the circuit element has output pins
    • That each such "logical function" can be modeled in CLOS
    • That it may serve to define an effective hardware definition language, in Common Lisp
    • That it may not be appropriate to reinvent SPICE / XSPICE  / NG SPICE / ...
    • That it may be appropriate to define a hardware definition language optimized for Common Lisp

Thursday, June 26, 2014

From 'OR' to Invention - Towards a Common Lisp Desktop Development Enviornment and Implementation-Specific "Robot Innards"

Part 1 - Logic and/or GUIs

This week, I've completed a session of the DeVry University Online (DVUO) basic digital electronics course, ECT-114. Among the topics addressed in the course: The generic qualities of basic boolean logic operations.  Presently, I'll skip the reiteration of the typical overview I may sometimes wish to present about MIT CADR, in all of its public domain Lisp Machine design qualities. There are reference resources available, online, about that topic in computing history -- such as at Unlambda.

The page that I am writing, here, it is not a project page about a Lisp Machine design, insomuch. Inasmuch, this is not a page about Xilinx FPGAs, and it's not a page about SysML, and it's not a page about SPICE NG. I think, those are all relevant topics for Lisp Machine design, but this it no about those topics -- not "This page," insomuch.

This is a page more about my wishing to develop an idea in regards to data flow programming, the ARM architecture, and digital logical applications. It's a sort of "Once in ever" kind of thing, to me, that I think I have arrived at a convenient coincidence of some concepts, at that.

Here's my best approximation of an outline:
  • Boolean logic
  • Boolean logical operations in Common Lisp, such as BOOLE [function]
  • Data flow programming
  • The ARM MCU instruction set architecture, as a subset of RISC architectures
  •  Not: The literally four instruction architecture of CADR — but that's pretty neat.
 Dandamudi's effective ARM instruction set reference,  specifically at that location in the same book, the full set of boolean logical operations in ARM is denoted -- as I would write in a literal expression syntax, here:
  • AND
  • OR
  • XOR
  • NOT -- and similarly, 'mvn'
Dandamudi also denotes the bit clear instruction, 'bic' and the count leading zeros instruction, 'clz', in that same context. Personally, I would like to focus on those four instructions denoted in that itemized list -- because that's it. In that exacting set of instructions in the ARM instruction set, there are exactly three diadic logical operations and the monadic compliment operation, NOT. Assuming that I've not made any to wide-arcing an interpretation of the matter,  presently, it must be that -- under such as DeMorgan's theorem -- those total of four microcontroller unit (MCU) instructions can be used for implementing all possible boolean logic functions.

I think that's pretty neat, firstly. Secondly, it reminds me of an at least ad hoc view -- "my own view," that -- about the VOP architectures of each of CMUCL and SBCL

So, then, of what practical relevance could that simple, cheerful matter of observation then be? I think, there could be a number of ideas that one could follow through with, at that:
  • To study any single fork of an ARM port of SBCL 
    • to see how the full set of Boolean Logic procedures are implemented in SBCL on ARM
    • likewise, to study the VOPs implementation in CMUCL and SBCL
    • optionally, to model some of "those VOPs" in a relatively bare-bones visual model, in an abstract graphical syntax such as of UML 
    • focusing specifically on CLtL2 BOOLE [Function]
  • To study more of CCL
    • firstly, to determine how it may be approached, and if it is already done in CCL, to implement assembler instructions directly in Lisp code, in CCL on Linux ARM and Android ARM platforms
    • commenusrately, to study how the CLtL2 BOOLE function is implemented in CCL
      • whether via LibC
      • or directly in assembler instructions?
  • Novel sidebar: To begin to develop a graphical model for logical data flow programming, in Common Lisp, commensurate with either mode of study
    • Inspired by National Instruments LabVIEW
    • Focusing on CLIM
      • in any single Lisp implementation on Linux
      • Linux and not Windows, as both a practical and personal choice -- namely, because my SLIME configuration really isn't working out, presently, in my Windows 8.1 desktop OS environment. (There's something about SLIME REPL not being loaded correctly in Emacs 24 on WIndows -- I haven't tried out XEmacs, at that, but might try that out, next, on the PC....)
      • because:
        • CLIM was defined with a platform-agnostic window system interface
        • CLIM is implemented in the free/open source McCLIM source tree
        • CLIM can be integrated well with CLOS MOP 
        • CLIM in CLX would not need any foreign function calls, such as might be difficult to "Trust" solidly in some implementations' respective interfaces onto the PC host environment -- or alternately, one might wonder: Why is CL+J not implemented any further than in MKCL, if it's not a matter of "hairy" FFI in some other Common Lisp implementaitons?
        • CLIM's window system interface framework, that being "one thing", mostly in regards to geometric interfaces onto user interface (UI) layouts
        • CLIM's effective gadget toolkit being "another thing," such that might seem to effectively parallel such gadget toolkits as are provided by  UI components such as Qt and the Cairo UI, those implemented in C and C++, on existing operating system architectures.
        • CLIM effectively "Leaves a door open" for further widow system development, with the respective CLIM implementation publishing a fairly architecture-neutral meta-interface, such as may be utilized by any CLIM application user interfaces, for interfacing transparently onto any single, host platform window system. In that much, it could seem nicely "Designer friendly," though it might not seem so stellar as a Qt application in all its maturity of human computer interface (HCI) designs
        • and if that's not enough for a practical sense of focus, but of course CLIM isn't easy to "Make work" on Microsoft Windows platforms -- not without something like XMing or Cygwin -- probably not anything I myself would recommend for production applications, in any sort of a consumer market, if simply due to the complexity of running an X server on top of the Microsoft Windows Explorer shell.
        • If that's still not enough for practicality: It is possible, moreover, to install a Linux virtual guest image onto a Microsoft Windows desktop host platform, using Virtualbox
          • I myself would recommend Linux Mint as a Linux desktop OS, whether for a virtual guest installation or directly as a host OS on a desktop PC. Personally, I think Mint's Cinnamon desktop environment is pretty keen for desktop Linux work
          • Using a virtual Linux Mint 64 bit edition (specifically LMDE 201403) in Virtualbox (4.3.12) on a 64 bit Microsoft Windows PC (Microsoft Windows 8.1)  "there" it is possible to run the Mint desktop environment in Dropbox seamless mode, such that the Linux guest desktop applications then would integrate quite smoothly with the desktop environment of the host PC OS. 
            • I think it's fine for a development environment, and with some further adaptation in the Linux guest desktop configuration -- e.g towards a more specific window manager selection and towards disabling the screensaver configuration, for instance -- that it could be alright for "production use," then, as a production-grade developer environment component
            • Of course, I've read that there's a Common Lisp desktop environment. That could be towards something of a good component for a desktop Common Lisp software development toolchain, as such -- simply, a nice Common Lisp interface onto the bare-bones session, the virtual guest installation then not really needing adding any further "GUI features" in such a configuration -- not menus, not panels, not pager, just GUI applications and maybe X session management.
        •  So, that's my recommendation for a working McCLIM development environment on a Microsoft Windows desktop OS -- all in one itemized list. Some features "New"
  • Because invention.
There's also the ARM MCU, beside all of the Intel desktop wonderment.

Assorted resources
 Because invention, and kites.

 Part 2 - "Development Environment" Not for Sale

In regards to beginning to develop a development environment with Virtualbox, Linux Mint (LMDE),  and Common Lisp, there are some initial observations I would denote:
  • Preferring Git for SCCM roles, I use Git, even for so much as storing my Emacs configuration files, i.e "Dot directory"
  • Using Git in a virtual guest OS is not the same as using Git on a host PC
    • When the virtual guest OS is running in Virtualbox, then a Git client in the virtual guest OS may access a repository installed on the host PC, namely if and only if:
      • The Git repository on the host PC would be stored in a Virtualbox shared folder, and/or....
      • The Git repository on the host PC would be available via a network service protocol such as SSH
        • Thus requiring that an SSH service would be running in the host PC OS -- as could be installed via Cygwin, when the host OS is Microsoft Windows
        • Therefore, effectively requiring that any changes made in the guest OS would be Git-pushed from the source tree/repository on the guest OS to the source tree/repository in the host OS, and conversely
    • The Shared folders approach would be simpler
    • The SSH git approach -- the second "of  those" -- depending on the host OS' firewall configuration, it may serve to allow for the Git repository to be accessed from the host OS via local LAN. Furthermore, it would not be exclusive of the shared folders approach.
    • A git repository in such a host environment may be shared with the guest OS via shared folder and via the local LAN (and the guest OS, ostensibly)  if the appropriate SSH service would be configured appropriately for the latter.


Wednesday, June 25, 2014

Aerospace and Computing - How Many Degrees of Separation?

Ed. Note: This is another brief "Finals week" item.

As a person born human, once upon a time I lived in North Carolina. My parents, and I along with, we'd visited the local "Beach scene," while there, and Kittihawk.

As a person born during the end of the Cold War, I think I'm familiar with a certain history of humanity that just doesn't "Make the press" any more, though it was a part of real human history -- the nuclear deterrence part of world history, not so much from a view of "Escalationism", and not so much from the time of the volatile "Post-OWS world."

As a student of information science, I'm cautious to share too much of a bibliography, however -- not if too hastily so -- in this same "Post-OWS world" -- this same "Post-Snowden world" -- this same "Post-Manning world" -- this same "Julian Assange world", this "same". The wish-oriented politics of a naive and revolutionary few could topple a whole nation, in "This world." I don't think that's a good thing, but even as in the time of the Cold War, one lives within the world climate in as it is, nonetheless.

There's a history of aviation -- certainly a few -- from the first person to see a bird in flight, to Da Vinci's ornithopter, later the Montgolfier Brothers in their "Lighter than air" designs, later the gliders  designed and put aloft by Octave Chanute, and later, the Wright Brothers -- they were certainly not "Makers, alone," in that history. Moreover, there's a fellow who worked with the Wright Brothers -- and later than that, who worked with IBM: Mr. Charles R. Flint, in whose ostensibly "Rambling" commentary, his support of the Wright Brothers is denoted -- namely, in an excerpt from Flint's autobiography. That excerpt alone, though it might not be suitable as a primary reference, but it speaks volumes of the history of aviation, of technology in war, and then there's the note about IBM.

Obviously, I'm writing this not with "Punched cards," though I've heard of those-- and it's nothing too far off from modern digital system, I'm sure.

So, in a spirit of "Once upon a time," I would ask such an oblique question:  

How many degrees of separation are there, between this:

and this:

aiga information bg

Additional Resources:

Quantum Computers use Clocks Too -- A Commentary about Quantum Computing, After a News Item about Quantum Chronography

Ed. note: For sake of brevity, I'm going to simply include my social networking comment, here, verbatim, in its "last draft" edition. It's "finals week" at DVUO, this "session".

Understanding it would be a sidebar to the matter of atomic clocks as chronographs,[1] moreover as a student of a certain digital electronics course at an online U, but I wonder if they could make a digital circuit using an atomic clock? Something about rate of clock pulse -- and sure, I can "Do my own research" just like "My own homework". For instance, there's something about MIT's AI Labs, it was called CADR, a successor to the CONS machine, both being "Lisp Machines". I understand that the schematics for CADR are formally in the public domain, now? In contemporary circuitry, there's the PRU-ICSS on the MCU used by the BeagleBone Black single board computer -- the PRU-ICSS modules, two of each on that MCU, those can run at different clock rates, as denoted in TI's own data sheets, which TI publishes.

I wonder, then, could innovations in atomic timekeeping affect digital circuit design, positively? Like, atoms -- the new germanium, perhaps? In a sense, towards transitorising the atom? [2] I'm sure MIT's physicists would be more capable than I to understand how that could go, though, LoL LoL

[2] -- there's a reason why they chose Phosophorous as the element of that atom, it being not an arbitrary thing, no doubt. One observes then, that that article includes a bibliographical reference too -- not sure it's too high level for the classes I'm in, though, quite seriously.

Further resources in theories of quantum computing, "Beyond punched cards"

Tuesday, June 24, 2014

On Installing Linux Mint - The 'Granite' PC Edition - "Issues Abound"

Cinnamon Destkop Environment, Linux Mint LiveCD
Some context:
  • HP Pavilion PC
  • Linux Mint (LMDE 201403)
  • Hostname: Granite
Some notes, on installing Linux Mint on an HP Pavilion PC
  •  Before writing this blog entry, the drivers for the touchpad for the PC needed to be configured to disable the touchpad when typing
    • That was "Easy enough," via the Mouse and Keypad configuration widget, under the System Settings menu entry in the Preferences menu of the Cinnamon Desktop Menu
    • Without that configuration change, otherwise the PC's hypersensitive touchpad would serve to prevent effective use of the web browser
  • Browser issues -- Mint LMDE 201403 ships with an actually "oudated" edition of Firefox
    • Negative features of the edition of Firefox shipping with LMDE 201403:
      • Firefox 27 -- Is it the ostensible "Optimized by Yahoo" edition of Firefox?
        • That page indicates, inaccurately, as if Firefox 30 was not available on Linux (Accessed 24 June 2014)
          • Maybe it's simply a matter of crossed semantics. Perhaps Firefox 27 is the latest version of Yahoo(Firefox) though it is not the latest version of Mozilla Firefox.
        • Firefox 30 is, in fact, available on Linux 
        • The current edition of Firefox (Firefox 30) is available via
      • The Firefox 27 edition shipped with that edition of Mint (LMDE) prevents the user from selecting Google as a search engine in the browser search bar
        • Google is not either available in the "Manage search engines" menu, in that Firefox 27 edition
      • The Firefox Synch configuration is strange in that edition, and not well usable. Unlike in Firefox 30, the Firefox Synch configuration in that edition of Firefox 27 it requires some sort of a "remote device" for its configuration, whereas in Firefox 30, the Firefox Synch configuration only needs one's regular username and credetials for login  
    • Due to the significance of the web browser as an application in the typical desktop OS user experience and workflow -- certainly, the web browser being no less significant as an essential desktop application, as much on a Linux Desktop, as much as on an OS X or Microsoft Windows desktop -- then the limitations of the edition of Firefox shipped with Mint (LMDE 201403) might seem to suggest a sense of limitations to the OS itself, if only due to the "Yahoo Optimized" edition's Yahoo branding and Yahoo search engine lock-in
    • At least the upstream Firefox is available to be installed by the user and/or admin -- an edition of Firefox not limited by any single search engine provider's own endeavors in marketing
  • The PC of this installation is an HP Pavilion, 15 D045NR
  • The Linux Mint used for that laptop: Linux Mint, LMDE 201403, 64 bit (amd64), with Cinnamon configured as the primary desktop environment 
    • Cinnamon -- great desktop UX, regardless of these "hangups"
  • There appears to be some kind of an issue with Linux KMS on that laptop -- specifically with  Kernel 3.11.2 on that model of PC
    • The PC will not "Boot to GUI" -- not either before or after installation -- if without the parameter, 'nomodeset', being specified on the kernel command line. 
    • Without that parameter, the install disk screen goes blank after the kernel is loaded. Similar behavior is observed with the OS as installed.
    • Advice about 'nomodeset' was found  via a tutorial at the Linux Mint community web site
    • Additionally, the kernel parameter, grub_gfxmode=1280x1024x24  as denoted in the tutorial, it serves to allow for a more usable terminal/console view, on that laptop
    • Those additional kernel command line parameters may be specified via Grub, at boot time, and may be added to the host Grub configuration, followed with `update-grub`
      • However, the KMS issue (framebuffer??) effectively asks for a long-term resolution, on at least that model of laptop
    • When the Cinanmon desktop boots to X, with the nomodeset parameter specified on the kernel command line, then there's a warning about the desktop running in software acceleration mode. That warning may be viewed as it being a useful item, however -- for instance, it may be viewed as effectively denoting some further concerns with regards to correcting the configuration on the laptop.
  •  Additionally, that model of PC uses UEFI, in such a hard disk and firmware configuration as makes it notably difficult -- though notably "not impossible" -- to install Linux in parallel to the PC's primary Windows 8.1 installation
    • "Quick" workaround: To enable "Legacy boot" in the BIOS, and to manually select the non-UEFI/non-EFI entry for the hard disk, in the boot device options, every time the PC boots
    • Alternately, one may consult available documentation online, for advice about installing Linux for dual-boot on an UEFI PC.
  • Perhaps in some relation to the UEFI issue, `cfdisk` is not able to read the partition table of the laptop's internal drive.
    • `cfdisk`emits the error message, "Unsupported GPT (GUID Partition Table) detected" and indicates that the partition table can be acessed with `gparted`
    • FIXME: The `gparted` partition editor  is not shipped with the LMDE live disk (LMDE 201403)
  • ntfsprogs -- unavailable?
  • Keyring issues
    • A workaround is available - note the comment by Sadi, in an item at Ask Ubuntu
      •  Though the  "convenient hack" is available, but that issue  needs an upstream resolution
    • Evidently it's not a matter of keyring issues, per se 
    • Aptitude reports the issue as if it being a matter of "Unauthenticated sources"
    • It appears that it is matter involving of the /var/lib/apt/list/... files, whether as installed by the LMDE installer and/or as updated after installation. The workaround entails an effective removal (renaming) and subsequent recreation of those files (FIXME)  

As I observe, my post-install tasks therefore include:
  • Task: Fix /var/lib/apt/list/... files (complete)
  • Task: Install gparted (complete)
  • Task: Configure swap partition (complete. "/" is on sda7, swap is on sda8, partitions configured previously via a Debian netinst install, since overwritten)
  • Task: Install new/open Firefox browser, and synch browser with Firefox Synch (add-ins, bookmarks, Diigo.) (complete, see notes)
    • Follow-up task: Update shortcut link (desktop toolbar, menu) for new Firefox (in progress)
      • Note: The KDE Menu Editor presents a convenient interface for editing the user's desktop applications menu. Cinnamon does not currently publish such an interface.
    • Follow-up task: Remove "Yahoo(Firefox)" from OS installation
    •  FIXME: Publishing an Open Firefox via a Debian repository?
      • Question: Compatibility and versions, between Iceweasel and Firefox?
      • Issue: Web usability 
      • Note: Shut down Mint Firefox before starting Firefox in "new" open Firefox installation
    • Note: Used stow for stowing the latest Firefox edition (Firefox 30) under /usr/local 
      • specifically,  /usr/local/lib/firefox  with a corresponding binary dir and symlink
      • the files are actually stored under  /usr/local/stow/firefox-30.0/ but symlinked, using `stow`, under /usr/local/
      • FIXME: Whither xstow?
  • Task: Modify Grub configuration for the temporary nomodeset workaround, and then `update-grub`
  • Determine and fix the cause of the "nomodeset issue"
    • Additional observations:
      • After using the "CTRL+ALT+F_" hotkey for switching to any of the console virtual terminals on that model of PC, and under at least that Linux kernel version, the PC's display screen becomes completely unusable, all of an "Empty black screen" of unusability, no matter what hotkeys would be applied,  then
      • Is it a framebuffer issue?
      • Question: What graphics hardware is the PC using -- as may be denoted, in some sort of a standard way of identifying the hardware -- and what kernel driver is being used for that graphics hardware?
        • Methodology: 
          1. Task: Install `lshw-gtk`
          2. Review the output from `lshw-gtk`as displayed at the desktop, to determine that further information -- namely, hardware ID and kernel driver.
          3. Alternately, review the shell output from `lswh --xml | less`
            • Observe xpath:node[@id='display'] 
            • Containing element:  xpath:/node[@class='system']/node[@id='core']/node[@id='pci']
            • product: 3rd Gen Core processor Graphics Controller
            • vendor: Intel Corporation
            • businfo: pci@0000:00:02.0
            • Identified at manufacturer product specification page as: Intel HD graphics 4000
            • See also: Intel Graphics Drivers for Linux
              • Note: For LMDE, download the source code, build, and install (note: dependency errors) For non-LMDE Mint distros, see advice for installing via apt (package: intel-linux-graphics-installer)
          4. If applicable, reconfigure the kernel for the graphics hardware. 
            • In some PC configurations, and at the user's own option, this may entail an installation of non-free graphics card drivers (whether from Nvidia or -- perhaps more likely -- from ATI, in this configuration) alternate to free/open source drivers (e.g. Nouveau)
    • Resources include:

gparted and terminal, Granite PC