Luckily I'm currently so swamped with other work, I can't do anything on this WTF looming over my head in the semi-near future...but it's going to hit me eventually. Here's the setting:

Project is to create a tool to communicate with a 3rd party controller (the main controller that controls Elevators). The tool has to perform diagnostics on the system and adjust settings, parameters, etc.

Now, since this controller is 3rd party, available documentation is zero and there is absolutely no assistance available from the original manufacturer. In a related project I have already reverse engineered the communications protocol sucessfully on the packet layer. But the actual parameters, min/max ranges for the parameters, what the parameters do, what parameters exist, what actual messages/commands exist, meanings of status bits in status messages, etc. all that is a big major, yet to be reverse engineered blur.

Up to this point in time, none of this partiuclarly bugs me and is actually fairly normal for me. I'm used to all of the above from the automotive tuning world where I used to write tuning software for GM, Ford and Chrysler and  of course didn't get any assistance from the manufacturers there either. Gotta love it when a bug in your code can make a connecting rod peek through the block...actually had such a bug once (luckily the engine did not break).

Here is however where the WTF's come in.

1 - The system I have to test on is only partially functional. I can't simulate or test all functionality.
2 - The platform for the device I have to work with is based on an Intel 8051. That chip has got to have the absolute worst assembly language i have *ever* worked with. Give me a motorola 6809. Give me a PIC. Give me an ARM. But for crying out loud, keep the frigging 8051 away from me.
3 - The device contains 3rd party software which takes up about 90% of the available 128-byte on-chip RAM. My own code is a function called by this 3rd party software.
4 - Since all the on-chip ram, which would normally be more than enough for me, is all taken up by useless to me 3rd party data I have to use the external ram. Normall a non-issue EXCEPT the 8051 only has two instructions (load/store) to access external ram with. So everytime I want to do *anything* with a variable I have to manually fetch it from external ram, or manually store it to external ram. The normal artihemtic / memory instructions can only address registers or internal memory. Hence my comment above about this being the absolute worst language/chip I've ever worked with. Not to mention code bloat.
5 - The device can't be remotely updated in the field so relasing software updates is impossible. The device only has a 485 port (required to communicate with the controller) and no way to hook it up to a PC without special 485 hardware that most people don't tend to own. Oh and even if that wasn't an issue, I'd have to send out the manufacturer's flashing tool along with the software in Intel HEX format. I may as well just include the source files along with it at that point in time...
6 - Oh, one of my bosses is under the firm belief that this shouldn't take longer than a week or two to have a fully working, 100% compatible tool.

There are a probably a few more things but that's a good list to start...

My normal response when faced with a project like that is to present a first-pass requirements list off to my boss.  In this case something like:

• Functional development environment.
• Tech contact at third party company
• Documentation on needed info

I think you get the idea.

Since your boss seems to think that this is easy (see appropriate Dilbert cartoon) then you're kinda screwed but at least you've documented what you need to make it work.

It's nice to see somebody else who sees the 8051 for the awful mess it is. I had to work with it in a few university classes (EE/CS), and it was thoroughly annoying to do simple things even with all of the on-chip RAM available, and accessing external memory was always a bit of a pain (load address into DPTR register, then do an indirect load/store). I suppose part of the problem was that I was already fluent in 6502 assembly at the time (in which most of said operations were trivial to do, and significantly faster), so I was constantly having to metally switch between the two.

In a later class, I worked with the PIC16F84 which, oddly enough, wasn't as difficult to work with - I suspect it was because it was so radically different from conventional microprocessors that I had to start from scratch, so I didn't have conflicting knowledge popping up constantly.

I agree with whatever Quietust just posted above.

There is pretty good C dev environment for those 8051 beasts. I forgot what it's called (its project files have .UV2 extension or something like that).

 Your BEST defence against your boss is to outline exactly what needs to be done (in detail) as best as you can get it. Then show him the list (kind of like dropping a box of papers on his desk telling him either we write a system or he has to manually go though all of em) and start giving realistic or passimistic estimates. It usually works.

