AVRA Extended

The AVRA open source macro assembler is a fair alternative for hobbyists developing for AVR microcontrollers. For others the official full blown IDE is also available from MICROCHIP for download.

I stated using the official AVRA macro assembler, but soon enough I hit the wall when I wanted to write an include file with macros calculating delay cycles for busy-wait loops. It turns out that the official AVRA macro assembler comes with a serious limitation. That is, it comes with 32 integers for expression values, while the AVRSAM2 -the official macro assembler from Atmel- has 64 bit integers for the same.

Another oddity is that it blurs the boundaries between the preprocessor- and assembler directives. Also lacks support for function-like preprocessor macros, like #define SQR(X) ((X)*(X)).

So I decided to contribute and implement some missing features. After submitting the PRs, I had to realize that the origin seems to be abandoned and not being maintained any more.

Finally I continued to work on my fork and implemented those parts which I was lacking. All is on the devel branch.

Check out the change log. My repo can be found here.

ARVA Change log

Release 1.4.2b (2024-04-26, by Imre Horvath)

  • Add 64 bit expressions
  • Add preprocessor directives #define and #undef to define and undefine object- and function-like preprocessor macros
  • Add preprocessor operator ## to concatenate preprocessor tokens
  • Implement .undef assembler directive
  • Update makefile for macOS
  • Add the command line option -W to the help text
  • Add tests for the new features
AVRA Extended

AVRDIS

For those, who like to tinker with AVR microcontrollers, and prefer to use small commandline tools, native to their OS, this free and open source project can come in handy.

Avrdis can be used to disassemble the flash contents of an 8-bit AVR microcontroller stored in a intel hex file format. Without any options, it will dump the assembly source to the standard output, which in turn can be piped into another command or redirected into a file.

If you prefer, you can make it emit a more verbose listing with putting the word address first, then the raw instruction word and finally the assembly equivalent by calling with the -l option.

The typical intended use-case is the following. You happen to have an 8-bit AVR microcontroller with an application code in it’s flash, for which you do not have the source code, but you’d like to tinker with it, possible change it an then re-flash your modified code. With this tool this process becomes straightforward.

Workflow

  1. Use avrdude to read the flash contents into an intel hex file.
  2. Use avrdis to disassemble the code.
  3. Edit the source code.
  4. Assemble the source code using avrasm.exe, avrasm2.exe or avra on Unix derivatives.
  5. Use avrdude to flash back the modified code to the microcontroller.

If you’re interested, check out the avrdis tool on GitHub.

AVRDIS

AVR ISP (ATmega328P, Addr. auto inc., STK500v1 at 115.2 kbps)

You happen to have an Arduino Nano laying around, and wanted to program some AVRs but don’t have an AVRISP programmer?

No worries. If you use the Arduino IDE, then you can opt for the built-in example, the 11.ArduinoISP. This out-of-the-box option is certainly useful for a lot of people, however it has some shortcomings. Like you need to use the Arduino ecosystem -which makes your compiled code big- with the bundled compiler toolchain. Also the ArduinoISP is slow, it uses 19.200 kbps for the serial communication with your computer. Also, it uses a fixed SPI clock -which cannot be changed dynamically at runtime-, which can be too fast for targets running at low frequencies.

Since these shortcomings were not suitable for my application, and I wanted to learn some AVR assembly, the project avrispm328p was born.

It turns your ATmega328P-based board (like an Arduino Nano, Uno, etc.) into an AVR ISP with adjustable SCK half-period, using the STK500v1 protocol.

It’s open-source and free, check it out on GitHub!

AVR ISP (ATmega328P, Addr. auto inc., STK500v1 at 115.2 kbps)

Facebook feed without ads? Possible?

The cat and mouse game between advertisers and ad-blockers are never over. As soon the blocker guys come up with some solution, the advertisers take counter measure to make the ad-blocking ineffective. No wonder, since selling ads is their business-model.

The gold standard for blocking content -including ads- is to use CSS selector based rules. This is what we can set up in our browser extensions, like Adblock, Adblock Plus, uBlock Origin, etc. All of them come with an extensive set of rules, sometimes referred to as filters.

The weakness in the CSS selector based approach has been identified by advertisers and they have made their counter measure. Since the CSS selector uses fixed IDs and classes, the obvious counter measure is to use dynamically generated IDs and class names on the server side, which changes all the time, making the fixed CSS selector based approach useless.

What else can be done to block unwanted content and ads when dynamic IDs and class names are in place? Well, instead of using CSS selectors, one can inspect the JavaScript objects themselves, using injected JavaScript code. Injecting JavaScript code into pages are supported by the major browsers, through some API. However this often comes with a limitations like the “isolated world” approach like in Chrome, meaning the injected JavaScript code runs in a different -isolated- engine, but shares the same DOM. Of course there are techniques to circumvent this limitation.

Facebook uses React. Even though the IDs and classes are dynamically generated, the properties in the JavaScript objects can be inspected and based on their values one can decide whether a particular feed-unit is genuine from one of your friends, or an ad.

