KarnEvil said:
not yet... i guess i should start thinking about that.
your preamp specs sound very good. very very similar to mine in fact. i will have to spec mine out soon so we have a better idea what we are trying to accomplish here.
the PIC is no doubt a perfectly capable part, we could easily have used it for this but i chose the AVR on the advice of a couple friends who thought it was a little easier and cheaper to do rapid development on. and yes, it has a very nice feature set.
i am going to be using an external 4k SRAM to store all settings as they are being made, so in theory we should not have to worry about settings being lost on power-down.
cheers,
marc
cuz i have a lot of stuff to store. =p
i want to have customizable text labels, trim settings, "favorite" volume levels, trigger settings, etc. for each input. the EEprom on a 8515 is only 512 bytes... granted this stuff can be encoded to be very compact i'd like the flexibility of having plenty of extra memory space available. using an SRAM also means i don't have to worry about backing up to EEPROM, i know my values will always be stored in non-volatile memory. slight overkill but i like it this way.
actually, on second thought... maybe the user values i need to store will only be about 256 bytes or so... lemme think about the feature set and get an estimate on memory requirements, i guess it's silly to wire up a 4k SRAM when i only need to store a couple hundred bytes...
uuuuhhhhh!!!!!!!!!! Are you out of your mind!? I did a project for a customer which used the the AT90S8515. By reusing text labels and some heavy assembler code.... I got a free codespace of only 200bytes ... And this was only in english!
Ohhh thats good i am not going to write code for this baby ... I don't think you would be able to fit it inside the codespace!
I think you should allready go for a Mega part with at least 16Kbyte code space .. Use the GNU AVRGCC compiler so everyone can debug/change/help you the program later.
Sonny
Ohhh thats good i am not going to write code for this baby ... I don't think you would be able to fit it inside the codespace!
I think you should allready go for a Mega part with at least 16Kbyte code space .. Use the GNU AVRGCC compiler so everyone can debug/change/help you the program later.
Sonny
SRAM is volatile. At least the SRAM's I have heard of - unless Atmel has some new technology or something.
You could use a small battery backup to hold your info when the unit looses power I suppose, but using the onboard EEPROM is cheapest solution.
The main concern with using EEPROM (as you have probably thought about already) is the limited amount of writes you are allowed before it becomes unreliable (all EE's and Flash are like this). So, you know you cannot sit there and update the EEPROM everytime someone increments the volume. That's what the SRAM will be used for. Actually, your C compiler for the 8515 will automatically use the SRAM for temporary variables.
By monitoring the power switch of the preamp (or are you planning on having the 8515 control the power supply?), all of the important settings can be quickly dumped into the EEPROM as the main PS caps discharge, holding the regulated voltage seen by the 8515 for a couple milliseconds - plently of time to go run some clean-up code and backup your settings.
As far as memory requirements go, pick a device that shares the same pinouts to others with different memory sizes first. Write the code and see where it takes you. Start basic and add features as you go - while also designing your code for expandability (always a challenge!). Expect to go through several different memory requirements as your project progresses! I started on a tiny PIC - made it talk to a display and the CS3310. Then moved up to a bigger PIC and added the features I wanted.
With the feature set you mentioned, the Mega may be the way to go - but don't be fooled. 8kB of flash can get you pretty far. If using a small display, like a 20x4, 512 bytes of EEPROM can store enough text for six 'screen shots', with 32 bytes left-over for volume/source sel. settings.
Dave
You could use a small battery backup to hold your info when the unit looses power I suppose, but using the onboard EEPROM is cheapest solution.
The main concern with using EEPROM (as you have probably thought about already) is the limited amount of writes you are allowed before it becomes unreliable (all EE's and Flash are like this). So, you know you cannot sit there and update the EEPROM everytime someone increments the volume. That's what the SRAM will be used for. Actually, your C compiler for the 8515 will automatically use the SRAM for temporary variables.
By monitoring the power switch of the preamp (or are you planning on having the 8515 control the power supply?), all of the important settings can be quickly dumped into the EEPROM as the main PS caps discharge, holding the regulated voltage seen by the 8515 for a couple milliseconds - plently of time to go run some clean-up code and backup your settings.
As far as memory requirements go, pick a device that shares the same pinouts to others with different memory sizes first. Write the code and see where it takes you. Start basic and add features as you go - while also designing your code for expandability (always a challenge!). Expect to go through several different memory requirements as your project progresses! I started on a tiny PIC - made it talk to a display and the CS3310. Then moved up to a bigger PIC and added the features I wanted.
With the feature set you mentioned, the Mega may be the way to go - but don't be fooled. 8kB of flash can get you pretty far. If using a small display, like a 20x4, 512 bytes of EEPROM can store enough text for six 'screen shots', with 32 bytes left-over for volume/source sel. settings.
Dave
KarnEvil :
You only store in the EEprom on a PFO (Power Failure) as you where talking off. When you do this your micro will last at least 10000 turns off.
I think this is a turn on and off for 25 years at least!
If think is not good enough mount an FM24C64 from ramtron next to the CPU then you have 1000000000000 write cycles (it is not a joke!)in every memory cell and it is a nonvolatile part. It just need 2 wires.
look at www.ramtron.com
Sonnya
You only store in the EEprom on a PFO (Power Failure) as you where talking off. When you do this your micro will last at least 10000 turns off.
I think this is a turn on and off for 25 years at least!
If think is not good enough mount an FM24C64 from ramtron next to the CPU then you have 1000000000000 write cycles (it is not a joke!)in every memory cell and it is a nonvolatile part. It just need 2 wires.
look at www.ramtron.com
Sonnya
dorkus-
Very cool!
sonnya -
Also very cool! These FRAMs look impressive! What is the cost?
Man, how this technology has progressed! I deal with larger scale design involving 32MB flash and SDRAM and PowerPC processors interfacing to DSPs and such. The smaller scale stuff has really taken off!
These sound like real good solutions to the power down and reliability issues. Yet this requires an external connection to these devices, which will chew some I/O - but only a couple lines. Heck, if the I/Os can be spared - which is feasible - this could be a very cool design!
Dave
Very cool!
sonnya -
Also very cool! These FRAMs look impressive! What is the cost?
Man, how this technology has progressed! I deal with larger scale design involving 32MB flash and SDRAM and PowerPC processors interfacing to DSPs and such. The smaller scale stuff has really taken off!
These sound like real good solutions to the power down and reliability issues. Yet this requires an external connection to these devices, which will chew some I/O - but only a couple lines. Heck, if the I/Os can be spared - which is feasible - this could be a very cool design!
Dave
I would say, skip the battery powered SRAM's. Go for ordinary RAM plus a EEPROM and write to this memory in intervals (120-60 minutes?) and/or also when the power goes down (not very important, nothing crusial will get lost). It depends how much you need to write. To speed things up you can have some detection of which parameters is changed and therefore need to be saved.
Efter 10 years you will be sure that the memory is obsolete and the battery is impossible to replace.
Efter 10 years you will be sure that the memory is obsolete and the battery is impossible to replace.
Power draw, noise, etc.
Noise emission is not solely a factor of power draw of the part. While I am not suggesting that we use and HC11, you may just find the noise spectra no worse than the Atmel or Microchip parts. The old HC11 parts tend to have high quiescent current, and they are not terribly efficient in terms of power draw, however, they also tend to be on old processes and switch quite slowly. It is a combination of switching edge speed and capacitive load that contribute mainly to noise. I think you will find PIC and ATMEL and Motorola similar in spec with Motorola tending to be better with better edge speed control. If you want lowest noise emissions, National COP and NEC micros are probably the best.
In terms of power draw, the Atmel parts are just average in terms of todays micros, i.e. Atmel, newer 8051 variants from Philips, Motorola 908, 9S12, etc., ST 92F1xx series, for equivalent amount of work done.
Microchip parts are flash based and can be programmed in system. As can Atmel, Motorola, etc. On a dollar per dollar memory basis, the new Motorola 9S12 series are probably some of the more cost effective parts out there.
In terms of development tool support, Atmel, Motorola, and Microchip all have low cost assemblers with some basic in-circuit debug capability though I would put Motorola at the front here. That can be quite an advantage!
If you want to see something cool, check out the Cypress PSOC microcontrollers. Unfortunately, they top out at 16K.
Noise emission is not solely a factor of power draw of the part. While I am not suggesting that we use and HC11, you may just find the noise spectra no worse than the Atmel or Microchip parts. The old HC11 parts tend to have high quiescent current, and they are not terribly efficient in terms of power draw, however, they also tend to be on old processes and switch quite slowly. It is a combination of switching edge speed and capacitive load that contribute mainly to noise. I think you will find PIC and ATMEL and Motorola similar in spec with Motorola tending to be better with better edge speed control. If you want lowest noise emissions, National COP and NEC micros are probably the best.
In terms of power draw, the Atmel parts are just average in terms of todays micros, i.e. Atmel, newer 8051 variants from Philips, Motorola 908, 9S12, etc., ST 92F1xx series, for equivalent amount of work done.
Microchip parts are flash based and can be programmed in system. As can Atmel, Motorola, etc. On a dollar per dollar memory basis, the new Motorola 9S12 series are probably some of the more cost effective parts out there.
In terms of development tool support, Atmel, Motorola, and Microchip all have low cost assemblers with some basic in-circuit debug capability though I would put Motorola at the front here. That can be quite an advantage!
If you want to see something cool, check out the Cypress PSOC microcontrollers. Unfortunately, they top out at 16K.
On long term memory.....
The flash in Motorola micros can be reprogrammed 10K times or more. For Microchip, you have 10K on the data EEPROMS built into the micros. This should be enough for any parameter storage. If you set aside some space for multiple sets of parameters, you can increase this 10K by a large amount.
The flash in Motorola micros can be reprogrammed 10K times or more. For Microchip, you have 10K on the data EEPROMS built into the micros. This should be enough for any parameter storage. If you set aside some space for multiple sets of parameters, you can increase this 10K by a large amount.
AVRs
The ATmega series simply rocks. It has everything you'd want on-die, including the programmer. Check out avrfreaks.net under the devices section for the full breakdown. A $5 cable w/connectors and you're ready to program. Plus, the free utilities for windows and linux allow easy setup and programming for everyone. What more could you want, yeah?
I'm getting a mega128 (overkill by a little).. added ethernet management of sound hardware (there are a few ethernet projects for avrs listed on avrfreaks), protection monitoring (faults, tempurature, etc.), sound quality monitoring, control of other DIY audio devices (a tuner, mp3 player, and cd player, right now), etc. Since I use my computer to do everything, it gives me everything I want, plus expansion room, and for $17 from digikey, it's pretty good.
Also, my two bits for the SOD-- this is a DIY project. The fewer costly assembly devices (non-free software, microcontroller programmers, multi-layer PCB printers, etc.) needed, the better.
I'm planning to snatch some of the ideas coming out of this project, or depending on how you look at it, add some of my own =)
Will
The ATmega series simply rocks. It has everything you'd want on-die, including the programmer. Check out avrfreaks.net under the devices section for the full breakdown. A $5 cable w/connectors and you're ready to program. Plus, the free utilities for windows and linux allow easy setup and programming for everyone. What more could you want, yeah?
I'm getting a mega128 (overkill by a little).. added ethernet management of sound hardware (there are a few ethernet projects for avrs listed on avrfreaks), protection monitoring (faults, tempurature, etc.), sound quality monitoring, control of other DIY audio devices (a tuner, mp3 player, and cd player, right now), etc. Since I use my computer to do everything, it gives me everything I want, plus expansion room, and for $17 from digikey, it's pretty good.
Also, my two bits for the SOD-- this is a DIY project. The fewer costly assembly devices (non-free software, microcontroller programmers, multi-layer PCB printers, etc.) needed, the better.
I'm planning to snatch some of the ideas coming out of this project, or depending on how you look at it, add some of my own =)
Will
got something working
Hi,
Have a look at my site, using a pic for controlling a preamp.
Nothing like this project (tubes, limited inputs, pot for volume, etc) but maybe there is something usefull (it working without problems).
On the display, i decided not to use a LC-display since there's a processor and clock on those things running all the time at 350kHz. The pic itself is in sleepmode when there's nothing to do.
Programming is in-circuit (connector on the back, easy).
Greetings,
Guido
Hi,
Have a look at my site, using a pic for controlling a preamp.
Nothing like this project (tubes, limited inputs, pot for volume, etc) but maybe there is something usefull (it working without problems).
On the display, i decided not to use a LC-display since there's a processor and clock on those things running all the time at 350kHz. The pic itself is in sleepmode when there's nothing to do.
Programming is in-circuit (connector on the back, easy).
Greetings,
Guido
I agree with Guido. I'm thinking right now about a very similar preamp idea for a friend of mine. I will probably just use simple 8-segment LED characters for the attenuation / balance display, and 3mm LEDs to show the input selection. No fancy menus or displays are really needed for a preamp, and the LEDs can all be driven EM-noise free. In a prior project, a little 8-pin PIC drove a display by shifting data out to a SIPO shift register, which in turn controlled the driver transistors for each element. The data could be shifted out so fast that the display update was invisible. Once the display was set, the micro could sleep until it was time to do something again.
Now, for my big DSP box, I was originally designing around ATmega103L as the "host" processor, which I'll probably switch to the '128 now, but in this application I really need all that I/O... perhaps just a small micro is all you need?
Now, for my big DSP box, I was originally designing around ATmega103L as the "host" processor, which I'll probably switch to the '128 now, but in this application I really need all that I/O... perhaps just a small micro is all you need?
nah, i want more control flexibility
the controller should be able to handle at least 8 channels, with custom settings for each input (including text labels), programmable 12V trigger outputs, possibly some other goodies. it is difficult to design an interface for this w/o some sort of text-based menu system, otherwise we will have too many buttons/LEDs and the whole thing will be clunky. this is supposed to be a slick, high-tech design. i am not worried about noise, the controller will be in a separate chassis from the audio circuits.
the controller should be able to handle at least 8 channels, with custom settings for each input (including text labels), programmable 12V trigger outputs, possibly some other goodies. it is difficult to design an interface for this w/o some sort of text-based menu system, otherwise we will have too many buttons/LEDs and the whole thing will be clunky. this is supposed to be a slick, high-tech design. i am not worried about noise, the controller will be in a separate chassis from the audio circuits.
this guy looks like he might have some relevent ideas.
I could be wrong!
http://www.diyaudio.com/forums/showthread.php?s=&threadid=4955&perpage=15&pagenumber=1
I could be wrong!
http://www.diyaudio.com/forums/showthread.php?s=&threadid=4955&perpage=15&pagenumber=1
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.