IT/Software career thread: Invert binary trees for dollars.

I definitely write Python like I'd write a C program, and I've come to learn that is bad. However, I write Python infrequently enough (like 1-2 programs a year, max) that I just don't know if it's worth me learning it deeper than I have.

No, but that could be my six sigma black belt project YESSS

Noodleface said:

No, but that could be my six sigma black belt project YESSS

Click to expand...

Thanks for the PTSD flashback.

I actually had a really great project where interpreting signal data on large files could take 60-90 minutes. My new program interpreted it exactly the same but in under 2 minutes.

I always felt like I should've gotten a fucking award for that

It wasn't regex haha, it was signal data from a radar - no way.

We could never understand why it was so slow before. The original was in Java and ours was Matlab though so that probably explains 95% of it

Since some of you work with firmware for embedded systems, maybe you can shed some light on this problem I have.

For some background: our company has a data manager that can communicate with a variety of devices from different manufacturers. As one of the developers, I am implementing support for a new device that was requested.

So, this particular device allows their users to update it's firmware remotely. So we are developing the option in our data manager to support this feature.

The update file is encoded as a base64 string, broken into 32kb chunks. We then transmit each of these chunks in a separate message along with an offset until the entire thing is sent.

The problem is, it's not clear to me how this "offset" is computed.

The vendor states:

offset = previous(PKG.block_offset) + previously downloaded data quantity

In other words, the block_offset is a number/offset/address that defines the position of the datablock (that would like to be downloaded) in the original/complete data (address/offset)

Click to expand...

So the very first 32kb chunk would have an offset of '0' since we're at the beginning. The device accepts this. Next 32kb chunk I'm sending an offset of 32769 (32768 + 1) but the device NAKs us.

Any clue what I'm doing wrong? And this is all the information that was given to us. No examples or anything and the vendor is difficult to communicate with.

Wouldn't you just measure the size of the last transmitted chunk and start at that +1?

Deathwing said:

Time to bust out your oscilloscope! I'm assuming you've tried different offsets around 32kb, testing for ++ errors somewhere in the code. My initial guess is that the initial communication isn't being handled correctly to leave continued communication as a possibility. Is this SPI or I2C?

Click to expand...

Hah. Fortunately I'm not working that low level. Communication is done via a TCP/IP connection and the protocol is XML-based.

alavaz said:

Wouldn't you just measure the size of the last transmitted chunk and start at that +1?

Click to expand...

Right, that was my interpretation but it ain't having it.

Why is the offset 32769? Where's the +1 from?

Yeah I guess if the formula is previous + current you wouldn't want to put in the +1. I was assuming he had already tried without incrementing though. I'd try setting the first block to 1 as well.

alavaz said:

Yeah I guess if the formula is previous + current you wouldn't want to put in the +1. I was assuming he had already tried without incrementing though. I'd try setting the first block to 1 as well.

Click to expand...

Yeah, I've tried several variations. Nothing works. I thought i may have missed a common approach used for this stuff. I guess I'll just have to ask for an explicit example from them.

Common approarch is just start at 0 and increment offset by block size

Only caveat are if they have header information or a wrapper on the chunk you need to split off. Other thing that's possible is they might not start at 0 or 1, could be funky.

Finally, it might be NAKing if it doesn't like the data you sent

One other thing I thought of, make sure there isn't a firmware update mode command you need to send first