what's wrong with a pic ?

IMHO, wheeled transportation should emulate the 1939-44 Willys Jeep design for simplicity and maintainability; all electrical apparatus should be field repairable without special fixtures and with a minimal complement of spares. A modern version could benefit from improvements in metallurgy and mechanical design and perhaps from aerodynamics. It should be EMP and ESD resistant (use few semi- conductors) and have line replaceable subassemblies with commodity pricing. It should be designed to prefer biofuels or waste oil.

Complex transportation design and research should be concentrated on airborne personal transit (which is way overdue); R&D overhead and initial manufacturing plant costs could be quickly recovered by the retirement of the massive road infrastructure maintenance and construction expense we now endure. Automated flight controls and a robust traffic control network would likely cut personal transportation death rates dramatically (the slaughter on the roads in the U.S. is remarkably tolerated -- equivalent to one Viet Nam each year) and at altitude a vehicle parachute (ala the Cirrus Design concept) would be effective in case of major system failures).

Where are our promised flying cars?

Regards,

Michael

Op Mon, 22 May 2006 19:53:09 +0100 schreef Ian Bell:

Not really, it had two: RET and DIS. But they did no pop of the return address, because the SEP (sort of call) did no push either. CALL and RTS had to be programmed and were slow, 29 * 16 ticks. So calling via SEP or MARK was preferable in short programs. I still have my ELF II but its now

I got some documentation about them a few days ago and I would rather have the 1802 / 1806 than a PIC. Still, the 8080 and later Z80 were much nicer.

Make it a flathead (sidevalve) using scavenger oiling (no pump) with mechanical brakes, three speed transmission, rumble seat, and running boards, and you might have something :-)

As you can see by all the replies you have received opinions vary a lot.

I have written code for PICs from the very first up to the current offerings.

The architecture of the PIC is in fact strange for most programmers.

If you don't like PICs or cannot understand them then don't use them.

For those whiners out there, should you just happen to be forced to code for a PIC, JUST SUCK IT UP AND GET ON WITH IT! Technology is no place for wimps.

And to you C coder script kiddies. You know that high level language stuff is not real programming, it's just data for a translator.

Real embedded programming is done in assembler and burned into silicon just one time!

I have not used pics, but have used stack processors for years that don't use stack pointers or stacks in RAM for a number of reasons. They are much faster than stacks in memory, and ours cannot throw errors. Of course if you expect to put more items there than you have room for and you expect to get them all back after some are lost you are not thinking straight.

We say that it is powerful and handy to have stacks that wrap and don't throw errors when we intentionally use them that way. We use it to make our programs smaller, faster, and simpler and to make writing the code simpler and we thing that is a good approach for embedded hardware/software.

We think this give us a number of advantages over the idea that stacks are arrays in normal random access data memory. But it does require a different way of thinking and some people don't like that.

We also have a stack for data and a stack for return addresses and loop counters. So we don't need stack pointers to build stack frames in arrays of normal data memory or index into them to get data because we have a separate stack for that.

After fifteen years of programming mostly these things I claim that it is easier than having to deal with slow stacks, stack pointers, and exception handling when no real errors are actually happening. Wrapping solves lots of problems. We also understand that it looks different than what most people are used to and is a problem until you make a mental shift.

We have this too although with a second stack it is not the problem it would be if you wanted to or needed to try to build stack frames like in typical C implementations.

We also feel that having embedded system have hardware that traps software design errors is not much help. One the device is in the field failing because it trapped a software design error in hardware is not goint to be much different than any other failure cause by undebugged software going out the door into an embedded product. It is a band-aide and if the app has a fatal flaw it has a fatal flaw, a band-aide won't help much with that. It does have some value as a weak debugging tool in developoment, but for those who depend on that

Yes. It has some powerful features that can be exploited. But they are unusual and so people have a learning curve and some people don't like it. It also can cause trouble for people who want to use a higher level of abstraction in their tools but find that the one they were using doesn't support these no over/underflow trap type stacks. But with the right software some people like them.

And of course it is only one the quirky PIC things that people talk about, and some people don't like dealing with those kinds of quirks. If they said that this feature was there so that the product could offer you a thousand mips per buck people might be more willing to consider a change.

I have to smile :)

First you say "i don't see anything wrong with it"

then you add

"i don't like the banked memory in most of the parts" "the risc is a little "too risc" "add with carry" would have been nice

so that's three things wrong, even before anyone replies..post. I'll leave others to add to this list...

-jg

time!

Rubbish Program it in binary, 0's and 1's , cell by cell, into the silicon, with a modified electron microscope, none of this libral weenie assembly crap

Or just use one of the usual suspects, 8051, AVR, 430

martin

Op 22 May 2006 14:48:38 -0700 schreef snipped-for-privacy@ultratechnology.com:

I know that you have used processors with two stacks for years. But on a PIC the stack is only used for calls and interrupts. There is no way (at least the smaller ones) to access the stack from within a program. The stack is only 7 or 8 deep with no chance to expand them. And if you can access the stack with the later PICs, only the top element can be accessed. Not a very friendly contraption to write a Forth for.

I'd say that car will still be running in 50 years. Todays electronic marvels are good (any number of you have driven my software ;-), but long-term repair is an issue. A former co-worker and I had a discussion about business possibilities for repair of automotive electronics for car collectors as the decades pass.

~Dave~

Indeed. People have done it, but it doesn't look like the best fit. If nothing else, many Forth words have to access the top two elements of the stack. If you only have one cell that you can access then it will get ugly and if you have only one stack then you will have to build a second one.

I am not a person using Forth on a Pic so I don't know how those people setup the compiler to generate reasonable Forth code. Where I work that job is pretty trivial because the instruction set matches up to the high level language nicely.

Some people seem to like Pics, some don't. The same as most things. It kind of depends on what you are used to.

:)

is my manly man project.

Do you think replacement points, drums, needle valves, molybdenum-containing gear oil, crankcase oil compatible with the temperatures and pressures of a present-day gasoline engine, or even compatible gasoline will be available in 50 years? Hell, I have trouble finding the right weight of motor oil for my car TODAY.

I have a 41-year-old truck. I happen to be lucky that International Harvester cast their engine blocks with some process that left the block very hard. Many other vehicles of the era cannot be operated on modern unleaded gasoline.

The project of mine is an FM receiver with USB interface. This would help recording of radio stations for long hours (depending of the harddisk capacity ofcourse). My needs to signal processing is just 2 folds. 1). dynamic range compressor 2). presets of graphic equalizer (as this device can also used to hear FM stations by plugging in the headphone.

For this, isn't using a blackfin etc and overkill? Using ARM is a good option I think. I have lots of good words about dsPIC30. Out of ARM based processor (Atmel etc) and dsPIC who wins for my situation?

Blackfin 533 and 531 don't have TWIs? How to communicate to FM chip then?

Warm regards

--Himanshu

Times are changing, though. I think in 50 years time, COTS consumer transport will no longer be gasoline-powered. Of course, I will be safely dead by then, so I have no trepidation that I'll live to see myself proven wrong.

mmm.... well, there are religious problems there :) (and admittedly I don't understand all the issues).

If you can afford a machinist to make a new crankshaft, you can afford to hire an embedded guy to make a new PCM or ECM from scratch using current technology.

Yes, they will be available. Model-T's are 80-100 years old and still run. Mechanical parts can be fabricated. The temps and pressures in todays engines are higher than older engines, so oils and other lubes are backwards compatible.

I have a 44-year-old sports car with an aluminum block (steel cylinder liners) and heads. It's the valve seats which are the problem and easily fixed by replacing them with hardened seats. There are also lead substitute additives. I have never heard of any concerns about engine blocks when using unleaded gas in lieu of leaded gas.

It's the electronics in todays (well, starting in the 70's) which will be the problem. I can walk in to my local machinist and have him fab a new crankshaft. What will I do for that micro which controls the engine and transmission, but hasn't been built for 44 years?

~Dave~

Would it have air conditioning, CD player, air bags, anti-lock brakes or the other safety and convenience features we take for granted? What will be the mileage on the freeway? Will it meet federal crash safety standards?

You've gotta be kidding! Have you checked what percentage of goods transfer in the USA occurs on semi trucks! We got a rough awakening here in Western Oregon when the department of transportation limited loads on a couple of older bridges on Interstate 5. You could take every private auto off the interstates and you'd still have to maintain them for the freight traffic. The railroads just don't go enough places in the Western US. Where they do go, half their loads are semi trailers on the way to hubs where the tractors take them the last hundred miles. There just aren't enough tracks or cars to replace the trucks.

So, what do you do when that parchute lets you down 100 miles from the airport? Why you wait for a truck, of course? ;-)

Talk to Paul Moller. His skycars are predicted to sell for about $500,000. Start saving.

Mark Borgerson

Are we working our way back to the Citroen 2CV? ;-)

Mark Borgerson

Perhaps that's a business opportunity. Develop an FPGA replacement for the 68332 or equivalent engine controller and put it on a PCB. Getting the original software might be more of a problem.

Mark Borgerson

Who

Blackwell

If Himanshu is interested in dsPic he should also check out the TI 320F28xx series. These are much easier and cheaper to deploy than ADI Blackfins.

The 320F2808 has on chip flash and RAM, serial port boot up and comes in a friendly 100 pin LQFP and the complete development toolset is about $2200.

The Blackfins are much faster, have no flash on chip, not much ram (except for the pricey BGA ones) and carry an official toolset price of $8000. ADI's dsp library support is better than TI's for these parts.

If you are going to use large numbers the cost of development does not matter of course.

Michael Kellett