Hello, I'm building a volume control using the PGA2311 IC and the PIC16F684 microcontroller. My project goals are to allow volume up/down, mute, and amplifier power off (via a relay), and it needs to receive its signal from both pushbuttons and a universal remote control (xbox360 remote). I know nothing of the programming involved but can easily take care of the hardware. Anyone know of such a setup that has code available? If not, some links to learning what I need to do this would be a great help.
Hi
I'd strongly suggest you invest some time in learning some form of programming language !
Although the opinions may differ I'd tentatively recommend jal.
A few years ago there was a similar project in Elektor (the audiolink).
The source is available and quite easy to adapt to your hardware.
Feel free to ask further assistance
It's good to invest some time in learning how to do it. It was certainly a good thing to learn about programming stuff. Just have fun.
HTH Alien8
I'd strongly suggest you invest some time in learning some form of programming language !
Although the opinions may differ I'd tentatively recommend jal.
A few years ago there was a similar project in Elektor (the audiolink).
The source is available and quite easy to adapt to your hardware.
Feel free to ask further assistance
It's good to invest some time in learning how to do it. It was certainly a good thing to learn about programming stuff. Just have fun.
HTH Alien8
Well, I found this link: TheNewBoston – Free Educational Video Tutorials on Computer Programming and More! C Would that be a good place to start? Also, the part that I'm having the most difficuty with is that I'm not quite sure I grasp the description on the PGA2311 datasheet as to the implementation of the control data.
Hi Lingwendil
My suggestion was a so called higher level programming language...
There are a lot of different choices here. Basically it turns out to be a lot easier if you pick a high level language. Here the compiler (the program that actually writes the machine code and spits out a hex file) takes care of the more difficult parts for you. The disadvantage is that time critical software may not work correct... On the other hand a lower level language expects the progammer to know a lot more of how to make a microcontroller work, but you are more in control of things.
As you've probabely guessed a low level language has a very steep learning curve........
My suggestion was to use JAL - Just Another Language (google it) which is very easy to start with. As said above, Elektor has a project published based on this language.
As to control the PGA chips : basically you need to 'select' it by pulling the cs line low (the bar above it in the datasheet means 'active' when low) and send two bytes - one for left, one for right by putting a bit on the data line and toggling the clock line. The PGA reads in a bit at each low to high transition of the clock line.
This is a common way to address and transfer data from chip to chip.
You could eg. use the data and clock lines connected to different chips and 'select' the right one to talk to using the cs line. Just leave it high for the ones you don't want to 'listen' ... Once you start you'll find yourself needing more and more pins on your microcontroller. The chip makers solved part of your problem here !
Examples are found easily on the web. The legendary preamp from mhennessy uses some of these tricks.
Good luck!
My suggestion was a so called higher level programming language...
There are a lot of different choices here. Basically it turns out to be a lot easier if you pick a high level language. Here the compiler (the program that actually writes the machine code and spits out a hex file) takes care of the more difficult parts for you. The disadvantage is that time critical software may not work correct... On the other hand a lower level language expects the progammer to know a lot more of how to make a microcontroller work, but you are more in control of things.
As you've probabely guessed a low level language has a very steep learning curve........
My suggestion was to use JAL - Just Another Language (google it) which is very easy to start with. As said above, Elektor has a project published based on this language.
As to control the PGA chips : basically you need to 'select' it by pulling the cs line low (the bar above it in the datasheet means 'active' when low) and send two bytes - one for left, one for right by putting a bit on the data line and toggling the clock line. The PGA reads in a bit at each low to high transition of the clock line.
This is a common way to address and transfer data from chip to chip.
You could eg. use the data and clock lines connected to different chips and 'select' the right one to talk to using the cs line. Just leave it high for the ones you don't want to 'listen' ... Once you start you'll find yourself needing more and more pins on your microcontroller. The chip makers solved part of your problem here !
Examples are found easily on the web. The legendary preamp from mhennessy uses some of these tricks.
Good luck!
I am not sure this is still true but when I was still working on this RC5 was developed by Philips and they released it for use unlicenced. It was very popular so they developed a new improved version RC6 which they licence to manufacturers.
Hence you may find it difficult to find data on RC6 on the web.
Regards,
Andrew
Hence you may find it difficult to find data on RC6 on the web.
Regards,
Andrew
For RC6 check : rc6 encoding
Are you sure all the commands on your remote are RC6 ? There is also an extended (more than 64 commands) RC5 available. Sometimes that is used and mistakenly advertised as RC6.
I once started on a decoding algorithm for RC6 but since I have a programmable remote I have no more need for that.
A8
Are you sure all the commands on your remote are RC6 ? There is also an extended (more than 64 commands) RC5 available. Sometimes that is used and mistakenly advertised as RC6.
I once started on a decoding algorithm for RC6 but since I have a programmable remote I have no more need for that.
A8
some very old arduino code of mine, maybe it will help you get started:
Index of /arduino_libs/pga23xx
again, just some old stuff that is not meant to be 'perfect' but to give you an idea.
I had my older pga chip behind a port expander (i2c) so that it would be easier to 'remote' the thing.
Index of /arduino_libs/pga23xx
again, just some old stuff that is not meant to be 'perfect' but to give you an idea.
I had my older pga chip behind a port expander (i2c) so that it would be easier to 'remote' the thing.
'any of the chips' - meaning cpus or i/o chips?
I'm happily using the mcp23008 as a port expander for the LCD side of things. i2c is i2c
I'm currently in code-reduction mode, since I'm totally out of ram, rom and eeprom! not 100% sure I can fit the pga code into the lcduino on first ship; but it will be very easy to comment out the relay stuff and put the pga code in, instead (I plan to do that eventually, as an option). I'm HOPING I can fit both in flash but I keep running out.
watch the amb.org forums (and diyaudio as well) for when we make the lcduino announcement. at that point, code will be published and people can play with it.
I'm happily using the mcp23008 as a port expander for the LCD side of things. i2c is i2c
I'm currently in code-reduction mode, since I'm totally out of ram, rom and eeprom! not 100% sure I can fit the pga code into the lcduino on first ship; but it will be very easy to comment out the relay stuff and put the pga code in, instead (I plan to do that eventually, as an option). I'm HOPING I can fit both in flash but I keep running out.
watch the amb.org forums (and diyaudio as well) for when we make the lcduino announcement. at that point, code will be published and people can play with it.
nope, the 'arduino' (atmel series of megaXXX chips + bootloader) is what it is. I think there are some simulators or something, but the chips are $5 and so .. what's the point?
for a while they were unobtanium. now the vendors have them back in stock again.
the arduino generally means the 168 or 328 chip but it can also mean that new smd-only version. not very diy friendly and not very affordable, either. at that point, its getting close to an ARM one-board linux system.
you never want the 168 chip anymore. its half the program space (and others) and not even that much cheaper. my source can just barely fit in the 32k that the 328 series chip has. now, a very simple app could use the 16k version but programs have a way of growing I just would stay with the current 328 'arduino's. like this:
ATMEGA328P-PU Atmel Microcontrollers (MCU)
looks like mouser has 47,643 in stock, right now
so for the moment, the arduino needs no pin-compatible sub.
for a while they were unobtanium. now the vendors have them back in stock again.
the arduino generally means the 168 or 328 chip but it can also mean that new smd-only version. not very diy friendly and not very affordable, either. at that point, its getting close to an ARM one-board linux system.
you never want the 168 chip anymore. its half the program space (and others) and not even that much cheaper. my source can just barely fit in the 32k that the 328 series chip has. now, a very simple app could use the 16k version but programs have a way of growing
I just would stay with the current 328 'arduino's. like this:ATMEGA328P-PU Atmel Microcontrollers (MCU)
looks like mouser has 47,643 in stock, right now
so for the moment, the arduino needs no pin-compatible sub.
I once did have 'universal' IR learning but since I got short on program space, I had to comment out all but the sony IR code stuff. the sony stuff tends to work better (no strange 'repeat codes' or shift codes like other protocols use). I do plan to restore the multi-protocol stuff back when I can compress the program a bit more and re-gain that needed space.
every multibrand remote can invoke a sony emulation mode, though, so I don't see it as a major problem even if the rc5/6/nec stuff has to be a developer build instead of a production build.
hard to believe I now have to remove code for X to make room for Y; but once you reach max program space, that's life in the embedded world.
every multibrand remote can invoke a sony emulation mode, though, so I don't see it as a major problem even if the rc5/6/nec stuff has to be a developer build instead of a production build.
hard to believe I now have to remove code for X to make room for Y; but once you reach max program space, that's life in the embedded world.
Ah, I get you. Just this afternoon, I found the codes to allow the Xbox remote to control Sony televisions. Fingers crossed, but this should allow me to control the LCDuino with my 360's remote. BTW, can you recommend any code to allow my Arduino to display basic date and time on the LCD screen? I think I'd better show SWMBO some evidence that this pile of parts and wire actually does something.
if you don't have a RTC chip, you can get by with 'millis()' calls and count them before they rollover. the RTC chips are about $5, the xtals less than $1 and I love the fact that the 1302 can use a supercap as a battery backup. smaller than a coin cell and should not need replacing. does not last a long time (a week or so) but its enough to keep things running while you reboot or move the system. the 1307 is native i2c (good) but they dropped supercap support (bad), so I used the ds1302 instead and kept it 'local' since its spi (more wires).
ladyada.net is another place (if you are new to arduino) to find code examples. and hardware, too. pretty active forums, as well.
ladyada.net is another place (if you are new to arduino) to find code examples. and hardware, too. pretty active forums, as well.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.