A few newbie questions

M

Mx5Daz

New Member
Hi,

I'm trying to build a circuit with analogue i/o - three analogue inputs, one analogue output, all 0-5v. Two of the inputs will be derived into X & Y pointers for an array stored in the PIC chip (I've not decided on which one yet), or EEPROM if necessary, with the third input value being stored in the array. Essentially, the circuit will construct a lookup table, and switched to 'mode 2' it will send the output by lookup up the output value from this table.

The programming logic I can easily work out myself as I have 20 years experience as a software developer, but I have a few questions about the circuit itself.

The manual contains an ADC circuit, so I'm probably ok there. There's no DAC though that I can find - is there a simple one I can use or do I need another IC for this?

What is the capacity of the PIC memory? From what I can gather it's 128k, can someone confirm this? If it's only 128k it might not have the resolution I want for the array, so how easy is it to interface to an EEPROM?

Can the output current be easily derived from the input current of one of the signals? The reason I ask is because once the array has been populated (probably using a DIP switch on the circuit) the output signal will go to a car ECU to replace one of the inputs - I don't want to fry the ECU.

How easy is it to interrogate and download the contents of the PIC memory and/or EEPROM to my laptop? This would be necessary in order to create a visual of the array, so that I will know when it's been sufficiently populated.

Power supply will be 12-14.5v from the car, I can step this down precircuit if necessary, or can the PIC chip do this?

That's all my newbie questions for now - I'm keen to get the circuit started on the breadboard as I don't think the hardware side will be especially complex. It'll be my first project though and I'm no electronics whizz, so I'm bound to hit some hurdles. Yes, I know I should start by switching LEDs on/off to start with but my style is 'in feet first' and I have a valid use (possibly commercial) for this circuit once I've finished it :)

Any help appreciated.

Thanks,

Darren
 
B

BeanieBots

Moderator
For analogue out, you can use PWM/PWMout fed into an RC circuit. This will however impact the overall bandwidth of your circuit.

Available memory within the PICAXE is limited.
Interfacing to external I2C EEPROM is easy. Have a look at the I2C commands in the manual.

The 12v line from a car is not as nice and clean as many would like or hope for. Your PICAXE will need a good clean stable 5v for any ADC work. (the supply is the reference).

I'll leave others to discuss the issues with running micros in car environments or you could have a search of the forum as it's been covered many times.
 
D

Dippy

Moderator
For fast-smooth Analogue out you will probably need an external DAC , but first check to see if BB's PWM/RC method is adequate.

I'm not sure where you got 128K from (??) but how much variable space do you need?
Then you will need to consider how fast and how often.
For 'often' you will probably need to consider an external RAM or FRAM chip.
Or an external SD controller.
For 'fast' you may need to consider a parallel format.

To get the Data back to your PC you will have to write a routine which reads the EEPROM/RAM/FRAM and send the data back to your PC. If it is a lot of Data this can be quite slow, an SD card (if appropriate) can be pulled out and shoved into your PC.

Bottom line: the choice depends on your precise specification.

Car Power Supply?
Well this will have the Doom&Gloom merchants linig up :)
Basically:
A fuse, a diode, a Transient suppressor, maybe a small choke, a capacitor, a regulator, a capacitor.
Get some regulator data sheets to see recomendations on capacitor values/types. It doesn't have to be Automotive Rated as long as you protect the front end from transients and nasties.
Inexperienced Doomer&Gloomers will tell you it MUST be Automotive rated - not true, but it won't hurt :)
Piece of cake to the experienced.

