# HardWire, the enhanced Arduino Wire library

I have spent a lot of time on playing and later working on the I2C buses. I almost always used self developed libraries, both for learning and job requirement purposes. Then, when experimenting with a portability of a project in the Arduino environment, I started to trying the official Wire library, discovering some incompatibilities for my needs.

When the limitations were somehow fixed, even though the small number of modifications (it is somehow a sort of hacking of the library) I found that the my final result were so useful to me that I thought was worth to write a short article about it. But let’s start with the problem found in the Wire.

### Arduino real-time buffer problem

I realized that if I wanted to make an Arduino slave, when receiving from master, it actually reads from a buffer that is already previously received. This make the communication not byte to byte controlled as I want it to be for my need.

In other words, basically when you read:


while (1 < Wire.available()) { // loop through all but the last
Serial.print(c); // print the character
}


means that you will read everything that was already sent from the master. So you cannot signal to the master to stop the ongoing physical communcation in case the slave cannot receive more bytes, or you cannot take decisions depending on what byte is received.

But more generally, in this way the Atmega328 (what I have used) cannot behave like any dedicated I2C slave device: i.e. like an RTC clock, an EEPROM, which actually are making their decisions based on the current byte currently received from the bus, not after such transaction has been finished. I wanted to do the same.

In other words…

##### A slave Arduino cannot behave like any other dedicated slave device: this is not fair. Join the cause.

The solution is to have a library that allow me to do things in the hard way. The wire made hard. The wire more close to the hardware in a simple way. I called it the Hard Wire. Because somehow allow me to made the microcontroller to behave as I want at very low level in the I2C communication, obtaining the equivalent of an hard wired slave device.

I’ve just added to the Wire library various “probes” inside each step of the I2C data exchange. As you may know the I2C data exchange is made my many steps, where the START and STOP are just the starting and ending point of a bus cycle:

The hardware of a slave can interact and decide to do something after a START condition, ADDRESS, R/#W mode, choose if send or not the ACK, decide on run time what DATA to send and so on. When doing complex stuff and being interfaced as a slave in the I2C, can be useful to decide an action during these I2C bus steps.

With the conventional Wire library, you can take action only after the STOP or when addressed. In my projects, when used an Arduino, I need to take different action potentially every time I am in the following states:

• Addressed in slave write mode
• ACK received after every byte sent
• NACK received after byte is sent
• ACK sent
• START
• STOP
• RESTART

Then I decided to keep things simple, to re-adapt the already tested Wire library, which already handle the underlined green states.

### Arduino real-time solution: runtime control

To countermeasure those kind of problems, I have placed functions inside each state of the I2C bus (those functions are the handlers, called when such I2C state happens). So that, over than the usual functions, the user can set up a fully working slave system implementing a few of other function than the usual onReceive and onRequest, where a particular action can be taken just after a byte is received or sent from the slave, and not only after we have reached the STOP condition. All by still using the same methods of the official Wire library!

## How to use it

### Handlers

Basically you can follow the official Wire guide. But this hard version also supports the following handlers assigned during the initialization (are listed also the official ones):

•  Wire.onReceive(handler) -> handler takes the number of bytes received, here the data buffer can be read, since the master has terminated the communication (official from Wire)
•  Wire.onRequest(handler) -> handler takes no parameters, but when called the slave prepares data to be sent using the standard Wire methods available, like read() and write() and whatever (official from Wire)
•  Wire.onReceiveData(handler) -> handler takes last received byte for the slave runtime computation, but will also fill the data buffer with that byte, as the official Wire does transparently (not present in Wire, new in the WireHard)
• Wire.onReceiveDataNack(handler) -> handler takes no parameters but is used to notify the slave, since this received byte shall not be used (not present in Wire, new in the WireHard)
• Wire.onReceiveAdx(handler) -> handler takes no parameters, but the slave is notified to prepare itself to receive data in the next bus transaction, the official Wire does it transparently (not present in Wire, new in the WireHard)
• Wire.onRequestData(handler) -> handler returns a byte to be sent to master. This byte can be generated from the slave in the handler at runtime without using the shared buffer. The official Wire does it transparently, retrieving the data from the buffer (not present in Wire, new in the WireHard)
• Wire.onRequestDataNack(handler) -> handler takes no parameters. Used when the master still requires data which is not available from the shared buffer. It is done transparently in the official Wire (not present in Wire, new in the WireHard)

All the functions marked as new in the WireHard are the core difference between the official Wire library. The normal Wire handle them automatically, always reading or writing in the shared buffer, transparently to the user.

### Initialization

Again, follow the official Wire guide. But this version supports a HARD_WIRE_MODE that shall be notified in the init. If mode is omitted, it is initialized following the normal Wire initialization and the additional handlers are still supported, but is not mandatory to use them. Actually, is never a mandatory to use the additional handlers.

• Wire.begin(slaveAddress, HARD_WIRE_MODE)  -> will be supported all the additional handlers, with an undefined (vitually infinite) number of read/write cycles, as any I2C slave device would do.
• Wire.begin(slaveAddress, NORMAL_MODE)  -> will be supported all the additional handlers, but when the shared buffer is full, it needs to be flushed or read before accepting any new incoming byte: this behavior is the same as the Wire library.

Hope this can be useful to someone as it was to me. More info and example on the GitHub page.

# Tiny, robust, low cost, fail-safe LED driver: the Glighter-S project

