The Son of Dork (SOD) project is the result of the diyAudio.com multi-channel preamp initiative (http://www.diyaudio.com/forums/showthread.php?threadid=3517). The project has been split into threads dedicated to discussion of the preamp's different functional units:
- General Discussion (project status, functional requirements)
- Active Circuitry
- Attenuator
- Power Supply
- Connections and Layout (including input switching)
- Chassis and Construction
- Hardware Logic, Controls, Display
- Microprocessor (programming, implementation)
I will be managing the project as a whole, as well as initially overseeing individual threads. For a background on the project, please see the original thread referenced above. A website dedicated to the project will be located at http://dorkus.org/diy/sod.
Let the fun begin!
- General Discussion (project status, functional requirements)
- Active Circuitry
- Attenuator
- Power Supply
- Connections and Layout (including input switching)
- Chassis and Construction
- Hardware Logic, Controls, Display
- Microprocessor (programming, implementation)
I will be managing the project as a whole, as well as initially overseeing individual threads. For a background on the project, please see the original thread referenced above. A website dedicated to the project will be located at http://dorkus.org/diy/sod.
Let the fun begin!
Should we start of choosing a micro!?
If AVR .. At least AT90S8515 but a Mega part would be nice.. Menu's take up a lot of space! .. Even in assembler.
There is even a FreeWare GNU c-compiler avialable..
look at www.avrfreaks.com
Sonny
If AVR .. At least AT90S8515 but a Mega part would be nice.. Menu's take up a lot of space! .. Even in assembler.
There is even a FreeWare GNU c-compiler avialable..
look at www.avrfreaks.com
Sonny
i've got a 90S8515 set up at on a dev board at the moment, the part was recommended to me for this application by some folks at avrfreaks.net. but i may step up to an ATMega if necessary... i will be using an external 8k SRAM to store parameters and such but as you say menus may take up a lot of program space in the flash ROM. i'm also not sure if it has enough inputs/outputs for me... i want to have up to 8-channel capability, 8 programmable trigger outputs (for remote amp turn-on etc.), separate memories for each input, etc. etc.... i was doing a rough sketch of my interface specs on the train the other day and it was pretty complicated, i'm going to have a lot of muxing/demuxing to do! i will have to put some more thought into it... 
when i have a better idea of the control scheme i will post it. i should also get the website for the project up soon...
when i have a better idea of the control scheme i will post it. i should also get the website for the project up soon...
dorkus said:i've got a 90S8515 set up at on a dev board at the moment, the part was recommended to me for this application by some folks at avrfreaks.net. but i may step up to an ATMega if necessary... i will be using an external 8k SRAM to store parameters and such but as you say menus may take up a lot of program space in the flash ROM. i'm also not sure if it has enough inputs/outputs for me... i want to have up to 8-channel capability, 8 programmable trigger outputs (for remote amp turn-on etc.), separate memories for each input, etc. etc.... i was doing a rough sketch of my interface specs on the train the other day and it was pretty complicated, i'm going to have a lot of muxing/demuxing to do! i will have to put some more thought into it...
You do not need a lot of pins... Take a look at 74hc165 and 74hc164 .. I use them all the time.
It makes the PCB simpler too.
Sonny
You may want to consider I2C ports Philips PCA95xx series, Micrel MIC74, etc. for digital control. Some are addressable and being serial, will make layout easier as stated for using simple logic gates. Another nice benefit is that I2C parts need to implement slew control on the edges [for serial transmission] reducing EMI and may lower the chances of digital feedthrough into the analog section which during volume control would be nice. Not the cheapest way to do port replication, but possibly a nice elegant way of doing it.
It is likely that more people out there have Microchip develop tools thatn ATMEL AVR parts. Both are relatively easy to work with.
It is likely that more people out there have Microchip develop tools thatn ATMEL AVR parts. Both are relatively easy to work with.
We use both Microchip PIC and Atmel AVR at work. According to my colleague AVR is the salvation (if you have PIC as an alternative). I, myself have done a couple of projects with PIC and I must agree with my pal. PIC sucks when it comes to a little larger programs (more than 1024 instructions). AVR is nice due to in circuit programming (Flash memory), simple programmer. We use 4434 and 8535 with very good results. I must also point out that PIC's works very well also if the program is well done.
My colleague is real good in programming so if you want to get in contact with him send me a message. I haven't asked him if he is interested, maybe.
My colleague is real good in programming so if you want to get in contact with him send me a message. I haven't asked him if he is interested, maybe.
hi peranders,
thanks for the info, it correllates with what i've heard about AVR vs. PIC as well... my sense is AVR is ideal for quick and easy application development, PIC is also very good but requires a little more experience/time to get running. i haven't started progamming in earnest yet as i'm concentrating on the analog circuits at the moment, but i'll try to post more specs on the microprocessor design soon.
cheers,
marc
thanks for the info, it correllates with what i've heard about AVR vs. PIC as well... my sense is AVR is ideal for quick and easy application development, PIC is also very good but requires a little more experience/time to get running. i haven't started progamming in earnest yet as i'm concentrating on the analog circuits at the moment, but i'll try to post more specs on the microprocessor design soon.
cheers,
marc
Considered Motorola?
Hey guys,
Has anyone considered the HC11 (8-bit) or HC12 (16-bit) microcontrollers from Motorola? If you have used them before, you know there is plenty of I/O and A/D for the monitoring that has been mentioned previously, SCI & SPI (no I2C), and more processing horsepower.
Just thought I would throw that hat in the ring.
Later,
Hey guys,
Has anyone considered the HC11 (8-bit) or HC12 (16-bit) microcontrollers from Motorola? If you have used them before, you know there is plenty of I/O and A/D for the monitoring that has been mentioned previously, SCI & SPI (no I2C), and more processing horsepower.
Just thought I would throw that hat in the ring.
Later,
i used the HC11 or HC12 (can't remember which) in school for my junior-year project and it was a nice chip. but i think using AVR parts gives us a lot more flexibility, esp. if you go with an ATMega. those babies are sweet. but i dunno, i'll defer to people who are more qualified in the matter.
The AVR core is an MIPS arcitechture which mean singlecycle instruction.
The 68HC** or PIC or 8051 family need more cycles too execute an instruction.
So bottom line.. The AVR can run at a lower frequency than the other micro's and still perform the same speed. Which turns into a lower radiation.
Sonny
The 68HC** or PIC or 8051 family need more cycles too execute an instruction.
So bottom line.. The AVR can run at a lower frequency than the other micro's and still perform the same speed. Which turns into a lower radiation.
Sonny
Hey guys,
I guess we can remove the Motorola from consideration based on your posts. However, I would like to point out that the reasons listed for favoring an Atmel derivative are low power consumption and the ability to "sleep" or enter a low power state. I understand the sleep mode which could be easily used to "save" volume settings, input selections, or any other changes that may require settings recall at power-up, but what is the concern about power consumption. We're not using batteries. Even the most robust development boards for the HC11 typically consume <100 mA. And as far as noise, I would assume that proper mixed-signal grounding techniques will be used. I would not expect the microcontroller to be used near any of the active circuitry, and I would expect that the microcontroller would be isolated with its complementary circuitry on its own PCB.
After looking at the Atmel microcontrollers I would agree that the ATmega series, especially those with larger amounts of Flash memory seem to be very desirable. The only draw back I see is someone using assembly language for coding. I have done limited programming with RISC processors, but I always seemed to write more lines of code for these programs than the equivalent program using a CISC processor.
Later,
I guess we can remove the Motorola from consideration based on your posts. However, I would like to point out that the reasons listed for favoring an Atmel derivative are low power consumption and the ability to "sleep" or enter a low power state. I understand the sleep mode which could be easily used to "save" volume settings, input selections, or any other changes that may require settings recall at power-up, but what is the concern about power consumption. We're not using batteries. Even the most robust development boards for the HC11 typically consume <100 mA. And as far as noise, I would assume that proper mixed-signal grounding techniques will be used. I would not expect the microcontroller to be used near any of the active circuitry, and I would expect that the microcontroller would be isolated with its complementary circuitry on its own PCB.
After looking at the Atmel microcontrollers I would agree that the ATmega series, especially those with larger amounts of Flash memory seem to be very desirable. The only draw back I see is someone using assembly language for coding. I have done limited programming with RISC processors, but I always seemed to write more lines of code for these programs than the equivalent program using a CISC processor.
Later,
The power consumption is essential when you talk emission! 100 mA Motorola system versus 1 mA (10µA) AVR, PIC system are miles apart! HC11 radiates RF, ....a lot! AVR and PIC are very nice in this respect. HC11 has a unnecessary high drive capabilty at the buses wich creates lots of noise. In audio it's even more important with quite control systems. Don't forget that LCD displays also radiates rather much.
oh yeah... i remember being able to parallel a lot of devices off the HC11 bus, drive LEDs even. it has pretty high current specs for the output pins, the total current from all pins is limited but any one pin can source somewhere around 30mA i think. this is unnecessary for us. we are trying to minimize noise as much as possible, although most likely the processor and control circuitry will be in a separate shielded chassis, with optocoupling to isolate the lines going to the audio circuitry.
Good point!
peranders,
Your post reminded me of some problems that I have had with noise and HCxx boards in the past (bus extensions). I do not know how that slipped my mind, probably because most of the environments that I have used them in are much noisier than the HC11 itself. I guess that tape was not loaded.
Everyone,
Are there any freeware or shareware development tools, assemblers, etc. for the AVR microcontrollers? Are there any good sources for development boards for ATmega microcontrollers?
Thanks,
peranders,
Your post reminded me of some problems that I have had with noise and HCxx boards in the past (bus extensions). I do not know how that slipped my mind, probably because most of the environments that I have used them in are much noisier than the HC11 itself. I guess that tape was not loaded
.Everyone,
Are there any freeware or shareware development tools, assemblers, etc. for the AVR microcontrollers? Are there any good sources for development boards for ATmega microcontrollers?
Thanks,
FWIW...
I know the PIC is not your first choice, but I know it can do the job you want. I am working on a preamp that uses a PIC16C67. The features I implemented seem similar to what you are looking for. Here's what I managed to cram into the internal 8k ROM of the device (with 2k left-over):
-Menu driven 20x4 display interface
-Eight stereo input control and four output control (using relays)
-interfaces to a CS3310
-Sony IR remote support
-external 256 byte serial EEPROM interface for storing volume, menu, source sel. settings
-power down detecting (with help from an external circuit to flag the PIC when VDD decreases - this forces the software to store all current settings to the EE)
-volume ramping between input source transistions - reduce 'audio shock' to the listener
-auto-repeat volume increment/decrement algorithm
-16 button interface (for the front panel)
This implementation was done with the help of an excellent compiler from Custion Computer Services, Inc. (www.ccsinfo.com)
I read somebody mentioning using the Atmel's powerdown to hold the volume/source settings, I assume, when you turn off the preamp. What happens when the unit is unplugged from the wall outlet? or a power outage? I would recommend using some type of EEPROM in your design to reduce the frustration of having to reset all of the settings - unless if you hard-code you desires as defaults! hee hee - the fun of DIY!
Anyway - I do not know much about Atmel device, but I am certainly curious - as I did my design a couple years ago and worked with what I thought was the best u-controller.
Dave
I know the PIC is not your first choice, but I know it can do the job you want. I am working on a preamp that uses a PIC16C67. The features I implemented seem similar to what you are looking for. Here's what I managed to cram into the internal 8k ROM of the device (with 2k left-over):
-Menu driven 20x4 display interface
-Eight stereo input control and four output control (using relays)
-interfaces to a CS3310
-Sony IR remote support
-external 256 byte serial EEPROM interface for storing volume, menu, source sel. settings
-power down detecting (with help from an external circuit to flag the PIC when VDD decreases - this forces the software to store all current settings to the EE)
-volume ramping between input source transistions - reduce 'audio shock' to the listener
-auto-repeat volume increment/decrement algorithm
-16 button interface (for the front panel)
This implementation was done with the help of an excellent compiler from Custion Computer Services, Inc. (www.ccsinfo.com)
I read somebody mentioning using the Atmel's powerdown to hold the volume/source settings, I assume, when you turn off the preamp. What happens when the unit is unplugged from the wall outlet? or a power outage? I would recommend using some type of EEPROM in your design to reduce the frustration of having to reset all of the settings - unless if you hard-code you desires as defaults! hee hee - the fun of DIY!
Anyway - I do not know much about Atmel device, but I am certainly curious - as I did my design a couple years ago and worked with what I thought was the best u-controller.
Dave
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.