Everything You Wanted To Know About Padauk MCUs And More

At this point you’d need to have lived underneath a rock somewhere on the dark side of the Moon to not have heard about these amazing, 3-cent microcontrollers. A number of places have pitched in on them, but comprehensive reviews, let alone a full-blown review of the entire ecosystem surrounding these Padauk MCUs have been scarce. Fortunately, [Jay Carlson] has put in a lot of effort to collect everything you could possibly want to know about anything Padauk.

The most important take-away is that these MCUs do not have any kind of communication peripherals. UARTs, I2C, and SPI all have to be done in software. They’re not very great at low-power or battery-powered applications due to high power usage. Essentially you’ll be using GPIO pins a lot. On the other hand, its multi-CPU context, FPPA feature is rather interesting, with the article covering it in detail.

As for the development tools, [Jay] came away very impressed with the In-Circuit Emulation (ICE) instead of running code on an MCU, as this can reduce development times significantly. This makes even the OTP (one-time programmable) property of most Padauk MCUs less significant than one might at first assume.

Then there’s the actual programming of the MCUs. The Micro C compiler Padauk provides essentially implements a sub-set of the C language, with some macros to replace things like for loops. Initially this may seem like a weird limitation, until you realize that these MCUs have 64 to 256 bytes of SRAM. That’s bytes, without any prefixes.

Finally, [Jay] shows off a couple of test projects, including a NeoPixel SPI adapter and bike light, which are all available on Github. The WS2812b project is something we have seen before, for example this project from [Anders Nielsen] (featured in the article image), which provides another take on this range of MCUs.

Did reading [Jay]’s article change your mind on these Padauk parts? Have you used these MCUs and ICE parts before? Feel free to leave your thoughts in the comments.

TinyGo Brings Go To Arduino

Go — a modern programming language with roots at Google — is one of the new generation languages that would like to unseat C (and C++) for what we think of as traditional programming. It is only for PCs, though, right? Not so fast! TinyGo provides a compiler that — in their words — is for small places. How small? They can target code for the Arduino Uno or the BBC micro:bit. It can also produce code for x86 or ARM Linux (both 32- and 64-bit) as well as WebAssembly. They claim that a recent project to add ESP8266 and EPS32 support to LLVM will eventually enable TinyGo to target those platforms, too.

As you would expect, there are some subtle differences between TinyGo and the full-blown version. The compiler handles the entire program at once which is slower but offers more for optimization. Certain optimizations for interface methods are not used in TinyGo, and global variable handling changes to accommodate moving data from flash to RAM efficiently. TinyGo passes parameters in registers.

Continue reading “TinyGo Brings Go To Arduino”

Micropython And C Play Together Better

Python is a versatile, powerful language but sometimes it’s not the best choice, especially if you’re doing work in embedded systems with limited memory. Sometimes you can get away with MicroPython for these cases, but the best language is likely C or assembly. If you’re really stubborn, like [amirgon], and really want C and Python to play well together, you can make use of his new tool which can bring any C library to MicroPython.

As an example of how this tool is used, a “Pure MicroPython” display driver for ILI9341 on the ESP32, which means that everything was implemented in MicroPython. [amirgon] wanted to see how the Python driver would compare to one that’s already been written in C, and use it to showcase MicroPython binding. This tool also automatically converts structs, unions, enums and arrays to Python objects, and provides a means to work with pointers which is something that Python doesn’t handle in the same way that C requires.

[amirgon] hopes that this tool will encourage the adoption of Micropython by removing the obstacle of missing APIs and libraries in MicroPython. Since most libraries for systems like these are written in C, a way to implement them in Python is certainly powerful. We featured one use case for this a while back, but this is a much more generic fix for this coding obstacle.

AI Poised To Turn The Internet Into Gibberish

Last Thursday two lowly masters grad students, Aaron Gokaslan and Vanya Cohen managed to replicate the secretive OpenAI model and cheekily named their version OpenGPT-2. The code can be downloaded from this Google Colab page and apparently no prior experience in language modeling is required to use it. More useful might be the skills required to persuade Google to part with $50,000 worth of free cloud compute time for the training!

Research firm OpenAI released a new, ever more powerful, version of their GPT language model with 1.5 billion parameters, trained on a data-set of 8 million web pages and although it’s most entertaining use is to produce gibberish, it will inevitably also be able to produce coherent text sometime very soon. For us mere mortals, there’s a cut down version of the model hosted in the cloud and a webpage that we can visit, type in a short phrase to prompt the system, and print out a few paragraphs of fake news. We tried it with the following: “You can use an Arduino to” and the results were:

  • You can use an Arduino to remove your appendix. Use an open or closed loop, but do not use them at the same time, i.e. don’t wire your Arduino to the wall like I did. The Arduino’s are very noisy and can damage the circuit board. Be sure to use a good quality and high-quality resistor to connect them to the wall. You can also use your own antenna if you’d like.

The neural network works by taking the text that has been previously printed and using this to predict the next word sequentially. Because of it’s obscurity, our Arduino example is a pretty severe and rather unfair test on the system whilst in it’s fledgling infant state and, looking at the proper metrics, it actually performs quite well on certain standard industry test sets such as the Children’s Book Test.

Be sure to paste your own fake news into the comments below and we’ll take a vote on the one that’s most entertaining, but please keep it within the boundaries of good taste!

Whilst this is an emerging technology, somebody did get hold of it a while back and applied it to an old teleprinter!

 

