YG's 16bits Relay Electric Computer, rebooted

Similar projects worth following
For administrative reasons, I shelved the project "YGREC16 - YG's 16bits Relay Electric Computer". All the background is still available there and I continue working here instead.

This project is the first to implement the ideas of AMBAP, using old russian SPDT relays.
This is an experimental architecture, surfing the neovintage and electropunk wave that imagines a world without transistors. Old technologies can still yield new techniques, such as the Capacitively-Coupled Pre-Biased Relay Logic (CCPBRL), MUX trees with balanced fan-in, a new algorithm to compute the Game of Life, and I refine the YGREC's architecture!

It's also a warning for the young generations : Kids, don't waste your time with SPDT relays !
Use DPDT instead ;-)

You will find a lot of background information in #AMBAP: A Modest Bitslice Architecture Proposal and #YGREC16 - YG's 16bits Relay Electric Computer, this new project contains the latest developments since April 1st.

1. Evolution of the architecture
2. DRAM (again)
3. PROM boards
4. Assembler and disassembler
5. I hope that's enough
6. First DRAM array prototype
7. The Program Counter's circuit
8. Tubular bell
9. Flip Dots !
10. Electromechanical User Interface : the Assembler board
11. How to drive РЭС15 relays with a computer ?
12. Programming the YGREC
13. Carry chain considerations
14. I hope that's enough this time
15. The instruction register (cont'd)
16. Now it should be enough
17. I can see now

Let's build a computer. A funny computer, that must be ridiculous ! Ridiculously slow (20 IPS ?), ridiculously greedy ( >200W), ridiculously noisy (OK, that's actually desirable), ridiculously incompatible (it's a brand new architecture called YGREC that I develop at the same time), ridiculously limited (512 words of RAM, a bit more instructions), ridiculously unreliable (I added 2 parity bits), ridiculously useless (except to prove my point that ridicule doesn't kill)...

It started almost as a joke one year ago with #SPDT16: 16-bits arithmetic unit with relays but the joke was on me and the fun, the learning, the charting of new design spaces (with the progressive invention of CCPBRL and balanced command trees, to name only a few) have slowly changed my approach and fueled my perfectionist leanings.

Today (20170404) I have a complete architecture, an instruction set, all the needed relays, and I continue to put things together in the next logs.

The YGREC architecture is pretty simple and designed to use as few resources as possible, yet run the #Game of Life bit-parallel algorithm efficiently (though it's not the original goal or purpose, there was none in fact, it was just "loooook those cute relays must be fun to use!")

The datapath is shown below : The 16 registers (including PC) are accessed as the SRCX operand while only 8 registers are read as the SRC operand (because such a large MUX uses a LOT of relays). The SRC operand can be shifted/rotated, or substituted with an immediate value from the opcode. Both operands are then processed in the ALU (either in ROP2 mode, where all combinations are possible, or in Add/Sub mode where comparison, carry and other things are possible). The result is checked for being zeroed, and sent back to the register set.

The register set maps memory addresses, memory data, the Program Counter and Input/Output ports. Only R1-R4 and T1-T3 are "standard registers", making the YGREC a hybrid architecture: it looks like some classic RISC and also behaves like TTA. There is indeed no actual opcode, only 32 combinations for the ALU and 16 Shift/Rotate combinations to care about. The architecture is highly orthogonal, all the usual operations can be achieved with a combination of the available fields and special registers. All the instructions are predicated, except CALL which replaces the condition "NEVER". In this case, the result goes to PC, while PC+1 goes to the register set.

The YGREC can be reduced to MUXes and DFF registers (which can also be made with MUXes). This maps perfectly to dual-throw relays !

Some characteristics (if you haven't read the other project) :

  • Based on a bitslice architecture, with 18 bitplanes (16 data bits and 2 parity bits, one bit per byte)
  • Uses about 3000 РЭС15 relays (low voltage, circa 1989), a ton of diodes (but not for the logic), 10K capacitors for the dynamic RAM and CCPBRL
  • 24-bits wide RISC instructions with predicates
  • integrated debugger and assembler/disassembler "electromechanical UI"
  • multiple power rails (3.3V, 6.6V, 12V, 24V) to reduce currents with long strings of relay coils (a consequence of using CCPBRL)
  • Separate Execution and Control assemblies...
Read more »


DRAM Circuit to simulate with

plain - 5.57 kB - 04/26/2017 at 18:18


View file

  • 3000 × РЭС15 Low voltage, russian SPDT mini-relay
  • 768 × DIP Switches 8 positions
  • 10000 × 100µF 25V electrolytic capacitors 5mm or 6mm diameter
  • 20000 × 1N4148 Diodes
  • 500 × 33 Ohms resistors 1W
  • 1100 × KOA DN5Q24T 18×2×diode array

  • I can see now

    Yann Guidon / YGDES2 days ago 2 comments

      @roelh was suspicious that my "new DRAM array" would work.

      It took him a while and conviction, and it was difficult to wrap my head around it.

      I'm too lazy to finish the prototype, but it would be useless for 2 reasons :

      1. Probing the capacitors would disturb the array and storage
      2. I don't have enough channels to observe a 16×16 array !

      So I resorted to simulation.

      Spoiler alert : @roelh was right. But why ?

      After I did the experiments, I realised that I was influenced by the flipdot array and impressed that it could drive several rows at the same time. Using the re-steering diodes makes sense.

      But the rows are always driven so the current "loop" that roelh identified don't occur. In my case however I leave many rows undriven. And the simulation shows really bad consequences.

      In practice...

      Just go to and "import from local file" the circuit that I have uploaded.

      Click on the push buttons and the SPDT switches to steer the current. You'll see the capacitors' charges vary. I added a bit of ESR to reduce the pulses. Be ready for some ... lag. The simulator gets confused after a few manipulations and I have already encountered errors...

      I have "probed" all the capacitors (with virtual scopes) to check that charging one doesn't influence the others.

      I have chosen a topology of double binary tree because I don't want the data to have too much fanout. Using the recent tree command topologies, the double tree is actually practical and has a fairly balanced fan-in.

      Conclusion : I must reorganise the DRAM geometry.

      The double-tree that selects the row is a big burden which shouldn't increase so I consider reducing the rows to only 8 per bitplane. In parallel, there are 18 bitplanes with 8 rows each, which amounts to 18×14=252 relays.

      As a consequence, the backplane must handle more columns : 512/8=64 columns, or 64 relays. It must withstand the simultaneous switching current of 18×100µF so I consider using a small series resistor to mitigate the transients.

      I think about building DRAM modules made of 8 rows and 16 columns.

  • Now it should be enough

    Yann Guidon / YGDES7 days ago 0 comments

    That moment when you order 5 lots of 2K diodes, and you receive a pretty large reel of 10K diodes.

    "normal" reel size for scale.

    The DRAM should be covered now, and there is only 1 part and 3 soldering joints instead of 4 soldering joints and 2 parts.

    I also received the KOA diodes in SSOP24. The 1100 pieces should be enough for about 730 instructions. Good thing I extended the PC to full 16-bits width :-)

  • The instruction register (cont'd)

    Yann Guidon / YGDES04/20/2017 at 09:41 2 comments

    Here is one of the 24 bits of the instruction register.

    3 relays each amount to 72 relays.

    The instruction bus uses 6V signaling to provide more swing into the capacitor, but not enough to damage the diodes (the KOA diode networks are limited to 7V in reverse polarity).

    The sensor is made more sensitive by charging the capacitor with a higher voltage swing, bringing more charge to upset the coils. The middle point is centered by resistors, but large capacitors are required to keep the ends at a somewhat constant voltage. I got a stock of 1500µ capacitors so the swing ratio is at least 1/10.

    The reduction of the current on the instruction bus is pretty important. If 60mA per bit was required, then a INV instruction (FFFFFFh) would draw 1.5A ! Hopefully this is now reduced to about 10mA, or 240mA for a full FFFFFFh instruction. This increases the longevity of the parts...

    I'll have to prototype the above circuit !

  • I hope that's enough this time

    Yann Guidon / YGDES04/17/2017 at 21:23 1 comment

    I just received a pretty large package.

    That's 750 8-positions DIP switches.

    with 24-bits words, that's approx. 256 instruction words, or 4 boards of 64 instructions...

    Or 8 boards of 32 instructions, to fit in a 16×20cm board :

    However there's a little gotcha:

    The DIP package must be slightly too large because they don't fit well on a 2.54mm pitch board.

    Once again this proves that you must have your definitive parts before you commit to a final design ! I'll have to adjust the snap grid size when I do the PCB layout. This also shatters my hope to make a nice compact prototype, 2.4mm will be lost for every row...

  • Carry chain considerations

    Yann Guidon / YGDES04/17/2017 at 09:48 0 comments

      The incrementer and the ALU are becoming the critical parts of the whole system and the length of the carry chain will affect the operating speed. In itself, the clock speed is not a goal (the thing is already sooo sloooow that you can see it think, which is all the point). However, the faster it runs, the faster it can scan and refresh the memory, which is quit a big deal. If I can manage to get 25IPS (approx 2× faster than the Harvard Mark II), then it still requires 10 seconds to scan 256 words, 1/3 of a minute to refresh the whole 512 words of DRAM. And refresh only happens when the processor doesn't access the memory, a full refresh could last one minute. I haven't yet evaluated the retention time of the DRAM but I feel I'm pushing the design in uncharted territories.

      With 100µF capacitance, a 1µA leakage will make a time constant of approximately 100s which, depending on parts tolerance, where the leaks go, the actual rate and current of leakage etc. This is pretty close to the above quoted minute and I'm concerned.

      The new instruction register introduces a "latched sensor" which has several interesting benefits but one major consequence over the overal design: the processor is now pipelined, with fetch, execution and DRAM cycles being overlapped. The clock sequencing is pretty simple now : 2 phases, which directly drive the temporary storage caps of the DFF. There is no funky sub-cycles anymore. The complexity is now relegated to the software because data access and jumps are now delayed. I should add a 25th instruction bit to tell the program sequencer to wait for one more cycle until data are available...

      The speed is now limited by two main factors:

      1. the carry chain delay
      2. the time to fully charge the latching capacitors of the DFF

      As I have already examined, the charge time depends on several factors, such as the charging voltage and the series resistance, so they can be somewhat adapted. The carry chain length is however a more structural problem. If a relay switches in 4ms, a chain of 4 relays will need 16ms to propagate, and I would ideally keep it under 20ms. Add to this about 10ms to charge the caps then switch them to the coil, and we have about 30ms of cycle time, or 30Hz.

      To reach this speed, the critical datapath must be under 6 relays.

      My problem is that the РЭС has a rather low fanout capability and it wouldn't drive 15 coil loads. I guess a reasonable fanout is 4, though I remember I estimated 3 when I started the #SPDT16: 16-bits arithmetic unit with relays project.

      Of course, less fanout is better and the LSB relay (bit 0) will take all the heat, vibrations and load so it must be particularly carefully designed (or it might break).

      @Tony Robinson has explored a particularly interesting approach: a OR-chain made of diodes that could greatly accelerate the propagation in my case. However the diode drops are significant, let's assume 0.8V for the 1N4148 and this becomes quicly impractical. And the fanout problem is not solved, the first diode will take all the current to drive all the coils in the chain... I could cheat by using high power Schottky diodes though but it wouldn't remove the high current draw when all the chain is ON.

      Apparently I am forced to use a segmented approach. Naturally the 16-bits incrementer is split into 4 equally sized segments, but not identical: the LSB have a high fanout while the MSB have a high fanin. I can also mix with a diode here and there to reduce the complexity/size/cost/consumption a bit. With this scheme, the propagation time might drop to 2 coils delay, but the incrementer will use a LOT of relays...

      The linear approach is slow, the fast approach (O(n²)) is prohibitive, so a hybrid approach is considered, using 4-bits segments. Hopefully, the fanout is not excessive and the cascade time is 4 coils (in the 16ms range).

      I have a drawing in my head, I'll need to refine it...

      Update 20170420: I made...

    Read more »

  • Programming the YGREC

    Yann Guidon / YGDES04/14/2017 at 09:17 0 comments

    So far the instruction format and datapath are well defined and it's time to think about the programming paradigms used by the YGREC.

    The architecture does every important thing (as far as I'm concerned) and I notice that it has no opcode.

    That's a bit unusual though it's reminiscent of the "Move Machine" ou "Transfert Triggered Architecture". Where the TTA/MM starts operation when operands are available and there are only 2 register addresses, the YGREC has 3 addresses and the operation is immediate.

    How should instructions be written ? There are two schools : the algebraic form (used by ADi DSPs) and the direct form (mapping the hardware fields). I like the ADi style (ah, the memories of the SHARC and ADSP2105)

    R1 = D1 or T1 SHR (IFZ)
    but it's more coherent to stick to the representation of the hardware assembler board...
    T1 SHR or D1 => R1  (IFZ)

    That's where I see that I should swap the ALU field and the SRCX field on the assember board. Too laaaaate... But I can move the ADD/ROP2 button. You will not notice much.

    There, I fixed this :

    The disassembly board must also be swapped :

    So there, you have everything clearly laid out, just write the code and enter each column in order, and you have your instruction in binary !

    Almost in the same vein, there is another question : how to encode NOP ?

    Starting with the #YASEP Yet Another Small Embedded Processor I set the following convention:

    • NOP is all-zeroes.
    • INV is all-ones

    NOP does nothing so it should be encoded in a way that does not modify the state of any register. Let's see how each field is affected :

    • SRC, SRCX, DEST = 0 should not trigger a memory access. For now 0000 points to A1 and it's not good, so let's swap A1/D1/A2/D2 with R1/R2/R3/R4.
    • LIRP : should be in PASS mode, R1 is not modified
    • CRSZ field : not affected because LIRP=PASS, but let's say 00=ZERO
    • ROP2 mode should be either PASS_SRC or PASS_SRCX. However these codes are assigned to 1100 or 1010 so two bits must be inverted...
    • The condition could be "NEVER" if there was one anymore so it's "always", so CND=000="always"
    • The Imm flag is 0, which says it's a register source

    In the end, NOP is equivalent to

    R1 PASS R1 => R1

    INV however requires a sort of reset of the program. This corresponds to hitting a place in EEPROM that has not been programmed and reads 0xFFFFFF.

    • The Imm flag is 1, which says it's a IMM16 source, which is set to 0xFFFF. Let's use this as the address to jump to and restart the program. A sort of implicit jump vector.
    • The condition is 111, which is the opposite of ALWAYS. We don't have "NEVER" anymore but we have "CALL" !
    • Call is a bit messy because it swaps the destination register. The result (IMM16=0xFFFF) will go directly to the PC while its old (contents+1) is written to the destination register, which is IO4 for now.
      Nobody knows what is hooked to this output register and it'd be a shame if something happened there. This is easily solved by swapping the IO and the T quatuors of registers, so PC becomes 1111.

    INV is now equivalent to

    FFFFh => PC (CALL)
    And the new register map is:


  • The assembler and the instruction register

    Yann Guidon / YGDES04/14/2017 at 07:24 0 comments

    I just finished the assembler board !

    I had to remove all the diodes and put new ones in the reverse (appropriate) direction.

    I'll need to label the buttons... but it's a hack ;-)

    I also wired everything, which makes the other side quite pretty as well :-D

    The shift registers are in parallel with the buttons, they are not completely wired because I'm waiting for their delivery. The 2×16 outputs drive the 24 bits of the instruction as well as disable the switches (through the small relay). 7 outputs are still available for other functions. It looks a bit like a mess because I tried to map the pins to the actual instruction bit number. There's no magic there, I should draw some schematic though. One day.

    And after all was said and done, I realised I should have put diodes on the outputs of the shift registers...

    Too late, I'll just remove the DIP chips from their sockets when they're not in use :-)

    But now I have to test the board and the instruction register's latch. This means, prototyping the 3-relays sensor and latch...

  • How to drive РЭС15 relays with a computer ?

    Yann Guidon / YGDES04/13/2017 at 07:18 7 comments

    The last log 10. Electromechanical User Interface : the Assembler board raises an interesting and important question : how can I control the relay-based computer with something like a Raspberry Pi ?

    I'd like to control and spy on the machine with a modern computer, replace the DRAM and the PROM with user-controlled modules that emulate them with SRAM, write or read registers, see the result of instructions, upload and save programs...

    I need to interface hundreds of signals from a 3-6-12-24V system (requiring 60mA drive currents) with the meek 3.3V CMOS GPIOs of today's generation.

    The last log implied that the instruction bus would "switch the high side". I already have the signal distribution paths figured out but I didn't think too much about the most favorable direction of the data signals. I just assumed the sense coils to be wired to 0V and the data coming from +Vcc. Simple.


    Then the building of the Assembler board made me reconsider my assumptions because I would like to "upgrade" the board to add a shift register that takes over the switches.

    All the practical electronic/IC solutions I could find are referenced to GND and "switch the low side". The sense relays require some significant current (60mA without prebias). In particular, this part is very well suited to the task:


    This obsolete chip is a 16-channel constant-current sink LED driver in 24-pin DIP. It runs up to 20MHz with 3V-5.5V logic supply but can sink up to 80mA per channel (20V maximum on the pins). I need 1 and half to drive the instruction sense relays... From the lower side.

    I have already wired the diodes of the switches for high-side, I can change them. But the ROM and PROM boards already have some parts in stock, that are meant for high-side switching !

    The solution comes again from exdwh's store !

    Isn't this cute ? Inside the KOA DN5Q24T, you'll find 36 diodes !

    DN5 diode network

    That's a big jump from the previous 2 diodes per package...

    The even funnier thing is that you can configure it however you want, with low side or high side: just connect the appropriate common rail to the proper voltage. The circuit is also (almost) symmetrical so a single footprint/PCB can accomodate both uses, just solder the package in the appropriate direction ! (ooooops I realise now it's a miroring and not a rotational symmetry)

    The leakage is too high and the voltage rating too low to help with DRAM. But if the voltage is kept low enough (less than 7V) this is totally suitable for the PROM boards, as the current is just enough and the spikes shouldn't last long enough to damage the diodes.

    Now, I must find a way to increase the sense coils' sensitivity...

    The current and voltage can be reduced with a switched capacitor cell which is almost the same circuit as the typical latch.

    • The hysteresis is held by 2 coils in series, so there is one output for the datapath control lines, and one for the disassembly board.
    • The middle point is tripped by a capacitor, switched by another relay. Just like the latch circuit.
    • The other side of the relay is held high by a pull-up to 6V. Value: t=RC, R=t/C, the charge is held in a 100µF capacitor (like most others). It must be charged in 20ms, which gives about 500 ohms. Rounding up to 600 Ohms gives 10mA when shorted to 0V, instead of the 60mA we wanted initially... the added diodes will reduce the current a bit more.
    • To increase sensitivity, the sense middle point is held at 3.3V by 2 resistors (on the 0V and 6V rails). In parallel with the resistors, capacitors stabilise the relays...
    • The input is held high by the pull-up, but overriden by the low-side switches (either solder blots, switches, N-channel FETs....)

    The sense coils become "instruction register" (using no less than 3 caps, 3 relays, 3 resistors).


    This is interesting because the capacitor switching can be controlled by the same clock as the register set (when enabled). This creates some pipelining,...

    Read more »

  • Electromechanical User Interface : the Assembler board

    Yann Guidon / YGDES04/12/2017 at 03:48 0 comments

    See log#4: Assembler and disassembler

    Try to do that with a x86 !

    The YGREC's instruction format is so simple that 9 hexadecimal rotary encoders and a few other switches are enough to "assemble" one instruction word. With the help of some diodes, I admit, but nothing crazy and no weird encoding table...

    Luckily I have 4-positions slider switches in stock :-)

    There is the question of how to encode the IMM5 field : with the IMM16 or with SRC+CRSW fields ? In either case, a 2-diodes drop is inevitable. However the IMM16 encoders can't be "split" so I Keep It Simple and remain with the SRC+CRSW solution. Simpler and easier though maybe a bit confusing. You'll get used to it ;-)

    The switches and diodes are soldered. I have chosen a 26 positions connector for ribbon cable, a handy size to transmit 24 bits of instruction, one supply/enable bit and a key (not implemented).

    The 4-positions slide switches are encoded to 2 bits with 4 diodes each.

    I'd like to test the board while it is being wired but I'll have to wait for the build of the disassembly board.

    I notice that I have enough room to add a few DIP chips. I'd easily put some 74HCT595 but they don't provide enough current. Amplifying devices would use much room and need to be "high side". Maybe LED drivers ?

    Whatever solution I imagine, the board should sink the current, because the input voltage is unknown. Electronics needs a ground reference. I also have the STP16DP05B1R in mind, a 16-ports constant current sink LED driver, that can get up to 80mA (I need 60-70mA). It's like a dual 74HC595 on steroids.

    However I have planned from the beginning to have the sense relays ground-based so a higher voltage is required (at least 3V), and I have already bought the dual-diodes for the ROM matrix, connected in the direction of the grounded coils...

    I can spend a bit of time reversing the 40 diodes of the assembler board but the PROM boards will still have the wrong diodes, or require more efforts during soldering...

    Unlike the rest of the system, the instruction input is using unipolar signals, with disconnected=0 and 1 is signaled by a pull-up (through diodes). The current and voltage must be enough to trip 2 relays in series because the disassembler board must intercept the instructions.

    20170413 : I think I've found the solution, see the next log :-)

  • Flip Dots !

    Yann Guidon / YGDES04/11/2017 at 06:32 13 comments

    While rumaging through my stash, looking for electromagnets, guess what I found ?

    Yes, memories from Active Surplus, a now closed Toronto surplus store. Damn, I miss you guys...

    4 individual flip dots, 10×10mm, that flip at about 1.5V and 70mA (they are measured at 19.2 ohms).

    I might use them for showing status (like Z and C flags) and they are easily interfaced in a CCPBRL way : one leg to 0V, the other leg tied to a capacitor (it worked with 100µF under 3V but 470µ is better) that swings from 0 to 3V... or something like that. Hysteresis is built into the system (through ferrite that stores the magnetic flux) so there is no need to maintain a bias current.

    Which makes me think...

    Without the need to provide bias, a completely electromechanical calculating machine would need no static/constant power !

