uController for Amp

What people are working on at the moment
User avatar
izzy wizzy
Old Hand
Posts: 1496
Joined: Fri Nov 02, 2007 7:02 pm
Location: Auckland NZ
Contact:

#1 uController for Amp

Post by izzy wizzy »

I've had a number of false starts at this but I have way more spare time now going forward. The sort of thing I'm hoping for is kinda based on Pete Millet's 813 amp uController here http://www.pmillett.com/813_se_triode_amps.htm

My GM70 PP amps are fixed bias and it is a bit nerve wracking that loss of bias could be expensive so monitoring the GM70 bias supply is one input.

Now and then, I'd like to change the bias of the GM70s. So far the bias has remained remarkably stable but they will move and I'd like to avoid the need to have test points and meter to plug in so display of bias is another feature. It might be another monitoring point(s) as well. Seeing both halves at once would make biasing way easier.

The amp has damper diode rectification for the finals and DH rectifier for the front end so is now easy start; it all comes up slow. I don't want to drag mains all over the amp so a relay to turn the thing on at the back with a low voltage push button or simple switch start/stop at the front to turn on via the uController would be good.

There might be some other things later on. So it sounds like a simple uController with a 16x1 LCD display, some OP amps to buffer the voltages and power supplies to feed it all.
User avatar
izzy wizzy
Old Hand
Posts: 1496
Joined: Fri Nov 02, 2007 7:02 pm
Location: Auckland NZ
Contact:

#2 Re: uController for Amp

Post by izzy wizzy »

From Mr Idler's Millett LR + TP Opus + AMB α24 reboot thread
jack wrote: Fri Sep 03, 2021 5:21 am I'm with the other Nick here - simple 8-bit ATmega328 or similar is fine, as is the ATtiny24 stuff (Atmel are now Microchip).

Rather than select a uP now, first try to work out what peripherals you need and what other level of I/O, then add a bit spare! Things like an internal clock (does away with external xtal if you don't need precision clocking), internal EEEPROM (as opposed to program) memory does away with external configuration memory, decent (free) development environment (maybe Eclipse based) with Git integration (if you want an SCCS), cheap development boards (normally manufacturers produce these as loss-leaders), do you really need 10 or 12-bit ADCs or will 8 do (the more bits, the slower the ADC and the more care you need with board layout and power quality)... Choose you uP on the basis of your priorities and needs, not on emotion.

The thing about the Atmel stuff is there is a HUGE support base out there, e.g. at AVR Freaks and the ATmega328P was the base for the original Arduino, so there's a world of free libraries out there.

If you're not too worried about overall performance, the Arduino libraries are really nice & simple - as a professional developer myself, I rather snobbishly looked down on some of the coding in the original libraries, but in recent years the quality has improved dramatically. Note that the Arduino libraries can be used by other uPs other than official Arduino ones - The Espressif Systems ESP-series stuff can also use them (it's an option - Espressif also have their own environment) - MSP430s are the same as the ESPs - Texas have their own "Driverlib" but you use the Arduino libraries if you want.

The more capable uPs also support free small real-time o/s, e.g. FreeRTOS

I now use a fair few ESP32s as they have WiFi built in (plus are dirt cheap) and MSP430s as they are ultra low power, but if you need simple, then go with the ATmega stuff.

Simple is good!
I'm after something that is achievable with my limited knowledge so am keen to lean on the work of others and use whatever libraries/code that works and glue it together. This isn't high performance stuff and my programming career was over 18 years ago and not particularly "clever" using VB and SQL to support early alternative telecom provider platforms. I don't know C/C++ or machine code but hey, hopefully my background will be OK enough. So far been doing some C tutorials and it's been OK. I'm sure the real world will be different.

This article http://www.avr-asm-tutorial.net/avr_en/ ... 4_lcd.html look like the kind of architecture that might work.

So that leads to development environment and how to get the program into the AVR (I think they're called)

This thing looks like something that may do the job https://www.jaycar.co.nz/isp-programmer ... wxEALw_wcB

Then there's the development environment but I haven't quite got that far yet. I've been babied on that front coming from VB and VBA (access) background. I suspect this isn't going to be like that especially as I'll be looking low cost/free. Sometimes free means hard work and doesn't pay off long term so possibly low cost might be better?

Anyway, onwards with the C tutorials for now.
User avatar
jack
Thermionic Monk Status
Posts: 5493
Joined: Wed Dec 29, 2010 8:58 pm
Location: ɐılɐɹʇsnɐ oʇ ƃuıʌoɯ ƃuıɹǝpısuoɔ
Contact:

#3 Re: uController for Amp

Post by jack »

You'll be wanting the Arduino environment.

I wouldn't worry about building your own LCD controller unless you really want to get deep into that - you can buy very very cheap SPI/I2C controlled alphanumeric and graphic LCDs and oleds from the usual sources. Arduino libraries are available for these so you can just concentrate on the important stuff.

There is almost certainly no need whatsoever to get into assembler/machine code - it's so rare it's needed, just forget it exists. Only go there if you are doing enormously time critical stuff and you're counting processor cycles for some reason. Stick with C/C++.

There are loads of Arduino tutorials around. If you have the mindset of a programmer, even 20 years ago, you're already at an advantage over most Arduino users.

C has plusses and minuses - it's really easy to pick up as it has so few structural elements - for/while/if-then-else/case/functions/subroutines etc. constructs, all of which you'll be familiar with.

The downside is that C provides very little protection if you make a mistake, so the compiler cannot help you if you try to write to an illegal address or trash the stack.

All the libraries are in source code, so a very good way of learning is to look at a chunk of code and to try to work out what it's doing - every time you come across a construct that you're not familiar with, look it up.

The Arduino stuff is a mixture of C and C++, but the C++ is generally very simple for various reasons, the main ones being that C++ can be heavy on stack and other memory usage, things that uProcessors generally don't have a lot of.

In a couple of days you'll be flying along.

For my sins, I was on the ANSI committee that standardised C (X3J11) and helped edit a couple of the better known advanced C++ books...
Vivitur ingenio, caetera mortis erunt
User avatar
Nick
Site Admin
Posts: 15706
Joined: Sun May 06, 2007 10:20 am
Location: West Yorkshire

#4 Re: uController for Amp

Post by Nick »

IMHO, there are two paths you can go down. Arduino which gets you going quicker and requires no additional hardware, there are simple dev environments and loads of libs and tutorials. But the downside is the additional hardware is needed on the dev board, and if you want to build the processor into the final product you will need to copy the additional hardware to allow programming after build. The bare bones approach needs more work up front and a programming interface like the one you found, and you build the 6 pin header into your target board to program the chip in place. That way needs the free and perfectly good atmel build tools and libavr to give you lots of useful primitives.

I use Atmel Studio 7.0 on my windows laptop for most dev now as its mainly small bits of code. If I was doing something more complex I would probably switch to linux as I am old and set in my ways :-)

I agree, using i2s can be a perfectly good way of talking to a LCD display as it will eat up I/O otherwise which can be a bit scarse on the smaller chips. But either way works fine.

I would decide if you want a 5v or 3v3 system as the older parts are both and the newer 3v3 only. If you want to integrate voltage sensors into the system, I would suggest using external comparators and opto couplers to allow the digital and analogue sides of the system to be isolated. Likewise isolated DC;DC converters can be useful to power parts of the system that you want to keep separate if you are looking at HT or for noise reasons. If you are going to switch mains transformers on and off make sure you use random switching SS Switches or do what I do now and use mechanical relays. However IXYS do some useful opto isolated mosfets which are great at switching B+ up to about 1kv https://www.ixysic.com/home/pdfs.nsf/ww ... C1786J.pdf I use one in the two box phono to isolate the B+ from the umbilical if it gets unplugged.
Whenever an honest man discovers that he's mistaken, he will either cease to be mistaken or he will cease to be honest.
User avatar
izzy wizzy
Old Hand
Posts: 1496
Joined: Fri Nov 02, 2007 7:02 pm
Location: Auckland NZ
Contact:

#5 Re: uController for Amp

Post by izzy wizzy »

Thanks both for putting forward the different ways to go.

