Some AVR devices, like attiny85 (on Adafruit Trinket, for example), do not
have hardware UART. However, it would be still nice to have serial output
I wrote a simple Soft_Serial package, which can use any GPIO pin as TX UART pin.
package Soft_Serial is
Serial_Pin : Boolean renames AVR.MCU.PORTB_Bits (2);
Serial_Pin_DD : Boolean renames AVR.MCU.DDRB_Bits (2);
procedure Write_Byte(B : Interfaces.Unsigned_8);
procedure Write (S : AVR.Strings.AVR_String);
The interesting bits in the implementation are:
MCU_FREQ : constant := 16_000_000;
procedure Wait_A_Little is new AVR.Wait.Generic_Wait_USecs
(Crystal_Hertz => MCU_FREQ,
Micro_Seconds => 102);
procedure Write_Byte(B : Interfaces.Unsigned_8) is
Data : Interfaces.Unsigned_8 := B;
Mask : Interfaces.Unsigned_8 := 1;
Serial_Pin := False;
for I in Interfaces.Unsigned_8 range 0 .. 7 loop
if (Data and Mask) = Mask then
Serial_Pin := True;
Serial_Pin := False;
Mask := Mask * 2;
Serial_Pin := True;
Basically, the Write_Byte procedure will put the GPIO pin up or down
with certain intervals.
The Wait_A_Little procedure has magic number 102, which gives us UART
speed 9600bps. (9600bps means one bit about every 104 microseconds,
the difference comes from the inaccurate internal oscillator.)
The procedure uses 8N1 format, meaning that the start bit (pin low)
is sent first, then the data byte as 8 bits, and finally one stop bit (pin high).
Open Gatekeeper settings located in System Preferences > Security & Privacy.
Set Allow applications downloaded from: to Anywhereand confirm by pressing Allow From Anywhere.
Run the application.
Once the application has been successfully launched, it no longer goes through Gatekeeper; so, restore Gatekeeper settings to the default option Mac App Store and identified developers after successfully launching the application.
EtherScope is a monitoring tool that analyzes the
Ethernet traffic. It runs on a STM32F746 board, reads the Ethernet packets, do some real-time
analysis and displays the results on the 480x272 touch panel. The application is completely
written in Ada 2012 with:
The GNAT ARM embedded runtimes is the Ada 2012 ravenscar runtime that provides support for interrupts, tasks, protected objects and other Ada features.
The EtherScope application which performs the analysis and displays the information.
The traffic analyzer inspects the received packet and tries to find interesting information about it.
The analyzer is able to recognize several protocols. New protocols may easily be added in the future.
The first version supports:
Analysis of Ethernet frame to identify the devices that are part of the network with their associated IP address and network utilization.
Analysis of IPv4 packet to identify the main IPv4 protocols including ICMP, IGMP, UDP and TCP.
Analysis of IGMP with discovery of subscribed multicast groups and monitoring of the associated UDP traffic.
Analysis of TCP with the identification of some well known protocols such as http, https, ssh and others.
Each analyser collects the information and is able to report the number of bytes, number of packets
and network bandwidth utilization. Some information is also collected in different graph tables so that
we can provide some visual graph about the network bandwidth usage.
Network setup to use EtherScope
To use EtherScope, you will connect the STM32F746 board to an Ethernet switch that you insert or have on your
network. By default, the switch will isolate the different ports (as opposite to a hub) and unicast traffic
is directed only to the concerned port. In other words, EtherScope will only see broadcast and multi-cast
traffic. In order to see the interesting traffic (TCP for example), you will need to configure the switch
to do port mirroring. By doing so, you tell the switch to mirror all the traffic of a selected port to the
mirror port. You will connect EtherScope to that mirror port and it will see all the mirrored traffic.
EtherScope in action
The following 4 minutes video shows the EtherScope in action.
EtherScope Internal Design
The EtherScope has several functional layers:
The display layer manages the user interaction through the touch panel. It displays the information that was analyzed and manages the refresh of the display with its graphs.
The packet analyzer inspects the traffic.
The Ethernet network driver configures the Ethernet receive ring, handles interrupts and manages the reception of packets (the transmission part is not used for this project).
The Ada Drivers Library provides a number of utility packages from their samples to manage the display and draw text as well as some geometric forms.
The GNAT ARM ravenscar runtime provides low level support for the STM32 board configuration, interrupt and task management. It also brings a number of important drivers to control the touch panel, the button, SPI, I2C and other hardware components.
The EtherScope.Receiver is the package that has the receiver task that loops to receive a
packet from the Ethernet driver and analyzer it through the analyzer. Because the result of
the analysis is shared between two tasks, it is protected by the DB protected object.
The EtherScope.Display provides several operations to display the analysis in various forms
depending on the user selection. Its operations are called repeatedly by the etherscope main
loop. The display operation fetch the analysis from the DB protected object and format the
result through the UI.Graphs or text presentations.
The Ada Embedded Network is a small IPv4 network stack
intended to run on STM32F746 or equivalent devices. This network stack
is implemented in Ada 2012 and its architecture has been inspired by
the BSD network architecture described in the book "TCP/IP Illustrated, Volume 2, The Implementation" by
Gary R. Wright and W. Richard Stevens.
This article discusses the Ethernet Driver design and implementation. The IP protocol layer part will
be explained in a next article.
In any network stack, the buffer management is key to obtain good performance. Let's see how it is modeled.
The Net.Buffers package provides support for network buffer management. A network buffer can hold a
single packet frame so that it is limited to 1500 bytes of payload with 14 or 16 bytes for the Ethernet header.
The network buffers are allocated by the Ethernet driver during the initialization to setup the
Ethernet receive queue. The allocation of network buffers for the transmission is under the responsibility
of the application.
Before receiving a packet, the application also has to allocate a network buffer. Upon successful reception
of a packet by the Receive procedure, the allocated network buffer will be given to the Ethernet
receive queue and the application will get back the received buffer. There is no memory copy.
The package defines two important types: Buffer_Type and Buffer_List. These two types are
limited types to forbid copies and force a strict design to applications. The Buffer_Type
describes the packet frame and it provides various operations to access the buffer. The Buffer_List defines a list of buffers.
The network buffers are kept within a single linked list managed by a protected object.
Because interrupt handlers can release a buffer, that protected object has the priority
System.Max_Interrupt_Priority. The protected operations are very basic and are in O(1) complexity so that their execution is bounded in time whatever the arguments.
Before anything, the network buffers have to be allocated. The application can do this
by reserving some memory region (using STM32.SDRAM.Reserve) and adding the region with
the Add_Region procedure. The region must be a multiple of NET_ALLOC_SIZE constant.
To allocate 32 buffers, you can do the following:
What happens if there is no available buffer? No exception is raised because the networks stack
is intended to be used in embedded systems where exceptions are not available. You have to
check if the allocation succeeded by using the Is_Null function:
if Packet.Is_Null then
null; -- Oops
The Net.Interfaces package represents the low level network driver that is capable of sending and
receiving packets. The package defines the Ifnet_Type abstract type which defines the three
Initialize to configure and setup the network interface,
Send to send a packet on the network.
Receive to wait for a packet and get it from the network.
STM32 Ethernet Driver
The STM32 Ethernet driver implements the three important operations required by the Ifnet_Type abstraction.
The Initialize procedure performs the STM32 Ethernet initialization, configures the receive and transmit
rings and setup to accept interrupts. This operation must be called prior to any other.
Sending a packet
The STM32 Ethernet driver has a transmit queue to manage the Ethernet hardware transmit
ring and send packets over the network. The transmit queue is a protected object so that
concurrent accesses between application task and the Ethernet interrupt are safe.
To transmit a packet, the driver adds the packet to the next available transmit descriptor.
The packet buffer ownership is transferred to the transmit ring so that there is no memory copy.
Once the packet is queued, the application has lost the buffer ownership. The buffer being
owned by the DMA, it will be released by the transmit interrupt, as soon as the packet is sent (3).
When the transmit queue is full, the application is blocked until a transmit descriptor becomes
Receiving a packet
The SMT32 Ethernet driver has a receive queue which is a second protected object, separate from
the transmit queue. The receive queue is used by the Ethernet hardware to control the Ethernet
receive ring and by the application to pick received packets. Each receive descriptor is assigned
a packet buffer that is owned by default to the DMA. When a packet is available and the application
calls the Wait_Packet operation, the packet buffer ownership is transferred to the application
to avoid any memory copy. To avoid having a ring descriptor loosing its buffer, the application gives
a new buffer that is used for the ring descriptor. This is why the application has first to
allocate the buffer (1), call the Receive operation (2) to get back the packet in a new
buffer and finally release the buffer when it has done with it (3).
Receive loop example
Below is an example of a task that loops to receive Ethernet packets and process them.
This is the main receiver task used by the EtherScope
The Ifnet driver initialization is done in the main EtherScope task. We must not use
the driver before it is full initialized. This is why the task starts to loop for the
Ifnet driver to be ready.
task body Controller is
use type Ada.Real_Time.Time;
Packet : Net.Buffers.Buffer_Type;
while not Ifnet.Is_Ready loop
delay until Ada.Real_Time.Clock + Ada.Real_Time.Seconds (1);
Then, we allocate a packet buffer and enter in the main loop to continuously
receive a packet and do some processing. The careful reader will note that there
is no buffer release. We don't need that because the Receive driver operation
will pick our buffer for its ring and it will give us a buffer that holds the received packet.
We will give him back that buffer at the next loop.
In this application, the number of buffers needed by the buffer pool is the size of the Ethernet Rx ring plus one.
One fascinating property of the LZMA data compression format is that it is actually a family of formats with three numeric parameters that can be set:
The “Literal context bits” (lc) sets the number of bits of the previous literal (a byte) that will be used to index the probability model. With 0 the previous literal is ignored, with 8 you have a full 256 x 256 Markov chain matrix, with probability of getting literal j when the previous one was i.
The “Literal position” (lp) will take into account the position of each literal in the uncompressed data, modulo 2lp. For instance lp=1 will be better fitted for 16 bit data.
The pb parameter has the same role in a more general context where repetitions occur.
For instance when (lc, lp, pb) = (8, 0, 0) you have a simple Markov model similar to the one used by the old "Reduce" format for Zip archives. Of course the encoding of this Markov-compressed data is much smarter with LZMA than with "Reduce". Additionally, you have a non-numeric parameter which is the choice of the LZ77 algorithm – the first stage of LZMA.
The stunning thing is how much the changes in these parameters lead to different compression quality. Let’s take a format difficult to compress as a binary data, losslessly: raw audio files (.wav), 16 bit PCM. By running Zip-Ada's lzma_enc with the -b (benchmark) parameter, all combinations will be tried – in total, 900 different combinations of parameters! The combination leading to the smallest .lzma archive is with many .wav files (but not all) the following: (0, 1, 0) – list at bottom . It means that the previous byte is useless for predicting the next one, and that the compression has an affinity with 16-bit alignment, which seems to make sense. The data seems pretty random, but the magic of LZMA manages to squeeze 15% off the raw data, without loss. The fortuitous repetitions are not helpful: the weakest LZ77 implementation gives the best result! Actually, pushing this logic further, I have implemented for this purpose a “0-level” LZ77  that doesn’t do any LZ compression. It gives the best output for most raw sound data. Amazing, isn’t it? It seems that repetitions are so rare that they output a very large code through the range encoder, while weakening slightly and temporarily the probability of outputting a literal - see the probability evolution curves in the second article, “LZMA compression - a few charts”. Graphically, the ordered compressed sizes look like this:
and the various parameters look like this:
The 900 parameter combinations
The best 100 combinations
Many thanks to Stephan Busch who is maintaining the only public data compression corpus, to my knowledge, with enough size and variety to be really meaningful for the “real life” usage of data compression. You find the benchmark @ http://www.squeezechart.com/ . Stephan is always keen to share his knowledge about compression methods. Previous articles:
____  Here is the directory in descending order (the original file is a2.wav). 37'960 a2.wav 37'739 w_844_l0.lzma 37'715 w_843_l0.lzma 37'702 w_842_l0.lzma 37'696 w_841_l0.lzma 37'693 w_840_l0.lzma 37'547 w_844_l2.lzma ... 32'733 w_020_l0.lzma 32'717 w_010_l1.lzma 32'717 w_010_l2.lzma 32'707 w_011_l1.lzma 32'707 w_011_l2.lzma 32'614 w_014_l0.lzma 32'590 w_013_l0.lzma 32'577 w_012_l0.lzma 32'570 w_011_l0.lzma 32'568 w_010_l0.lzma  In the package LZMA.Encoding you find the very sophisticated "Level 0" algorithm
if level = Level_0 then while More_bytes loop LZ77_emits_literal_byte(Read_byte); end loop; else My_LZ77; end if;
Here are some recent updates to our Free Tools and Libraries page:
September 30, 2016: Added X-Cleaner, a Windows tool to securely erase data.
August 11, 2016: Added PUGIXML Ada, a set of Ada bindings to PUGIXML, a lightweight XML processing library.
Added ZStd for Ada, Ada bindings to ZStandard, a new lossless compression algorithm.
July 19, 2016: Added Libsodium-ada, a set of thick Ada bindings to libsodium. Libsodium is a portable implementation of the NaCl encryption, hashing, and authentication library.
June 22, 2016: Added Container JSON, utilities for serializing/deserializing Ada containers to/from JSON.
Added SymExpr, a generic package for manipulating simple symbolic expressions.
May 19, 2016: Added AdaBase, a new database interface for Ada.
Added Imago, a binding to DevIL (a universal image handling library).
(This post will be periodically updated – Webmaster.)
Here are a few plots that I have set up while exploring the LZMA compression format.
You can pick and choose various LZ77 variants - for LZMA as well as for other LZ77-based formats like Deflate. Of course this choice can be extended to the compression formats themselves. There are two ways of dealing with this choice.
You compress your data with all variants and choose the smallest size - brute force, post-selection; this is what the ReZip recompression tool does
You have a criterion for selecting a variant before the compression, and hope it will be good enough - this is what Zip.Compress, method Preselection does (and the ZipAda tool with -eps)
If the computing resource - time, even energy costs (think of massive backups) - is somewhat limited, you'll be happy with the 2nd way. A criterion appearing obviously by playing with recompression is the uncompressed size (one of the things you know before trying to compress).
Obviously the BT4 (one of the LZ77 match finders in the LZMA SDK) variant is better on larger sizes than the IZ_10 (Info-Zip's match finder for their Deflate implementation), but is it always the case ? Difficult to say on this graphic. But, if you cumulate the differences, things begin to become interesting.
Funny, isn't it ? The criterion would be to choose IZ_10 for sizes smaller than the x-value where the green curve reaches its bottom, and BT4 for sizes larger than that x-value.
Another (hopefully) interesting chart is the way the probability model in LZMA (this time, it's the "MA" part explained last time) is adapted to new data. The increasing curves show the effect of a series of '0' on a certain probability value used for range encoding; the decreasing curves show the effect of a series of '1'. On the x-axis you have the number of steps.
This summer vacation's project was completed almost on schedule: write a LZMA encoder, whilst enjoying vacation - that is, work early in the morning and late in the evening when everybody else is sleeping; and have fun (bike, canoe, visiting caves and amazing dinosaurs fac-similes, enjoying special beers, ...) the rest of the day.
Well, "schedule" is a bit overstretched, because with a topic as tricky as data compression, it is difficult to tell when and even whether you will succeed...
LZMA is a compression format invented by Igor Pavlov, which combines a LZ77 compression and range encoding.
With LZ77, imagine you are copying a text, character by character, but want to take some shortcuts. You send either single characters, or a pair of numbers (distance, length) meaning "please copy 'length' characters, starting back 'distance' characters in the copied text, from the point where the cursor is right now". That's it! LZ77 is a well covered subject and is the first stage of most compression algorithms. Basically you can pick and choose an implementation, depending on the final compression size.
Range encoding is a fascinating way of compressing a message of any nature. Say you want to send a very large number N, but with less digits. It's possible - if some of the digits (0 to 9), appear more frequently, and some, less. The method is the following. You begin with a range, say [0, 999[. You subdivide it in ten intervals, corresponding to the digits 0 to 9, and calibrated depending on their probability of occurrence, p0 .. p9. The first digit of N is perhaps 3, and its corresponding interval is, say, [295, 405[. Then, you continue with the second digit by subdividing [295, 405[ in ten intervals. If the second digit is 0, you have perhaps now [295, 306[, representing the partial message "30". You see, of course, that if you want to stick with integers (with computers you don't have infinite precision anyway), you lose quickly precision when you set up the ten intervals with the probabilities p0 .. p9. The solution is to append from time to time a 0 to the interval, when the width is too small. So, if you decide to multiply everything by 10 each time the width is less than 100, then the interval for "30" will be now [2950, 3060[. Some n digits to be encoded later (after n subdivisions and some x10 when needed) your interval will perhaps look like [298056312, 298056701[. The bounds become larger and larger - second problem. Solution: you see that the leftmost digits won't change anymore. You can get rid of them and send them as a chunk of the compressed message. The compression will be better when symbols are much more frequent than others: the closer the probability is to 1, the more the range width will be preserved. If the probability was exacly 1, the width wouldn't change at all and this trivial message with only the same symbol wouln't take any space in its compressed form! It is an absurd case, but it shows why compression methods such as LZMA are extremely good for very redundant data. That's how the basic range encoding works. Then, a funny thing is that you can encode a mix of different alphabets (say digits '0' to '9' and letters 'A' to 'Z') or even the same alphabet, but with different probabilities depending on the context, provided the decoder knows what to use when. That's all for range encoding (you find a more detailed description in the original article ).
LZMA's range encoder works exclusively on a single, binary alphabet (0's and 1's), so the range is always divided in two parts. But it works with lots of contextual probabilities. With some parameters you can have millions of different probabilities in the model! The probabilities are not known in advance, so in this respect LZMA is a purely adaptive compression method: the encoder and the decoder adapt the probabilities as the symbols are sent and received. After each bit encoded, sent, received, decoded, the entire probability set is (and has to be) exactly in the same state by the encoder and by the decoder.
Developing an encoder from scratch, even if you have open-source code to reproduce, is fun, but debugging it is a pain. A bug feels like when something doesn't work in a PhD work in maths. No way to get help from anybody or by browsing the Web. By nature, the compressed data will not contain any redundancy that would help you fixing bugs. The decoder is confused on faulty compressed data and cannot say why. For range encoding, it is worse: as in the example, digits sent have nothing to do with the message to be encoded. The interval subdivision, the shipping of the leading interval digits, and the appending of trailing '0', occur in a way which is completely asynchronous. So, the good tactic is, as elsewhere, to simplify and divide the issues to the simplest. First, manage to encode an empty message (wow!). It seems trivial, but the range encoder works like a pipeline; you need to initialize it and flush it correctly. Then, an empty message and the end-of-stream marker. And so on. Another source of help for LZMA is the probability set: it needs to be identical at every point as said before.
The results of this effort in a few numbers:
LZMA.Encoding, started July 28th, first working version August 16th (revision 457).
Less than 450 lines - including lots of comments and some debugging code to be removed!
5 bugs had to be fixed.
To my (of course biased) opinion, this is the first LZMA encoder that a normal human can understand by reading the source code.
Zip-Ada's Zip.Compress makes use of LZMA encoding since revision 459.
The source code is available here (main SourceForge SVN repository) or here (GitHub mirror).
Back to vacation topic (which is what you do often when you're back from vacation): a tourist info sign was just perfect for a 32x32 pixels "info" icon for the AZip archive manager.
Click to enlarge
The beautiful sign
By the way, some other things are beautiful in this town (St-Ursanne at the Doubs river)...
 G. N. N. Martin, Range encoding: an algorithm for removing redundancy
from a digitized message, Video & Data Recording Conference,
Southampton, UK, July 24-27, 1979.
Playing with limited-length Huffman trees Read more
On the second image you can recognize "DIZAINES" and "UNITÉS". The letters are hardly visible after some 90 years of use... It's a pool table in the mythic Schlauch Restaurant in Zurich.
There is an equally beautiful implementation , translated for the purpose of the Zip-Ada project - a proper dynamic Deflate for compression is still missing, and a limited-length Huffman tree building algorithm is needed for that. Translation is there: specification, body, test procedure, and abstract enough to build with an Ada 83 compiler (at least GNAT in -gnat83 mode)! ___  Search: "A Fast and Space-Economical Algorithm for Length-Limited Coding"  Search: "katajainen.c" (this part of the "Zopfli" project)
...not in the economical sense fortunately, except that it's all about economy of bits.
Following last post about limited-length Huffman trees, there is now the very early development of a compression algorithm for the so-called "Dynamic Deflate" compression format. From revision #297 the code (checkout here) seems to correctly compress data (correctly means that the data is correctly decoded, even by buggy but popular decoders...). The efficiciency of the compression is in the works. Stay tuned!
Testing is welcome: build and use the ZipAda command-line tool, or use the Deflate_1 method in your code using the Zip-Ada library.
In a nutshell, there are now, finally, fast *and* efficient compression methods available.
* Changes in '50', 31-Mar-2016: - Zip.Compress.Shrink is slightly faster - Zip.Compress.Deflate has new compression features: - Deflate_Fixed is much faster, with slightly better compression - Deflate_1 was added: strength similar to zlib, level 6 - Deflate_2 was added: strength similar to zlib, level 9 - Deflate_3 was added: strength similar to 7-Zip, method=deflate, level 5
I use the term "similar" because the compression strength depends on the algorithms used and on the data, so it may differ from case to case. In the following charts, we have a comparison on the two most known benchmark data set ("corpora"), where the similarity with zlib (=info-zip, prefix iz_ below) holds, but not at all with 7-Zip-with-Deflate. In blue, you see non-Deflate formats (BZip2 and LZMA), just to remind that the world doesn't stop with Deflate, although it's the topic in this article. In green, you have Zip archives made by Zip-Ada.
Click to enlarge image
Click to enlarge image
Here is the biggest surprise I've had by testing randomly chosen data: a 162MB sparse integer matrix (among a bunch of results for a Kaggle challenge) which is a very redundant data. First, 7-Zip in Deflate mode gives a comparatively poor compression ratio - don't worry for 7-Zip, the LZMA mode, genuine to 7-Zip, is second best in the list. The most surprising aspect is that the Shrink format (LZW algorithm) has a compressed size only 5.6% larger than the best Deflate (here, KZip).
Click to enlarge image
Typically the penalty for LZW (used for GIF images) is from 25% to 100% compared to the best Deflate (used for PNG images). Of course, at the other end of redundancy spectrum, data which are closer to random are also more difficult to compress and the differences between LZW and Deflate narrow forcefully.
As you perhaps know, the Deflate format, invented around 1989 by the late Phil Katz for his PKZip program, performs compression in two steps by combining a LZ77 algorithm with Huffman encoding. In this edition of Zip-Ada, two known algorithms (one for LZ77, one for finding an appropriate Huffman encoding based on an alphabet's statistics) are combined probably for the first time within the same software. Additionally, the determination of compressed blocks' boundaries is done by an original algorithm (the Taillaule algorithm) based on similarities between Huffman code sets.
Zip-Ada is a library for dealing with the Zip compressed archive file format. It supplies:
- compression with the following sub-formats ("methods"): Store, Reduce, Shrink (LZW) and Deflate - decompression for the following sub-formats ("methods"): Store, Reduce, Shrink (LZW), Implode, Deflate, BZip2 and LZMA - encryption and decryption (portable Zip 2.0 encryption scheme) - unconditional portability - within limits of compiler's provided integer types and target architecture capacity - input (archive to decompress or data to compress) can be any data stream - output (archive to build or data to extract) can be any data stream - types Zip_info and Zip_Create_info to handle archives quickly and easily - cross format compatibility with the most various tools and file formats based on the Zip format: 7-zip, Info-Zip's Zip, WinZip, PKZip, Java's JARs, OpenDocument files, MS Office 2007+, Nokia themes, and many others - task safety: this library can be used ad libitum in parallel processing - endian-neutral I/O
Update to the Ada 2012 Rationale available Read more
The Rationale Update for Ada 2012, based on an article in the Ada User Journal by John Barnes,
organizes the changes of Technical Corrigendum 1 for Ada 2012 into the same chapters
as the Ada 2012 Rationale. It is an essential companion to the Rationale document. It is available on the
Ada Conformity Assessment Authority website in a variety of formats.
GLOBE_3D is a GL Object Based 3D engine realized with the Ada programming language. URL: http://globe3d.sf.net
Use of Generic Image Decoder (GID) in GL.IO; now most image formats are supported for textures and other bitmaps to be used with GLOBE_3D (or any GL app)
New Wavefront format (.obj / .mtl) importer
Doom 3 / Quake 4 map importer more complete
Unified GNAT project file (.gpr), allowing to selected the target Operating System (Windows, Linux, Mac) and compilation mode (fast, debug, small) for demos, tools, etc.
Project file for ObjectAda 9.1+ updated
The first two points facilitate the import of 3D models from software such as Blender. Here is an example:
Click to enlarge
Coincidentally, the Wavefront file format so simple that you can also write 3D models "by hand" in that format. An example made in an Excel sheet is provided along with the importer, in the ./tools/wavefront directory.