Today I am going to start playing around with a modified version of the WordPress twenty-seventeen theme. I want to be able to write content in a nicer style and it is easier to do this with a clean slate. Some of the existing content will need reformatting and this will happen when I settle on my style. In the meantime be patient.
I have been using WordPress for this site since I set it up. Over the years the platform has developed significantly. I used to spend hours creating a customised site from scratch. I abandoned this approach a few years ago due to the focus on 'responsive design' allowing the site to be viewed on mobile screen sizes and aspect ratios. I moved to the pre-created templates and modified them.
Trying to make a few small changes today has been frustrating. In part due to the limitations of the parent theme being used. While the overall appearance of the theme I am happy with it is the interaction on the back end that is the problem. Whilst the administrative interface provides customisation options for certain features it didn't allow access the fine grained modification I wanted. I only wanted to change the maximum number of featured posts to display. Ideally this option should have been included when the original theme was created. I suspect however the theme styling was the main thing on the developers mind rather than what functionality was going to be given to the end user. I resolved my issue with a few little tweaks, but a good bit of time wasted in doing so.
This month I have been spending some time putting together a simple development set-up for 32bit ARM devices. Whilst not yet fully complete I am making steady progress and have begun to document the process. This is easier said than done. I set out to do the simple task of making an LED blink to test my set-up. There is a lot more to learn than what I had originally expected. The 8bit Atmega 328P was simple by comparison.
What I have discovered is a lack of resources based around my set-up & understanding. Hence why I feel the need to document it where I can. My documentation is taking shape HERE. It is likely to evolve over time but it is better to make it available as I write it in the hope it proves useful to others.
This month I have started a couple of new projects. It began as one but soon split. The primary project was to make use of a 128x64 I2C OLED display. It has been sitting on the side for a few months after an impulse purchase. It soon became apparent that I needed a way to generate static images for the screen. Although there were programs out there that would convert a bitmap image into the hex code I needed, many were for Windows. So I decided to have a go at converting it myself.
Both projects are under development at the moment. How much they develop will depend on how my experimentation with the OLED display goes.
I am sat here on a Sunday evening trying to debug embedded C/C++. For the most part all has been going well and the code has been behaving as expected. I have however run into one of my least favourite problems, the interrupt service routine (ISR). I have a couple of ISR's and they are presenting an unexpected start-up condition. The flow of the main body of the code is fine. I just can't understand why I am getting the current output.
All these problems take me back to a traffic light program I wrote at University. That worked fine for most of the sequence only to be tripped up by an ISR along the way and ending up in a stuck state. Not what you want from a set of traffic lights, especially if you find yourself stuck in the queue behind the red light.
Luckily there wasn't a green light & green man situation with the pedestrians finding themselves in the role of Frogger.
Only one solution for this situation; single malt.
I have been making use of the Arduino Makefile from ed.am for some time but recently I needed more functionality from the Makefile.
I ran across a case when needed to check the number of instructions/clock cycles that my C/C++ code was generating. To do this I needed to have a look at the assembly listing that was created. Reading just the assembly is tricky so adding in the C/C++ that creates it makes following it a little easier.
The instructions contained here detail the commands required to generate the debugging information and the flags for avr-objdump which allow the C++/ASM listing to be generated. Typing in all these commands takes time, hence why I am using a Makefile in the first place. What I needed was to add them to the existing ed.am Makefile.
It turns out that the easiest way to do this is not to modify the original Makefile. Instead I created a blank Makefile for my project and include the ed.am Makefile. Having done this I can overload and add to its contents.
This is what I came up with, using “make list” will generate a program listing interspersed with the source code.
# Include Arduino Makefile # ======================== include ~/bin/arduino.mk # Arduino Makefile downloaded from: # http://ed.am/dev/make/arduino-mk # Override some of the included Makefile settings # =============================================== # Add '-g' to compiler flag to embed debug info (doesn't end up in .hex) CPPFLAGS += -g # Locate avr-objdump on system OBJDUMP := $(call findsoftware,avr-objdump) # Create a listing of asm and C source code list: $(TARGET).elf @echo "Generating Listing" $(OBJDUMP) -h -S $(TARGET).elf > $(TARGET).lst # Override clean target to remove additonal files clean: rm -f $(OBJECTS) rm -f $(TARGET).elf $(TARGET).hex $(ARDUINOLIB) *~ rm -rf .lib .dep rm -f $(TARGET).map $(TARGET).lst
During experimentation with my I2C board (dn2012-000) and an Arduino board, I decided that I wanted to code in a service/configuration menu to allow me to change settings and read the memory locations without having to reload the sketch. This had me thinking about menus in general and how they are implemented on different devices.
How are menus implemented on existing devices? What methods are used?
My day job working in Medical Engineering means I have plenty of opportunities to work with products from different manufacturers. Devices range in cost from the cheaper (replace rather than repair) items to the very expensive (needing maintenance/servicing over many years). The devices can be the latest the manufacturer has to offer or the ones that refuse to fail as they were built to last. Device menus are implemented in a few distinct ways.
Approaches to menu implementation
1. No menu options. The device has no changeable settings. Fixed HW/SW.
1a. No menu options. Switch or button operation to toggle modes, features. Fixed SW.
2. User accessible menu options during normal operation. Changes reset on reboot, power cycle. [Features such as Volume, screen brightness, alarm triggers]
3. User accessible menu options during normal operation. Changes preserved across reboot, power cycle. [Features such as Volume, screen brightness, alarm triggers]
4. As approach 3 but requiring user to input a code to change or save a setting.
[Used for setting default alarm triggers]
5. As approach 4 but requires user to enter multiple codes to enter different levels of nested menus. [First code for configuration options, second code for service menu]
6. Configuration/Service menu is not accessible via normal operating mode. Unit needs to be put into service mode. [Prevents accidental changes of settings]
6a. Combination of button/switch presses during power up.
6b. Change/removal of physical switch/jumper. Can be hidden/internal.
6c. Hardware dongle or key.
7. Data Port. Another device (Laptop/RS232/USB/Other) is connected to a data port to access settings. [Less complex user interface needed on product, can be used to take log data from device.]
7a. Manufacturer provided cable/programmer [Usually for non-standard ports/protocols]
7b1. Terminal Access (RS232/USB) - Standard Serial Console tools
7b2. Terminal Access (RS232/USB) - Manufacturer Application
7c1. LAN/WIFI – Access Web Interface
7c2. LAN/WIFI – Manufacturer Application
7d. Memory Card/USB Stick to upload/download settings file.
8. Multiple of any of the above approaches.
Assessment of Approaches
Creating the different menu methods requires different amounts of hardware/software to implement. Having a code to change settings needs a way to input the code and process it.
Whichever method is used depends on several factors:
- What does the menu needs to access? (user settings, configuration, logs, service functions)
- Who needs to access the menu? (End User, Developer, Service Personnel, Company Representative)
- How often is access needed? (Easy access for common tasks of a few more steps for occasional options)
- Where is access needed? (On-site, during use, on a workbench)
- Disassembly / Tools required?
The method used will ultimately depend on which is the best fit for the product. If the user interface is sufficiently complex anyway adding extra menu options is software only. A basic user interface might encode options as numbers on LCD/7-Segment displays or just go for a data port approach.
Which Approach will I use?
My needs are simple. I am working with a serial data connection, led and 2 buttons (one is for resetting the Arduino board). My approach will use a held button and board reset to enter the service/configuration mode. The same serial console used to read data during normal operation will be used to show the menu. No additional hardware required. I have no need for codes to protect changes as the project doesn't warrant the additional security that brings. The need to enter service mode and connect with a serial terminal should be sufficient to prevent accidental changes.
The intent is to have the serial console output human readable text. This might change if the program exceeds the capacity of the chip. In this case I might resort to an external application to provide the human readable side by processing the raw serial data.
This week whilst thinking about how to represent an idea as a GUI application I ran into the limits of GTK3. I had a look around at matplotlib and pygame as possible work arounds but neither suited what I had in mind. It was then that I discovered Kivy.
Kivy - Open source Python library for rapid development of applications
that make use of innovative user interfaces, such as multi-touch apps.
Having had a look at some of the demo interfaces that have been created it looks like a really powerful tool. The only limitation appears to be your imagination. In addition the multi-touch aspect is appealing in the longer term as touch interfaces become more prevalent. Once I can get it fully installed/working on Fedora I will be experimenting with it a little.
I have been using the same theme for this site for many years now. Over that time WordPress, which powers the site, has undergone many changes and improvements. In that time the way the WordPress code combines with the theme has changed. This has resulted in my aging theme containing legacy code whilst at the same time not supporting some newer features. I had in the past updated the theme adding in new changes where possible but I think now is the time for a radical change. I'm throwing away the old design and starting again with the twentyfourteen theme as a base. There are design elements which I had been working on with the old theme which I will port across. This approach will hopefully mean a more complete and stable theme for years to come. In the short term there will be things that need adjusting so it's likely to be a little while before the site takes on its final form.
Time for a look back at what I intended to do last year.
- Read an ebook on my Kindle Paper-white. - I have managed to read several and it's in regular use.
- Contribute to some open source projects. - Failed
- Continue to develop my wireless sensor system. - Mostly failed, a little progress made but not much.
- Buy a new soldering iron/station. - I have an ERSA Icon Nano
- Decorate and carpet my lounge. - Success - It now looks lived in.Still needs curtains.
- Document more of my projects on this website. - Mostly failed, a few notes were uploaded but not much else.
- Use my Raspberry Pi for something interesting. - Barely looked at it.
- Clear clutter out of my garage. - Cleared once then got full again.
- Finish networking between lounge and bedroom. - Completed as part of decorating.
- Write an android application for my tablet or phone. - I wrote a calculator script for use at work but it's in html rather than an app.
So 2013 was mixed, some things achieved some not.
Time to see if I can complete some of last years goals in 2014.
- Contribute to some open source projects.
- Put more time into electronics projects (Raspberry Pi/Wireless Sensor System).
- Get curtains for lounge.
- Clear out Garage (again).
- Write an android application for my tablet/phone
- Pay off student loan.
- Carpet master bedroom.
- Build a Gaming PC and/or Steam Box
- Repave Back Yard
- Use a Linux desktop environment other than Gnome 3 for at least a month
Another to do list, but as before it will be a good year if I can cross a few of them off.