Kermos:

2 - The platform for the device I have to work with is based on an Intel 8051. That chip has got to have the absolute worst assembly language i have *ever* worked with. Give me a motorola 6809. Give me a PIC. Give me an ARM. But for crying out loud, keep the frigging 8051 away from me.

You're setting a pretty high bar there- the 6809 and the PIC are both emminently programmable. I once spent weeks writing ML for the 6809 (CoCo graphics library) for no purpose other than nostalgia / recreation. Right now, I am trying to finish my real work (.NET / WPF - ugh) so that I can do some recerational PIC programming. If Intel ever makes anything half as user-friendly as a PIC or a 6809, it's a fair bet they stole the design.  

I've never done 8051 programming but I work with a guy who does. I really think his rationale is to obfuscate certain parts of the system which would supposedly not be secure on a PIC. (Of course, I don't necessarily buy this argument... I pretty good with PICs but I've never been able to steal anyone else's code).

Kermos:

5 - The device can't be remotely updated in the field so relasing software updates is impossible. The device only has a 485 port (required to communicate with the controller) and no way to hook it up to a PC without special 485 hardware that most people don't tend to own.

Hmm... RS485 doesn't scare me that much if the PC has an RS232 port. Am I missing something? When I do serial communications it typically involves an industrial PC; do these have more RS485 support than a typical PC (which is technically RS232)? Or are you just pointing out that most modern PCs don't even have RS232 support?

Incidentally, the more I work with RS485 the less I like Ethernet. Amazingly, Microsoft officially deprecated RS232 in 1997, which to me just typifies their affection for bloatware. Those serial protocols are pretty much the core of computer engineering. There timeless in my view, not subject to obsolescence by USB or (ugh) Ethernet.

Kermos:

6 - Oh, one of my bosses is under the firm belief that this shouldn't take longer than a week or two to have a fully working, 100% compatible tool.

Let me guess, he's an "idea man" whose visible role consists of spouting out supposedly brilliant ideas and then hectoring you into making them work in the exact form he imagined. Yeah, I really can't stand that kind of boss. Their performance expectations seem to be based on "24" or "CSI," where everyone has a grandkid that can game the NASDAQ while whipping Steve Wozniak's ass at chess and cracking an iPod.

WTF-y possible workaround for #3: when your code is called, move some of the 3rd party data off-chip and use that memory. Just re-load that data before returning. Depending on how much memory access your function does, it might well be faster than putting your stuff off-chip.

lolwtf:

Suppose due to some quirk in the code that you missed when disassembling it, the elevator decides to accelerate straight down at some insane speed?

Not to worry: all software includes a mop and bucket as part of the "support contract". 

lolwtf:

So this device controls elevators, and you have no support or documentation? Sounds dangerous. Suppose due to some quirk in the code that you missed when disassembling it, the elevator decides to accelerate straight down at some insane speed? If I were you I'd point that out, hopefully something can be done to improve the situation.

Unlikely; the elevator brakes are pretty good at preventing that kind of thing.  What's more likely is a misguided attempt to make the elevators run "faster" will mean that they never stop exactly at the floor level and the hardware interlocks prevent the doors from opening.  You need a crash-test dummy that doesn't mind being locked in the elevator while you de-bug the program. 

The other tenants in the building might get upset if you're locking out the elevators for more than an hour or two.  Couple of days?  Unless the boss is willing to invest some serious money in this project, it sounds like it's on the fast track to WTF.

lolwtf:

So this device controls elevators, and you have no support or documentation? Sounds dangerous. Suppose due to some quirk in the code that you missed when disassembling it, the elevator decides to accelerate straight down at some insane speed? If I were you I'd point that out, hopefully something can be done to improve the situation.

I've seen much, much worse in the world of industrial controls. At least the elevator can't move in open space where it can do real damage; and at least it doesn't use ASP.NET or Java. The bottom line is that software engineering is still in its infancy, like medicine was when it was practiced by barbers. (The "barber-surgeons" in this analogy are the electrical engineers, managers, degreeless grandkids, etc. trying to design software without formal CS training).

