2014-07-16

I Don’t Like This Blog

No. I don’t. I do like the subject material and the escape that writing is for me. But man, I’m over how it looks and what it takes to get a blog post up. Here’s my beef:
  1. The formatting is terrible.
  2. The online editor is quirky.
  3. Linking files and code to posts is more work than it should be.
But I’m sure solutions exist to all of these so I’m going to work out the kinks, now.
It’s funny though. It’s been quite a bit of mental work to ignore these issues and just keep writing. My desire is to have pixel-level control over the output and not having that frustrates me immensely. So each time I’ve gone near my blog I’ve had to half close my eyes and try to concentrate on enjoying the writing without getting bogged down in the publishing details. But now I have time to fix it.

2013-08-11

Building DateTime with Code::Blocks

Now that I have moved house from the Arduino IDE into Code::Blocks, I'm going to document the start of the development process in Code::Blocks. I expect to be tripped up by a number of problems and I'll write down how I muddle through.

I have my ConsoleDateTime project for Code::Blocks set up. I deliberately did not pull my DateTime.h and DateTime.cpp files over from Arduino. I'm going to run the two IDEs side-by-side and pull across chunks of code one at a time and deal with any errors that come up as I go.

Get code here: https://github.com/prawnhead/ConsoleDateTime

2013-08-04

Developing Without an Arduino

Working on my DateTime library has slowed to a crawl. I guess because I'm out of the habit (of doing things differently) I've been developing the DateTime class in the Arduino IDE. I remember now why that's a bad idea.

The Arduino process (you probably know so well) goes:

  1. change the code
  2. upload to Arduino
  3. run
  4. find errors
  5. repeat (ad nauseam)

This is good and normal and healthy development for the "usual" Arduino applications that are hardware dependent and relatively simple. But for a library like DateTime a few factors completely change the equation.

Get code here: https://github.com/prawnhead/ConsoleDateTime

2013-07-28

Using Program Memory (PROGMEM)

As I was building my DateTime class (Arduino library) I realised I had hard-coded strings for the names of the days of the week and the months of the year. I know that this is a huge drain on the Arduino's minimal amount of SRAM. It was finally time to tackle program memory and get an understanding of it. This is the process I went through ...

Get code here: https://github.com/prawnhead/ArduinoDateTime

2013-07-21

Building DateTime for Arduino

Testing. Yup, testing. With this class it can’t be avoided. Actually, even better, instead of seeing testing as a chore, let’s use it to our advantage. We’ll build a suite of tests for the unfinished DateTime class and test it until it works.
The goal here is to write all the tests first and run them. Some percentage of them will fail. Then we modify the DateTime class until all tests pass. As we find issues along the way, we add more tests.
Get code here: https://github.com/prawnhead/ArduinoDateTime

2013-07-14

The Need for a Date and Time Class for Arduino

I want a fully-functional date and time library for my Arduino applications. The goal behind my GPS clock is to have a clock with no buttons. Yes, if you’re wondering, I have been reading about Steve Jobs. No buttons!
Why no buttons? Because fundamentally any clock with buttons on it requires a human operator to set the time. Since every house has many clocks and every clock has buttons and every clock keeps slightly different time and it’s physically impossible to synchronise all your clocks you inevitably have different time displayed in each room of the house. Sorry for the run-on sentence. I’m sure there are some people for whom this is not a problem. But if you are a little OCD (and I say that admiringly, not mockingly) you’re regularly annoyed by the need to fix your clocks.

2013-07-07

DS1307 Real-time Clock Library

As committed in my last post, I’ve put up my next coding effort on GitHub.
Get code here: https://github.com/prawnhead/DS1307
The DS1307 is a highly accurate clock module that connects to the Arduino via the I2C protocol (SDA/SCL lines). As implemented on the Sparkfun BOB-00099 break-out board it comes complete with a crystal (to keep time) and a watch battery so that it maintains current time even when not being powered externally.
This library was developed to be a full-featured implementation of the DS1307 chip. This includes the cool but probably not very often used feature of having 56 bytes of NVRAM that is persistent and can be read/written very simply.
I’m torn between a simple-as-pie implementation and the one I know I really need. At this stage I’ve only covered the simple option; you need to read/write the date/time as a set of bytes. I’d rather have the class read and write a DateTime data type, but I think that’s too much for people who want the basics. (Correct me!) I have a DateTime class that I’ve created, tested and used but that I haven’t posted on GitHub yet. That’s next.
I honestly don’t know how collaboration is achieved on GitHub yet. I understand at this stage that anyone can clone my repo and go to town on my code. That’s what I want, that’s great. But I also want people to suggest improvements and commit them!I’m unsure of how this happens. Is it anything goes? Is it “commits only by repo members?” Is there an approvals process? I need to go an answer these questions. For now, here’s the simple version of this class. I guess the appropriate thing to do is to fork it and build on the ‘advanced’ version of the same. Again, questions. If the same repo now makes two versions available, how are they surfaced? I guess I’ll go ahead and see.
That is all.
References: