Need to farm out some PIC C programming for PGA 2310 volume control.

GroupDIY Audio Forum

Help Support GroupDIY Audio Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

rlaury

Well-known member
Joined
Jun 5, 2004
Messages
331
Location
Nashville, Tn
I know enough C to be dangerous. I'm looking to farm out the programming part
of this project out. It's pretty straight forward. No weird functions.
I can provide you with a flow chart and details. Let me know your background and experience
if your interested.

RonL
 
You would be better off doing it yourself. If you pay someone it will either be very expensive or the code will be useless. Or, the most likely scenario is that it will be very expensive AND useless. You're better off just taking it slow just figure it out yourself. Divide and conquer: Get the toolchain to work by writing a trivial little program that just toggles a pin. Then write a minimal program to write data to the IC. Break it up into chunks. Try to have fun with it.
 
I coded up an automatic mixer using DPOTs on a PIC (pic24F?)...  Even though I took one night school course in C language, I code in PICs using machine language. As an old analog dog it makes more sense to wiggle ports and whatever one at a time...

The project I worked on never made it to market but it is probably far more complex than you need...  Who knows if I even remember what all I was thinking when I wrote it, my code is not well documented (I'm old.... what was the question?).

I can share or advise, but not looking for actual work (I just got down off my ladder mounting gutter guards on 140' of gutter, so I'm a little tired. )

FWIW I was impressed by how good the DPOTs worked without extraordinary measures (like coordinating gain changes to zero crossings.). I built that capability into the design but never needed to implement it.  That said it was never put into production so customers didn't get their say about how it sounded.

JR
 
I'm old too. I started with the Altair 8080, 6800, and the 6809.
All in assembly. I studied C about 10 years ago and wrote a few things.
But i'm going to get back in it.
 
PIC programming is not so much "C" and more like just reading / writing registers, bit manipulation, figuring out where to put state and how each iteration of the loop changes that state. If you understand hex, pointers and structs, you're good.
 
I love MPLAB from Microchip! Its Free and not too complicated to learn. The simulation function is very handy. They even have it for OSX now a days!

Just be sure to check the data sheets well for the PICs, the older 16f677 (I think it was...) you had to make sure the program pointer didn't overflow at higher addresses. Before you figure why suddenly you have a unwanted goto jump you have lost a lot of hair.

ASM for the win!
 
synthiaks said:
I love MPLAB from Microchip! Its Free and not too complicated to learn. The simulation function is very handy. They even have it for OSX now a days!

Just be sure to check the data sheets well for the PICs, the older 16f677 (I think it was...) you had to make sure the program pointer didn't overflow at higher addresses. Before you figure why suddenly you have a unwanted goto jump you have lost a lot of hair.

ASM for the win!
My first generation drum tuner used an 8 bit PIC (like 16F). I promised myself to never again limit myself to such low resolution.

I ASSume a high level language like C transparently manages the manipulations to cobble together  two 8 bit bytes to make 16 bit data.  Modern 16 bit processors are cheap enough IMO to not consider 8 bitters.

JR
 
I also enjoy programming PICs in assembler language, specially if your timing is crucial, you know exactly how much time each instruction takes, you know exactly what the processor is doing and when it is doing it, with C is a bit more of a gamble in this aspect, yet doing more complicated things in assembler is just a waste of time.
 
user 37518 said:
I also enjoy programming PICs in assembler language, specially if your timing is crucial, you know exactly how much time each instruction takes, you know exactly what the processor is doing and when it is doing it, with C is a bit more of a gamble in this aspect, yet doing more complicated things in assembler is just a waste of time.
When I first went over to the dark side... I bought a C compiler, but never ended up using it...  I ended up reading the definitions of actual code that the C instructions generated and that low level code made more sense to me...

I got a little tangled up trying to write FFT in assembler... but I'm old and drummers are too cheap to pay me for an even better tuner.

JR 
 
JohnRoberts said:
When I first went over to the dark side... I bought a C compiler, but never ended up using it...  I ended up reading the definitions of actual code that the C instructions generated and that low level code made more sense to me...

I got a little tangled up trying to write FFT in assembler... but I'm old and drummers are too cheap to pay me for an even better tuner.

JR

So your drum tunner is programmed in assembler? Nice!

AFAIK the only difference between using the free C compiler on MPLAB VS buying it is that the paid version has a code optimizer so the instructions are less redundant and take less time to compute
 
My guess would be that you only write in assembly if you're looking to save a little money on the chip which I think would only be justified if you're mass producing. Otherwise, it makes more sense to write in C and then do FFT or whatever in assembly and then link it into one executable. Just as fast and way easier.
 
user 37518 said:
So your drum tunner is programmed in assembler? Nice!
Thousands of lines of code, that even I probably couldn't figure out now...    :eek:

I would love to use high level languages but I almost always pursue unusual solutions...

For example to speed up level vs pitch scans to identify resonances, I play 3 octave spaced sine waves at the same time, then read the levels of each coming back from the drum. Trust me you won't find a C routine for that. The trick I used was to sample synchronously, in the octaves I was looking for,,, summing 2x or 4x samples would cancel themselves out...  crude and not perfect, but good enough to perform a fast rough scan across 3 octaves in the time of only one scan.

Later on using a DSP prototype platform I was able to make something like 8 or 10 sine waves simultaneously with the  built in 16B dac, then use FFT to ID loudest return... This was fast enough I could iteratively zero in on the exact resonances much faster. Where I stalled was extracting the phase information... I found the math for FFT phase, just not how to execute the math I needed in code.

of course this model would also benefit from a much richer graphic display, and I even considered adding a touch screen (bought a prototype display and overlay) but.... and I am repeating myself... drummers think my current model is too expensive so, never mind.
AFAIK the only difference between using the free C compiler on MPLAB VS buying it is that the paid version has a code optimizer so the instructions are less redundant and take less time to compute
IIRC the last programing interface I used also compiled C (not optimized) but almost everything I did was too complicated for me to trust C for important stuff... like try generating  8 sine waves simultaneously  (not hard just a bunch of detail work).  The built in DAC was sweet compared to my current model drum tuner where I make sine waves with the PWM output (good enough to wiggle drumheads at desired pitches).

JR

@squarewave... yes if I was paying programmers I'd insist on the most cost effective way...I am personally more comfortable coding down at machine level. These days not very comfortable even doing that... Assembly is useful for managing critical timing issues, and limited processor overhead... the modern stuff is so powerful when overclocked I never came close to running out of clock ticks to do something....  For the console meter project I wrote my own algorithm to perform square root (for RMS calculation).. I didn't even bother to see how C would do that (not as fast as mine I'm sure). FWIW I could have avoided the RMS calculation by using a look up table, but ended up not using the RMS at all. 
 
Try Pinguino, it's Arduino for PIC microcontrollers.

https://www.instructables.com/id/Pinguino-Project-a-PIC-Microcontroller-Based-Ardui/

Don't know which compiler they use though. There are also some PIC32 variants for the environment.

Some PGA2310 code for Arduino (Atmel version) can be found here:

https://forum.arduino.cc/index.php?topic=22404.30

There is even an Arduino library:

https://github.com/kashev/ti-pga2310

Very easy to use:

https://github.com/kashev/ti-pga2310/blob/master/PGA2310_Arduino_Demo/PGA2310_Arduino_Demo.ino

It's more like C++ though.
 

Latest posts

Back
Top