PSoC based possibilities

From DIY contraptions to sophisticated FreeEMS-specific designs! Plus general hardware development!
User avatar
ababkin
LQFP112 - Up with the play
Posts: 215
Joined: Tue Jan 15, 2008 5:14 pm

Re: PSoC based possibilities

Post by ababkin »

I've just skimmed through the article and, I must say, it's very interesting and may end up being useful to this effort.

I am a fan and proponent of idea to have a dedicated and isolated decoder/scheduler module for decoding the wheels and scheduling ign/inj events (even though Fred disagrees with me ;) ). Preferably, this module will be VERY noise and harsh-environment resilient and mounted somewhere under the hood, coupled with the appropriate signal conditioning and high power circuitry, very close to the actual VR/Hall sensors - to reduce the noise. This remote location, decoupled from the main MCU, would also be beneficial for noise isolation of the MCU from the high-power ign/inj drivers.

So anyone knows why it would be a better idea to use this PSoC for this module rather than implementing the decoder/scheduler logic in a CPLD/FPGA?

Alex
Legal disclaimer for all my posts: I'm not responsible for anything, you are responsible for everything. This is an open and free world with no strings attached.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: PSoC based possibilities

Post by Fred »

Half the point of this effort is to create a good single chip solution to engine management in an affordable and technically manageable way. Software is "easy" lets go with KISS for hardware where possible. Multiple important chips and interchip comms for critical processes when a single chip can do it and do it well seems like an exercise in excessive complexity for minimal or no gain.

However, for knock sensing it sounds very promising :-)

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
toalan
Wideband Wizard
Posts: 241
Joined: Tue Jun 10, 2008 2:53 am
Location: Toronto Canada
Contact:

Re: PSoC based possibilities

Post by toalan »

I do not think PSOC is suitable for general EMS, you would probably do better with something like AVR and ARM just because of the processing power, large user community, and cheap dev tools. Off the top of my head I can not really think of any good way to leverage the programmable analog and digital blocks, but if you are creative I am sure you can make good use of it.

I made a piggyback controller, based on PSOC. I only used it because I had previous PSOC experience and because the PSOC that I like has built in USB. I would have done much better to use an AVR with USB capabilites. In my project, typically the uC is tied up with looking up values and interpolating, and I was not very impressed with the speed.

PSOC has a MAC, in my experience I did not get huge performance increases from it, I would say at best 20%. An AVR without MAC can easily outperform a PSOC with MAC by 4-5 times. Of course I use the MAC for plain vanilla arithmetic, I did not get creative with it.

Also the current crop of PSOCs do not have built in EEPROM, it uses flash to emulate EEPROM. Downloading tables to it is not very elegant, the CPU is halted during a write, and you need to reset the uC after each download to get it out of the writing mode. What I had to do was to devote a huge chunk of RAM to store the downloaded tables, then I had to write from ram to flash. Ideally I would want to save the data to EEPROM as it is downloaded from the PC. I ended up just using an external EEPROM chip, it served to save the lookup tables as well as to store huge amounts of datalogging info, so in the end it worked out but I am still not very happy.

The ADCs on PSOC are slow because they do not have sample and hold circuitry, but they can be tailored to reject noise at specific frequencies.


Regards,

Alan To
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: PSoC based possibilities

Post by jharvey »

toalan wrote:I do not think PSOC is suitable for general EMS, you would probably do better with something like AVR and ARM just because of the processing power, large user community, and cheap dev tools.
Sorry to hear you don't think it's a good idea. I know Cypress has specifically targeted the automotive industry with the LIN bus. I also see a couple automotive app notes from Cypress as well. I still feel it's got it's place in automotive applications. I also know the software is free for asm and $150 for C. The PSoC can bootstrap, so it's basically free to get the compiled code into the PSoC. The ICE is about $400. Doesn't sound to expensive to me.

I'm not sure what the need for large processor power is. I know the HC11 (at a womping 1MIP) was dominant for many years for most of these task in commercial products. I can perhaps see the need for MIP's if you choose to ban-pass filter, and such, in software rather then hardware. However, the PSoC allows you to do it in hardware, so I don't see much of a need for heavy processing. The PSoC also allows for an on-board scope feature, allowing you to see the signal at different points. That is much harder to do with software. You would have to port the data stream somewhere usable with out effecting the processing code, then run some other software on it, to see what it's doing at the specific times of interest. Sounds like a lot of work, that a scope could tell you in seconds. Or even better, the on-board scope could tell you.