It has been a while since the last LED related article. Was experimented the linear current source, its pros and cons and the field of application. Now arises the need of a small version, handling the same high power, things that are contrapposed in the linear regulator. I need something that I can bring with me, connecting a bit of everywhere, potentially. Heatsinks were expensive, heavy and it is impossible to cover the entire voltage range without huge radiating elements and is also very low efficient. So what I need to do?

### A new board design

With the new version, the entire design is completely changed. I moved to a swiched solution, by exploiting an integrated buck converter controller.

The core is the Texas Instruments LM3405 buck controller, with a fixed sense resistor directly mouted on PCB. With some tricks, like using an external companion LDO boost voltage regulator, I can provide all the required drive voltage for the LM3405’s internal mosfet over an enormous input voltage range without damage or efficiency loss. More over, the output voltage required can be of any value from almost 0V to the input applied, therefore there is no concerns related to what minimum or maximum LED voltage I can use, matters only the current which the LED can withstand without generating the magic smoke.

The high switching frequency of 1.6MHz of the controller allow also to use small components: in the picture there is a reduced size inductor, mounted on pads designed to carry on the higher ones. This left me some flexibility on performance analysis and experimentation.

### Project summary: Glighter-S Power LED driver

• Technology: switching buck regulator
• Input voltage: 3V to 20V (note 1)
• Output voltage (LED Vf): 0.3V to 20V
• Sourced current: up to 1A (note 2)
• Size: 32mm x 21mm
• Efficiency: ~90% (note 3)
• Operating Temperature: -40°C to 60°C
• Safety features:
• Short circuit immune
• Open circuit immune
• Safe state (off) when no control is applied
• Control features:
• PWM control: voltage swing from <0.4V to >1.8V up to input voltage, max PWM frequency 5kHz
• Analog control: voltage swing from 0.4V to 1.8V. Outside these limits device is either shut off of fully on.
• Overtemperature protected
• It does not make the coffee, but the coffee made this. (note 4)

Note 1: active regulation starts from the forward LED voltage plus 0.6V. Full power is delivered from 4V on (device’s control voltages fully on)
Note 2: can be set by changing a resistor
Note 3:  with one led with a forward voltage of 3V is 83%. 90% can be achived my using more than 3 LEDs in series.
Note 4: with caffeine.

On the back of the board there is a brief indication of what is summarized above:

Regarding safety, if the output is shorted, the regulator instantly lower the output voltage avoiding failures. With open circuit, as any buck converter with a sense resistor removed, the output raise as the input voltage due to the broken feedback loop, but with no damage on components: when connecting the LEDs back again, the regulation starts “immediately” avoiding LED damage. Smooth delayed start of few microseconds is implemented when powering the board with the enable already active, to avoid high inrush currents, stressing also less the LED avoiding high current glitches.

It can be dimmed with an analog signal or through a PWM wave up to 5kHz. A greater frequency is just filtered away. Another safety feature is that when PWM pin is left floating or the wire is broken, is equipped with a pulldown in order to guarantee a device shutoff with no misbehaviors. If no control is needed, just connect the PWM pin safely to the input voltage to turn it always on.

### Wiring the LEDs

I wanted a very high power LEDs, but with a relatively low voltage, in order to try it also with low voltage batteries, lower than 6V. So I choose an LED with single diode chip, because when power LEDs have an high voltage (usually greater than 5V) is composed with multiple LEDs in series. My choice is a Luxeon Rebel LEDs, with a single diode, no series:

Each of these LEDs can take up to 700mA (1A peak), therefore I chosen the sense resistor on the board in order to achieve 700mA. I designed a board used as a satellite, mouting 4 LEDs, with the peculiarity of handling the thermal management of a global 9W LED lamp.

The LED board (a.k.a. satellite board) is straighforward: 8 pins, 4 anodes and 4 cathodes to drive each LED individually using 2 wires per LED connected to the driver. The A means anode (connect the +), K the cathode (connect the -). Below the RGBW LEDs soldered on the red, green, blue and white position.

On the back is mounted an heatsink capable of dissipating through natural convection up to 9W up to 40°C of ambient temperature. Bigger heatsink will extend the temperature range. But here the purpose is to have a small heatsink, and wasting time in my playground.

### Wiring the driver

Here is shown the board connections used to test the LEDs and the driver.

The input voltage was 20V from an old laptop power supply, the enable pin shorted to the 20V. I have connected 4 LEDs in series (one cathode on the next anode and so on), with a total forward voltage of around 12V, which means that in this configuration, the minimum supply voltage required was a bit higher than 12V, here 20V are provided. Since the leds in seried are dropping more than 3V (12V in total), the efficiency of the driver is near the 90%, because the ratio between internal losses and delivered power is lower.

The power absorbed is roughly 9W, I just can’t prove its light due to the exposure of the camera, but it is comparable of a white LED bulb of 10W commercially available.

Fun fact: these LEDs are also used in some Philips RGB lamps, with a similar thermal design of the PCB. That is somehow encouraging.

### Conclusion and next steps

There is no much else to say, but it works and it is a small accomplishment that allows me to play more with power LEDs, more easily than before, mainly because of the possibility to use, NOW, almost any power supply (from tablet’s charger, to laptop ones and any battery lying around).

Every microcontroller can drive these boards with no additional components. The absolute value on the pin have analog effect if inbetween 0.4V and 1.8V, while if lower than 0.4V shut off the driver, and if higher than 1.8v will fully turn on the device. Any board, 5V, 3.3V or 1.8V can drive this module even with a low voltage logic I/O pin or even using an DAC. I plan to continue the improvement, and maybe design a control board in order to control these drivers with a small power low-profile set-up.

# DS1307 RTC Emulator: triple library, one hack

I have already tried once in this article. An emulation of DS1307 chip, to hack in some way other devices, tricking them to talk with the DS1307 chip. I’ve tried to see if was meaningful to emulate a well-known RTC protocol in an MCU instead using the additional dedicated DS1307 RTC chip.

### What I have learned so far

I have experienced the real need of software organization, portability and layering. With this goal, I’ve previously developed a firmware for a Microchip PIC microcontroller, exploiting its RTC hardware and writing a layer that allow the MCU to be interfaced with systems that are designed to talk to the DS1307 (which instead was the PIC), without the need to put my hands on their code at all, since it was already designed and tested fot the DS1307 chips that I was emulating. Now I am oriented to use the emulator in more MCUs, so being really platform independent. Again, testing is not an issue, since there are tons of libraries developed for the DS1307, that I can use as testers.

The old library can be modified and used for other microcontrollers (MCUs), with few modifications, but the portability was rough. Moreover, only with an already present RTC hardware in the MCU was possible to emulate an RTC protocol.

In this new article, I will show a DS1307 emulator written in a more portable way. It was tested on an Atmel MCU and with no RTC hardware, but only a timer. Thus a bit of precision estimation shall be done, at the expense of greater portability, because all MCUs have a timer.

### The new library: technical specifications and host requirements

This library is absolutely non-blocking with the eventually present user code, that can exist simultaneously. This means that interrupt capabilities must be supported on the used MCU. And all MCUs have this capability.

The host MCU shall contain/support at least:

• Data Memory: 180 Bytes of RAM
• Program Memory: 2kB of Flash/EEPROM
• Oscillator: one external crystal
• 3 GPIO (one RTC output pin, two I2C pins)
• I2C bus, physical or emulated on 2 GPIO pins
• 1 Timer (better if supports counting in sleep mode)
• (Suggested) I2C physical
• (Suggested) External crystal oscillator AND internal RC oscillator
• (Suggested) 5V tolerant pins
• (Suggested) More memory space for additional user code

The user firmware can:

• Read/write data internally with DS1307 protocol with no bus or other components/masters required: this means that the emulation is also inside the MCU hosting the emulator itself.
• Let another MCU (master) to read/write with DS1307 protocol using I2C bus: this is the real emulation, where the MCU hosting the emulator library is connected on the bus, and is detected as the DS1307 and behaves like it.

#### Behavioral known discrepancies and fixing

At this moment the DS1307 emulator can do everything stated in RTC datasheet. Except that is improved, fixed the unpredicted behavior in case of illogical date and time written in DS1307 emulated register: in this library it mismatches the days and date, but nothing more strange.

But there is a discrepancy, it can output on a digital pin a restricted set of output waves at the moment:

• 1Hz tick indicator
• Digital write high
• Digital write low

Every other configurations like output 32768Hz, 8192Hz, 4096Hz are resulting in a digital write low. While the low power capability depends on the clock source and the supported functionalities of the selected timer.

## Firmware organization

The firmware was improved written in two main sections, the rtcProtocol and rtcHal files. The protocol handles the entire logical behavior of the emulated device, and is the core of the project. It can be used practically on any MCU. The Hal contains the calls to the device library, therefore the content of functions in this Hal library can vary, depending on the library available for the used MCU, the user preference and so on.

Here the basic blocks:

The application (in picture 1) is the code running on the MCU that could need the access of data. This library is non blocking and concurrent. This means that once you have set up the firmware, you could use it also internally and don’t bother of performance reduction due to external requests from masters in the I2C bus. In other words, using this RTC emulator your MCU can do a lot of other things rather than being only an emulated RTC device. The infinte loop in the main is therefore not required to be fullfilled, since everything works in ISR.

The hardware abstraction layer is everything is contained in the rtcHal file, and contains all the calls to the hardware. This is the only part that needs to be modified when changing the MCU adopted, and is this part is confined in the User Defined Library space.

The RTC application is the core of the emulator and never changes when changing the MCU. If RTC data is needed from the application rather than from bus requests,  can be used be means of the API Data. Otherwise, serves the I2C master requests, as the DS1307 original chip does. Accessing through the API Data, if before ending a read/write cycle a bus request arise, will be returned no valid data because is temporary reserved to the application.

## How to use it: API and user HAL calls

Library inclusion by one header file: rtc_protocol.h
The behavior is developed by studying the functional details of the original chip. That means a data handling in the same way, in order to guarantee the same data security. To be compatible, the firmware actually buffers all the time dependent data before write on the core variables, buffers all data before is is actually read and other actions like this to avoid rollovers and data corruption. So the library can be exploited by interacting with the API and User Defined Library (UDL).

### API.  Are provided mainly 6 user functions:

1. rtcProtocol_init() -> this call initialize all the system variables and hardware. Must be called once before use any functionality.
2. rtcProtocol_freezeUserData() -> prepare the data safely avoiding rollover
3. rtcProtocol_writeUserData(unsigned char byte) -> write one byte in the RTC
4. unsigned char data = rtcProtocol_readUserData() -> return one byte to data
5. rtcProtocol_setUserData() -> need to be called in order to apply RTC the data adjustment
6. rtcProtocol_tickIncrementISR() -> Every HALF SECOND, this call will increment the internal RTC tick

Follows an example on using it.
Read RTC data safely by issuing APIs in this order:

1. rtcProtocol_freezeUserData();
3. rtcProtocol_setUserData();
4. rtcProtocol_freezeUserData();
6. recall point 5 as many times is needed to read all the RTC bytes
7. rtcProtocol_setUserData();

Write RTC data safely by issuing APIs in this order:

1. rtcProtocol_freezeUserData();
3. rtcProtocol_writeUserData(data);
4. recall point 4 as many times is needed to write all the required RTC bytes
5. rtcProtocol_setUserData();

While in an independent way the rtcProtocol_tickIncrementISR() is called every 500ms.

For details of when and what write the address and write/read data you can read the official page at Maxim Integrated. Remember that the DS1307 initial conditions are also those one in the emulator library. Learn how to use the DS1307, and you can use the emulator!

### UDL.  Are provided few APIs that can be fullfilled with user defined code:

These functions must be fullfilled with the required drivers in order to drive the GPIO, timer and bus. The bus will work on interrupt in order to not block the RTC tick. It is not needed to know exactly when and how their are called, but just know what functionality put in what API. And this is written below:

1. rtcHal_setPinDigitalMode(void) -> initialize the used defined pin as a digital output pin. Like the pinMode(OUTPUT) in Arduino. This is not a mandatory if a digital output is not needed.
2. rtcHal_resetPinDigitalMode(void) -> disable the pullup/pulldown capability of the pin and set it as input. Put something like pinMode(INPUT) in Arduino. This is not a mandatory if a digital output is not needed.
3. rtcHal_setPinDigitalValue(uint8_t value) -> write on a user defined pin the digital value. Like the digitalWrite() in Arduino. This is not a mandatory if a digital output is not needed. This can be used only if the previous ones are fullfilled.
4. rtcHal_stopRtcTick(void) -> here must be present code that stops the timer. This is mandatory.
5. rtcHal_startRtcTick(void) -> here must be present code that starts the timer. This is mandatory.

Remember that with the UDL, some other headers might be needed for the user code delcaration, if external functions are used.

## ComboLib: integrated by default with a Timer and I2C library

#### Two Wire Interface

Using the library to interact with master requests, as an DS1307 does, the API functions shall be placed in a proper sequence. This, without a I2C library which rely on a FSM, is a bit tricky. For this reason this library contains also the I2C. If another I2C library is used, the following shall be considered to be fully compatible with the RTC fucntionality:

1. Configure the host MCU to respond to the same DS1307 address: 0x68
2. Call the rtcProtocol_freezeUserData() after the start I2C bus condition
3. Call the rtcProtocol_setUserData() after a stop or restart I2C bus condition
4. When a byte is received, before any further I2C bus command or condition (new byte, stop req, start req) is received, send it to the rtcProtocol_writeUserData(unsigned char byte).
5. When a byte is required from master, send the value returned from rtcProtocol_readUserData() before any further bus command or condition.

#### Timers

This library is released with the 3 timers handlers. In this version I have used the Timer1 which trigger an interrupt when reaching a certain compare value. The achieved precision depends on divider errors and crystal precision. To have the DS1307 functionalities, I set up the tick to be 2Hz instead one and make some controls on one tick, and increment time on the other.

So, for a 16MHz quartz oscillator, with a 16bit Timer1 and 2Hz timer tick frequency I have a prescaler of 256 and compare value of 31249:

#### $compare = \frac{16\cdot10^6 MHz}{256 \cdot 2Hz} - 1 = 31249$

where the -1 is due to the extra counting when timer goes from 31249 to 0.

The resolution is the one of the quartz which can be similat to the 32768Hz used for the RTC, but consumes more power. The other error is the real tick obtained, but in this case is not present, since 31249 is not an approximation but an integer number:

#### $f_{real} = \frac{16\cdot10^6 MHz}{256 \cdot (31249+1)} = 2 Hz$

Other error sources could be the elaoration time, but since the timer uses the system clock without interfering with the CPU resources. When the timer reaches the 31249 value, triggers a signal that interfere with the CPU generatin an IST, but timer will continue immediately from 0. This means that if we have an elaboration time lower than 500ms, there is virtually no risk on losing ticks, both of timer or 2Hz RTC.

Using the Asyncronous Timer can be also a good choice, allowing to use the low power 32768Hz crystal, but the CPU shall be clocked from this or the internal one, and one can’t use the original 16MHz timer, assuming an Arduino is used.

If you want to use your own timer application, make sure that when the timer ticks, calls the rtcProtocol tick increment API, below the example of my implementation, which call the API in the compare interrupt:

ISR(TIMER1_COMPA_vect)
{
rtcProtocol_tickIncrementISR();
}


## Tests

On Github are provided few Arduino sketches in order to test the RTC read, write, output pin modes and NV-RAM. Another test is made with the RaspberryPi, following instructions [written here].

Github. This library is under constant improvement.
That’s all.

# DS1307 Real Time Clock hacking: the emulation

Maybe some of you knows well the so called GertDuino, an expansion board of the RaspberryPi. It is like an Arduino which can communicate with the Rasp, and moreover it also mount an Atmega48 which can be used to emulate an RTC. Yes, I’m going to talk about this.

### The challenge: proof-of-concept of commercial real time clocks emulation (DS1307).

I saw my board with a PIC18 microcontroller, that embeds an RTC module inside the microcontroller. Since I’ve recently tried the on-chip RTC capabilities of my PIC, the idea is born spontaneously: can I cheat my Pi by making it see a fake (but working) DS1307 RTC? Well, if I’m writing this, means that the answer is yes. And this, of course, can be applied to any single board computer (like Raspberry) which carry an I2C interface. This can be helpful even if you have a different microcontroller, because the software libraries can (in an ugly way) be portable! Oh, and the microcontroller which emulates the DS runs at 3V3 and it is even 5V tolerant, so no need of any adapter, when working with RaspberryPi.

### The RTC nostalgia

Dallas Semiconductor were quite known as a company which design and manufacture mixed-signal semicoductors and a lot of digital and analog complete amazing modules (like voltage references, battery handlung, real time clocks ecc). With our hands we can touch the old real time clocks inside old computers, like the firsts IBM in the Intel 80286 epoch. A lot of sweet memories with my old and still working IBM PS/2, with the (now battery drained) DS1287 (photo on the left).

Now the company has been acquired from the Maxim Semiconductor, which still produce some of their products. The RTC series still exist and will continue, as long as the driver support from embedded Linux distributions, and are currently still used in a lot of microcontroller based projects and commercial products. The firsts embedded RTCs have their own battery embedded in the package, which is called E-DIP package. They was huge and if the battery wears out, you can forget to disconnect the supply, or change the chip, or… breaking it and apply an external battery!

Apparently, a famous RTC used, especially in hobbysts and makers is the DS1307. A very basic RTC, without any alarm system capabilities. For that reason, since my microcontroller with RTC module is supporting alarm clocks too, I may need, in the future, to change and emulate a different RTC, like an DS1337. Ah, today are packed in standard DIP or small SO packages without the internal battery, but I’ve found that are still exist the E-DIP packages. Interesting.

The DS1307 works with a logical registers interface. Physically the access is made through 3 wires using the I2C bus, where the RTC is always a slave (SCL, SDA, GND). Except for the first byte on the bus, which identify the slave (here this DS has always a 0x68 bus address) plus a read/write bit mode, the real data, which can be named as payload, can be sent in writing (to DS) or retrieved in reading (from DS) mode. Refer to datasheet for details. The trick is simply to emulate the behaviour and timings. If you know it, you can become it. 😀

## Firmware and code portability

When I started writing the code for testing an EEPROM, since the need of very standard interface like the I2C, I thought to use the already written libraries from the XC8 compiler: but I found their names and usage too less intuitive and with the same time spent in learning how to use them I could write my own. So as a good exercise I wrote them and now, for this project, are also improved a bit, using a lot of defines and enumerations, allowing to increase the functionalities and simplifying their usage and writing, and keeping them quite inexpensive in terms of allocated resources. The tool used are:

• MPLAB X IDE, with the XC8 compiler (free version)
• PIC18F47J53, mounted on this italian development board, known as PIERIN Pic18.
• 32768Hz quartz, disassembled from a thermostat or so, I didn’t remember
• RaspberryPi for tests
• GitHub
• Coffee

I’ve also though that if a new microcontroller needs to be changed, the code should be portable, or at least should not be painful when porting it. So I thought to a very primitive level of abstraction layers, written in pure C. The whole code is here on GitHub.

### Abstraction Layers

The firmware is composed by three logical structures, but keep in mind that I’m talking about firmware, so are not quite imponent and distant these layers between each other, as in common PC applications:

1. The classic main and other configuration files, like interrupt, config bits ecc, that are common to other functions, not only to the DS emulation in case other tasks are implemented. Let’s call them as common layer, because is common to the other layers, it is a “vertical” layer.
2. The implementation of the higher level of the DS algorithm, that contains procedures which are calling the hardware drivers in a proper order. Name it as api layer (a very basic form of application programming interface). More functions at this level means more things done by the MCU. Here can be managed the hardware allocation for each task.
3. The drivers called and used by the previous layer, in which are present the procedures that are implementation dependent (the hardware handling). Changing the hardware means change (or add) some row in these files. So they are a basic form of hal layer (hardware abstraction layer interface).

Each of them are interacting with each other, roughly, in this way:

Thanks to the API layer, I can improve the emulator with more features and other hardware support, due to practical experimentation purposes, leading to a more enriched, open project. For sure I will need to implement a software RTC feature for platforms that don’t have that module. Last but not least, the “compass” of the emulator was this table, which is the register interface of the DS1307, one eye on the code and the other on this table:

The various defines in the code in the HAL and API layers are related to this table. Those definitions are not well compartmentalized from one layer to another, because I thought to be more flexible w.r.t. emulator platform rather than the emulated object itself. Nevertheless, a new emulated object will bring to a complete review of the layers, because different APIs are needed as much as a different hadware (the HAL) behavior as different are the required procedures of the driver.

## Hardware setup and demo tests

Now it’s time to test if everything works. I started directly on the RaspberryPi using the hwclock routines from terminal and its embedded I2C module. Strange things happened, from writing an year and reading another to get the Pi freaking out due to detected error configurations on the DS. So more simple functions were needed to test it, in a very fast way. Here my old school Arduino Duemilanove became very useful, by using and adapting some DS1307 libraries, to run a complete test of basic interactions, check the change of settings and play with the NVRAM.

### Coherence and settings tests

