We are delighted to announce the successful completion of a tiny footprint high-level computing language for high-speed, low-power, embedded computing on bare silicon (no BIOS, no OS). In terms of size, cost, and carbon footprint, the kernel clocks in at 730 bytes which includes a fully extensible runtime kernel providing DSL (domain specific language) capability for application specific computing.
Continue reading this article…
|
||||
|
January 31st, 2024 (4th ed)1 This article takes a look at what is involved in taking an end-to-end perspective in design in which the goal is to minimize the overall complexity of the system, i.e. of the hardware-software-user combination. To achieve this, it is helpful to understand how computing, and within that, how the notions of the sacred and the profane have evolved over the past 60 or so years.2 The following remarks capture the perspective:
The discussion requires a familiarity with lower-level computing, i.e. computing that is close to the underlying hardware. If you already have some familiarity with this, you can jump straight in to section 2. For all backgrounds, the discussions in the Interlude (section 4) make for especially enlightening reading. Whether you find yourself in violent agreement or disagreement, your perspective is welcomed in the comments!  Between complexity and simplicity, progress, and new layers of abstraction. Continue reading this article…
TinyPhoto is a small rotating photobook embedded graphics project that uses the low-power ATtiny85 microcontroller (3mA) and a 128×64 pixel OLED display (c.5-10mA typical, 15mA max). This combination can deliver at least 20 hrs of continuous play on a 3V coin cell battery (225mAh capacity). TinyPhoto can be readily built from a handful of through-hole electronic components (12 parts, £5) organized to fit onto a 3cm x 7cm single-sided prototype PCB. The embedded software is c.150 lines of C code and uses less than 1,300 bytes of on-chip memory. TinyPhoto rotates through five user-selectable images using a total of 4,900 bytes (yes, bytes!) stored in the on-chip flash RAM. The setup produces crisp photos on the OLED display with a real-time display rate that is instantaneous to the human eye with the Tiny85 boosted to run at 8MHz. A custom device driver (200 bytes) sets up the OLED screen and enables pixel-by-pixel display. Custom Forth code converts a 0-1 color depth image into a byte-stream that can be written to the onboard flash for rapid display. It is a reminder of what can be accomplished with low-fat computing… The magic, of course, is in the software. This article describes how this was done, and the software that enables it. Checkout the TinyPhoto review on Hackaday!  Tiny Photo – 3cm x 7cm photo viewer powered by ATTiny85 8-bit microcontroller sending pixel level image data to OLED display (128×64 pixels), powered by 3V coin cell battery. Cycles through 5 images stored in 5kB of on-chip Flash RAM. (Note, this is 1 million times less memory than on a Windows PC with 8GB RAM). The magic is in the software. Voice controlled hardware requires four capabilities: (1) vocal response to trigger events (sensors/calculations-to-brain), (2) speech generation (brain-to-mouth), (3) speech recognition (ear-to-brain), and (4) speech understanding (brain-to-database, aka learning). These capabilities can increasingly be implemented using off-the-shelf modules, due to progress in advanced low-cost silicon capable of digital signal processing (DSP) and statistical learning/machine learning/AI. In this article we look at the value chain involved in building voice control into hardware. We cover highlights in the history of artificial speech. And we show how to convert an ordinary sensor into a talking sensor for less than £5. We demonstrate this by building a Talking Passive Infra-Red (PIR) motion sensor deployed as part of an April Fool’s Day prank (jump to the design video and demonstration video). The same design pattern can be used to create any talking sensor, with applications abounding around home, school, work, shop, factory, industrial site, mass-transit, public space, or interactive art/engineering/museum display.  Bringing Junk Model Robots to life with Talking Motion Sensors (April Fools Prank, 2021) Abstract This brief note explores the use of fuzzy classifiers, with membership functions chosen using a statistical heuristic (quantile statistics), to monitor time-series metrics. The time series can arise from environmental measurements, industrial process control data, or sensor system outputs. We demonstrate implementation using the R language on an example dataset (ozone levels in New York City). Click here to skip straight to the coded solution), or read on for the discussion.  Fuzzy classification into 5 classes using p10 and p90 levels to achieve an 80-20 rule in the outermost classes and graded class membership in the inner three classes. Comparison with crisp classifier using the same 80-20 rule is shown in the bottom panel of the figure.
In Section 7, we implement the grammar of the statement calculus in the Symbolic Logic Simulator (SLS), a program written in 28 lines of Forth code, that allows computer-aided verification of any theorem in Propositional Logic (see Appendix 1 for source code). The program makes it straight-forward to explore non-obvious logical identities, and verify any propositional logic theorem or conjecture, in particular see Appendix 2 for key identities in the statement calculus (duality, algebraic, and canonical identities). The concept of linguistic adequacy is developed in Section 8 and the NAND Adequacy Theorem is proved showing that NAND can generate all logical operations. A corollary is that any digital logic circuit can be built up entirely using NAND gates, illustrated using the free Digital Works software. 2nd ed., Feb 1, 2024, 1st ed. Jan 9th, 2010 A common misconception is that assembly language programming is a relic of the past. This is certainly not the case, and assembly language remains a core knowledge area for embedded systems development, digital design, and algorithm development in the 21st century. A second misconception, especially amongst those who are only familiar with higher level languages (Python, Ruby, C#/.NET, Perl), is that assembly language is a defective programming language and therefore not worth the time to invest in. But assembly language is more than ‘just another general purpose programming language’. It is actually the control signal specification for the microprocessor or microcontroller that will be running the instructions, and whose digital design must be reasonably well understood in order to get it to work successfully. Higher level languages typically hide the underlying toolchains behind turnkey integrated development environments (IDEs). But the toolchains are valuable in their own right, comprising various software components (pre-processor, compiler, assembler, linker, loader) which take the high level code and transform it to executable machine code that can run on the target processor, optionally producing assembly code for inspection along the way. Familiarity with this toolchain can help evaluate how much overhead the high-level tools introduce on the code, which is an important part of understanding how much you’re trading off. In this article, we’ll look first take a look at the software toolchain involved in general terms, before turning to specific tools you can use on a modern Windows computer (through Windows 11) to target an x86 chip (no longer in your PC but in a DOS Emulator). Similar skills and approaches carry over to the toolchain for the Atmel 328P and ATTiny 85 with a graphics application (TinyPhoto) on the ATTiny85 here. Before domain-specific languages (DSLs) and REPL environments (read, execute, print, loop) became fashionable, computing pioneer Charles (Chuck) Moore had built, by 1968, what he viewed as the perfect computer programming language, which he named FORTH (for fourth generation language). What he had kept in view during its creation was an extreme austerity in syntax and structure as he searched for the minimalist system required to interact with a computer and be able to write custom problem-oriented languages to solve them. This approach is what he considered to be “programming”: you solve your problem by developing an application specific language with multiple levels of abstraction giving you in the end a small dictionary of simple words (in code) which represents the solution cleanly and in overall the fewest lines of code. Let’s look at this idea, how it has worked out over the years, and how you can apply this, regardless of the language you choose to (or have to) work with. This article looks at Forth, Lisp & Ruby, language that make it easy to solve classes of problems by writing your own DSL, i.e. by programming a specific “problem-oriented language” in which to solve your problem. |
||||
|
© 2009-2024 Assad Ebrahim To contact me on email, use: assadebrahim2000 at gmail dot com (do the obvious) |
||||