I wrote an article a long time ago where I tried to determine which was better ‘Bioplastic’ or ‘Petroplastic’.
Ecogeek has a post about the same thing – and drew similar conclusions. Worth the read.
December 4th, 2010 § Comments Off on Bioplastic not the ‘greenest’? § permalink
I wrote an article a long time ago where I tried to determine which was better ‘Bioplastic’ or ‘Petroplastic’.
Ecogeek has a post about the same thing – and drew similar conclusions. Worth the read.
June 4th, 2009 § Comments Off on almost there… § permalink
May 8th, 2009 § Comments Off on Fabr v3 § permalink
Fabr v2 uses a moving platform for the Z axis. This means it has a maximum volume is quite difficult to change. The platform requires a significant number of moving parts. I had been wondering if I could change fabr so that one axis could be changed out…
For Fabr v3, I wanted to see if I could replace the Y axis with a replaceable platform, driven by an edge motor. With this arrangement, I could replace the platform with any length I needed for the job at hand. I’m not quite sure if this will work, but something I’ve been thinking about.
May 4th, 2009 § Comments Off on Super ‘Struder § permalink
I’ve been having problems keeping the my extruder up to temperature, and eventually, well dissolved my working extruder. So… I’m building a new ‘super extruder’ based on research by nophead’s work.
April 12th, 2009 § 1 comment § permalink
“I love it when a plan comes together”
The Fabr motherboard is complete, and the firmware refactor I’ve been working on is ready for testing.
Here are some glamor shots of the motherboard (which are reprap firmware and connector compatible, just in case).
Hoping to have this thing up and running for the Robotics meeting this weekend.
March 28th, 2009 § Comments Off on Behavior – Device Abstraction § permalink
You’ve coded your project with your x-axis step pin on GPIO11. But my device has it on GPIO3. Or even worse, I use a a servo and counter, which doesn’t have a concept of a step. How do we resolve this?
If instead of considering the device itself when coding the logic, what if we were to abstract the meaning of the device from its behavior? That’s the basic idea behind Behavior-Device abstraction.
Say I’m building a Unmanned Aerial Vehicle (UAV). I have a navigation behavior which needs realtime orientation data. A typical orientation circuit requires a Gyro and accelerometer for accuracy and drift compensation. If the navigation system had to deal with those calculations, that code becomes unwieldy. However, if it were coded to a single OrientationDevice, then the implementation of that device could be two sub devices – the GyroDevice and AccelerometerDevice, and can build a homogenized notification of orientation changes. What if a manufacturer were to build a single chip that handles both and provides a single interface to it? All one would need to do is replace out the Orientation device without rewriting the Navigation behavior.
The example above described a composition – Each component has a singular responsibility. These are aggregated into a composite or logical device, which then can be actioned upon or notified from independent of the internal implementation.
RepRap has 1 main behavior – The GCode interpreter. It receives commands from the host machine, and drives two logical components – the extruder and the Cartesian bot. The Cartesian bot is composed of 3 linear actuators. The Extruder has a temperature sensor, heater and feed device.
The RepRap project uses Stepper motors for linear actuation, with end stops for collision avoidance and homing. It could be implemented using a servo motor or linear stepper driver. Since driving the linear actuator is now abstracted from the behavior, changes to the driving mechanism becomes much less complicated.
In other words, the behavior tells the bot where to go, the bot figures out how to get there, and the linear actuators figure out how to do it.
class CartesianDevice : public Device,
public Observable,
public Observer
{
LinearActuator& _x;
LinearActuator& _y;
LinearActuator& _z;
bool _xInMotion;
bool _yInMotion;
bool _zInMotion;
public:
CartesianDevice(LinearActuator& x, LinearActuator& y, LinearActuator& z);
void moveTo(float newX, float newY, float newZ);
void moveHome();
inline bool axesInMotion() { return _xInMotion || _yInMotion || _zInMotion; }
virtual void notify(uint32_t eventId, void* context);
};
class StepperDevice : public EventLoopTimer,
public Device,
public Observable
{
int8_t _stepPin;
int8_t _dirPin;
bool _forward;
int _currentTick;
int _targetTick;
int _ticksPerRev;
milliclock_t _maxRate;
public:
StepperDevice(int8_t stepPin, int8_t dirPin, int ticksPerRev, milliclock_t rate);
void goForward();
void goBackward();
void turn(float numberOfRevolutions = 0.0f);
void start();
void stop();
void setTempRate(float rate);
virtual void fire();
};
class OpticalInterrupt : public Device,
public Observable,
public PeriodicCallback
{
int _inputPin;
public:
OpticalInterrupt(int pin);
virtual void service();
};
March 27th, 2009 § Comments Off on Event Loop for the Arduino § permalink
Making an LED blink or driving a single stepper using the Arduino is very easy – pulse a pin in the Arduino loop handler is all you need. However, as builds become more complex, there is often the need to manage multiple devices.
The RepRap firmware is such a project. The firmware has numerous steppers, motors, heaters, fans and sensors – it is chalk full of features. The developers have literally performed magic with the tiny little Arduino. However, I believe they will admit that the code base is becoming a little unwieldy and difficult to modify.
As an operating systems developer, my job is to identify patterns in application development, build abstractions which simplify these common cases and generate boiler plate or error prone code. In my post on the RepRap firmware refactor, I described several design patterns which are applicable to not just RepRap, but many other complex embedded projects. The best place to start is with the root of all evil – the event loop.
Event driven programing is a staple of modern application development. In my experience, event driven patterns are not as prevalent in embedded development – it’s a shame, because it is very useful. The main conceptual leap requires the developer to give up control to the power of the loop – a leap that is often very difficult as they are used to complete control. I’ve completed an implementation, which in its current state is more of a timer loop, but will grow to enable queued events (both on and off board).
This code is currently checked into the RepRap source forge repository. It is only dependent on the Dynamic Array implementation checked into the tree as well.
There are several features of this event loop:
(NOTE: It is not interrupt safe at the moment)
void StepperDevice::turn(float numberOfRevolutions)
{
if (_currentTick)
{
stop();
}
_targetTick = (int)(numberOfRevolutions / _ticksPerRev);
notifyObservers(StepperEvent_Start, this);
EventLoop::current()->addTimer(this);
}
void StepperDevice::fire()
{
digitalWrite(_stepPin, HIGH);
delayMicroseconds(5);
digitalWrite(_stepPin, LOW);
++_currentTick;
if (_targetTick && (_currentTick == _targetTick))
{
notifyObservers(StepperEvent_Complete, this);
stop();
}
}
#ifndef EventLoop_h
#define EventLoop_h
typedef unsigned long milliclock_t;
extern const unsigned long MILLICLOCK_MAX;
//
// Periodic Event Callback
// Derive from this class to implement a periodic servicing
//
class PeriodicCallback
{
public:
// NOTE: This is a harmless warning:
// alignment of 'PeriodicCallback::_ZTV16PeriodicCallback'
// is greater than maximum object file alignment.
// Bug in avr-g++.
// See http://www.mail-archive.com/avr-chat@nongnu.org/msg00982.html
PeriodicCallback();
virtual ~PeriodicCallback();
virtual void service() = 0;
};
//
// Timer
// Derive from this class to implement a periodic timer.
// This class also contains information needed for
// maintianing a timer, designed to be memory efficient.
//
class EventLoopTimer
{
private:
milliclock_t _lastTimeout;
milliclock_t _period;
protected:
inline void setPeriod(milliclock_t period)
{ _period = period; }
public:
EventLoopTimer(unsigned long period);
virtual ~EventLoopTimer();
virtual void fire() = 0;
inline milliclock_t period() const
{ return _period; }
inline milliclock_t lastTimeout() const
{ return _lastTimeout; }
milliclock_t nextTimeout() const;
inline void setLastTimeout(milliclock_t nextTimeout)
{ _lastTimeout = nextTimeout; }
};
//
// Event Loop
// This class implements the main loop.
// It allows clients to register for periodic
// servicing, or timed servicing.
//
class EventLoop
{
private:
DArray _periodicEvents;
DArray _timers;
milliclock_t _lastTimeout;
bool _running;
void sortTimers();
DArray* findFiringTimers();
public:
EventLoop();
~EventLoop();
void addPeriodicCallback(PeriodicCallback* callback);
void removePeriodicCallback(PeriodicCallback* callback);
int periodicCallbacks() { return _periodicEvents.count(); }
void addTimer(EventLoopTimer* timer);
void removeTimer(EventLoopTimer* timer);
int timers() { return _timers.count(); }
bool running() { return _running; }
void exit() { _running = false; }
void run();
static EventLoop* current();
};
#endif
March 24th, 2009 § Comments Off on Updated Arduino plugin § permalink
I updated the Arduino plugin with the following features:
Let me know if you have any issues. (or send a quick note to say you use it)
March 5th, 2009 § Comments Off on Retrofitting an EasyDriver § permalink
Brian Schmalz’s easy driver, offered by SparkFun is a nice little stepper driver. There are two major deficiencies however: It is hard wired to eighth step mode, and the ground pin is opposite the signal pins. I decided to fix these as I reassemble the extruder.
The step mode on the A3967 is selected by pin 12 & pin 13. By bringing these pins low, we can select full step. This is achieved by clipping the pins from the pads and soldering a wire to ground – the same ground I wanted to route over to the signal pins. In order to seat the polarized header, I filed a pin slot and soldered the ground jumper.
February 11th, 2009 § Comments Off on avr-libc realloc ‘fix’ § permalink
I’ve been working on patterns for Arduino, which relies on a dynamic array for managing event loops, observables, and device abstraction. However, I was blocked by a critical failure in realloc. While I could have worked around it using malloc/free, but wanted to understand what was going on in libc.
One thing that struck me about realloc was the naming conventions; What was the difference between fp1, fp2, cp1, cp2? Some referred to a free block, some referred to a free pointer. I gave up and renamed the variables to something more readable.
The fatal flaw has to do with mixing sizeof(__freelist) and sizeof(size_t). In many cases, the difference results in indexing into the middle of a free list entry, thus corrupting memory.
(compare to avr-libc/libc/stdlib/realloc.c)
void* realloc(void *ptr, size_t newLength)
{
struct __freelist *currentBlock, *nextBlock,
*currentFreeBlock, *previousFreeBlock;
char *currentPointer, *nextPointer;
void *memp;
size_t largestBlockSize, sizeIncrease;
/* Trivial case, required by C standard. */
if (ptr == 0)
return Malloc(newLength);
currentPointer = (char *)ptr;
currentBlock = (struct __freelist *)
(currentPointer - sizeof(size_t));
nextPointer = (char *)ptr + newLength; /* new next pointer */
if (nextPointer < currentPointer)
{
/* Pointer wrapped across top of RAM, fail. */
return 0;
}
nextBlock = (struct __freelist *)(nextPointer - sizeof(size_t));
/*
* See whether we are growing or shrinking. When shrinking,
* we split off a chunk for the released portion, and call
* free() on it. Therefore, we can only shrink if the new
* size is at least sizeof(struct __freelist) smaller than the
* previous size.
*/
if (newLength <= currentBlock->sz)
{
/* The first test catches a possible unsigned int
* rollover condition. */
if (currentBlock->sz <= sizeof(struct __freelist) ||
newLength > currentBlock->sz - sizeof(struct __freelist))
{
return ptr;
}
nextBlock->sz = currentBlock->sz - newLength - sizeof(size_t);
currentBlock->sz = newLength;
Free(&(nextBlock->nx));
return ptr;
}
/*
* If we get here, we are growing. First, see whether there
* is space in the free list on top of our current chunk.
*/
sizeIncrease = newLength - currentBlock->sz;
currentPointer = (char *)ptr + currentBlock->sz;
for (largestBlockSize = 0, previousFreeBlock = 0,
currentFreeBlock = __flp; currentFreeBlock;
previousFreeBlock = currentFreeBlock,
currentFreeBlock = currentFreeBlock->nx)
{
if (currentFreeBlock == nextBlock &&
currentFreeBlock->sz >= sizeIncrease)
{
/* found something that fits */
if (sizeIncrease <= currentFreeBlock->sz + sizeof(size_t))
{
/* it just fits, so use it entirely */
currentBlock->sz +=
currentFreeBlock->sz + sizeof(size_t);
if (previousFreeBlock)
previousFreeBlock->nx = currentFreeBlock->nx;
else
__flp = currentFreeBlock->nx;
return ptr;
}
/* split off a new freelist entry */
currentPointer = (char *)ptr + newLength;
nextBlock = (struct __freelist *)
(currentPointer - sizeof(size_t));
nextBlock->nx = currentFreeBlock->nx;
nextBlock->sz = currentFreeBlock->sz -
sizeIncrease - sizeof(size_t);
if (previousFreeBlock)
previousFreeBlock->nx = nextBlock;
else
__flp = nextBlock;
currentBlock->sz = newLength;
return ptr;
}
/*
* Find the largest chunk on the freelist while
* walking it.
*/
if (currentFreeBlock->sz > largestBlockSize)
{
largestBlockSize = currentFreeBlock->sz;
}
}
/*
* If we are the topmost chunk in memory, and there was no
* large enough chunk on the freelist that could be re-used
* (by a call to malloc() below), quickly extend the
* allocation area if possible, without need to copy the old
* data.
*/
if (__brkval == (char *)ptr + currentBlock->sz && newLength > largestBlockSize)
{
nextPointer = __malloc_heap_end;
currentPointer = (char *)ptr + newLength;
if (nextPointer == 0)
{
nextPointer = STACK_POINTER() - __malloc_margin;
}
if (currentPointer < nextPointer)
{
__brkval = currentPointer;
currentBlock->sz = newLength;
return ptr;
}
/* If that failed, we are out of luck. */
return 0;
}
/*
* Call malloc() for a new chunk, then copy over the data, and
* release the old region.
*/
if ((memp = Malloc(newLength)) == 0)
return 0;
memcpy(memp, ptr, currentBlock->sz);
Free(ptr);
return memp;
}