And ALWAYS have something like a 100nF Ceramic on the PICAXE +V / Gnd (0V) power pins - as close to the chip as possible. Some people recommend X7 dielectric or better. (IN fact some chips suggest this also but as my anorak is hanging up I can't remember which).

Also, depending on spec, you may need to RC the analogue-in (ADC) lines and/or sample-averaging if signal lines are noisy.
 
M

Mx5Daz

New Member
Thanks for the replies so far!

I'm not sure where I got 128k from either tbh. I'm trying to read up as much as possible in a short space of time, looks like something's lead me astray. Ok, so it looks like I need to use an external EEPROM for storage. What kind of capacity is available? The lookup table needs to be as large as possible, as in certain parts of it the resolution will be down to mv on the Y axis. The size of the table shouldn't affect normal operation of the circuit since the build/lookup functions will only be one cell at a time. Whether I would need to use a RAM buffer to achieve the speed I will need I'll only know once I've got the circuit built, but hopefully I can avoid this to keep the component count down.

Circuit speed is important, I'm investigating the speed of the ECU to see what sort of streamrate I need to handle, but I'd have thought that 10ms would be good, 100ms might suffice. The PIC chip I currently have for this is the 18X, but I can always upsize it if I need to. However I'd like to keep it to the minimum possible to reduce cost-per-unit of the finished product.

Speed of the table download is far less critical as this is a diagnostic function. Once the table has been fully populated, I would store this table on the PC to prepopulate the EEPROM with for new products.

As for power supply, I've been thinking on this. I can take a 5v+ feed from the ECU, which will already be noise filtered. I'm not adverse to adding extra filtering myself, but hopefully this source will be pretty clean already. All 3 input signals to the circuit will be from sources that feed the ECU directly or indirectly so they should already be clean. I'm beginning to understand now why aftermarket devices I have that affect ECU signals (wideband controller etc) all share the 5v+ and GND with the ECU and why I need to do the same.

Thank you all for the info so far, this is proving very useful indeed!
 
D

Dippy

Moderator
Without knowing exactly what you are trying to achieve it's difficult to advise..

If it's a Top Secret commercial product then contributors may be 'hamstrung' as far as advice is concerned.
Is it?

You say circuit speed is important, but then say 10mS is good.
To me that's very slow :)
You realise with your average I2C EEPROM thats 10mS (arguably) per byte/block write?

Have you any idea what data is coming out of ECU?
Baud rate?
Formats/parity?
Bytes per block?

How large is large? 1Mb / 100Mb ?

With 24LC type EEPROM you can bank 8 x 512Kb. (i.e. 8 x 64K Byte).
Other types of memory can do more.

I guess you can nick 5V off ECU, but have you considered cock-up protection if your circuit/wiring is dicky?
Risky with prototypes if you don't know what spec for +5V that ECU can supply.

What is your skill level with electronics/microcontrollers?

PS. Is it a Mazda?
 
hippy

hippy

Ex-Staff (retired)
Usual caveats about safety critical systems and tapping into vehicle components apply.

As you say, the programming should be straight forward; read X, read Y, combine them, read Z from an I2C Eeprom, PWMOUT the Z to an RC, repeat. I'd expect the 18X could easily manage a 10ms stream rate ...

#Picaxe 18X
SetFreq M8
I2cSlave $A0, I2cFast_8, I2cWord
Do
ReadAdc 0, b0
ReadAdc 1, b1
I2cRead w0,(b2)
PwmOut 3, 63, b2
Loop

An over-head to watch for on writing I2C Eeprom is the minimum write time which can be a few milliseconds; no matter how fast the PICAXE you cannot reduce that time.

It would be possible to connect static RAM (SRAM) to a 40X2 through I suspect I2C Eeprom may turn out to be just as fast ( one PICAXE command and reasonably fast read against a sequence of relatively slow PICAXE commands and a near instant read ). One would need to do comparative testing.

Going from an 8-bit system to 10-bit ADC, 1MB I2C Eeprom and 10-bit DAC shouldn't be much more complicated or slower though a faster PICAXE will help there.
 
M

MartinM57

Moderator
...or, just when you thought you had enough to Google, have a look at Ramtron FRAM. Just like EEPROM, but (virtually) instantaneous write time...well, so quick you don't have to worry about it.
 
D

Dippy

Moderator
Maybe instead of EEPROM you may like to consider FRAM. Far tougher, no delays and just as easy to 'drive' as EEPROM.
 
M

Mx5Daz

New Member
Yes, lots for me to read up on :)

Dippy - it's for a Mazda MX5. The device I'm trying to create isn't rocket science, it's to make it possible to remove the airflow meter and simulate it from a MAP sensor against RPM. This would be worth 10bhp+ as the AFM is restrictive. On an FI'd car it's worth more so I'd hope to see 15-20bhp for my supercharged car. There are other elements to the circuit than what I'm discussing here, but this is the core part of the device. There's nothing secretive about this - it's my own project and if I end up with a commercially viable product then I'll sell it myself. If I seem a bit vague on some elements (EEPROM capacity, speed requirements etc) it's because until I do some testing, I don't know the answers.

If 10ms is regarded as slow, that's a good thing as far as I'm concerned. Building the lookup table is less speed critical than using it to read from, which is the part that is in real time (or what the ECU thinks is real time). If it misses the odd beat when it's building the table then that's not important - it will fill in the gaps over time. The idea is to run the circuit with the AFM still in place, and once the table is fully populated, datalog the actual AFM signal against the simulated one in order to test it. I can datalog using other hardware/software so as not to affect the running speed of the circuit. When I'm happy that the simulated signal is accurate then I take out the AFM and run the feed from the circuit.

I'm not overly concerned about frying the ECU during development. Even if I do, they're readily available and cheaply. I've created analogue circuits to modify ECU signals before without any problems so I'm not overly concerned about that. It's all on my own head anyway!

I'll look up FRAM as an alternative to EEPROM, but it's going to be largely down to cost against each other, unless EEPROM performance really does turn out to be a bottleneck. Capacity likewise, more will be more accurate, but there's a level at which price starts to become prohibitive.

