S4A known directories

 the IDE has grown organically over the years and many things are not documented. I thought something useful might be the (current) set of directories used by S4A 4.9.2 (note, these things change often) In ~/Library/Application Support/SwiftForArduino... Boards - a supplementary boards.yaml file and related images, allowing you to add board definitions, which will be detected if their USB VID/PID match Builds - dynamically created/destroyed folders that contain the files built from source code, created on demand and deleted when you close the project, there is an advanced setting to keep contents Extensions/Build - the location for build plugins used by the board definitions, e.g. 0-series atmega chip build plugins Extensions/Upload - the location for upload plugins used by the board definitions, e.g. 0-series atmega chip upload plugins Extensions/Modules - added into the swift compile and clang compile paths, you can put built modules in here for import into your code Libraries - auto

code signing, entitlements, bundles, sandboxes, hardened runtime, notarisation, app store security

Some people had mentioned troubles with code signing, i thought a brain dump of my learnings on it might be informative and helpful as I've learned a lot in developing a mac app (the s4a IDE).  Some of these concepts are used in ios too but this post is about mac apps. First up, terminology. Code signing. *** This is a variant of normal PKI (public key infrastructure) signing. A hash is made of the binary you're signing (the actual macho executable file), then encrypted with your private key to make a signature that anyone with your public key can decrypt and verify to check your binary hasn't been altered in any way since you signed it. Code signing could in theory be done with any tool, (many of these concepts are NOT mac/ios only concepts but follow general unix/windows/etc. principles and ideas widely used across industry), but in reality, people on a mac use the built in (to macOS) tool "codesign" which is a command line tool that can create, alter, remove an

Comparing iLEDs

This might seem a bit off topic, but i've never seen the need for this blog to only be about S4A. :) There are a bunch of RGB LEDs out there that are controlled by a one wire protocol (note: readers, feel free to add any info in the comments section or links to similar comparison blog posts, let's help each other out!) Most of them are made by world semi, hence the WS part numbers. Here are some comparison links: needless to say any of the relatively small family of core ileds are then resold by a variety of manufacturers in a variety of form factors, but fundamentally the code needed to control them is the same for each family (note, I'm not talking about other chips that are contro

All about bootloaders

 BOOTLOADERS *** Some interesting general boot loader facts: The Boot Loader is basically a section at the top of flash memory, how big it is depends on the BOOTSZ1 and BOOTSZ0 bits in the Low Fuse byte. It has the special property that ONLY while the core is running instructions in the bootloader, a special instruction called SPM will function. This function allows writing data to the flash memory. As normal with all flash, you need to erase the page you are writing first, otherwise your write operation will often not function correctly. I think you can change 1 bits to 0 bits but not the other way around, which is true for all flash writing. So the flash erase process always sets a flash memory page to all 0xFF (all 1 bits) The usual way the boot loader runs is if the fuse bit BOOTRST is active (i.e. it reads as a 0!) then when the MCU is reset, it will start execution at the beginning of the bootloader (as defined above). If the bit is not set, it will start execution at 0x0000. But

Pushing the limits

 The nice thing about Swift for Arduino these days is we are having a lot of conversations like "exactly how much performance can you get from an atmega328p, how much program space is the limit? what about RAM?" To me it shows we've gone far beyond the 'hobbyist' place we started from and now as we build professional products, we are dealing with the same issues all professional embedded developers grapple with... in a word efficiency. To that end I thought it might be worth me putting down some thoughts on what some of the numbers are, where the overheads are, what are the limits on RAM and program memory? I'm talking here to the atmega328p as that's what most of our work uses.. the classic Arduino UNO heart, but of course similar things would apply for other chips. In spec, we have 2k RAM, 32k program memory? Can I use all of those? Of course not. ;-) Let's break it down. PROGRAM MEMORY You might have seen my earlier article with a breakdown of what