The camera is controlled by a SAMD21G18A microcontroller. During acquisition, the microcontroller's main job is to sample from the image sensor using its internal ADC, and run a control loop to sweep the motor from left to right.

The firmware for the camera is written in C++ using the PlatformIO framework. The main challenges in the design of the camera's software were the management of the SAMD21s shared resources, and the management of concurrent tasks. During acquisition, it's necessary to run a control loop and simultaneously sample from the ADC. These tasks involve capturing PWM from the encoder, commanding the motor using PWM timers, sampling from the ADC to get pixel data, and writing that data to the SRAM. The ADC acquisition should happen as fast as possible to minimize rolling shutter and to allow the motor to run at a reasonable RPM.

In order to achieve the highest sample rate of the ADC while also allowing some CPU cycles to run the motor controller, it was necessary to use the SAMD21's DMA and event systems. The DMA allows the ADC to write directly to the external SRAM, and the event system allows the microcontroller to automatically generate a pulse on the READ line when the ADC is done reading a sample. This allows the CPU to intervene only after sampling an entire column of the image (about once every 2 ms sampling at 500kHz), rather than on every pixel (which would require intervention every 2 us).

The motor control loop cannot benefit from quite as much autonomy, but the SAMD21 allows for PWM capture to occur entirely in hardware, so CPU cycles can be saved just for updating the state of the PID controller.

Other subsystems require shared access to the ADC. The 5-way button, for example, uses a voltage divider network to generate unique voltages for each of the 5 possible directions which are sampled by the microcontroller's ADC.¹ A simple mutex is used to prevent the button subsystem from sampling from the ADC while an acquisition is taking place.

The button subsystem, motor controller, encoder, image sensor, display, and status LED all need time on the CPU, but the amount of time varies significantly from subsystem to subsystem. For example, the status LED only needs to update once every 100 ms or so, while the motor controller's control loop needs to run at a relatively high frequency, and the button pad needs to be sampled often in order to make the input feel responsive. In order to accommodate these timing requirements, each subsystem gets a class implementing the interface defined below:

template <typename M>
class AbstractTask
{
    friend class Scheduler<M>;

public:
    virtual YieldAction do_work() = 0;
    virtual const char *name() = 0;

    int deadline() { return m_deadline; }
    bool has_messages();
    bool get_message(M *m);

private:
    TaskState m_state{TaskState::DEAD};
    // The time at which this task should resume work on the CPU.
    unsigned long m_deadline{0};
    MessageQueue<M> m_message_queue;
};

Where YieldAction is defined as:

struct YieldAction
{
    enum Type
    {
        WAKE_AFTER_DURATION,
        WAKE_ON_MESSAGE,
        DIE
    } type;
    int duration{0};
};

A task does work by overriding do_work, which is a function that usually handles any messages in the queue, and does a little bit of work (for example, running one iteration of the PID loop, in the case of the motor controller task). It returns an action which the scheduler should take after the work is done (see YieldAction). The scheduler is implemented as a priority queue where the keys are the m_deadline of each task. The scheduler has no priorities, and so starvation is not possible (so long as one of the tasks doesn't loop inside do_work).

The below is the most successful image I acquired with the line camera:

The image has several flaws, the most noticeable of which are probably the random black pixels. I believe these are due to SRAM write errors caused by poor adherence to the chip's timing requirements, or some issue with the DMA transfer. Even though the image is pixelated and has low contrast, we can also see that the optical system (a pin-hole poked through a sheet of aluminum foil) has trouble reproducing small details. A smaller hole, further from the image sensor would probably increase the detail.

The main issue with the image (in my opinion), however, is that it's not a panorama. In fact, the above image is just a thin vertical slice of the camera's output, which I've stretched to fill a square window. ² I was never able to capture a proper panorama with this camera because of a mechanical issue with the motor.

If I were to build a second version of the scanning line camera, I would first and foremost address both sides of the The Motor Issue:

• The motor issue could be solved by sampling faster. The SAMD21 is a little under-powered for the task of sampling from the EPC901. A better design might include a stand-alone ADC with faster sample rate, and a microcontroller which can handle the increased data rate. Of course, there is a limit to how much faster we can sample, because we still need to allow time to expose the image sensor on each frame.
• The motor issue could also be solved by choosing a more appropriate motor, or by doing away the motor altogether. One attractive solution is to use a purely mechanical system – probably involving a spring and a damper – to rotate the sensor, and potentially an encoder to compensate for any nonlinearities in the motion. The motor and its controller are the most power hungry components of the system, and big contributors to noise, and so removing them would certainly benefit other electronics which aren't directly related to sensor motion control.

Secondly, the user interface could be somewhat improved. Mainly, I'm referring to the old Nokia 6100 display which I recycled to use on this project. There are very cheap displays to be found with better color rendering, and without the need to generate 7 volts for the backlight.