My experience so far (as you probably have gathered from my posts) is zero with microcontrollers, so it's all new. However I did used to code assembly in the 90s with the old 8 bit computers, and I know the principles. I'm no electronics whizz either but I have created a few circuits for various tasks, which worked. The learning curve may be high for me, but I'm taking it in.

Hippy - thanks for the code sample, that makes sense (and was what I was formulating in my head!). I guess I'll see from testing whether the 18X is fast enough.

Thanks!

Darren
 
M

MartinM57

Moderator
20x2 is the bang-per-buck PICAXE - I'd recommend over 18X unless you've already got a stock in. You can use SETFREQ m64 on the 20X2 - about 4x faster than a SETFREQ m8 on an 18X (not 8 times as you might expect, due to firmware differences).

Even if 18X ends up the target chip (for cheapness), it worth having the horsepower (!) for development purposes...
 
hippy

hippy

Ex-Staff (retired)
Mx5Daz said:
I'm not overly concerned about frying the ECU during development. Even if I do, they're readily available and cheaply. I've created analogue circuits to modify ECU signals before without any problems so I'm not overly concerned about that. It's all on my own head anyway!
Click to expand...
I really wish you hadn't said that as it gives the appearance of a blasé approach to safety critical issues which we don't encourage on the forum.

No matter how cheap and easy to fix a fried ECU is that won't alleviate any adverse consequences of ECU failure while driving on the public highways. Past success is not a guarantee of future success. While consequence will be on your own head, those consequences can severely affect others and there is a duty of care to third parties.
 
D

Dippy

Moderator
Mmm... well do remember that an EEPROM (like a 24LCxx) has a limited lifetime when writing to cell.
If your code is writing lots of times then it could be a problem.
FRAM is much much more robust. That's why it has been echoed a few times.. ;)
So the extra few pennines may be worth it.
But again it's down to data size and speed requirements - maybe you can tell us about it when you have doen some tests and hopefully calculated some figures too.

I know you are keen and want it finished yesterday but please consider these aspects - people here might not know as much as you about MX5s but they know a lot more about electronics than you do (at the moment) :)
 
M

Mx5Daz

New Member
hippy said:
I really wish you hadn't said that as it gives the appearance of a blasé approach to safety critical issues which we don't encourage on the forum.

No matter how cheap and easy to fix a fried ECU is that won't alleviate any adverse consequences of ECU failure while driving on the public highways. Past success is not a guarantee of future success. While consequence will be on your own head, those consequences can severely affect others and there is a duty of care to third parties.
Click to expand...
Sorry, I didn't mean to be flippant and/or dismissive - I appreciate that's how it probably came across. I won't take risks that'll leave my (or others) cars stranded, I'll put it through bench testing first before it goes on the car and I won't fit it until I'm happy that it will work.

Dippy said:
Mmm... well do remember that an EEPROM (like a 24LCxx) has a limited lifetime when writing to cell.
If your code is writing lots of times then it could be a problem.
FRAM is much much more robust. That's why it has been echoed a few times.. ;)
So the extra few pennines may be worth it.
But again it's down to data size and speed requirements - maybe you can tell us about it when you have doen some tests and hopefully calculated some figures too.

I know you are keen and want it finished yesterday but please consider these aspects - people here might not know as much as you about MX5s but they know a lot more about electronics than you do (at the moment) :)
Click to expand...
I'm all ears - if there are valid reasons to choose FRAM over EEPROM then of course, that will be taken into consideration. While there will be lots of writes in total it will only require one write per cell. Does an EEPROM page write regardless of whether it's one byte that's changed or the whole page? If it does then that's something else for me to consider.

I know there are people here who know a lot more about electronics than I do - that's why I'm eliciting opinions, so that I know my approach to it is the right one :)

I'll keep this thread updated with my progress, and probably more questions when I hit more issues.

Thanks

Darren
 
B

BeanieBots

Moderator
Mx5Daz said:
I'll put it through bench testing first before it goes on the car and I won't fit it until I'm happy that it will work.
Click to expand...
Applications which get fitted to cars are CLASSIC examples of "it worked on the bench" but failed badly when tested in the field.

STRONGLY suggest that your "bench" trials include actual vehical supply trials.
 
M

Mx5Daz

New Member
Well naturally, the prototype will go on my own car. I'll test it on the driveway before I take it onto the roads. I meant that I'll be checking the tables & outputs are as expected before it goes anywhere near the car.

I thought that went without saying...
 
B

BeanieBots

Moderator
Yes, that bit does go without saying.
A common failure of many test regimes is forgetting to include the expected environment in the test plan. (that's both electrical and environmental).

Shortly followed by "well, it worked fine on the bench!".
 
You must log in or register to reply here.
Top