Shenzhen I/O: The Engineer's Blog

The Something Awful Forums > Discussion > Video Games > Let's Play! > Shenzhen I/O: The Engineer's Blog

Ibblebibble: Nov 12, 2013

I'll be honest, I've been speaking Mandarin for ages and I've always pronounced it like somewhere between 'ts' and 'jj' in Korean. Might just be a Southeast Asia variant.

# ? Aug 23, 2018 10:27

Adbot: ADBOT LOVES YOU

# ? Apr 26, 2024 12:15

Quackles: Aug 11, 2018; Pixels of Light.

Self-Driving Car Stuck In a Loop? You May Be Entitled to a Settlement

Before I moved to China, I was never really in a position to afford a self-driving car. I guess it's a bit of a blessing in disguise, with this sort of thing going on.

I'd joke that bicycles are the way of the future, but the air quality readout on my tablet menu is telling me that that's a really bad idea, at least in Shenzhen.

The_White_Crane posted:

The best advice I heard for an English speaker emulating a Chinese "zh" was to use the sound that is in the middle of "pleasure" or "leisure". Though I expect that depends on what your particular dialect of English is.

Ibblebibble posted:

I'll be honest, I've been speaking Mandarin for ages and I've always pronounced it like somewhere between 'ts' and 'jj' in Korean. Might just be a Southeast Asia variant.

I've mostly been pronouncing it... OK, so you know how there's a 'juh' sound if you say 'Japan'? Or there can be. I've been pronouncing the 'zh' like that, maybe a little more blended with the 'en' at the end. So it's more of a... "Shen-j'h-eh-n".

I'm not exactly a linguist or anything, but so far so good.

# ? Aug 23, 2018 11:20

Quackles: Aug 11, 2018; Pixels of Light.

Infrared Sensor - IMPORTANT

These jobs are getting a bit more complex. Not only do I have the sensor to deal with, there's also three other inputs that are in the form of self-contained parts: two dials and a real-time clock. (I can move the dials and the clock wherever I want on the board, at least.)
The job is complex enough that it almost looks like I'll have to use two MCs directly connected together (something I've been low-key dreading learning to set up). However, while I'm pretty sure I could direct-connect two MCs, one line in the specs means that today is not going to be that day:

"Whenever the device is armed and the sensor reads at or above a value of 20, the alarm output should be active."

And as in... AND gate!
With that in mind, here's my first attempt.

This is pretty straightforward, really. The upper MC turns its output on if the sensor is 20 or over. The lower MC turns its output on when the clock matches the On Time dial, and back off when the clock matches the Off Time dial. The AND gate turns on only if both MCs are on at once - and that's the cue for the alarm.

The spec strikes me as the type of job you could overthink pretty easily - mostly when it comes to the real-time clock. A logical (but painful) approach would be to make the timer MC check if the current time on the clock was between the 'on' and 'off' dials... each cycle. Which would require some extra math in case the Off dial is set to an earlier time than the On dial, like in the image.
I'm not gonna try to implement that here. I'm pretty sure this design is more efficient.

[ ~ ]

I've had another look at the design, and I realized you could probably fit the logic on these two MC4000s into a single MC6000. Let's try it out and see how it compares.

The updated design worked even better than I thought! The top four lines (which keep track of the clock) now set dat on or off instead of an output pin. From there, it's just a matter of testing whether dat is on and then if the sensor is reading heat, and moving the appropriate value to the alarm output (through an output expander, as I'm out of simple I/O ports again).

The simulator reports this version's power usage is about the same as the other (average 358 units - the original averaged 362), and I've saved �1.

Wait, we're becoming a defense supplier?

OK, so... I did come to China to make things. And a good number of the things I've helped make so far have been... junk, basically. And I wouldn't mind if I ended up getting jobs at Longteng that are a little less ignoble. It's just... I'm not sure I want it to turn into making just military gear or whatever.

I could have stayed in North America for that.

P.S: Here's the clock's datasheet.

I'm going to start organizing these datasheets into their own post on this blog, so people can refer to them all in one place, if they want to. I've just added the DT2415 (clock) to the list.