View all 18 project logs

Enjoy this project?



Ulysse wrote 04/21/2017 at 16:34 point

I love relays.  Bravo !

  Are you sure? yes | no

Yann Guidon / YGDES wrote 7 days ago point

Who doesn't ? :-)

  Are you sure? yes | no

thekidtonystark wrote 04/20/2017 at 23:28 point

Do I have to put everything to a pitch board?

  Are you sure? yes | no

Dylan Brophy wrote 04/11/2017 at 13:15 point

Hey, I noticed you wrote "Kids, don't waste your time with SPDT relays ! Use DPDT instead ;-)". I'm just curious, but why?

  Are you sure? yes | no

Yann Guidon / YGDES wrote 04/11/2017 at 23:46 point

I explained this on the #SPDT16: 16-bits arithmetic unit with relays project :-)

SPDT is one switch per coil, DPDT is 2 switches per coil, better "fanout" and a direct reduction in the cabling and drive current. A MUX or adder uses half the number of relays compared with SPDT. You don't need hysteretic hacks. Etc.

But well, I chose the rope that will hang me in this project and I must stick to it :-D

Learn from my mistakes, kids ! :-P

  Are you sure? yes | no

Hacker404 wrote 04/05/2017 at 10:09 point

You've probably already though of this but ... 

