# Shenzhen I/O: Color-Changing Vape Pen

Welcome back to china and our electronic building company. This time we got a contract with Cool Dad to make a color-changing vape pen – or rather millions for all his fans, so let’s see how we can implement that.

The specs here says that we will get a packet over radio which is either -999 which means that we should just sleep or it is four values with the meaning red, green, blue, duration. Which means the intensity of the 3 colors and the duration to hold it.

It also says that if we get a new instruction while we are currently running, we should override it. However, it only happens in the test set if the duration is 999. Otherwise it seems to run out.

## Structure of the solution

From the problem it is clear that we need 3 simple outputs to control the led. And this time we cannot use the DX300 trick. Because we need the value of the signal, not just 0 or 100. So we need at least to micro controllers.

I have chosen a solution that have the structure like this

So if we can build a color-changing vape pen with that structure, we would end at 8￥for the cost. I do know that there exists 6￥ solutions out there, but I haven’t been able to condense the problem into two MC4000.

## Coding a color-changing vape pen

The mc4000 code I chose as simple as I can.

```  slx x0
mov x0 p1
```

All it does, is to sleep until it receives something on the xbus and pass it on to p1 as a simple output.

The MC6000 is a little more tricky. The structure of that code is a little bigger. It goes something like

```Read the first value from x1
Test if the value is -999
if not then set the red led to that
read and set green and blue
sleep for the duration specified unless it is 999
If 999 sleep 1 and try again
```

And how exactly do we fit that into 14 lines of code? Like this!

```  mov x1 dat
tgt dat -100
+ mov dat x0
+ mov x1 p1
+ mov x1 p0
+ mov x1 acc
+ tlt acc 999
+ slp acc
+ mov 0 p1
+ mov 0 p0
+ mov 0 x0
slp 1
```

It wasn’t until I started writing this post that I got the last bits and pieces sorted out for this problem. Among the issues was that I checked the acc every run through, instead of making that a condition I checked only when I set the leds. That last change cut the energy almost in half.

The solution looks like this once it is implemented

It solves the problem in

Cost: 8￥
Energy: 238
Lines of code: 14

Did you do it better? Can it be done better? I know it can be done at a lower cost, but I don’t know of solutions using less power or lines of code.

### Posted by Kristian

Parabellum

Hi Kristian,

Just to let you know that you can save one line (and its associated power) by clearing both P0 and P1 at the same time, using [ mov p0 p1 ] instead of [ mov 0 p0 / mov 0 p1 ]

(reading a port that was in write mode will reset it to 0)

sec1

the question is what happen for example if the pulse is 50 ? and you got a “packet” ?
that should fail in: slp acc…

Anon

What sec1 said seems to be true. There are only interrupts for 999 pulses during the test runs (as of today). If a packet was sent with 998 as pulse length, it would sleep for 998 steps and not accept another packet during that sleep. For the test to be robust, an interrupt for a shorter pulse length should have been added (to match the specs).

mister majister

What sec1 is true. If an incoming packet had a pulse length of anything less than 999, e.g. 50, that 50 step sleep couldn’t be interrupted. As of today, it works in game because the test runs only interrupt a packet if it had pulse length 999.

mister majister

awesome it works great! thanks a lot!

Chine

This solution is a hack that only works because of an oversight in the testing data. It does not meet the design requirements.