While we're talking about the clock, it's nice to see a few chips being made back in NA for once. Maybe I could convince 诚尚Micro to outsource production of their MCs to the USA. They could save a fortune in labor costs...!

Quackles fucked around with this message at 00:19 on Aug 28, 2018

# ? Aug 23, 2018 11:20

Pierzak: Oct 30, 2010

Next stop: design a murderbot.

# ? Aug 23, 2018 18:27

TooMuchAbstraction: Oct 14, 2012; I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.; Fun Shoe

Pierzak posted:

Next stop: design a murderbot.

acquired is a simple input that indicates the presence of a target.
scream is a standard input that measures volume of screaming detected.
stab is a standard output that controls stabbing depth of an attached knife.

# ? Aug 23, 2018 18:51

Carbon dioxide: Oct 9, 2012

TooMuchAbstraction posted:

acquired is a simple input that indicates the presence of a target.
scream is a standard input that measures volume of screaming detected.
stab is a standard output that controls stabbing depth of an attached knife.

Do you have stairs in your house?

# ? Aug 23, 2018 19:17

Quackles: Aug 11, 2018; Pixels of Light.

Working Remotely

I do hope her car's not in a Rogue Loop or anything.

Pierzak posted:

Next stop: design a murderbot.

I know you're joking about this, but if they do actually ask me to design one, I'm quitting on the spot.

Carbon dioxide posted:

Do you have stairs in your house?

I am protected. Guess how you get to my (21st floor) apartment?
_{Yes, there's also an elevator.}

# ? Aug 24, 2018 11:00

Quackles: Aug 11, 2018; Pixels of Light.

Virtual Reality Buzzer

Ooh, this seems like a cool idea. And� man, I gotta congratulate David in person when I next see him!
Now, let's see what the specs are for this thing.

Uh-oh.
The bit with the radio seems straightforward. That's not the problem. As the datasheet says...

quote:

Reading from the C2S-RF901 when no data is available will yield a value of -999 instead of blocking until data arrives (which is typical XBus behavior). With the C2S-RF901, you can keep working while you wait for data to arrive!

What the problem is is that the buzzer isn't a straight on-off output like I expected. You have to pulse it. And 'off' packets can come in at the end of a pulse or right before the beginning of the next one, so it looks like ignoring input until the start of a new pulse is right out.

I think the best way to do this might be to join two MCs together (I knew this'd be the case sooner or later). MC #1 samples info from the radio, and sets its output pin to on or off depending on whether the buzzer is supposed to run. MC #2 pulses the buzzer whenever its input pin is on.

Seems pretty simple, when broken down. What could go wrong?

[ ~ ]

This is the first prototype. It behaves exactly like I described above (the tcp in the first MC lets it check for 0, 1, and -999 without having to store the value from the radio), but you might notice something strange about the second MC.
It turns out there's something I didn't know, or didn't realize, about chip timing:

Suppose you have two MCs connected two each other, by simple I/O ports. Chip #1 sends a value to Chip #2 midway through its script.
Chip #2's script is still running while Chip #1 gets its value ready to send.

Let's say Chip #2 is supposed to read the value that Chip #1 sends. If the "read data" instruction is earlier in Chip #2's script than the "write data" instruction is in Chip #1's, the write will happen after the read and the read will get the old value from the pin.

This is what happened to me while I was building the prototype. The effect was to make the buzzer start pulsing late.

This is what the 'nop' instructions are for in MC #2. 'nop' stands for "no operation" - literally, "do nothing". They're just there to make MC #2 wait for MC #1 to tell it what to do.
There's an unfortunate side effect of 'nop'. Unlike 'slp' instructions, 'nop' instructions do consume power at the usual rate. I'm paying electricity to have the chip stand around idle, and it shows. The simulator says the design has an average power usage of 348 units, which feels kind of high for this application.

There has to be a better design out there - but what? I'm going start by going back to the drawing board and trying to do it all with just one MC, maybe a MC6000. The script'll be a bit more complex, but it'll almost certainly be more efficient.

[ ~ ~ ]

Here's what I came up with. It's 10 lines of code, so it does need the MC6000, but the simulator says it's more efficient (284 average power - about a 20% savings over the original). Slightly cheaper, too, so that helps it as an impulse buy.

The first few lines are like MC #1 from the original prototype - testing the radio input, then setting dat to indicate whether the buzzer's on or off. acc is used to store the current state of the buzzer - it's set to 100 when the buzzer's switched on, set to 0 when it's turned off, and pulsed with the not / moved to the output the rest of the time.
I'm still not that satisfied with this design, though I can't see a good way to improve it. It looks like you do have to check the radio every cycle to be able to stop the pulses on time, and that's the real stumbling block here... right?

Let's send it out and see what response I get.

Just a note: that's David's first response, and it does work great for him 'cause he's got a quality headset. Regarding selling it to act as an accessory, David did note that some of the lower-powered VR headsets on the market might not quite be able to drive the current version's power requirements - the device needs to use at least 30% less power* to be compatible with everything. It feels like a better-optimized version is out there somewhere... but how?

_{*About 200 units or less, on average.}

Readers, can I ask for your help with this?
(I'll post a Engineer's Corner about the ways you can wire MCs together once we get this sorted out.)

Quackles fucked around with this message at 00:19 on Aug 28, 2018

# ? Aug 24, 2018 11:00

pumpinglemma: Apr 28, 2009; DD: Fondly regard abomination.

I see a way to cut the cost and maybe the power - you could replace dat's role by p0, throw in an AND gate between p0 and p1, and switch out the MC6000 for the cheaper model. The code would look something like this:

tcp x1 0
-jmp pulse
+mov 100 p0
+mov 100 acc
mov 0 p0
pulse: mov acc p1
not
slp 1

But I certainly don't think that would give a 30% reduction.

# ? Aug 24, 2018 11:56

RichardA: Sep 1, 2006; .; Dinosaur Gum

Quackles posted:

Readers, can I ask for your help with this?

Hint1: In this design you never receive two signals in one time-step
Hint2: The radio has an internal buffer.
Hint3: Consider the possible timing for the off signal in a pulse.
Solution: A pulse is mov 100 p1, slp 1, mov 0 p1, slp 1. You don't need to check between the two sleeps - if the off occurs during the gap it would result in a output of 0 anyway.

Also in the Infrared Sensor it might be possible to fit in a slp acc with acc being the time until the sensor is armed instead of looping and checking each time-step.

# ? Aug 24, 2018 13:55

Sydin: Oct 29, 2011; Another spring commute

I managed to get a design down to 180 power. Code is at the bottom but if you just want a hint: No signal (-999) is your downtime and you want as little as possible happening when receiving it to conserve power. In particular, you shouldn't need to do any mov operations unless the buzzer is on.

mov x0 acc
tgt acc -1
+ mov acc dat
teq dat 1
+ mov 100 p1
+ slp 1
+ mov 0 p1
slp 1

Sydin fucked around with this message at 15:51 on Aug 24, 2018

# ? Aug 24, 2018 15:44

pumpinglemma: Apr 28, 2009; DD: Fondly regard abomination.

Hold on, something weird is going on here. If you miss the "off" input on x0 before outputting 0 on p1, you'll be doing the right thing for that time step, but won't you then continue pulsing when you should have stopped?

# ? Aug 24, 2018 16:11

Sydin: Oct 29, 2011; Another spring commute

I realize I said You shouldn't have to do any mov operations, when the very first instruction in my setup that always runs is a mov operation. Nothing like trying to explain code in cryptic hints at 7AM :downs:

That said I messed around with it a bit more and managed to get power all the way down to 146. I even managed to shrink the code down to 7 lines and remove the need for dat so it can use an MC4000 and save two bucks:

tgt x0 -1
+ not
teq acc 100
+ mov 100 p1
+ slp 1
+ mov 0 p1
slp 1

# ? Aug 24, 2018 16:22

TooMuchAbstraction: Oct 14, 2012; I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.; Fun Shoe

It bugs me that you can use nops to precisely align instruction execution timing across two different chips. That doesn't feel very realistic to me.

# ? Aug 24, 2018 19:18

Carbon dioxide: Oct 9, 2012

I think a much more sensible way to do this than using nops is by using the X-bus because an X-bus connection between two chips will block the reading chip until the writing chip is ready to send something. I wonder how much power it would save to take the prototype and change nothing other than making the inter-chip connection using the X-bus and removing the nops.

# ? Aug 24, 2018 19:45

Grayshift: May 31, 2013

Power usage down to 146. Still not lowest bar on the histogram though.

Strat: Uses/abuses the fact that all non -999 inputs can be considered toggles rather than sets in the test data. 0 = 1!

tgt x0 -999
+ not
teq acc 100
+ mov 100 p1
+ slp 1
+ mov 0 p1
slp 1

This kind of solution has always made me feel there's a missed element that would introduce even more replayability to Zachtronic game levels - a "quality" ranking based on whether your solution passes just the bare minimum test cases, and higher quality grades being granted on optionally passing increasingly more rigorous test cases. Whether your design is cheap Chinesium crap or precision German engineering. Like in the Baron von Schnapps puzzle, my solution falls apart if there's ever a test case where both the Point and Foul buttons are pressed on the same cycle. But there isn't, so I get away with it!

Edit: Thinking about the quality grading more, I can sort of see why it might not be a great idea. As the stringency of the requirements increases solutions would tend to converge and those clever hacks around recognizing patterns in the input data would disappear. Having the most freedom in the bargain-bin quality grade means it would always be the most interesting category. I don't think it would be a bad idea, the higher quality grades would always just be optional.

Grayshift fucked around with this message at 20:04 on Aug 24, 2018

# ? Aug 24, 2018 19:56

TooMuchAbstraction: Oct 14, 2012; I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.; Fun Shoe

You can optimize for different things. A category that's all about minimizing power requirements, one that's about passing more complex test scenarios, one that's for minimizing component counts, etc.

# ? Aug 24, 2018 20:17

EponymousMrYar: Jan 4, 2015; The enemy of my enemy is my enemy.

Infinifactory, the only Zachtronic game I own and kinda enjoy does that. There's separate achievements for each optimization in a level, considering that it's outright impossible to fully optimize some things at the same time.

IE: when optimizing a factory for time you'll need to use more blocks so you can do multiple things at once, which is the exact opposite of optimizing the footprint (minimizing the amount of blocks in your solution.)

# ? Aug 24, 2018 22:03

mercenarynuker: Sep 10, 2008

I don't understand a dang thing in this LP because I'm not a programmer, but I'll be damned if I can't look away. I know everyone is posting streamlined elegant solution ideas, but could we see some kind of burly, over-engineered, trashy solution to one of these as well?

# ? Aug 24, 2018 22:34

TooMuchAbstraction: Oct 14, 2012; I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.; Fun Shoe

mercenarynuker posted:

I know everyone is posting streamlined elegant solution ideas, but could we see some kind of burly, over-engineered, trashy solution to one of these as well?

That's pretty much what the first solutions in each update have been. Maybe not as wasteful as I think you're imagining, but a straightforward, unoptimized approach to the problem.

# ? Aug 24, 2018 23:14

GuavaMoment: Aug 13, 2006; YouTube dude

Grayshift posted:

Edit: Thinking about the quality grading more, I can sort of see why it might not be a great idea. As the stringency of the requirements increases solutions would tend to converge and those clever hacks around recognizing patterns in the input data would disappear. Having the most freedom in the bargain-bin quality grade means it would always be the most interesting category. I don't think it would be a bad idea, the higher quality grades would always just be optional.

I remember a post from the games thread. Every person has 3 solutions to every level in this game - what the customer wants; ehhh this assumption makes my life easier; and gently caress IT, IT PASSES CERTIFICATION, SHIP IT.

Sometimes the first one isn't possible...

# ? Aug 25, 2018 00:37

Sydin: Oct 29, 2011; Another spring commute