Whats the quickest way to set bits?

[rmteo]

Charles, download the current issue of Embedded Systems Design here. You can also subscribe to the print version which is available for free to professionals.



It will give you a good idea of what is happening in terms of tools (hardware and software) and techniques that are used in current embedded systems design and development.

[Charles Linquis]

I keep threatening to change compilers (to C18, for example) or make a bigger move to ARM chips, but it seems like I never have time to make the switch.

Also, I have so many thousands (truly!) of PICs in military applications that it is really hard to change. In some cases, it took a year to get the hardware qualified but we now have enough of a 'track record' with the hardware and sw that we can get products qualified "by example". If I changed chips, I would have to start over.

I guess I'll have to keep doing it the hard way for a bit longer.

And one more thing - anyone who thinks that PBP is somehow not as good as 'C' can be told that it is running in an awful lot of very, very critical military applications. When written correctly, PBP is bulletproof.

[rmteo]

....And one more thing - anyone who thinks that PBP is somehow not as good as 'C' can be told that it is running in an awful lot of very, very critical military applications. When written correctly, PBP is bulletproof.

Hey, if it works for you and your customers are happy, go for it.

[Charles Linquis]

But I will still have to make the change sooner or later. That is, unless we can get Darrel to add functions, procedures, better string handling and a few other features to the next version of PBP!

[rmteo]

Charles, it is not about you saying that something is bulletproof or whether C (or other language) is better/worse than PBP (or anything else). It is about how easy/difficult it is to ensure (from a maintenance/validation standpoint) that the application/system is correct and how you can validate/test that is so.

From the software perspective, you have discovered that as an application becomes more complex, it gets increasingly difficult to maintain (make changes, additions or corrections). As you have mentioned, languages having structured elements (such as functions, procedures, local and global variables, etc.) go a long way in making it so. Also, features such as pointers, structures, members and unions are very useful when dealing with complex data structures. These features are available in languages such as C.

As for hardware, having the ability to do some form of in-circuit hardware debugging is extremely useful. The ability to single step through the firmware (at the source and/or debug level), set breakpoints, inspect memory and register values, change values on-the-fly, tracing, etc. can give you a view of what your system is actually doing that is difficult to impossible otherwise.

[Charles Linquis]

I only made the 'bulletproof' comment because although I write mostly in PBP, I have hired people that knew only 'C'. At first, they were totally convinced that a program written in BASIC was either very slow in execution, or lacked a lot of functionality, or was a "toy" for some other reason.

After a couple of months, they realized their opinions were wrong. All of them learned PBP at least to some extent.

I was trying to give a "pep talk" to all the other PBP coders out there.

My heartburn with PBP is that it is difficult to write reusable code, and also the lack of easy debugging.

[rmteo]

Charles, if I (and even more importantly, my customers) are convinced that we have a serious (non-toy in your words), commercial grade MCU development toolchain that is considered bulletproof, I would not bother looking for anything else.

[mackrackit]

It all comes down to who is banging on the keyboard.

I write crappy code no matter what language I use. I imagine folks like Darrel and Bruce write great code no matter what language they use.

I also bet that Darrel and Bruce can write in Basic and blow even a good "C" coder out of the water.

So if you like B, C, or what ever... use it. What is good for one is not necessarily good for another.