Hopefully the elevator (like all good control applications) has some minimal hardware failsafes to keep it from chewing up any puppies, babies, or $100 bills.

Jimmy Savile:

Is this some kind of joke, its not 1986 any more!

Yeah, because everything should be run by needlessly powerful computers, and there's absolutely no market for low cost, low power, reliable electronic devices that just do the job they're designed for.

beau29:

Hmm... RS485 doesn't scare me that much if the PC has an RS232 port. Am I missing something? When I do serial communications it typically involves an industrial PC; do these have more RS485 support than a typical PC (which is technically RS232)? Or are you just pointing out that most modern PCs don't even have RS232 support

Well I suppose you could make 485 work with a RS232 comport if you can directly control the pins of the RS232 port. However, as most PC's don't even have a RS232 port, I don't see that working all too well with some random 3rd party USB port attached.

beau29:

Let me guess, he's an "idea man" whose visible role consists of spouting out supposedly brilliant ideas and then hectoring you into making them work in the exact form he imagined. Yeah, I really can't stand that kind of boss. Their performance expectations seem to be based on "24" or "CSI," where everyone has a grandkid that can game the NASDAQ while whipping Steve Wozniak's ass at chess and cracking an iPod.

Naw, he isn't quite like that. Sometimes he can actually be a pretty decent person to work with. However, the problem is his complete lack of understanding of how anything like this works. In his mind, if you press a button on the device, all it needs to do is send a "number" which button was pressed to the controller to make it do whatever you want to do. Everytime I try to explain to him what it will actually take the only answer is.."Oh nothing to it!"....right.

The bigger WTF is that we actually have the in-house capabilities to design our own hardware with a decent CPU and all the necessary peripherals to create a really nice tool. I could even design an enclosure for the thing, I'm quite decent with Solidworks. However, he doesn't want to do that because it's too expensive. Between prototyping costs, tooling costs, etc. it'd cost more than we can make off it as he's got a whole 5 people who wanna buy the tool after I'm done with it! No, 5 isn't a typo nor is it missing any digits.

joemck:

WTF-y possible workaround for #3: when your code is called, move some of the 3rd party data off-chip and use that memory. Just re-load that data before returning. Depending on how much memory access your function does, it might well be faster than putting your stuff off-chip.

While theoratically possible the problem with that is that some of this data is needed during interrupts and there is little to no information what memory areas are needed where and when. Just simply "from address X to Y is reserved".

lolwtf:

So this device controls elevators, and you have no support or documentation? Sounds dangerous. Suppose due to some quirk in the code that you missed when disassembling it, the elevator decides to accelerate straight down at some insane speed? If I were you I'd point that out, hopefully something can be done to improve the situation.

Well I'm not directly modifying the elevator controller, not going anywhere near that code. I'm just working with the tool to adjust the parameters and do diagnostics in case of problems. It's still very possible though that due to a bug in my code that a wrong parameter could get adjusted incorrectly and weird things could happen. Yup, I definitely see that as a possibility...

drinkingbird:

Jimmy Savile:

Is this some kind of joke, its not 1986 any more!

 

Yeah, because everything should be run by needlessly powerful computers, and there's absolutely no market for low cost, low power, reliable electronic devices that just do the job they're designed for.