There are many times that software FIR's ect have image rejection issues, there are often holes and poles that can easily throw off results and cause software induced noise. With hardware these are much more reproducible, and much less prone to issues from higher frequencies. I think good use of hardware makes the design much more robust, and much more reliable. We get to see similar with Software Defined Radio's. The software equivalents are sensitive to about -90db, where the hardware versions are easily sensitive to -120 often as much as -150 db. Doing stuff in software is cool, but not necessarily the best answer. However, if you have a hammer, I guess the problem might start to look like a nail.
toalan wrote:Also the current crop of PSOCs do not have built in EEPROM, it uses flash to emulate EEPROM.
Don't you only write to the tables when you program it, excluding the EGO that is. Even then the EGO could store the data in RAM, then save it when it shuts down. Preventing excessive write operations, prolonging the memory life. I don't see a huge need for fast write operations to permanent memory with EMS.
toalan wrote:The ADCs on PSOC are slow because they do not have sample and hold circuitry, but they can be tailored to reject noise at specific frequencies.
A/D speed is an interesting one. I think they are fast enough for EMS needs. I seem to recall that you can get them up to about 1MHz bandwidth, but typically an 8 bit is around 20 to 150 KHz. An engine cranking at 12 KHz could get by with as little as 24 KHz bandwidth. However PSoC's are significantly faster then this minimum need. Also don't forget, this speed is only required on the VR circuit, which already has a reference design. Most other signals like knock, temp, map, ect are below 10KHz, and the PSoC is at least a decade faster then that.

A 1MHz 8 bit A/D requires much more horse power to deal with the data. Probably a min of at least 8MIP's but more likely it would need at least 20MIPs. That's just to do a simple ban-pass filter. I just don't see what looking at larger bandwidth signals gets you, and therefore I don't see the need for more bandwidth and processor power. I think that overkill in the A/D department is going to cause extra work in the software department.

I think the PSoC is powerful enough to do it all, but I don't think it should. The PSoC could have 8 PWM's for fuel, a pile of IO for spark, and at least 4 A/D inputs for O2. But why limit the design to the capabilities of a PSoC, AVR, Blackfin,ect, when a modular design would easily allow for 48 cyls. I think a modular design would allow for other to make their own contribution with out the need of investing massive resources. It would also allow for much less costly re-spins when you say oops on a single module.

Sounds like a couple thumbs up, couple thumbs down, and a bunch that are in the middle. Any how enough with the shed color, has anyone started laying out a draft board design, or a draft layout? Doesn't matter if it's PSoC, AVR, PIC, or 8051, if no one starts something tangible. Unfortunately I'm not able to make this commitment right now, so I can't start drafting up a general layout. So who is able and willing? I'd probably be best off trying to help them in their efforts. Offering advice that matches their skills.
toalan
Wideband Wizard
Posts: 241
Joined: Tue Jun 10, 2008 2:53 am
Location: Toronto Canada
Contact:

Re: PSoC based possibilities

Post by toalan »

what do you mean by onboard scope? I never heard of it.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: PSoC based possibilities

Post by Fred »

jharvey wrote:Doesn't matter if it's PSoC, AVR, PIC, or 8051, if no one starts something tangible. Unfortunately I'm not able to make this commitment right now, so I can't start drafting up a general layout. So who is able and willing? I'd probably be best off trying to help them in their efforts. Offering advice that matches their skills.
I've been advising people to hold off doing this until the firmware is closer to being usable. I see it as somewhat wasted effort if the pin out was to change in the future for example. Chances are that we won't move pins much/at all, so I guess a prototype is an OK idea. Karri has done us an Adapt card footprint for KiCAD so that would be a good place to start. Perhaps looking at a budget case/connector would be a better place to start? The first iteration should be budget minded, 2 layer and through hole such that tinkering is easy for anyone on the team IMO. Perhaps bump the appropriate threads or start new ones if you wish. I still think it is premature though.

EDIT : 8 x PWM is not a suitable selection of outputs for accurate fuel usage. Especially not if they are low bit count, but not at all anyway.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: PSoC based possibilities

Post by jharvey »

toalan wrote:what do you mean by onboard scope? I never heard of it.
The PSoC has a register configured MUXable analog input. So the analog input(s) can be changed by changing register values. If you use some analog block(s) as an A/D, you can move the A/D's input to just about any pin on the device. If that A/D data stream were connected to a digital block, or piped via USB to a PC, the PC could work as a scope display. If the A/D is direclty connected to a digital block and using I2C, 232, or other, it would require next to no overhead from the M8C processor.

There are many scope projects out there with the PSoC as the core. Here are a couple app notes that cover scopes and PSoC

http://www.psocdeveloper.com/docs/appno ... n2178.html
http://www.psocdeveloper.com/docs/appno ... n2106.html

There was also this contest entry back in 2002 called the Poor Man’s Oscilloscope

http://www.circuitcellar.com/psoc2002/winners/oe.htm

While re-finding my above sources, I came across this article about sample and hold. It appears it can be done, but the module isn't pre-made for it. So you have to use a generic switch cap block, then do some software on your own. Here's the app note.

http://www.psocdeveloper.com/docs/appno ... n2350.html
Post Reply