Slashdot Mirror

v4e (or eV4 in some documents): Enhanced version of the v4, launched in 2000. Adds optional MMU, FPU, and enhanced MAC unit to the architecture.

Just like Apple, industry moved on to the PPC. The Coldfire was still a 'last gen' embedded chip where it was a catch all between microcontroller/microprocessor. For example NXP has the MPC5744P that has an Arduino compatible $40 devboard. It is ASIL-D certified (SIL-B IEC-61508;DO-178/254 DAL-B) chips. It has a lockstep processor and ECC RAM. It's used in stuff like your brakes and powertrain.

It's in the same family of chips as the PowerPC G4 and RAD750 (which is running around on Mars and outerspace) implementing Power ISA v.2.03.

There's being conservative and there's being lazy. At this point it's just laziness. Automotive (ISO26262) and Industrial (IEC61508) are getting close to Aerospace's requirements tracking (DO-178C).

Part of that progress has been getting Functional Safety (FuSa) certified chips. The NXP MPC574xP is ASIL-D certified (SIL-B IEC-61508;DO-178/254 DAL-B) chips. It has a lockstep processor and ECC RAM.

It's more or less an embedded PowerPC G4 (Power ISA v.2.03). For the more general purpose computing, the [RAD750](https://en.wikipedia.org/wiki/RAD750) is off this world. The embedded e200 cores are likely out running around the JSF, in another custom core configuration. I *think* it's a tri-core embedded MPC56xx series.

It's also what every GM vehicle and Caterpillar engine has been running since Mid 2000s.

It's safe. The 68k decision was made by someone retiring in 4 years as a 'fuck you'. It's the only thing he knows. They literally have no one lined up to replace him. But because he's in charge until D-day, they picked a 68k. An *uncertified* chip (but had been in a previous certified system), where they draw the boundary diagram of "won't fail" gets political.

ARM is getting certified or recently got certified. Dig through NXP's "automotive" chip website and see what's available. From Drivetrain through ADAS (self driving) to Infotainment, the chipsets exist for functional safety.

Looking at their technology page they are using this chip from NXP: https://www.nxp.com/products/i...

This is a massive security fail. It's just an EEPROM and unique ID combo. Easy to clone. If they had a clue they would use a challenge-response system with no way to read back the critical IDs.

Almost all cars are using RISC.

https://www.nxp.com/docs/en/da...

To my knowledge GCC doesn't have any ISO26262/IEC61508/DO-178 certifications meaning you're not going to be using it anywhere that is life or death.

Sorry, but that simply isn't true. I regularly work on DO-178 DAL-A software for the aerospace industry—primarily flight deck operating systems for everything from business jets to the Boeing 787 and the Airbus A380—and every platform I've worked on over the last decade has employed a version of GCC. True, GCC was not developed with DO-178 certification in mind. That doesn't matter, though, because GCC is not the software that is being certified for use on the aircraft. The released binaries will be subject to requirements-based testing, object code analysis, link analysis, and other verification steps which together demonstrate that the final product works as intended, regardless of any issues which may or may not exist in the compiler.

BTW, you mentioned the PowerPC e200 as a chip you've used—there is, in fact, a GCC-based toolchain from Freescale which targets that microarchitecture. My own experience is more along the lines of the PPC 7447 CPU and the PPC 440H6 and e500 SoC cores, and as I've said these were used exclusively with derivatives of GCC.

Look up ISO 26262 & ASPICE and other things related to 'functional safety'.

Not everything in the vehicle is, or needs to be, compliant but your powertrain and anything with life and safety is. This isn't fly by the night programmers coding a Radio GUI.

This stuff goes all the way down to the hardware level. With dual core CPUs running in lock step, dual memory banks and ECC memory. If there's a mismatch anywhere along the line an error is thrown.

http://www.nxp.com/products/pr...

https://www.renesas.com/en-us/...

In a lot of bigger old companies OpenSource is a forbidden word. Working with AUTOSAR and ISO26262 at separate companies it's sad how many companies are reinventing the wheel on their own because: "Our competitors might steal our work." Our legal team forbid us from sending in bug reports to something as popular as Numpy because: "The information could reveal _____ proprietary information." Despite the fact that where it was found is such a niche of a niche of a part of the programming industry that I could hand out our source code and there may be 1000 people at 10 different companies that even knew what it did.

I'd love to see what VW, BMW, Benz, Caterpillar, Cummins, Ford, and Toyota are doing for their on-highway software certifications. Maybe provide some feedback. I'd like to share with them what I use, maybe they can improve it and save some time doing the same thing.

Go through the Fortune 500 and see how many companies have an active GitHub repository. Everyone on slashdot did a doubletake when Walmart opensourced its cloud ops. It seemed to be a shock that Walmart got as big and efficient as they did without some technology pulling the strings.

NXP just released a $35 development board that is hampered by terrible software and outdated business practices. Despite being "free" you need a license key that multiple people have trouble with. All of the Matlab and Simulink code they released is protected. However for the first time, ever, the GCC source code for e200 core PPC chips with VLE extensions has been released for free. Previously you had to have a WindRiver or GreenHills.

Who knows what random product or software people could come up with if they were allowed to work with peers doing the same thing. Even if it was for a sworn corporate mortal enemy.

Last I checked the GCC didn't support the PPC VLE extensions, which makes it a non-starter for our use. Did that change?

And damn, It looks like NXP has finally done something: https://community.nxp.com/thre...

RTEMS

Has someone paid for their ISO-26262 certification? That's what holding us up. I'm trying to convince my boss that $(FOSS+Pay for the cert) $(Windriver RTOS)

they usually run at a minimum of 200MHz with a few megabytes for software because they run full-blown operating systems.

No. No. Just No.

The top of the line MPC57xx is only ranges from 32 MHz to over 300 MHz. Most of the ones that are currently in production are more than likely the MPC56xx or MPC55xx line. All of which are much more reliable than the 68ks. The highest end/safest ones run lock step cores with a 3rd core that compares the output to make sure that they're both calculating the same values.

For OS' it's running a RTOS of some sort, not a 'full blown OS'. There are a few different vendors: GreenHills, WindRiver, ETAS, etc.

For compilers it's either WindRiver's Diab or Green Hills. To my knowledge GCC doesn't work on the MPC5xxx line. I've been trying to talk my boss into sponsoring a grad student to get LLVM ported so we can at least do some prototyping without paying for a license.

And not if you're going to be using the eTPU, which requires a separate compiler.

With most of the control algorithms written in Simulink and the HAL done in C or C++.

What we need is standardized and open source ECUs that handle all the basic systems needed for the car to function.

I'll be the first in line.

So to recap:

• The dev boards start at ~$500+.
• Theres' no opensource compiler for the chips.
• There's no opensource RTOS for the chips.

A single small team *may* be able to make ECM for vehicles ~10+ years old but unless you have a lot of money to donate to a cause, a fully opensource everything for 2017 vehicles isn't going to happen.

they usually run at a minimum of 200MHz with a few megabytes for software because they run full-blown operating systems.

No. No. Just No.

The top of the line MPC57xx is only ranges from 32 MHz to over 300 MHz. Most of the ones that are currently in production are more than likely the MPC56xx or MPC55xx line. All of which are much more reliable than the 68ks. The highest end/safest ones run lock step cores with a 3rd core that compares the output to make sure that they're both calculating the same values.

For OS' it's running a RTOS of some sort, not a 'full blown OS'. There are a few different vendors: GreenHills, WindRiver, ETAS, etc.

For compilers it's either WindRiver's Diab or Green Hills. To my knowledge GCC doesn't work on the MPC5xxx line. I've been trying to talk my boss into sponsoring a grad student to get LLVM ported so we can at least do some prototyping without paying for a license.

And not if you're going to be using the eTPU, which requires a separate compiler.

With most of the control algorithms written in Simulink and the HAL done in C or C++.

What we need is standardized and open source ECUs that handle all the basic systems needed for the car to function.

I'll be the first in line.

So to recap:

• The dev boards start at ~$500+.
• Theres' no opensource compiler for the chips.
• There's no opensource RTOS for the chips.

A single small team *may* be able to make ECM for vehicles ~10+ years old but unless you have a lot of money to donate to a cause, a fully opensource everything for 2017 vehicles isn't going to happen.

they usually run at a minimum of 200MHz with a few megabytes for software because they run full-blown operating systems.

No. No. Just No.

The top of the line MPC57xx is only ranges from 32 MHz to over 300 MHz. Most of the ones that are currently in production are more than likely the MPC56xx or MPC55xx line. All of which are much more reliable than the 68ks. The highest end/safest ones run lock step cores with a 3rd core that compares the output to make sure that they're both calculating the same values.

For OS' it's running a RTOS of some sort, not a 'full blown OS'. There are a few different vendors: GreenHills, WindRiver, ETAS, etc.

For compilers it's either WindRiver's Diab or Green Hills. To my knowledge GCC doesn't work on the MPC5xxx line. I've been trying to talk my boss into sponsoring a grad student to get LLVM ported so we can at least do some prototyping without paying for a license.

And not if you're going to be using the eTPU, which requires a separate compiler.

With most of the control algorithms written in Simulink and the HAL done in C or C++.

What we need is standardized and open source ECUs that handle all the basic systems needed for the car to function.

I'll be the first in line.

So to recap:

• The dev boards start at ~$500+.
• Theres' no opensource compiler for the chips.
• There's no opensource RTOS for the chips.

A single small team *may* be able to make ECM for vehicles ~10+ years old but unless you have a lot of money to donate to a cause, a fully opensource everything for 2017 vehicles isn't going to happen.

Probably not a great decoder implementation. If a 72MHz ARM7TDMI with 40KB of RAM and no FPU can decode MP3s (NXP AN10583 circa 2007), I have to believe any i586 can pump MP3 out into PCM, linux bloat or no. Did you try OSS instead of ALSA? Performance is better that way. ;)

Pretty sure you're thinking of Sonar, not Radar, which as the OP says, does use lots of power (and a vacuum tube, which means a separate high voltage power supply, no such thing as solid state radar, because SS can't handle the power needed).

Welcome, time traveller from the 1970s, to the year 2016, where 3.3V low-power solid-state radar most definitely is a thing, and is mass-deployed in cars and other moving objects.

and all of it is C.
That is wrong.
All embedded systems I was involved in the last 10 years used: C++

And still half of all embedded systems build in Avionics use: Ada

For example, the Freescale line of coldfire processors all use a tool called codewarrior.
You clearly have no idea what you are talking about.
Codewarrior is an IDE!!! It uses what ever compiler you put behind it. And usually that is a variation of GCC.
Codewarrior is an IDE that was originally written by Metroworks for MAC OS, an IDE focused solely around C++. The fastes C++ compiler for Macs around that time and later acquired by Freescale.
http://www.nxp.com/products/so...
Scroll down to: "Unlimited C/C++/EC++/cC++ Compiler and Debugger for HCS12(X) derivatives and XGATE module "

C has been ported to every instruction set that has ever been invented, and there are more C compilers in the world than there are Java, C++ and Python compilers / interpreters combined.
How is that relevant to the points I made? (If it is even true)

The IEEE keeps a list of the top languages, and their list includes the embedded space which is ignored by these other lists. C and C++ take the #2 and #3 spots, which accurately reflects the underlying reality.
For embedded programming!!! Yes. Not for business code. Not for web pages ... not for smart watches, not for iPads, iPhones, Samsung Galaxies or any other Android device.

If one hires a developer because he has used Codewarrior and ditches one who used Code Composer Studio instead: he is an idiot.

If I had to hire an embedded programmer I would insist on seeing some C/C++ code and would not care what kind of tools he used.

At the current state of affairs, almost all IoT devices are programmed using development environments provided by the semiconductor (e.g., http://www.nxp.com/products/so...). And most of these are a composition of open-source tools (i.e., GCC, Eclipse, etc.) with some proprietary interfacing software (e.g., something like JTAG to program the chip with). The vendor-specific IDEs (e.g., customized Eclipse) often come with networking libraries (i.e., something BSD sockets-esque for Internet) they made and /maybe/ some simple threading library (i.e., no operating system). The programs compile to real-time code and this code is then "flashed" to the chip/flash using something like JTAG. That's it. Security nightmare. The "obfuscation" of JTAG and compiling to ARM (versus x86) has let A LOT of companies do some crazy programming on IoT devices. My IoT camera has a physical kill-switch I use when I get home (i.e., I unplug it).

availability of OSS compilers for Embedded PPC:

Do any of those support the eTPU functionality of the Freescale chips? As far as I know there's:

- CodeWarrior
- Byte Craft
- Ashware

While the whole board isn't rated for industrial temp range, the BCM2836 is supposedly -40C to 85C.

There is a whole lot more to living than what the main processor is rated for. Random stray static voltages, high power FET drivers, etc

spark plug firing not being available in generally available consumer parts.

Any senior EE should be able to make one out of an FPGA. It's just a highly accurate timer.

but where does one start with the list?

Start with Simulink. Model based design is everywhere. Simulink is the only gorilla in the room at this point. With what I've seen people do with Python it shouldn't be hard (technically) to make something similar. You're going to have to make sure it meets industry standards like ISO 26262.

Pick a RTOS. ChibiOS, FreeRTOS, etc

A decent CANape replacement for calibration.

Then you're going to need hardware. You just need an open source version of the Caterpillar A4. Something that takes 18-28V, is hardened against lightning strikes and random stray voltages. Can handle thousands of hours under the hood of a diesel engine. It needs to have a eTPU or FPGA made for timing diesel injection events accurately. The rusEFI project has started their own ECM and in the last year gotten the absolute basics but is nowhere close to what engineered OEM ECMs provide.

Any one of those on its own would be a grad school level project (and should be).

My Arduino projects don't require the power of a 32-bit processor, but do run on batteries. How much more (... or less maybe?) power is drawn by this processor?

It's reasonably close. If you check the datasheets for "Static Characteristics" / "DC Characteristics" you'll find:

The LPC1114FN28 (the ARM chip) draws 9ma @50 MHz, 6ua @deep-sleep, and 220na @power-down;
The ATMEGA168PA (typical Arduino-ish AVR) draws 4.2ma @8MHz, 0.8ua @power-save, and 0.1ua @power-down.

These numbers are just for the chips - the Arduino draws considerably more (about 40ma @idle), and you can stretch your batteries a lot by hacking it. To give a sense of scale, the power LED on an Arduino probably draws 5-10 ma just by itself.

Note that this is a "Cortex M0" profile ARM chip - M means Microcontroller, and 0 means low-end. This is a 50 MHz chip with 32K of flash and 4K of RAM. It's more powerful than an AVR, but don't expect to boot Linux on your breadboard with this thing... that's a job for the Cortex A (Application) series.

Source:
http://www.nxp.com/documents/d...
http://www.atmel.com/images/At...

Reactive Ballasts do

Nope, they *really* don't, current spikes (and causes the lamp to emit light) twice per cycle, resulting in 120hz light. But let's post a wikipedia article that does nothing to back up your claim anyway! How about this white paper from Philips (they know a little bit about lighting) to settle the issue. Make no mistake, there are people sensitive to 60Hz strobing, and people sensitive to 120Hz strobing, but you are not witnessing 60Hz strobing when you look at conventional tube fluorescent lights.

Any reason why you couldn't replace your ATmega with something like this Cortex M0 and have the same cheap DIP setup? With codesourcery lite you also have a compatible gcc version for free

Also did you benchmark the digitalWrite function? I don't really see any reason why digitalwrite won't compile to direct register access.

There are many little ARM boards, some of which are priced as low as $39 in quantity 1. These are useful for applications where the ATMega in an Arduno is too limiting.

The choice of peripherals these guys made is unusual. With a USB port and an HDMI port, you can build a game machine, which is probably what they had in mind. Most such boards are more suited to embedded applications, and have I/O - digital TTL ports, Ethernet, LCD drive, etc.

A problem with these minimal machines is deciding what to put on them. The lowest-price devices tend to have too little of some resource and too much of something you don't need. This leads to a proliferation of little embedded boards with slightly different options, which runs the cost back up.

For hobbyists, the Leaflands Maple may be interesting. It's an ARM board in the Arduno form factor. It's compatible with Arduno daughter boards ("shields"), and has some commonality with the Arduno development environment. Not enough memory to run Linux, though.

The $25 price is a vaporware price - they're not actually shipping. NXP is shipping LPCExpresso for "under $30", and that includes the entire tool chain (Eclipse, GCC, JTAG debugger, etc.)

LabView is like the 555 timer chip. Anybody who can do intelligent electronic design knows you don't use a fricking 555 timer chip. It's a 50 cent part that has 'issues', and you can use a 2 cent dual op-amp to accomplish as much, or more if you know anything at all about linear circuit design.

Actually, I think most, if not all, of those issues were fixed with the 7555.

Oh, and tell that to Steve Wozniak, and the engineers of the original IBM PC. But I guess they don't qualify as people who knew anything about linear circuit design.

Also, there have been an estimated one BILLION 555 timer ICs manufactured EVERY YEAR up through the present, and by nearly everyone who spins linear silicon. Obviously, many of those are going into some pretty high-volume PRODUCTS.

So, it looks like you are a typical engineering snob, and not the "Illuminati" here.

The point is the technology that is used on the internet should be royalty and licensing free. Period. If they want to be grinches about it, they can shove it up their ass.

Let's think about what you're saying here. Just imagine this world.

A) Pay per visitor for Ethernet
B) Pay per visitor for IP
C) Pay per visitor for TCP
D) Pay per visitor for HTTP
E) In addition to that, all vendors across all supply chains pay for rights to use these technologies. Cisco and Juniper pay royalty rights for the aforementioned technologies, end users pay for it in the devices. People and companies paying to run a business off of each of these technologies.

