A free toolchain for 0.01 € - computers
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Krause, Philipp Klaus
The Taiwanese company Padauk makes small 8-bit microcontrollers, the smallest of which are available at 0.01 € even in small quantities. Even the larger ones are just a few cents; a particularly interestign feature is the hardware multithreading support available in larger devices. Until recently, the only available toolchain was Padauk's non-free toolchain based around their "MINI-C" IDE (which despite, the name, ist just a bit of C-like syntactic sugar coating for assembler, and in no way a C implementation). In 2019, an effort to provide a free alternative resulted in a full free toolchain. Documentation beyond that provided by Padauk was created by reverse-engineering. A free design for a programmer along with firmware was created. Assembler, simulator and a Small Device C Compiler (SDCC) backend were written. The Padauk microcontrollers (µC) are small 8-bit Systems-on-a-Chip (SoC). Their program memory (PROM or Flash) is 0.5 KW to 4 KW with word sizes from 13 to 16 bit. Their data memory is 60 B to 256 B with 8-bit Bytes. The µC only have few peripherals; however, some of the larger devices are barrel processors with support for up to 8 hardware threads. This allows the emulation of even timing-critical peripherals in software. Padauk also supplies a programmer and a non-free "MINI-C" IDE. There is a lack of documentation when it comes to aspects not needed for users of MINI-C. In particular, there is no documentation of opcodes and very little information on the programming protocol. There are 4 subarchitectures, which we name by the word size in the program memory pdk13, pdk14, pdk15 and pdk16. There is some variation in the form of optional instructions within the subarchitectures. In 2019, a full free toolchain for these µC was created. The necessary documentation was reverse-engineered. A free programmer design and firmware was created. For the pdk13, pdk14 and pdk15, we wrote free assemblers and simulators. We also wrote an SDCC backend for these. SDCC is a free C compiler that emphasizes standard-compliance and generating efficient code for small devices; while not up to the level of GCC and LLVM it tends to hold up well against many non-free compilers targetting small devices (see e.g. the FOSDEM 2018 talk "The free toolchain for the STM8"). While stack handling on the Padauk µC is much better than on e.g. small Mirochip PIC devices, it is still not efficient (in particular, there is no stack-pointer-relative addressing mode). Thus SDCC does not place local variables on the stack by default, which makes functions non-reentrant and is not standard-compliant, but a common choice in such cases (see e.g. the mcs51 backend in SDCC or Keil for MCS-51). However, this approach does not work well for devices with hardware-multithreading (i.e. few pdk14 and all pdk16).
 One cent computers. It started kind of about a year ago when there was an e-V blog entry about three cent computers, well, or microcontrollers. And at some point I had a look at the hardware and it seemed like it would be a nice target architecture for the small device seed compiler and well, today we have a free tool chain for these microcontrollers. Not perfect for all of them yet, but well, we'll see where we are. Okay, so I'll start by talking a little bit about the background. What are these microcontrollers that are relatively cheap? I'll talk a little bit about free hardware to support them, basically device for programming them, and then about the tool support by the seed compiler. Okay, those microcontrollers are made by a Taiwanese company called Padok. There's also a reseller that rebrand them under the name of Poo-O-Lop. Since Padok sometimes makes like semi-custom versions, there's something available from Poo-O-Lop that one can't get directly at Padok, I think, when microcontroller with three quarters of a kilo worth of program memory. They're relatively cheap, so the very cheapest is indeed available for one cent if bought in quantities of ten. However, those very cheap ones, their program memory is PROM, so I prefer to have them reusable, so personally I use expensive versions, which also have bigger memory, so the chips on here cost about four to seven cents. But the tool chain can also target the very cheapest ones. So they are quite low-power devices. The architecture is accumulator-based, meaning you don't have quite unlike RISC, you don't have a lot of registers, but you have one register, and you typically have accumulator memory instructions or memory accumulator instructions, so not a lot of store architecture, but direct use of memory operands. The architecture is relatively nice if you look at such small devices. I mean, there's, it was for a long time around the microchip pick, which has the problem that the smallest devices have a hardware stack, so you're limited in your call depths, and then there's plenty of Chinese-made 4-bit microcontrollers that are very hard to target with something like a C compiler. So considering that this thing is cheap and low-power and small and everything, it's a very nice architecture. It's kind of comparable to the Intel 8051 in terms of how nice or non-nice it is. The devices have RAM between the smallest one have 60 bytes, but this version's up to 256 bytes. One sub-architecture would allow up to 512 bytes because it has 9 address bits, but no existing devices are known, and there's actually more different sub-architectures will come to it soon, and the smallest one has only 6 address bits for the RAM. We have program memory that's between half and half a kiloWert, and for kiloWerts of program memory, depending on the sub-architecture, the width of a Wert is between 13 and 16 bits. There's very few peripherals, typically just timers, comparators, ADC, something for pulse width modulation and watchdog. However, we have something, well, I wouldn't, it's not full multi-core, even so I'll use the term core on the rest of the slides because the manufacturer does, but it's kind of hardware thread, a bit like hyperthreading or something like that, which is convenient because you can emulate a peripheral in software on kind of a separate, let's call it core now, and have it respond fast to our IO. Okay, so let's get to the sub-architectures. I usually call them PDK13 to PDK16 by the width of the Werts in program memory. They have internal names that are found in files from the non-free IDE from the manufacturer, again, 13 to 16 bits. So for every bit width, there's a sub-architecture and actually assisting devices. The address bits for the program memory also go up by one, and the address bits for the data. For IO, mostly so except for PDK16, having less address bits. As far as I know, PDK16 actually seems to be the oldest of the sub-architectures with the other ones added later. And only for the PDK14 and PDK16, they're actually devices with multiple hardware threads. And if you want the full eight threads, it's only the PDK16 sub-architecture. There's still a little bit more variation within the sub-architectures. So you have some PDK16 devices that have a multiplication instruction, others don't and so on. But looking at the big picture, these four sub-architectures are there, and then sometimes there are a few additional instructions or not. Okay, how is the hardware multithreading implemented? Well, this is a so-called barrel processor, which you may know from the Honeywell H800 from the early 1960s, I think. I think there's also the X-core microcontroller or something that uses something similar, but I don't know of any others. Apart from the PDK16, basically the idea is you have a set of registers for every hardware thread, and then cycle per cycle you rotate through your other, your arithmetic and logical unit, and every cycle, this arithmetic logical unit, processes an instruction from a different core. Yeah, we call these core processing units whatever. Hardware threads is more accurate. I'll use core cause it's short, but manufacturer documentation uses different terms. And there's unfortunately a lack of instruction support for this parallelism. Usually you have multi-causing units except, expect stuff that makes it easy to implement locks to implement atomics and so on. Unfortunately, it's not in this architecture. Yeah, it's very complicated to kind of emulate locks as atomics or something, but we'll get to that later. So synchronization between the multiple hardware threads is a bit problematic, at least from a C perspective. Okay, this is how this thing looks. Well, I've boiled it in colophony to take it apart and put it under a microscope. What we see here is the PMC234 is one of the big devices. It has eight hardware threads, it has lots of peripherals by paddock standards. Still, what we see in the middle, the sea of gates, so all the digital logics, the cores, the peripherals don't actually make up that much space. Basically, I will look at the program memory and include the address decoder. I've already have about the same amount of space in just the program memory. And then, of course, there's the IO part, then here these diodes for ESD protection. Yeah, I think the cheaper, really cheapest ones, the BMS158, so the one-time things have a die of, I think, a quarter square millimeter or something like that. So this here is a little bit bigger, it's like about one millimeter times 1.2 or something like that. So it's easier to pick up with pliers and not to lose when you're decapping a chip. Okay, so before I started the work, of course, there were non-free tools available. So the manufacturer provides this thing called Mini-C. It's an IDE with compiler sampler and everything in one thing. It's one binary. It's essentially a sampler with a bit of C-like syntactic sugar on top. And well, there's a program adapter in circuit emulator, so yeah. It's far from real C. I mean, they don't even have different data types for pointers and integers. It's just the 8-bit data type and 1-16-bit data type, and that's it. And your integer type is the same as your pointer type and so on. Okay, so let's get to the free tools. There it will be the small device C compiler, which you might already know if you're into the 8-bit stuff with the sample link simulator. So back end for that, the EZP-DK programmer to write it. The programmer from the manufacturer, the big blue box. And some very basic development boards. Okay, now let's get into the details of that. So someone reverse engineered the programming protocol, which was quite weird because it lost lots of different voltages. A little bit unexpected and created this EZP-DK programmer. So that's all on GitHub, including the files for 3D printing it. That works under various OSes. Well, I've only used it under Linux, but I've seen people use it on MacOS and I think Windows. Yep, and it so far fully supports six of those small devices, the PMS-15A, which is that thing that's actually available at one cent. And two flash devices, the PFS-145 and 173, which are nice because they have flash instead of RTP memory. For 12 more devices, there's already read-only support. And yes, further know the developer of these devices is happy to add support for more when he gets his hands on the hardware. Padok has announced lots of interesting microcontrollers that are not really available as distributors yet, especially in the realm of two and four core devices, the flash support. Currently, all multi-core things are OTP. So because of any development boards, I designed these very, very basic ones. It's just a minimal board. There's five LEDs of which four are connected to IOs. The fifth one is just there to tell if power is coming from the USB or elsewhere. You can supply power again via USB connector that's really only there for power, pins or USB. There's some diodes to protect the USB in case something goes wrong and that's it. There's also demo programs to be found on GitHub for basic stuff like blinking the LEDs, counting it, or Hello World via a software emulated UART on the pins. So nothing fancy, but nice to get started. Now, the big thing on the software support side is a small device. C compiler. Well, a quick introduction on SDCC for those who don't know it. It's a C compiler. It tries to be standard compliant. It has the usual switches to select the mode via the C90, 99, 11 or the upcoming C2X standard, which is the letter mode, of course, is still quite incomplete because the standard is still quite incomplete. But we are trying to implement stuff as it gets decided by the standards committee. It's usually used as a freestanding implementation, but it can actually be used kind of part of the hosted implementation. For those not familiar with this terminology, the C standard basically defines two subsets of the standard and the freestanding doesn't have lower requirements, for example, on the library. So when you're doing bare metal programming, you usually have a freestanding implementation, hosted implementation, you would have advanced stuff such as a file system, but there's actually operating systems like Fusix. You might have known it. Ellen Cox from my Linux kernel developer is making a unique system for Z80s and then use SDCC as a cross compiler, but since the Fusix libraries are there, it's then a hosted implementation. The supporting tools, the sampler linker simulator that we need. It works on many host systems such as New Linux, Windows Mac OS, Herat OpenBSD, FreeBSD. It probably works on more, but these are the ones on which I know it causes testing done. It targets plenty of 8-bit architectures such as the 8051 and similar, the Z80 and a lot of Z80 related architectures. The LR35904, those who are not familiar with the term, is a processor in the Game Boy. HT08 was once a popular microcontroller series. The STM8 is still a very popular 8-bit microcontroller architecture. Then those three subarchitectures of the paddock, so everything except for PDK16. Then there's in development not yet stable support for the microchip, PIC14 and PIC16. It has been in that state for a long, long time, but it's still kind of usable even for the microchip picks. It does have some unusual optimizations that you don't find in other compilers, in particular in register allocation, because for these architectures you're in a bit different situation. With GCC or LLVM, you're usually targeting something like risk. You have lots of registers, but here you have usually very few registers, so you have to... And if you have multiple registers, they're not equally. And risk doesn't matter what goes into which register. ChineT and graphColoringRetroStator is perfect, but here you really have to take into account, okay, this instruction is only available on this register, that instruction only in that one, and this instruction might be available on both registers, but it takes one cycle more if I have this register as operant. So that makes it a bit different here. It's on sourceForge. So the paddock backend, as I said, it supports three of the subarchitectures. Functions are by default non-re-entrant. The problem is that stack access is quite inefficient in these paddock architectures, so we by default read everything as if it was static. So you can't have recursion unless you use the keywords to say, I want this function re-entrant or use the command line option to say, I want the whole compilation unit, and just to illustrate how much that costs. A typical 16-bit addition of two local variables that have been spilled to memory. We'll take 40 cycles if it's on the stack and just six cycles if not. So re-entrancy has a cost. We have special keywords to access the IO address space. Now just to see how much this architecture would benefit if it had better instructions to access the stack, I created a branch of SDCC and compiled some benchmarks with hypothetical variants. So we see code size could go down. These are in these cases only the functions that really need to be re-entrant. Our mark is re-entrant. However, if you want to compile everything as re-entrant, as you want it usually in a standard compliance C implementation, you'd get even bigger savings. So yes, the architecture could be far, far nicer to see if they made just a few small changes. But for now we have to work with what is there. So I'll try to contact them sometime and ask them if they can't. At these things, there's always different things. The SPF is just an instruction that adds an immediate offset to the stack pointer. IDXSP would mean you have a load and store instruction with stack pointer relative addressing. Blue is how much you get code size and code size if you have both and SPRL would mean you have stack pointer relative addressing in all instructions. And it's code size is of course relative to the current architecture. So we would for some cases like this drystone benchmark fully re-entrant. We could get code size down by 60% if we would have the best version of stack pointer relative addressing. Okay, I've already mentioned we have an unusual register allocator. It's optimal and it works in polynomial time. In general, register allocation would be an NP-hard problem. However, that only happens if you have either the number of registers as part of the input, but for any given architecture it's fixed. You assume that to be a constant or you allow unbounded tree widths of the control flow graph. And I've proven that to do that you need a huge number of go-to labels per function in C. So unless you make excessive use of go-to labels per function in C, you have bounded tree widths and the number of registers is fixed, of course. So in that case, we can do optimal register allocation in polynomial time. We calculate the 3D composition of the control flow graph and then do the standard dynamic programming bottom-up. And that is still slow because the runtime is exponential in the number of registers. Not so big deal for padocs, so we use one pseudo-register. But for the C80, we have eight or nine, so it's already a lot. But still it's worse for those small embedded systems where your program is small anyway because it needs to fit onto the small device. And you really care about optimization. There's a compilation speed quality trade-off. Otherwise, if partial results are too many at a certain point, heuristics kick in and we are no longer provably optimal. Okay, so you might wonder this SDCC compiler, how reliable is it? I mean it's not a big thing like GCC or LLVM. However, SDCC does regression testing. We have nightly snapshots that are generated for various architectures. About 12,000 tests. These are mostly from fixed bugs from our side. And we also took most of the GCC test suite into our tests. We do it for all our stable target architectures and a few host so-as, including one called Windows, but it's actually cross-compiled under Linux and then the test is run under Vine. And we do that for four different host architectures. So not every host-to-as-host architecture combination is done. So, but the general thing is if it's standard compliance, C code, then it works under GCCs and most likely it will also work with SDCC. Given, of course, the memory of science and whatever of the target architecture. Okay, for those who don't like C, there's this experimental LLVM. Plus SDCC toolchain that I haven't done any work on recently. Basically, the LLVMC front and back end are used to compile input to LLVM into C code. While the LLVMC back end has been thrown out of LLVM a long time ago, there's still people maintaining it on GitHub. It can be mixed with pure C code compiled with SDCC. The idea was to allow languages other than C and to use LLVM's high-level optimization. But this is all quite experimental stuff. It kind of works. I managed two years ago when I tried to compile a tristone using this and run it and got a little bit of optimization out of it. But that definitely needs more work. And it's actually not the only thing that needs more work. There's still quite a bit to do. I mean, SDCC needs more developers, in particular people who have been working on the 8051 back end. These days, not as active as they used to be. There's, of course, bugs to fix, improvements and standard compliance. There's always more optimizations to do. Debug info is not that nice yet. I mean, for some back ends, we have LLVM's barf output. But there's still some... It's not perfect yet. It tends to work for a lot of cases, but sometimes the debug info causes problems. And this LLVM plus SDCC thing, as I said, is experimental still. And the work needs to be done to make it usable. IDE integration can be improved. I mean, CodeBlocks has kind of support for SDCC. And there used to be this Eclipse plugin, but that is un-maintained for a while. And it doesn't seem to work well for everyone anymore. And, of course, then the programmer could get more support for more devices. So, questions? Thank you. Thank you. Yeah? Why are you working with the Padak chip? Have you encountered some hardware bugs and so on? I will relay a little visit for your point of view. I have not encountered any actual hardware bug. I've encountered bugs in the documentation, though. Ah, yes. The question was if I've encountered hardware bugs while working with Padak chips. Of course, I mean, I've mostly done the programming stuff, so if there would be a bug in a peripheral, I wouldn't know. On the other hand, they have such simple and few peripherals that there's not a lot of bugs to hide there easily. I'm a great fan of SDCC, but have you any architectures where you can add to how to run the SDCC and I would use it to your level? Yeah, if you could compare the two. No, there was an attempt in a long time ago. Someone wanted to make an AVR backend in SDCC, but they never finished it a few years ago, so there was some talk of reviving it, because GCC was about to, intends to drop the AVR backend. I think it's un-maintained, but no. There's no architecture which is targeted both by SDCC and GCC or SDCC and LLVM. What you could try to compare is to use IAR, because IAR targets both architectures like ARM targeted by GCC and LLVM, and architectures targeted by SDCC. Is it possible to write a bootloader for those MCUs? If it's possible to write a bootloader for those things. I mean, what's a bootloader? It's just some programs that run at the very beginning, but it needs to fit into the hardware. Can it self-write its flash? No, as far as I know. The question was, can it self-write its flash? As far as I know, no. And it's run from RAM? And you can't run it from RAM easily either. I mean, there's not a lot of RAM anyway. I mean, 60 bytes up to 256. I'm not sure if there's some very, wait, there's upcoming variants. They are announced already on the website with data sheets, I think, but they are not available at the distributors that have quite a bit of EE prom. I'm not sure if you can, I think you can write EE prom from the thing, and you might be able to run a program from there, but I'm not sure. I think the documentation isn't complete yet either. But those might be the PGC, or it's the numbering scheme, and they tend to have four cores, and yeah. I haven't seen the hardware yet. In the back first. How hard is it to get a programmer for it? Excuse me? How hard is it to get a programmer for it? How hard is it to get a programmer for it? Well, you can buy the big, barking thing from the manufacturer for 100 euros or something, and then have it only supported by their hardware, or you can look at this thing, which is relatively simple, and the files are at GitHub, but I guess, I mean, there's someone, there's been two people now who intend to manufacture something like that, but if you want to quickly just have it, just do it yourself. All the design files on GitHub. So what kind of packages and pin counts are available? So the question was, what packages and pin counts are available for these PADOC things? I'm not exactly sure. There's eight pin devices. I'm not sure if there's six pin devices. Nothing under six pins. And it goes up to 20, 24, something like that. What packages? Packages. A lot of packages are mentioned in the data sheets, but so far, everything I've seen is these SOIC ones. So that's what's available at typical distributors, but in the data sheets, they even mention dip variants and then BGA and whatever. Maybe, I mean, I guess a lot of people who buy microcontrollers for one cent by like billions of them and then can get their custom packaging anyway. I mean, PADOC sometimes apparently even makes custom instruction for this customer. Do you see any usage of the PADOC in the maker scene? If there's use in the maker scene. Well, they're cheap. They're low power. So I mean, this is cheaper than the 7.4 LS, whatever thing. So you can, I guess there's a lot of uses, but I wouldn't count pin points or something. I mean, it's still a bit too big for smart dust and then you'd need RFID communication or something like that, which I haven't tried yet. I mean, the tips themselves don't have support, but it could probably be done by an external thing. Or, of course, the classic low power thing combines this. We use an ESP A266 that sleeps all the time. This C is active all the time. And when something interesting is to be reported, wake up the other thing that takes power. You're talking about low power, but so how low power can it get? To be honest, I don't remember by heart, so you'd have to look up the datasheet. But when I first went into this, I noticed that they actually quite low. I think they were lower than others. I'm not sure, but as far as I remember, you got them in some cases lower than, let's say, an STM8L. So the low power variant of S. But I'm not sure about that aspect. I'd have to look at the datasheets again. I just remember a year ago when I looked at all the hardware before I really did dive into doing stuff. Something close to this question. Would it be possible to kind of drive them without battery, like, I don't know, EM or whatever, or sunlight? Well, sunlight, yes. You could use a solar cell and a capacitor, stuff like that. That would work. Like a solar cell, like you have in these calculators, or something like that. How fast and how slow can you run them? How fast, how slow? You can go really low. And I think you can go below a kilohertz if you really want to. How fast? Well, the oscillator is at 16 megahertz, and the system clock would be at 8 megahertz, and nearly all instructions are single cycle. Except for those that access 16 bit words in memory, those are two cycles. Okay, that's it. Fortunately, no hands up and time's up as well. Thank you.
 One cent computers.  It started kind of about a year ago when there was an e-V blog entry about three cent computers,  well, or microcontrollers.  And at some point I had a look at the hardware and it seemed like it would be a nice target  architecture for the small device seed compiler and well, today we have a free tool chain  for these microcontrollers.  Not perfect for all of them yet, but well, we'll see where we are.  Okay, so I'll start by talking a little bit about the background.  What are these microcontrollers that are relatively cheap?  I'll talk a little bit about free hardware to support them, basically device for programming them,  and then about the tool support by the seed compiler.  Okay, those microcontrollers are made by a Taiwanese company called Padok.  There's also a reseller that rebrand them under the name of Poo-O-Lop.  Since Padok sometimes makes like semi-custom versions, there's something available from Poo-O-Lop  that one can't get directly at Padok, I think, when microcontroller with three quarters of a kilo worth of program memory.  They're relatively cheap, so the very cheapest is indeed available for one cent  if bought in quantities of ten.  However, those very cheap ones, their program memory is PROM,  so I prefer to have them reusable, so personally I use expensive versions,  which also have bigger memory, so the chips on here cost about four to seven cents.  But the tool chain can also target the very cheapest ones.  So they are quite low-power devices.  The architecture is accumulator-based, meaning you don't have quite unlike RISC,  you don't have a lot of registers, but you have one register,  and you typically have accumulator memory instructions or memory accumulator instructions,  so not a lot of store architecture, but direct use of memory operands.  The architecture is relatively nice if you look at such small devices.  I mean, there's, it was for a long time around the microchip pick,  which has the problem that the smallest devices have a hardware stack,  so you're limited in your call depths,  and then there's plenty of Chinese-made 4-bit microcontrollers  that are very hard to target with something like a C compiler.  So considering that this thing is cheap and low-power and small and everything,  it's a very nice architecture. It's kind of comparable to the Intel 8051  in terms of how nice or non-nice it is.  The devices have RAM between the smallest one have 60 bytes,  but this version's up to 256 bytes.  One sub-architecture would allow up to 512 bytes  because it has 9 address bits, but no existing devices are known,  and there's actually more different sub-architectures will come to it soon,  and the smallest one has only 6 address bits for the RAM.  We have program memory that's between half and half a kiloWert,  and for kiloWerts of program memory, depending on the sub-architecture,  the width of a Wert is between 13 and 16 bits.  There's very few peripherals, typically just timers, comparators, ADC,  something for pulse width modulation and watchdog.  However, we have something, well, I wouldn't, it's not full multi-core,  even so I'll use the term core on the rest of the slides  because the manufacturer does, but it's kind of hardware thread,  a bit like hyperthreading or something like that,  which is convenient because you can emulate a peripheral in software  on kind of a separate, let's call it core now,  and have it respond fast to our IO.  Okay, so let's get to the sub-architectures.  I usually call them PDK13 to PDK16 by the width of the Werts in program memory.  They have internal names that are found in files from the non-free IDE  from the manufacturer, again, 13 to 16 bits.  So for every bit width, there's a sub-architecture and actually assisting devices.  The address bits for the program memory also go up by one,  and the address bits for the data.  For IO, mostly so except for PDK16, having less address bits.  As far as I know, PDK16 actually seems to be the oldest of the sub-architectures  with the other ones added later.  And only for the PDK14 and PDK16,  they're actually devices with multiple hardware threads.  And if you want the full eight threads,  it's only the PDK16 sub-architecture.  There's still a little bit more variation within the sub-architectures.  So you have some PDK16 devices that have a multiplication instruction,  others don't and so on.  But looking at the big picture, these four sub-architectures are there,  and then sometimes there are a few additional instructions or not.  Okay, how is the hardware multithreading implemented?  Well, this is a so-called barrel processor,  which you may know from the Honeywell H800 from the early 1960s, I think.  I think there's also the X-core microcontroller or something that uses something similar,  but I don't know of any others.  Apart from the PDK16, basically the idea is you have a set of registers  for every hardware thread, and then cycle per cycle you rotate through  your other, your arithmetic and logical unit,  and every cycle, this arithmetic logical unit,  processes an instruction from a different core.  Yeah, we call these core processing units whatever.  Hardware threads is more accurate.  I'll use core cause it's short, but manufacturer documentation uses different terms.  And there's unfortunately a lack of instruction support for this parallelism.  Usually you have multi-causing units except, expect stuff that makes it easy  to implement locks to implement atomics and so on.  Unfortunately, it's not in this architecture.  Yeah, it's very complicated to kind of emulate locks as atomics or something,  but we'll get to that later.  So synchronization between the multiple hardware threads is a bit problematic,  at least from a C perspective.  Okay, this is how this thing looks.  Well, I've boiled it in colophony to take it apart and put it under a microscope.  What we see here is the PMC234 is one of the big devices.  It has eight hardware threads, it has lots of peripherals by paddock standards.  Still, what we see in the middle, the sea of gates,  so all the digital logics, the cores, the peripherals don't actually make up that much space.  Basically, I will look at the program memory and include the address decoder.  I've already have about the same amount of space in just the program memory.  And then, of course, there's the IO part, then here these diodes for ESD protection.  Yeah, I think the cheaper, really cheapest ones, the BMS158,  so the one-time things have a die of, I think, a quarter square millimeter or something like that.  So this here is a little bit bigger, it's like about one millimeter times 1.2 or something like that.  So it's easier to pick up with pliers and not to lose when you're decapping a chip.  Okay, so before I started the work, of course, there were non-free tools available.  So the manufacturer provides this thing called Mini-C.  It's an IDE with compiler sampler and everything in one thing.  It's one binary. It's essentially a sampler with a bit of C-like syntactic sugar on top.  And well, there's a program adapter in circuit emulator, so yeah.  It's far from real C. I mean, they don't even have different data types for pointers and integers.  It's just the 8-bit data type and 1-16-bit data type, and that's it.  And your integer type is the same as your pointer type and so on.  Okay, so let's get to the free tools.  There it will be the small device C compiler, which you might already know if you're into the 8-bit stuff with the sample link simulator.  So back end for that, the EZP-DK programmer to write it.  The programmer from the manufacturer, the big blue box.  And some very basic development boards.  Okay, now let's get into the details of that.  So someone reverse engineered the programming protocol, which was quite weird because it lost lots of different voltages.  A little bit unexpected and created this EZP-DK programmer.  So that's all on GitHub, including the files for 3D printing it.  That works under various OSes. Well, I've only used it under Linux, but I've seen people use it on MacOS and I think Windows.  Yep, and it so far fully supports six of those small devices, the PMS-15A, which is that thing that's actually available at one cent.  And two flash devices, the PFS-145 and 173, which are nice because they have flash instead of RTP memory.  For 12 more devices, there's already read-only support.  And yes, further know the developer of these devices is happy to add support for more when he gets his hands on the hardware.  Padok has announced lots of interesting microcontrollers that are not really available as distributors yet,  especially in the realm of two and four core devices, the flash support. Currently, all multi-core things are OTP.  So because of any development boards, I designed these very, very basic ones.  It's just a minimal board. There's five LEDs of which four are connected to IOs. The fifth one is just there to tell if power is coming from the USB or elsewhere.  You can supply power again via USB connector that's really only there for power, pins or USB.  There's some diodes to protect the USB in case something goes wrong and that's it.  There's also demo programs to be found on GitHub for basic stuff like blinking the LEDs, counting it, or Hello World via a software emulated UART on the pins.  So nothing fancy, but nice to get started.  Now, the big thing on the software support side is a small device.  C compiler. Well, a quick introduction on SDCC for those who don't know it.  It's a C compiler. It tries to be standard compliant.  It has the usual switches to select the mode via the C90, 99, 11 or the upcoming C2X standard,  which is the letter mode, of course, is still quite incomplete because the standard is still quite incomplete.  But we are trying to implement stuff as it gets decided by the standards committee.  It's usually used as a freestanding implementation, but it can actually be used kind of part of the hosted implementation.  For those not familiar with this terminology, the C standard basically defines two subsets of the standard and the freestanding doesn't have lower requirements, for example, on the library.  So when you're doing bare metal programming, you usually have a freestanding implementation, hosted implementation,  you would have advanced stuff such as a file system, but there's actually operating systems like Fusix.  You might have known it.  Ellen Cox from my Linux kernel developer is making a unique system for Z80s and then use SDCC as a cross compiler,  but since the Fusix libraries are there, it's then a hosted implementation.  The supporting tools, the sampler linker simulator that we need.  It works on many host systems such as New Linux, Windows Mac OS, Herat OpenBSD, FreeBSD.  It probably works on more, but these are the ones on which I know it causes testing done.  It targets plenty of 8-bit architectures such as the 8051 and similar, the Z80 and a lot of Z80 related architectures.  The LR35904, those who are not familiar with the term, is a processor in the Game Boy.  HT08 was once a popular microcontroller series.  The STM8 is still a very popular 8-bit microcontroller architecture.  Then those three subarchitectures of the paddock, so everything except for PDK16.  Then there's in development not yet stable support for the microchip, PIC14 and PIC16.  It has been in that state for a long, long time, but it's still kind of usable even for the microchip picks.  It does have some unusual optimizations that you don't find in other compilers, in particular in register allocation,  because for these architectures you're in a bit different situation.  With GCC or LLVM, you're usually targeting something like risk.  You have lots of registers, but here you have usually very few registers, so you have to...  And if you have multiple registers, they're not equally.  And risk doesn't matter what goes into which register.  ChineT and graphColoringRetroStator is perfect, but here you really have to take into account,  okay, this instruction is only available on this register, that instruction only in that one,  and this instruction might be available on both registers, but it takes one cycle more if I have this register as operant.  So that makes it a bit different here.  It's on sourceForge.  So the paddock backend, as I said, it supports three of the subarchitectures.  Functions are by default non-re-entrant.  The problem is that stack access is quite inefficient in these paddock architectures,  so we by default read everything as if it was static.  So you can't have recursion unless you use the keywords to say,  I want this function re-entrant or use the command line option to say,  I want the whole compilation unit, and just to illustrate how much that costs.  A typical 16-bit addition of two local variables that have been spilled to memory.  We'll take 40 cycles if it's on the stack and just six cycles if not.  So re-entrancy has a cost.  We have special keywords to access the IO address space.  Now just to see how much this architecture would benefit if it had better instructions to access the stack,  I created a branch of SDCC and compiled some benchmarks with hypothetical variants.  So we see code size could go down.  These are in these cases only the functions that really need to be re-entrant.  Our mark is re-entrant.  However, if you want to compile everything as re-entrant, as you want it usually in a standard compliance C implementation,  you'd get even bigger savings.  So yes, the architecture could be far, far nicer to see if they made just a few small changes.  But for now we have to work with what is there.  So I'll try to contact them sometime and ask them if they can't.  At these things, there's always different things.  The SPF is just an instruction that adds an immediate offset to the stack pointer.  IDXSP would mean you have a load and store instruction with stack pointer relative addressing.  Blue is how much you get code size and code size if you have both and SPRL would mean you have stack pointer relative addressing in all instructions.  And it's code size is of course relative to the current architecture.  So we would for some cases like this drystone benchmark fully re-entrant.  We could get code size down by 60% if we would have the best version of stack pointer relative addressing.  Okay, I've already mentioned we have an unusual register allocator.  It's optimal and it works in polynomial time.  In general, register allocation would be an NP-hard problem.  However, that only happens if you have either the number of registers as part of the input,  but for any given architecture it's fixed.  You assume that to be a constant or you allow unbounded tree widths of the control flow graph.  And I've proven that to do that you need a huge number of go-to labels per function in C.  So unless you make excessive use of go-to labels per function in C, you have bounded tree widths and the number of registers is fixed, of course.  So in that case, we can do optimal register allocation in polynomial time.  We calculate the 3D composition of the control flow graph and then do the standard dynamic programming bottom-up.  And that is still slow because the runtime is exponential in the number of registers.  Not so big deal for padocs, so we use one pseudo-register.  But for the C80, we have eight or nine, so it's already a lot.  But still it's worse for those small embedded systems where your program is small anyway because it needs to fit onto the small device.  And you really care about optimization.  There's a compilation speed quality trade-off.  Otherwise, if partial results are too many at a certain point, heuristics kick in and we are no longer provably optimal.  Okay, so you might wonder this SDCC compiler, how reliable is it?  I mean it's not a big thing like GCC or LLVM.  However, SDCC does regression testing.  We have nightly snapshots that are generated for various architectures.  About 12,000 tests.  These are mostly from fixed bugs from our side.  And we also took most of the GCC test suite into our tests.  We do it for all our stable target architectures and a few host so-as, including one called Windows,  but it's actually cross-compiled under Linux and then the test is run under Vine.  And we do that for four different host architectures.  So not every host-to-as-host architecture combination is done.  So, but the general thing is if it's standard compliance, C code, then it works under GCCs  and most likely it will also work with SDCC.  Given, of course, the memory of science and whatever of the target architecture.  Okay, for those who don't like C, there's this experimental LLVM.  Plus SDCC toolchain that I haven't done any work on recently.  Basically, the LLVMC front and back end are used to compile input to LLVM into C code.  While the LLVMC back end has been thrown out of LLVM a long time ago,  there's still people maintaining it on GitHub.  It can be mixed with pure C code compiled with SDCC.  The idea was to allow languages other than C and to use LLVM's high-level optimization.  But this is all quite experimental stuff.  It kind of works. I managed two years ago when I tried to compile a tristone using this and run it  and got a little bit of optimization out of it.  But that definitely needs more work.  And it's actually not the only thing that needs more work.  There's still quite a bit to do.  I mean, SDCC needs more developers, in particular people who have been working on the 8051 back end.  These days, not as active as they used to be.  There's, of course, bugs to fix, improvements and standard compliance.  There's always more optimizations to do.  Debug info is not that nice yet.  I mean, for some back ends, we have LLVM's barf output.  But there's still some...  It's not perfect yet.  It tends to work for a lot of cases, but sometimes the debug info causes problems.  And this LLVM plus SDCC thing, as I said, is experimental still.  And the work needs to be done to make it usable.  IDE integration can be improved.  I mean, CodeBlocks has kind of support for SDCC.  And there used to be this Eclipse plugin, but that is un-maintained for a while.  And it doesn't seem to work well for everyone anymore.  And, of course, then the programmer could get more support for more devices.  So, questions?  Thank you.  Thank you.  Yeah?  Why are you working with the Padak chip?  Have you encountered some hardware bugs and so on?  I will relay a little visit for your point of view.  I have not encountered any actual hardware bug.  I've encountered bugs in the documentation, though.  Ah, yes.  The question was if I've encountered hardware bugs while working with Padak chips.  Of course, I mean, I've mostly done the programming stuff,  so if there would be a bug in a peripheral, I wouldn't know.  On the other hand, they have such simple and few peripherals  that there's not a lot of bugs to hide there easily.  I'm a great fan of SDCC, but have you any architectures where you can add to how to run the SDCC  and I would use it to your level?  Yeah, if you could compare the two.  No, there was an attempt in a long time ago.  Someone wanted to make an AVR backend in SDCC,  but they never finished it a few years ago,  so there was some talk of reviving it,  because GCC was about to, intends to drop the AVR backend.  I think it's un-maintained, but no.  There's no architecture which is targeted both by SDCC and GCC or SDCC and LLVM.  What you could try to compare is to use IAR,  because IAR targets both architectures like ARM targeted by GCC and LLVM,  and architectures targeted by SDCC.  Is it possible to write a bootloader for those MCUs?  If it's possible to write a bootloader for those things.  I mean, what's a bootloader?  It's just some programs that run at the very beginning,  but it needs to fit into the hardware.  Can it self-write its flash?  No, as far as I know.  The question was, can it self-write its flash?  As far as I know, no.  And it's run from RAM?  And you can't run it from RAM easily either.  I mean, there's not a lot of RAM anyway.  I mean, 60 bytes up to 256.  I'm not sure if there's some very,  wait, there's upcoming variants.  They are announced already on the website with data sheets, I think,  but they are not available at the distributors that have quite a bit of EE prom.  I'm not sure if you can, I think you can write EE prom from the thing,  and you might be able to run a program from there,  but I'm not sure.  I think the documentation isn't complete yet either.  But those might be the PGC,  or it's the numbering scheme,  and they tend to have four cores, and yeah.  I haven't seen the hardware yet.  In the back first.  How hard is it to get a programmer for it?  Excuse me?  How hard is it to get a programmer for it?  How hard is it to get a programmer for it?  Well, you can buy the big,  barking thing from the manufacturer for 100 euros or something,  and then have it only supported by their hardware,  or you can look at this thing,  which is relatively simple,  and the files are at GitHub,  but I guess, I mean, there's someone,  there's been two people now who intend to manufacture something like that,  but if you want to quickly just have it,  just do it yourself.  All the design files on GitHub.  So what kind of packages and pin counts are available?  So the question was,  what packages and pin counts are available for these PADOC things?  I'm not exactly sure.  There's eight pin devices.  I'm not sure if there's six pin devices.  Nothing under six pins.  And it goes up to 20, 24, something like that.  What packages?  Packages.  A lot of packages are mentioned in the data sheets,  but so far, everything I've seen is these SOIC ones.  So that's what's available at typical distributors,  but in the data sheets, they even mention dip variants  and then BGA and whatever.  Maybe, I mean, I guess a lot of people who buy microcontrollers  for one cent by like billions of them  and then can get their custom packaging anyway.  I mean, PADOC sometimes apparently even makes  custom instruction for this customer.  Do you see any usage of the PADOC in the maker scene?  If there's use in the maker scene.  Well, they're cheap. They're low power.  So I mean, this is cheaper than the 7.4 LS, whatever thing.  So you can, I guess there's a lot of uses,  but I wouldn't count pin points or something.  I mean, it's still a bit too big for smart dust  and then you'd need RFID communication  or something like that, which I haven't tried yet.  I mean, the tips themselves don't have support,  but it could probably be done by an external thing.  Or, of course, the classic low power thing combines this.  We use an ESP A266 that sleeps all the time.  This C is active all the time.  And when something interesting is to be reported,  wake up the other thing that takes power.  You're talking about low power,  but so how low power can it get?  To be honest, I don't remember by heart,  so you'd have to look up the datasheet.  But when I first went into this,  I noticed that they actually quite low.  I think they were lower than others.  I'm not sure, but as far as I remember,  you got them in some cases lower than, let's say, an STM8L.  So the low power variant of S.  But I'm not sure about that aspect.  I'd have to look at the datasheets again.  I just remember a year ago when I looked at all the hardware  before I really did dive into doing stuff.  Something close to this question.  Would it be possible to kind of drive them without battery,  like, I don't know, EM or whatever, or sunlight?  Well, sunlight, yes.  You could use a solar cell and a capacitor,  stuff like that. That would work.  Like a solar cell, like you have in these calculators,  or something like that.  How fast and how slow can you run them?  How fast, how slow?  You can go really low.  And I think you can go below a kilohertz if you really want to.  How fast?  Well, the oscillator is at 16 megahertz,  and the system clock would be at 8 megahertz,  and nearly all instructions are single cycle.  Except for those that access 16 bit words in memory,  those are two cycles.  Okay, that's it.  Fortunately, no hands up and time's up as well.  Thank you.