I’ve written a piece of JavaScript code, called as a “scriptlet” -using uBlock Origin’s terminology-, which can be used together with the uBlock Origin browser extension. This small JavaScript code, identifies the ads and other unwanted feed-units -configurable what- and blocks them.

To use it, you first need to install the uBlock Origin browser extension, then configure the extension to use the external scriptlet from my repository, then you need to add a filter line to have it injected.

If you are interested, check out my GitHub repository!

Facebook feed without ads? Possible?

Wanna build GNU Emacs on macOS from source?

It’s really easy to build GNU Emacs on macOS from source. However it comes with some catches.

Basically you only need the Xcode Command Line Tools (CLT) installed and you are good to go. If you don’t have it already, simply run the following to install.

sudo xcode-select --install

Now you download the tarball from the official GNU site. After extracting, you want to configure and make it. Now you face the problem of dependent dynamic libraries like gnutls and jannson.

You realize that it’s easy to get them installed, provided you have Homebrew. You simply run

brew install gnutls
brew install jansson

respectively. That’s nice! Now you can build Emacs by issuing

./configure
make
make install

Perfect! This leaves you with a freshly built Emacs.app in the nextstep sub-directory. You probably want to stage it to your local Applications directory for further inspection and try.

cp -a nextstep/Emacs.app ~/Applications

Now comes the catch! Since the app depends on extra libraries which are not present on macOS systems by default, you cannot simply add your freshly built app to your friend to use, unless he/she has these extra libraries pre-installed on their system. This is bad. You want an app to simply work on any of those macOS systems, without the hustle installing dependent libraries first, right? What can we do?

Well, one solution can be to use a tool which puts all the dependent dynamic libraries inside the application bundle and fixes their dynamic-linking configuration to refer to them inside the bundle.

Is there such a tool? Well, neither Apple nor GNU offers such a command line tool to my knowledge. However there are several solutions floating around the internet. Some of them are written in C++, Ruby, Python and Shell. What’s common in them is that they invoke the commands, otool and install_name_tool from the CLT to get the job done. Also due to the nature of the dependency-tree, they do it recursively on all the dependent extra libraries.

Inspired by these, and my drive to learn about macOS bundles, dynamic libraries and tools, I created a command line tool in Shell which makes it super easy to process the Emacs.app after building it to make it truly standalone.

Tip: place the script bundle-dylibs in ~/bin and make sure that it’s executable and ~/bin is on the PATH!

curl -s -O https://raw.githubusercontent.com/imrehorvath/bundle-dylibs/main/bundle-dylibs
chmod +x bundle-dylibs

The final step is to invoke the tool, to do the magic. Simply run:

bundle-dylibs ~/Applications/Emacs.app

Of course, the tool can be applied to other application bundles as well. However it is highly recommended to apply it to a COPY of the app and not the original! Also keep in mind that there are no liabilities! Use it at your own risk!

Check the tool out on GitHub!

Wanna build GNU Emacs on macOS from source?

Arduino Yún – Seeeduino Cloud vs. Adafruit IO

Introduction

As you may know, I own an Arduino Yún board. When I bought it several years ago, it came with the OpenWRT Yún image pre-installed. This is an OpenWRT Linux fork running on the Atheros SOC, leaving the ATmega 32u4 for you to program. The Bridge library is used to connect the two, using the Serial1 on-board connection between them.

More recent (after 2015) Arduino Yún boards seems to ship with a different image, the Linino. This latter approach seems to be different compared to the original OpenWRT’s, in some fundamental way. In Linino they seem to be using the firmata firmware on the AVR side, and they offer you to program the board using the Linux side exclusively by using Node.JS or something else capable of talking to the AVR side using the firmata protocol.

Because the original setup is more versatile to my use, I decided not to upgrade to Linino.

Using Adafruit IO

Anyways. I wanted to use the Cloud service of Adafruit Industries, with my Arduino Yún board. Unfortunately it turned out, that this particular board is not supported.

I was a bit disappointed, but it didn’t stop me. I decided to fork their repository, and implement the missing support myself.

Unfortunately there is a name clash between the class names in the ArduinoHttpClient- and the Bridge library. They both use the class name HttpClient. I had to came up with a solution, because the former is a dependency in the Adafruit IO and the latter comes with the Yún. I solved it by implementing another HTTP client library for the Yún and by using preprocessor directives to include sources conditionally.

The BridgeHttpClient library offers generic HTTP client functions.

The forked Adafruit IO library is now usable with the Adafruit IO cloud service, however there are limitations. The SRAM in the ATmega 32u4 is small and your application might not fit into. The other limitation is regarding the insecure MQTT connection. Unfortunately the last official Yún image ships with a Bridge version (Bridge version 101) which does not permit SSL connections. However the Bridge version 161 is available on GitHub, but has not been released yet. So use it on your own risk!

The typical examples included in the library have been successfully tested and were working for me.

Arduino Yún – Seeeduino Cloud vs. Adafruit IO