His attitude really pisses me off as well... you can't just assume resources are endless because it's 2008. All these people walking around saying how nobody needs to learn C, or pointers, or assembly, or optimization any more (and that everything can be written in C# / Java / Python) are the same people producing crappy bloatware like Word, Outlook, and IE.

If you confront them with reality, these people will admit something like "oh, well sure, if you're writing some oddball embedded app, then maybe you need to worry about that stuff, but for typical desktop programs it's not necessary." Of course, as a result most desktop apps are agonizingly slow.

I remember using an Apple ][ at school and experiencing keystroke lag for the first time. I was used to the faster TI-99/4A, and I rightly associated this lag with primitive, overtaxed hardware. The fact that we still have to deal with keystroke lag (which, if anything, has got steadily worse over time) in 2008 makes me want to vomit.

I'd venture to say that the majority of CPUs out there are 8 or 16 bit devices running object code that came from an assembler of C compiler. You business programmers, with your profligate refusal to collect your garbage or lift a finger in the way of optimization, could learn a lot from the people who program these devices.

beau29:

His attitude really pisses me off as well... you can't just assume resources are endless because it's 2008. All these people walking around saying how nobody needs to learn C, or pointers, or assembly, or optimization any more (and that everything can be written in C# / Java / Python) are the same people producing crappy bloatware like Word, Outlook, and IE.

While I agree with the sentiment, you realize Word, Outlook and IE aren't exactly written in Java, right...?

beau29:

...............

I'd venture to say that the majority of CPUs out there are 8 or 16 bit devices running object code that came from an assembler of C compiler. You business programmers, with your profligate refusal to collect your garbage or lift a finger in the way of optimization, could learn a lot from the people who program these devices.

 

99.95% of 8 or 16bit embedded apps are C or ASM

 As you go to 32bit device there is more c++, since they come with larger (excess for some projects) flash/ram size

alegr:

There is pretty good C dev environment for those 8051 beasts. I forgot what it's called (its project files have .UV2 extension or something like that).

Keil uVision  for 8051 - pretty good tool until ARM bought them up, stoped development and slowed support.

An alternative is IAR EW8051, similar price leves, support and features.  It is still being developed *yes thats right* silicon vendors are still putting 8051 cores in SoCs

Kermos:

Project is to create a tool to communicate with a 3rd party controller (the main controller that controls Elevators). The tool has to perform diagnostics on the system and adjust settings, parameters, etc.

OK - So you are devloping a new product/device? 

Kermos:

Now, since this controller is 3rd party, available documentation is zero and there is absolutely no assistance available from the original manufacturer. In a related project I have already reverse engineered the communications protocol sucessfully on the packet layer. But the actual parameters, min/max ranges for the parameters, what the parameters do, what parameters exist, what actual messages/commands exist, meanings of status bits in status messages, etc. all that is a big major, yet to be reverse engineered blur.

Since they provide a comms channel i would keep hammering them for information on this.  Are you helpng them with your device or are you devoping a competitor product?

Kermos:

2 - The platform for the device I have to work with is based on an Intel 8051. That chip has got to have the absolute worst assembly language i have *ever* worked with. Give me a motorola 6809. Give me a PIC. Give me an ARM. But for crying out loud, keep the frigging 8051 away from me.

If its a new project, just choose a different micro?

Kermos:

3 - The device contains 3rd party software which takes up about 90% of the available 128-byte on-chip RAM. My own code is a function called by this 3rd party software.

4 - Since all the on-chip ram, which would normally be more than enough for me, is all taken up by useless to me 3rd party data I have to use the external ram. Normall a non-issue EXCEPT the 8051 only has two instructions (load/store) to access external ram with. So everytime I want to do *anything* with a variable I have to manually fetch it from external ram, or manually store it to external ram. The normal artihemtic / memory instructions can only address registers or internal memory. Hence my comment above about this being the absolute worst language/chip I've ever worked with. Not to mention code bloat.

??? - so are you actually modifying the 3rd party firmware - no wonder you will not get support.

Kermos:

5 - The device can't be remotely updated in the field so relasing software updates is impossible. The device only has a 485 port (required to communicate with the controller) and no way to hook it up to a PC without special 485 hardware that most people don't tend to own. Oh and even if that wasn't an issue, I'd have to send out the manufacturer's flashing tool along with the software in Intel HEX format. I may as well just include the source files along with it at that point in time...

 

If you are modifying the 3rd party device, think about putting your own micro inside then hijack the RS485 port.  Messages can be passed on to the old 8051 or used for firmware updates.

MAybe TRWTF is that you are not sure what you are doing on the project??