A is probably a bad example. There's all sorts of IP involved there (no pun intended).
http://www.nxp.com/news/content/file_625.html for example

Mod parent up.

His point is correct, although the details are a bit misleading.

Just to give an impression of the magnitudes involved, I2C high speed (here's the spec) signals have rise/fall times in the 10-80 ns range. The setup time, which depends on the synchronization between the data and clock lines, has a minimum spec of 10 ns. If the implementation puts things in the center of the window, there's about an 80 ns setup time, so their might be 70 ns of slop available on either side.

Twisted pair cables will have a velocity factor in the 70% range. i.e. electricity travels through them at about 210 000 000 m/s. In 10 ns, electricity would travel about 2.1 meters.

How much margin any particular I2C implementation has depends on many things, but it should be clear that any decent implementation won't be affected a 10 ns delay to either signal, which equates to a couple of meters of additional wire.

All joking aside, the radio-interference issue is a non-trivial one to many people (including myself) who are concerned about mass producing a whole lot of anything that's going to possibly mess up the shortwave or HF radio bands. Luckily, most CFLs don't seem to be too bad. There are a lot of anecdotal reports of ham radio operators using them alongside HF radios without problems, and the manufacturers themselves seem to be cognizant of the problem.

In case anyone is interested in specific figures, there is a chart of RFI versus frequency from a typical CFL ballast here (go to the very end of the document for the graph).

Experiment. Really.

I started with electronics properly in about September time. Probably the most valuable parts I have in terms of experimentation:

1. A large breadboard (the plug in type). This means you can rapidly try things out. I now have two breadboards - one small, and one large.
2. An oscilloscope. I bought a dual trace 20MHz Gould scope off an eBayer. I would have been lost without it. The dual trace is very useful too when you need to compare signals or check that things are synchronized.
3. The Internet. Seriously - some good resources:

http://www.ibiblio.org/kuphaldt/electricCircuits/ - Lessons in Electric Circuits, a free book - will get you started.

http://www.standardics.nxp.com/products/ Datasheets for every standard logic IC (4000 series and 74 series). Browse the site for chips you're interested in. They are cheap to buy from your local distributor (in Britain, you've got several choices - RS components, Maplin (a bit on the expensive side, but very fast delivery), Bowood Electronics (a superb small firm, fast delivery), Farnell (not used them yet, but they have an extensive catalogue).

http://www.wikipedia.org/ Lots of good articles. I used their article on buck and boost converters to get started on making high voltage switch mode power supplies for my first proper project.

The first thing I did on my breadboard was make simple circuits and understand them - using the versatile 555 timer, making logic gates out of discrete components, making an oscillator from transistors, capacitors and resistors. Then learned about how inductors work - how to use a small inductor to make a DC-DC converter. Comparing how bipolar transistors and MOSFETs work. Making small practical circuits like pulse generators etc. Then using logic ICs

I then built a Nixie tube display (with 7 tubes) out of raw 4000 series logic - essentially, I designed and built my own UART to receive data from a computer's RS232 port and display it on the tubes, and to be able to send data back to select what to display on the tubes. (Two pages of pictures here: http://www.alioth.net/pics/nixies/nixies.html). The nixie tube project was a great one to do as I had to learn lots of different things to be able to make it work: how to make a 170 volt switch mode power supply to the use of digital logic and how to debounce switches.

Now I've started designing and building an 8 bit computer based around the Z80, with flash ROM and static RAM plus an LCD interface etc. It actually works, too - I've got it running off a 4MHz crystal oscillator that I built. There's still a lot to learn - but I've gone from having very little knowledge of how to build electronic circuits to designing and building a simple 8 bit computer (with a keypad for input and LCD for output) in just a few months - if you're already experienced with software, learning about digital electronics is fairly natural. I can really recommend building something reasonably complex out of discrete 4000 or 74 series parts, because this is a great vehicle for learning about digital electronics, and how the real world tends to impinge on you a lot more than it does with software.

Pictures of the rat's nest of wiring that's the Z80 project is here (I've not updated it in a few weeks, I have more photos and assembler code to go in soon): http://www.alioth.net/Projects/Z80/

Why the Z80? Unlike all other processors, the Z80 has registers implemented in static memory. This means when you're experimenting, you can clock the processor arbitrarily slowly - fractions of 1Hz if you really want (or even clock it by hand). This makes early circuits A LOT easier to debug. It's not hard to program, has superb documentation free to download from Zilog. It has separate I/O

It's a common misonception that flash ins't accessible, the latest versions are very much so. JK Rowlings new site is meant to be a good example of this.