Visual studio support for embedded application written for LPC2478 / ARM

Yes he has to.

You are very fortunate if you have never had an employer tell you what you have to do?

Yes he has to.

You are very fortunate if you have never had an employer tell you what you have to do?

In some camps (I can only guess the reason) It is considered beneficial to be able to simulate an embedded app under windows. Maybe it is fear of embedded, maybe it is what the boss is used to, maybe ...

And they specifically told you to use those particular tools, as opposed to, say, telling you to make a version of program that runs on a PC so it can be subjected to unit tests methods available there?

Well, if your employer feels justified to make such detailed requests, it's up to them to ensure that you are in a position to fulfill them. So get them to tell you how you're supposed to do that. If they can't, maybe it's time to upgrade to a better employer.

Yes he has to.

And how do you come to know that?

On the other hand employers tend to expect you to know what you're doing (skills often expressed as experience/training on a CV), or be able to figure it out, otherwise your position might as well be out sourced. Are there other competent individuals within the organization who can help or mentor you? Perhaps a question you should ask when interviewing?

What's the question here? How to install and compile programs under VS? Or how to write and integrate C applications on a Windows platform?

If you have a reasonable abstract of the code you should be able to build a framework under Windows or Linux, etc that can feed it data, simulate some hardware function/interaction, and record results/outputs to a log file.

Is it unusual for a friend and colleague to know?

No, but it's useful information to impart to people who know neither of you, or who you work for. Why can't you help him?

"In some camps (I can only guess the reason) It is considered beneficial to be able to simulate an embedded app under windows. Maybe it is fear of embedded, maybe it is what the boss is used to, maybe ..."

I'm in such a camp. The 8051 is special because of the C-unfriendly architecture. But the ARM is a general-purpose processor core. I can compile and run a huge percent of application logic on a PC just as well as I can compile it for an embedded device. And I can use threads, pipes etc to feed stimuli.

Communicating using a specific protocol? I can send the other side a program that emulates the installation and let them test their side of the protocol implementation long before there exists any hardware. And I can simulate timeouts, transfer errors, error codes etc that might be almost impossible to get the real hardware to suffer.

The almost infinite bandwidth while simulating in a PC means I can run through a huge number of test cases in a very limited time frame, while the real hardware system might need hours or days for the same tests.

Think about a LED display. I can send in a message with lots of formatting instructions. Then capture frame-by-frame the generated display output. Every single pixel state as the sign transitions from one message to another. Every frame can be paused and viewed. And every frame can be compared to the corresponding frame generated before the last source code change.

So when the hardware finally shows up, it's enough to focus on initialization code, timing and load, because the business logic has already been tested and maybe even reviewed and accepted by the customer.

So when the hardware finally shows up
is that the root of the frequent problems "I can't use the pin the hardware has connected"
When I'm involved, the hardware is fully defined before coding starts. With hardware fully defined, it does not take long to get boards. I do not recall any software development that got to any testing beyond testing "funcxx()" before hardware was available. if any more is required before "the hardware finally shows up" a devboard serves nicely

Of course I'm involved from day one.

I can't write code that makes use of a specific capture pin if I haven't made sure that the relevant signal is routed to that pin.

But from me creating an Excel file with all the processor pins with supported functionality, and all the required functionality and then produced a complete list of pin allocations until I get real hardware I'll have to wait a while. The external electronics can often be too complex for it to be meaningful to take an evaluation board and try to bread-board the design.

If it takes 6-8 weeks until I have initial hardware, that is time when I have already written and tested a significant amount of code. I'm far better off concentrating on the requirements of external test harnesses for factory-testing of the hardware than building my own prototype hardware.

In some situations, there might be specific parts of the design where it might be relevant to mill a circuit board so some critical sub-function can be tested. But if you involve BGA components, it's normally way easier to just leave it to the guys with real production equipment.

When you see issues with people routing signals to totally wrong processor pins, that's normally what happens when people don't invest the required time to very carefully work themselves through the chip documentation before deciding which chip to use and before designing the electronics. That kind of stupidity will come back and hit them hard.

In the end, an evaluation board can be great to figure out if a processor is up to the task. But it's often too much work involved to try to make use of evaluation board when writing the real code. I only use them to evaluate processor load and when implementing the hardware mapping layer, i.e. the driver functionality. And I write and test most the business logic on a PC.