I'm going with a feeling of what I'm trying to achieve/learn and my admittedly brief look at the Arduino way vs the bare bones approach I've been looking at more already, has me leaning more to the latter. I may regret that when I run into trouble.

This thing here http://www.avr-asm-tutorial.net/avr_en/ ... 4_lcd.html seems to have most of the processor/display bit with enough inpouts for my use and most of what Pete Millet did has the interface bits/ideas to the amp. It also has an example of a voltmeter. From what I can make out, the link above has examples/links to code to make the display go but not looked too hard at that bit yet. I think this direct aspect of this project is what I'm after even if I'm using code blocks/functions of others.

I'll look a bit more at the Atmel Studio and figure out an overall architecture in a drawing.
User avatar
Nick
Site Admin
Posts: 15706
Joined: Sun May 06, 2007 10:20 am
Location: West Yorkshire

#6 Re: uController for Amp

Post by Nick »

That board is using 5 lines for the LCD, i2s would only need 2. But it may be a good place to start, it shows the use of the programming interface, and its simple enough to get you going. There is nothing stopping you unplugging the LCD and using the lines if needed.
Whenever an honest man discovers that he's mistaken, he will either cease to be mistaken or he will cease to be honest.
User avatar
jack
Thermionic Monk Status
Posts: 5493
Joined: Wed Dec 29, 2010 8:58 pm
Location: ɐılɐɹʇsnɐ oʇ ƃuıʌoɯ ƃuıɹǝpısuoɔ
Contact:

#7 Re: uController for Amp

Post by jack »