Few main bugs in my code are find by using some Arduino libraries. But I used them to see the first heart beat. The Adafruit RTClib, where some of them are modified to fit my first alive tests. Then a code from a guy on Instructables, I’ve just googled for a testing function. Taken the I2C pins A4 for the SDA and A5 for the SCK from the Arduino, and connecting them to my Pierin, I finally make the PIC18 seen by the Arduino. But it was frozen. Of course, I forgot the little brother, the timekeeping crystal on RC0 and RC1 oscillator pins.

And then, it started breathing:

The doctor said – time of birth: 12pm, 48′ and 53″. The date was taken using the RTC.adjust(DateTime(__DATE__, __TIME__)); call. Moreover, I can easily test the output pin functionalities, halting the clock, change output settings and  testing the NVRAM by using the RTClib. At this stage, the difference with the original DS1307, is the frequency at the output of RTC pin. It is not a bug, but the PIC hardware support only 2 modes instead of 4. If needed, can be done easily in software, but now, as stated in the first title, I’m at a proof-of-concept phase. Below there is the output pin table of DS1307 with shaded modes that are not currently available in this emulated module:

### RaspberryPi: connection and setup

The systems which will use this emulator would be also any computer with an I2C port. Here, a Raspberry Pi is very appropriate. I’ve the RPi B rev.2, so I’ve used the I2C module 1, using pins 2 and 3 (plus GND and 3V3) of the R2 reference. Connections are made by taking care, in testing phase with PIC18 powered by my PC, to have the ground in common with all systems and then connecting the SCL1 and SDA1 ports of the PIC to the respectively GPIO2 and 3 of the Pi:

Now it is needed the software setup under  Linux (here Raspbian). One can follow the standard steps for the DS1307 written everywhere, but sometimes bad things happens. Here my final setup (I would to thanks the source http://en.gnublin.org/index.php/RTC_DS1307).

1. Firstly check if the RTC bus is alive, by typing sudo i2cdetect -y 1:
2. Then enter in bash mode by typing sudo bash and only then type echo ds1307 0x68 > /sys/bus/i2c/devices/i2c-1/new_device to put on the i2c bus 1 a new device called ds1307 at address 0x68. This data is being used by the Hwclock procedures. If an error arise try to remove something, like echo 0x68 > /sys/bus/i2c/devices/i2c-1/delete_device and repeat the new device insertion.
3. Load the already present (it should be) module “ds1307” to the kernel using (I did it in bash mode but it is not a mandatory) modprobe rtc_ds1307 2>/dev/null 1>&2. The numbers are meaning that the standard error (2) is trashed and write the output (1) also in in stadard error. This allow the hwclock utility to avoid problem related to “IOCTL” not working calls in which you can step into, and it is used to keep trace of the output of commands without printing them on the screen.
4. ONLY IF YOU GET ERRORS WITH HWCLOCK: To avoid further problems, which are not taken into accout by the standard guides, it is needed to add the physical rtc device, which often is not present, allowing problems of ioctl type. I’ve added to rtc0 by typing: mknod /dev/rtc0 c 253 0 2>/dev/null 1>&2.
5. Check with dmesg that is something positive like this:
[ 5061.101787] rtc-ds1307 1-0068: rtc core: registered ds1307 as rtc0
[ 5061.101837] rtc-ds1307 1-0068: 56 bytes nvram
[ 5061.101895] i2c i2c-1: new_device: Instantiated device ds1307 at 0x68
6. For verification purposes, typing lsmod should output the rtc_ds1307 module somwehere.

Now exit from bash, and if you want you can setup a script from the linked Gnublin source. I didn’t test it. Now, if you need to test the device using the i2c utilities, you need to delete the device (step 2) to free the bus address reservation. There is not much to show on photos, but I put my test bench just to make this article a bit more coloured. 🙂

And the tick is got.

### Unix epoch and misunderstandings

A curious thing is related to the date previous to year 2000. If I have the 1970 as starting date (the first year of the Unix epoch), issuing the hwclock -w will write this date to the RTC. But any read was wrong, giving back the year 2066. Writing manually the registers produces a normal results, so the only conclusion, since these RTC are supporting dates from years 00 (2000) to 99 (2099), the hwclock is making something that is misunderstood since will work on more than 8bit to represent that value, but the RTC understand this as a 2066 due to some millennim transformation. In fact, with date from 2000 to 2038 everithing is fine and surprisingly everything it is not my fault. But why 2038? Don’t get me wrong, the RTC module can handle dates to 2099 correctly, but any Unix derived OS can not. In fact, I’ve sperimented that dates (dd/mm/aaaa format) until the 19/01/2038 03.14.08 am are correct. But the second later the end of the Unix epoch, any read will indroduce a mismatch error. And any set over this date is notified to be… correctly wrong. All this is because the timebase variable which keep tracks of the total seconds from the 01/01/1970 12.00.00 midnight, is a 32bit signed and will wrap at that date in 2038. That will be the thirtyennium bug or whatever, but I doubt that the world will collapse in a black hole. Here, is what an end of epoch will appear:

If you wake up in the morning, without smog, smarthphones, computers and in the street you see only stagecoaches and horses with gentleman or a huge poverty, well, probably you have travelled in time. In the meantime, the others will see on their PC/smartphone/ecc clocks this awkward date. There are many proposed solutions, but it is not a trivial thing.

## Future improvements and lessons learned

During this trip I’ve discovered how powerful can be an on-chip module, how much can be simplified the programmer’s life and firmware execution. Since I’m an electronic engineer at heart, I’ve made some progress in the coding art, despite it still look not so perfect. And with the excuse of debugging the I2C bus, I’ve finally bought the PicKit 3 and my life became easy and free from bootloaders or fuse registers unchangeable.

As soon as I can I’ll try to implement the alarm part, which can be used to trigger stuff on the GPIOs of the RPi. In this way I may need to became compatible with another version of Dallas Semiconductor real-time clock.

And now, getting involved in bus protocols and by discovering how powerful can be just an 8-bit microcontroller, how is difficult to fill even 5KB of flash and with the help of past experieces, new ideas are under development. As an engineering mind is in constant motion.

Follows DS1307 RTC hacking part 2 HERE.

# The classic hardware hacking: ATX power supply

If you like playing with lab instruments, enjoy to make things and design electronic stuff, you are probably attracted from the idea of create a new powerful (with some limitations) bench power supply by using an old ATX supply. Moreover, I need an high power supply to test my motors. For sure, building your own (not switching like this one) is possible and far more instructive.

### WARNING

You should follow this and/or other guides related to high voltages only if you know what you are doing. It is also a good thing to know the Ohm’s law and dimensioning a resistor to light up an LED. Remember that inside the PSU there are high voltages, potentially deadly. Despite I’ll not try to manipulate these voltages, the insulation integrity must be kept. Do this hack at your own risk! See also the disclaimer.

###

### Let’s start

Firstly, in case it is not clear, you need to find an old ATX power supply of a PC that you don’t use anymore. Usually it’s always a low cost supply, those that will never reach powers that are mant to be supported. Those sold to be, for example, 300W can output more than 200W nicely, with a lot of voltage combinations but with some drawbacks: without adding some hardware, are neither voltage nor current adjustable. This means that if you short something on your low power PCB, you can destroy it because it will source all its possible current. This is a situation that a bench born power supply will avoid.

TIP: when you buy an ATX power supply of a “generic” chinese sub-brand, apply a security factor of 0.5 when planning the power budget of your PC, usually they can stand a stable current/voltage which is usually far less than what is written.

Then let’s open it and see what’s inside. This one is a “chinese” one, with no EMI filters nor a power factor corrector.  Considering that my version of hacking will have all cables tied inside, that can arise an heat problem which is ignored right now, because can be easily solver later, after the completion of the bench supply.

Here you can see the missing filters, along the uncomfortable soldered fuse:

But never mind, I continue, aware that this power supply can be not compliant with some RF constraints. If the final job is accomplished, I’m are already happy.

I cut out all the connectors and applied as many holes on the chassis as I need (see the bottom of this article). I’ve considered 3 indicators (+5VSB orange LED, 230VAC orange neon lamp and a green Power Good LED indicator). Other holes should be dedicated to the voltages I want to obtain. I used a normal drill, so was quite difficult to obtain the holes. Everyone must sadly arrange with what is present at home. But just rember that there are so many ways to implement your own implementation, and mine can be done more cleverly than what I’ve realized at the end.

### Connectors and signals

Since those power regulators are very complex, I’m limiting to check the compliance with the ATX standard and follow that to manage the few control signals. For that same safety reason, this “hacking” does not involve any modification to the original PCB.

The ATX (version 1 and 2) follow the ATX standard to define control signals and some internal regulations. At the www.formfactors.org can be found the full specification of the connectors that we’re facing to. Mine is version one, you can check by googling or referring to ATX standard to understand what version you have in your hands.

I’ve to identify all common voltages, like +-5V, +-12V, 3V3, COM ecc and cut out the connectors. Then merged all the same voltages togheter. Since the GNDs wires are too much, I’ve split them in two separate threads of wires. I’ve joined the cables with the same voltage and appllied some solder tin to make the pin of merged cable stronger. Then I’ve soldered them to the crimp connector which will be inserted to the back of banana connector that I used (below the crimp is pointed by the black arrow), and closed everything in a thermo shrinking rubber, if the crimp does not already have some “protection”. This gives a mechanical strenght and electrical insulation. It looks not perfect, but it’s very solid and easy to mount. The tin on the bolt has no meaning, as you may see there are few signs of experimentation on alternative fixing leading to melting some plastic, but neglect them.

Remember, depending on what you want to obtain, to keep apart the VIOLET cable (+5VSB), the GREEN and GREY and one +5V RED cable. As one can easily check holding the original connector, those are the voltage of Stand-By, +5VSB, used to power up some peripheral of your PC like the PS2 keyboard, some of USB connectors and the auxiliary functions on the motheboard. See:

Reading the specifications of the ATX, the Green and the Grey are used to provide a digital TTL signal on the PS_ON#, being low to start the supply and can left float, by defined by the standard, to assert it high (if the PSU is designed properly, otherwise you can use a 10KΩ pull-up resistor, here is not needed though), then, when voltages are considered stable, an high TTL signal is readable from the PWR_OK. But if I want to use this signal to light up an LED I need a transistor. Here I will use a switch to turn on the system, which will tie the GREEN cable to GND and I will use a BC337 bjt to receive the OK signal to drive the LED, because the TTL port can sink up to 4mA which are too few to bright an LED correctly. Moreover, since I want to light-up the LED when the signal is high, the TTL port can source a max current of 200uA with a 1KΩ  resistance: a bjt is totally needed.

A FACT: The LED will turn on very dimly without using the BJT, so maybe more than 200uA are provided and the TTL can go lower than 5V. Even using a BJT can absorb more than 200uA to keep the transistor saturated; it could work in the active region, but I don’t like it when it is needed just to visualize the presence of a digital status. Ideally could be a MOSFET, but I’ve no one which works at a signal level. What can I do?

I’ve seen that LED has turn on dimly because there was at least 1mA.  Digging in the circuit, I discovered that this is the output of an LM393 comparator: it can sink only, in other words the logic high signal is provided by a simple pullup resistor.

Once all connections of the schematic below are made “on the air” I’ve closed every thing in the magic shrinking rubber as it’s reported on images below.

One thing on dimensioning the circuit:

The power dissipated by BJT is devised by multiplying the collector current by the voltage drop. Here Ic=15mA (see Icsat formula below) and Vcesat = 0.7V; so P = Ic*Vcesat = 10mW and to be safe we can consider it at least 3 times, P = 30mW. Datasheet says that the TO-92 package can dissipate 200°C/W and provide a graphical representation, with a maximum temperature of 150°C. Yes, at 25°C I can dissipate more than 600mW, but it will burn if you turn off your air conditioner: what are my ranges? 30mW means an increase of 6°C, which means that the power supply can stay lower 144°C. If I will get to that temperature, the problem is somewhere else. So everything is good.

Of course I want to use the BJT in saturation, so to keep the BC337 Vce under the saturation value, I need to provide some high base current. The Vcesat = 0.7 V by datasheet, obtaining a saturation current of Icsat = (5V – 0.7V – 1V)/(220Ω) = 15 mA, where 220Ω is the LED resistor and the LED drops by 1V the voltage. To devise the base current we apply an overdrive factor of 10, obtaining a beta = 100/10 = 10, where saturation beta is 100. This lead to a base resistor of (5 – 0.7)V/1.5mA <= 2533 Ω. The overdrive will cover the BJT approximations. I put a 1.8KΩ resistor in the base, added to the 680Ω already mountend to be the pullup of the comparator.

Good. And in fact, the LED looks pretty bright. A way to think: the current should be limited by the resistor and not limited by the BJT, when used in saturation.  🙂

See images below.

While the monitoring of the +5VSB can be made simply attaching an LED (orange here) to see if is present, just a series resistor is put (allowing some mA, like 10/15mA). But, be aware to create a fork of the Violet cable, since here there is only one wire and we want also to use this voltage as output for the bench supply! As shown below. The arrow indicates the LED connected to the blue cable derived from the violet (see the fork from violet to blue on the left image), and the series resistor is hidden under some shrinking rubber (not visible here).

Due to lack of dimension of holdings dedicated to LEDs (because I used a drill which was not the proper one to be used to make holes on chassis), those LEDs can’t be fixed mechanically in the holes. So I just glue them on the respective holes. You can now insert the banana connectors in the other holes and screw in the bolt to keep the crimp connector (the one indicated before with the black arrow) strongly attached to the back of banana ones. I also directly connected to the 230VAC an orange neon bulb to see always if there is AC line inserted. Insulated with a proper not home-made holder.

### Things to keep in mind

Oh yes! There is a remaining one +5V cable. This is used to power up some dummy resistors. If you search in the web, you can find the general advice to use a load resistor of 5W or 10W of 10Ω. I’m not always agree with that.

Depending on the power supply used, you may need to power a dummy load to the 12V or 3.3V. Usually for old ATX power supply like mine the 5V should be loaded. Here I’m referring to this voltage, but situation can vary with other PSUs.

The resistor is used to let flow some current from the +5V rail and close the loop of voltage regulation feedback, which is applied the the +5V also to regulate the other rails (3V3, 12V ecc). Since I don’t want to waste energy and generate uselss heat in the resistor, I measured the stability and the absolute value of voltages by varying the resistor. I came up with a minimum current which is arount 100mA that seems sufficient to keep the supply stable. So I used 4 resistors of about 38Ω to obtain a final equivalent resistor of the same value but able to support twice the power of the single component (2 series pair of resistors, each with a parallel of two single resistors). I also check by removing the PCB if the grounding was directly connected to the chassis and it is. So the chassis screws can be used to close the circuit. The space is precious here. Also, the resistors are not quite hot, so it’s ok. The white tape in the picture has insulation purposes, underneath wires are soldered, of course.

### Final result

I put some effort to keep the airflow as clean as possible, the heatsink on the left has also a couple of wings that are bended to not touch cables too heavily. For now, seems that there are no heating issues. All voltages are good  enough excepts for negative ones: could be my fault, but they were few mV under the nominal value also when the power supply was used in a real PC, prior to any modification. The technical reason is that this power supply is a crappy one. The whole result is posted here below.

A clever thing could be use the hole on the front to hold the switch. I didn’t, I’ve complicated my life uselessly, cutting a piece of metal (the one on the relief) to give a shape on the space where the switch slides, because the rectangular shaped hole was not perfect at all. But holes for screws were quite nice and the switch is fixed strongly on the chassis.

### What I’ve learned

As you may notice, I wanted to have a power supply which was blue. So I spent a week trying to painting it and learning all steps to achieve a durable paint on a metal chassis. I’ve also tried to paint some letters on the top to make them visible inside the blue main paint, just for experimenting some painting techniques. I used the primer to allow me use the spray can to cover the whole chassis with this blue that you can see. And it’s not perfect at all the whole result. But I’ve never painted a chassis before and I feel satisfied.

The whole hacking, at the end, has taught me basics about painting. Yes, agree, WTF! 🙂