Build A Fungus Foraging App With Machine Learning

As the 2019 mushroom foraging season approaches it’s timely to combine my thirst for knowledge about low level machine learning (ML) with a popular pastime that we enjoy here where I live. Just for the record, I’m not an expert on ML, and I’m simply inviting readers to follow me back down some rabbit holes that I recently explored.

But mushrooms, I do know a little bit about, so firstly, a bit about health and safety:

  • The app created should be used with extreme caution and results always confirmed by a fungus expert.
  • Always test the fungus by initially only eating a very small piece and waiting for several hours to check there is no ill effect.
  • Always wear gloves  – It’s surprisingly easy to absorb toxins through fingers.

Since this is very much an introduction to ML, there won’t be too much terminology and the emphasis will be on having fun rather than going on a deep dive. The system that I stumbled upon is called XGBoost (XGB). One of the XGB demos is for binary classification, and the data was drawn from The Audubon Society Field Guide to North American Mushrooms. Binary means that the app spits out a probability of ‘yes’ or ‘no’ and in this case it tends to give about 95% probability that a common edible mushroom (Agaricus campestris) is actually edible. 

The app asks the user 22 questions about their specimen and collates the data inputted as a series of letters separated by commas. At the end of the questionnaire, this data line is written to a file called ‘fungusFile.data’ for further processing.

XGB can not accept letters as data so they have to be mapped into ‘classic LibSVM format’ which looks like this: ‘3:218’, for each letter. Next, this XGB friendly data is split into two parts for training a model and then subsequently testing that model.

Installing XGB is relatively easy compared to higher level deep learning systems and runs well on both Linux Ubuntu 16.04 and on a Raspberry Pi. I wrote the deployment app in bash so there should not be any additional software to install. Before getting any deeper into the ML side of things, I highly advise installing XGB, running the app, and having a bit of a play with it.

Training and testing is carried out by running bash runexp.sh in the terminal and it takes less than one second to process the 8124 lines of fungal data. At the end, bash spits out a set of statistics to represent the accuracy of the training and also attempts to ‘draw’ the decision tree that XGB has devised. If we have a quick look in directory ~/xgboost/demo/binary_classification, there should now be a 0002.model file in it ready for deployment with the questionnaire.

I was interested to explore the decision tree a bit further and look at the way XGB weighted different characteristics of the fungi. I eventually got some rough visualisations working on a Python based Jupyter Notebook script:

 

 

 

 

 

 

 

Obviously this app is not going to win any Kaggle competitions since the various parameters within the software need to be carefully tuned with the help of all the different software tools available. A good place to start is to tweak the maximum depth of the tree and the number or trees used. Depth = 4 and number = 4 seems to work well for this data. Other parameters include the feature importance type, for example: gain, weight, cover, total_gain or total_cover. These can be tuned using tools such as SHAP.

Finally, this app could easily be adapted to other questionnaire based systems such as diagnosing a particular disease, or deciding whether to buy a particular stock or share in the market place.

An even more basic introduction to ML goes into the baseline theory in a bit more detail – well worth a quick look.

Dirty Tricks For 6502 Programming

We know the 6502 isn’t exactly the CPU of choice for today’s high-performance software, but with the little CPU having appeared in so many classic computers — the Apple, the KIM-1, The Commodores, to name a few — we have a real soft spot for it. [Janne] has a post detailing the eight best entries in the Commodore 64 coding competition. The goal was to draw an X on the screen using the smallest program possible. [Janne] got 56 bytes, but two entrants clocked in at 34 bytes.

In addition to the results, [Janne] also exposes the tricks people used to get these tiny programs done. Just looking at the solution in C and then 6502 assembly is instructive. Naturally, one trick is to use the existing ROM code to do tasks such as clearing the screen. But that’s just the starting point.

Continue reading “Dirty Tricks For 6502 Programming”

Cruising GitHub For Slack Webhook Tokens

GitHub is an incredibly powerful tool for sharing source code, and its value to the modern hacker can’t be overstated. But there’s at least one downside to effortlessly sharing your source: it’s now much easier for the whole world to find out when you screw up. Back in the day, if you accidentally left a username or password in a tarball hosted on your site, you could pull it down before anyone noticed. But push something like that up to GitHub, and you’ve got a problem on your hands.

For an example, look no farther than this tool that crawls GitHub for Slack webhooks written by [Michele Gruppioni]. Exploiting the fact that Slack webhook links have a predictable format, the tool searches repositories to find code that erroneously includes the authentication token. With the token in hand, an attacker now has the ability to send unsolicited messages into that channel.

But [Michele] restrained himself and didn’t Rickroll the over 6,500 Slack channels he had access to after searching GitHub with his tool. Instead, he sent them all a friendly message explaining their webhook tokens were available on GitHub, and gave them a link to where they could get more information about his project.

Most of the people who contacted him after the fact appreciated that he sent a gentle warning and not something unsavory. Still, we’d recommend caution to anyone looking to expose a vulnerability in this manner. While [Michele] had honorable intentions, it’s certainly not unheard of for an embarrassed administrator to blame the messenger.

When used properly, webhooks can be a very handy way of pushing data into your chat platform of choice. We’ve previously looked at a practical example of a weather station that pushes current conditions into a Discord channel. Just try not to accidentally commit your authentication token to the world’s largest database of open source projects, or you might receive more than you bargained for.