For Atmel stuff, 90% of the time I use Microchip Studio (which is based on Microsoft's Visual Studio) - I don't use the Arduino stuff unless I'm modifying an existing project.

Atmel Studio 7.0 was replaced by Microchip Studio which covers all the Atmel & the newer SAM Microchip stuff - the other Microchip processors (PICs etc.) are covered by MPLAB X.

So it's really Microchip Studio that you want... Still free though.

There are a bazillion development boards at very cheap prices out there. One thing worth considering, bearing in mind how cheap this stuff is, is to develop on a more capable processor, i.e. one with loads of I/O and memory, then resize to one that is maybe better suited for production when you know how much memory & how many I/O lines you'll need. It's easier to do this if you start with a "parameterising mentality", i.e. avoid "magic numbers" (like explicit I/O pin numbers) like the plague - create a HAL (Hardware Abstraction Layer) header file where all hardware-specific stuff like what-pin-does-what stuff is assigned to #defined names, e.g. (a butchered example from an MSP430 project, but the principle is identical):

Code: Select all

#if !defined(__HAL_H__)
#define __HAL_H__
// Some compilers support "#pragma once" to prevent inclusion of a header file more than once
/**
 * \file main.h
 *
 * \brief Main program common header
 *
 * \author	Nick de Smith
 * \date	09/12/16
 * \version	X0.1
 */

enum
{
	PRODUCT_TEST0 = 0x0042,
	PRODUCT_TEST1 = 0x0043
};

#if defined(__MSP430FR5969__)

// MSP-EXP430FR5969 Launchpad I/O
//	Red LED		Port 4.6
//	Green LED	Port 1.0
//	Button 1	Port 4.5
//	Button 2	Port 1.1
#define GREEN_LED	GPIO_PORT_P1,GPIO_PIN0		// Green LED on FR5969 LP
#define RED_LED 	GPIO_PORT_P4,GPIO_PIN6		// Red LED on FR5969 LP

#else if defined(__SOME_OTHER_PROCESSOR__)

// Values for SOME_OTHER_PROCESSOR
#define GREEN_LED	GPIO_PORT_P2,GPIO_PIN1		// Green LED on SOME_OTHER_PROCESSOR
#define RED_LED 	GPIO_PORT_P3,GPIO_PIN4		// Red LED on SOME_OTHER_PROCESSOR

#else

#error Processor not supported!

#endif

// Paranoia checks
#if !defined(GREEN_LED) || !defined(RED_LED) 
#error One or both the LED definitions are missing
#endif

#endif // !defined(__HAL_H__)
In your code, always just use the defined NAMES, not some magic number. When moving to a different processor, just edit the HAL header file accordingly and re-compile. Many compilers define the name of the target processor so it's available in your code to do conditional compilation, in this case, the compiler has defined __MSP430FR5969__ which is a Texas Instruments ultra-low-power 16-bit processor - my HAL file can check that the code is being compiled for the correct (or a supported) processor and forces a compilation error message (stop the compilation) if an attempt is being made to build the code for an unsupported target.

If you start to get serious about this, consider using JTAG to program & debug your projects - It's very cool & powerful...
Vivitur ingenio, caetera mortis erunt
User avatar
izzy wizzy
Old Hand
Posts: 1496
Joined: Fri Nov 02, 2007 7:02 pm
Location: Auckland NZ
Contact:

#8 Re: uController for Amp

Post by izzy wizzy »

Been trying to get a basic architecture together to determine controller direction, size of LCD, I/O required and external input processing stuff.

Microchip studio installed but not played with it yet. In my travels around the web, I seem to have found code that will drive the LCD the way I want. Also been looking at controller options.

This is the basic architecture of the controller bit

Arch1.jpg
Arch1.jpg (194.64 KiB) Viewed 3637 times

BIAS1 and 2 will be driven by op amp comparators from the GM70 bias sampling resistors which are grounded.

ON/OFF is a push button to make the amp go and stop. The relay and it's contacts will turn the mains on and off.

-bias is from the negative supply in order to monitor it being there or not

So far this thing will:
- display bias for each GM70 at the same time
- monitor the bias supply and shut down if it disappears
- monitor each GM70 bias and shut down if they go too high
- start and stop the amp
- log hours of use for valve life purposes

I'm assuming so far I'll need a controller with ADC on board; some don't seem to have them. Many that have ADC have the option for an external reference. Can't quite work out yet if that's for accuracy or noise reasons? I only need the thing to be reasonably accurate with the emphasis on being repeatable and consistent.

Not sure I'll need a Xtal as nothing is being timed very accurately.

I was looking at this USB ISP Programmer https://surplustronics.co.nz/products/8 ... rammer-usb. The support documentation for the bought product derived from this project https://www.fischl.de/usbasp/#gallery gives a range of supported AVR chips. This got me a bit confused as I had thought this type of programmer would do a fuller range of controllers not just a select few. Obviously I haven't looked too far into this yet but at the moment, I'm guessing I wouldn't want to choose a USB ISP programmer and then choose an AVR controller it doesn't support. A part of me thought these gizmos were a bit more universal i.e. good for one Microchip AVR, good for a whole bunch of them.

Not much of this are my ideas; pinched most of it from Pete Millet's site. He doesn't use opto isolators or isolated DC DC convertors. That might be a mistake but if this thing is audible, then I think I can go down that route later.
User avatar
ed
retired
Posts: 5384
Joined: Thu Jun 21, 2007 4:01 pm
Location: yorkshire
Contact:

#9 Re: uController for Amp

Post by ed »

Hi Stephen

I haven't contributed to this thread but thought I'd add my two penneth.
I started with Atmel tiny and then mega back in the day using the dragon to interface. This was brill, but I was using assembler mostly for historic reasons(it allowed me to take a trip back down memory lane). Back then I was using the ubiquitous hd44780 for all projects as it was easy to program natively. There are some examples of sig gens, preamps with digi pots and bias control for the sv572 amp on my website.

When I got on to weather stations I found the need for lots of peripherals was made much easier with the arduino libraries and I switched to the ST7735 lcd at the same time. SPI is much more pin efficient than parallel data lines for LCD control.
I have also used the 1" ssd1306 screens which are fine if you like reading small

I would advocate the arduino environment to anybody getting into this. Atmel(microchip) studio 7 is great but the arduino libraries make light work of stuff with peripherals. I still use Arduino IDE because it seemlessly supports the ESP processors I now use.

For hair-shirt if you insist on a naked atmel chip on a board I have written programs in the arduino ide and then uploaded the hex code to a naked 328 using the dragon...this is brill if you don't have much space.
There's nowhere you can be that isn't where you're meant to be
User avatar
Nick
Site Admin
Posts: 15706
Joined: Sun May 06, 2007 10:20 am
Location: West Yorkshire

#10 Re: uController for Amp

Post by Nick »

Small points, you don't need the 5v pull ups for the i/o you can enable internal pull up for the inputs. I would add some clamping around the analogue input excess voltage is only too easy and probably fatal.

The rest is mainly a "this is how I do it" sort of thing, so not going to argue for or against that.

I suspect the limited range of that programmer is because its from 2012. It looks to me as if Ardueno has driven out the cheap AVI programmers from the market now. The available list seems a lot smaller than the last time I looked. I would have suggested the AVR Dragon, but see its discontinued. Maybe Microchip are getting rid of AVR. Seems very strange.
Whenever an honest man discovers that he's mistaken, he will either cease to be mistaken or he will cease to be honest.
User avatar
ed
retired
Posts: 5384
Joined: Thu Jun 21, 2007 4:01 pm
Location: yorkshire
Contact:

#11 Re: uController for Amp

Post by ed »

I suspect the limited range of that programmer is because its from 2012. It looks to me as if Ardueno has driven out the cheap AVI programmers from the market now. The available list seems a lot smaller than the last time I looked. I would have suggested the AVR Dragon, but see its discontinued. Maybe Microchip are getting rid of AVR. Seems very strange.
I was going to write as much but decided against it...however

I'm a cynic, as well you know.....when Microchip bought Atmel my first thought was..ah ha! they are buying the competition, either the AVR chips will go or the pic chips will go...I was curious to see which.
There's nowhere you can be that isn't where you're meant to be
User avatar
izzy wizzy
Old Hand
Posts: 1496
Joined: Fri Nov 02, 2007 7:02 pm
Location: Auckland NZ
Contact:

#12 Re: uController for Amp

Post by izzy wizzy »

The only thing I've invested so far is time so not wedded to anything yet so still listening.

I can understand a path to what I want to do so far but if I can't easily and cheaply get the program into the processor then maybe that's the stumbling block. I'm not bothered it's basic and unsophisticated. I kinda like that.

I thought I could see a processor for $3 that would work and a display for about $15. The rest is easy but the programmer seems not unless I'm missing something.

I'll go and look at arduino to see what's up. My gut says it's something like a raspberry pi community type thing.
User avatar
Nick
Site Admin
Posts: 15706
Joined: Sun May 06, 2007 10:20 am
Location: West Yorkshire

#13 Re: uController for Amp

Post by Nick »

The Arduino is in effect the chip with an on board programming interface with a usb interface. I think Simon has done some stuff with Arduino.
Whenever an honest man discovers that he's mistaken, he will either cease to be mistaken or he will cease to be honest.
simon
Thermionic Monk Status
Posts: 5600
Joined: Thu May 24, 2007 11:22 am
Location: People's Republic of South Yorkshire

#14 Re: uController for Amp

Post by simon »

Yes I played about with arduino a while back. Need to get back to it one day. It worked well for me - I knew C 20 years previous but didn't understand all the hardware requirements. Didn't need to with arduino, just plug it in via USB to the laptop. And boards were cheap on ebay, £13 for the mega.

The thriving community really helped as it was easy to Google projects and find example code. How good it was is another matter, but there was a lot to go at out there.
User avatar
Nick
Site Admin
Posts: 15706
Joined: Sun May 06, 2007 10:20 am
Location: West Yorkshire

#15 Re: uController for Amp

Post by Nick »

Had a search. As long as you only want serial programming (ie not the xmega devices) then the Sparkfun Pocket Programmer looks fine.

https://www.sparkfun.com/products/9825

It seems to have a 10 pin to 6 pin converter so you can use either on your board.

Looks like the AVR Dragon has been replaced by the ATATMEL-ICE-BASIC which supports JTAG, SWD, PDI, TPI, aWire, SPI and debugWIRE interfaces. Thai's probably more than you need at the moment.
Whenever an honest man discovers that he's mistaken, he will either cease to be mistaken or he will cease to be honest.
Post Reply