paduak_toolchain_0_155.png paduak_toolchain_156_1067.png paduak_toolchain_1068_1823.png paduak_toolchain_1824_7031.png paduak_toolchain_7032_9083.png paduak_toolchain_9084_9143.png paduak_toolchain_9144_11411.png paduak_toolchain_11412_13439.png paduak_toolchain_13440_13571.png paduak_toolchain_13572_14387.png paduak_toolchain_14388_15131.png paduak_toolchain_15132_15203.png paduak_toolchain_15204_15599.png paduak_toolchain_15600_17363.png paduak_toolchain_17364_18635.png paduak_toolchain_18636_18779.png paduak_toolchain_18780_18827.png paduak_toolchain_18828_24011.png paduak_toolchain_24012_24059.png paduak_toolchain_24060_25319.png paduak_toolchain_25320_25391.png paduak_toolchain_25392_26123.png paduak_toolchain_26124_26183.png paduak_toolchain_26184_27683.png paduak_toolchain_27684_27743.png paduak_toolchain_27744_29651.png paduak_toolchain_29652_30059.png paduak_toolchain_30060_30119.png paduak_toolchain_30120_31271.png paduak_toolchain_31272_31643.png paduak_toolchain_31644_31715.png paduak_toolchain_31716_32123.png paduak_toolchain_32124_32879.png paduak_toolchain_32880_32939.png paduak_toolchain_32940_32999.png paduak_toolchain_33000_45719.png paduak_toolchain_45720_45839.png