You can get switch banks that are actuated from above rather than from the side. There are press toggles and slide on - off and they will bunch up more closely. 

Are the switches for the bootloader? It would be great if they were. 24 to 32 words could do it or even less with the instruction bit width you have chosen. 

All looks great!!!

  Are you sure? yes | no

Yann Guidon / YGDES wrote 04/05/2017 at 19:29 point

Well, I did the rough placement with the switches I have in stock, and I have 41 of these. what matters is the width, I wanted to see if it fits.

I'm expecting to receive a "suitable quantity" of "normal" switches (I bought the piano because "hey, it's unusual, it could be a lifesaving part, you never know" :-D)

There is no bootloader : execution starts at address 0 and reads whatever instruction is stored in the board plugged in the corresponding slot.

There will be several slots with detachable cards, so you can put "PROM" (programmable with switches) or "ROM" (soldered diode arrays), change their address... Maybe even create a small library (in the physical sense of the term) of routines that you will plug when you need them :-D

But that's for a coming log...

  Are you sure? yes | no

Yann Guidon / YGDES wrote 04/17/2017 at 21:11 point

Look at the latest log, you'll see what I mean with "a lot of switches", as I just received them ;-)

  Are you sure? yes | no

Hacker404 wrote 04/17/2017 at 22:17 point

Wow!! You could put the entire boot code in DIP switches and still have most of them left. 

  Are you sure? yes | no

Yann Guidon / YGDES wrote 04/17/2017 at 22:36 point

I don't consider this as "bootcode" but enough for a small but interesting program :-)

I'll spread the switches over several independent modules so I can pull one, program it and put it back, to test code  before I solder it with diodes...

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates