Let's Design and Build a (mostly) Digital Theremin!

Fred, I'm very sorry to hear about the issues you are running into with PSoC.  (There can be many gotchas associated with programmable devices - Altera's earlier block ram used the falling clock to do the write which was weird and rather severely impacted timing margins.  DLLs in Xilinx offerings often weren't what people were expecting in the way of PLL behavior.  It's all in the fine print - after enough users complain.)

When it comes down to it, the tools need gobs of development in order to not put up roadblocks with respect to what the hardware can actually achieve.  A company can make the best HW in the world but if they have poor tool support one would likely never know it.  I suppose that's why I don't look too far afield of Altera and Xilinx as their toolset support is incredible.  Tried Lattice and had an OK experience, but it really wasn't the same.

If you could move more of your design into purely digital it might save you some heartache (though it will give you some initial headaches).  I'd be happy to help you in this regard in any way I could.  For example, first order PWM is pretty trivial, second order is entirely doable, third order MASH is simple but requires a small DAC.  NCOs generating ramps and triangles are also trivial, as are fixed frequency sine waves.  First order filters and cascades of them are nothing, second order with fancy Q and precise cutoff are where the weirdness starts.

Thanks for your offer of help, Dewster..

Have now moved from angry frustration to actually finding it quite funny! - When I talk about using PWM blocks here, its at simplest most trivial level - all I need as two dividers that can either be programmed to divide be 2,4,or 8,and / or a pair of counters tapped at 1 (input) 2, 4 and 8 going into a MUX..

It was bitter enough having to dedicate two complex 16 bit TCPWM blocks for something so trivial (at first I created a specific UDM component for the job, but soon found that I had run out of UDM resources, so moved this function to TCPWM blocks, and everything fitted and ran well - when using clock-chain clocks )

I am now going back over the UDM components to see if I can implement some in LUT state machines.. The fitter report is not detailed enough (doesn't give the equations for the fitted logic, which is a major bummer - perhaps it does when it actually manages the fit) but I think the bottleneck is with the registers (DFF and the like)

I have seen an "escape" route - Not a route I really wanted to go, but if I must.... I had planned on a basic build with just 1 PSoC4, and limited user control implemented with potentiometers- this was going to have a serial port for communication with a second board having a comprehensive digital user interface and more audio processing stuff.. The idea was that the first board had place for digital potentiometers and was wired ready to drive these, but on the simple theremin the digital pots would instead go to manual user pots... these being replaced by digital pot IC's if the second board was added (the idea was to simply have the manual pots wired to headers which plugged into the IC sockets intended for the DPots)

I really wanted to keep the first board a simple stand-alone theremin with register switching.. The second PSoC will need almost no UDB resources -so I could palm off the register switching to this one, and make the first board a non-register-switching stand-alone theremin.. This route probably makes a lot of sense even from a selling perspective - But its still frustrating.. Adding register switching for the cost of a selector switch, and using resources inside the chip which cost no extra - for that to be inhibited by something stupid really annoys the hell out of me!

Fred.

Ok - Got some feedback.. This issue only applies to the PSoC4, not to the 3+5..  PSoC4 is quite restricted and its a big mistake to think its similar to the 3 or 5 - its a low cost cobbled down part.

>> Update:

Ok - I am an ignoramus! ... I have just discovered a whole suite of deep-level editing tools for the UDB.. I have only been playing with the tip of the iceberg (the logic gates etc available in the main component catalog) and linking these to make 'components' ... But hidden away, each UDB has a dedicated state machine, data-path block, a counter, status and control registers.... And all of these can be accessed with a dedicated UDB editor, complete with Verilog code generator.. The only problem is, it will take me longer to read the damn manual than it took to put the whole design together..

>> Update:

A few small changes to the 'components' (after understanding the PLD structure better) and I was easily able to fit the additional logic to implement register switching, and have spare capacity (fitter now tells me I have used 56% - but I dont trust the fitter one bit ;-)

The fitter was telling me, before I made some minor adjustments to the components, that I needed another 4 UDB's to fit the design! (there are a total of 4 UDB's in the device) .. It should have been able to re-route the resources automatically IMO..

You are right, Dewster - Its the tools that are probably the biggest problem, not the silicon.

"Its the tools that are probably the biggest problem, not the silicon."  - FredM

This is why I'm fairly averse to using programmable devices from any but the big 2 - and if you ask me even their tool teams are somewhat wildly out of control when it comes to code bloat.

================

Updated the Hive Excel simulator to reflect the latest HW changes:  http://www.mediafire.com/download/4vy7d202xu7fdbs/HIVE_SIM_2014-10-08.xls

I'd really like to move the simulator into a more stable, cross-platform, standalone application.  Does anyone have any suggestions as to how I might do this?  Every time I look into widgets and such I get deflected by all the complexity and weirdness and massive learning curve.  And I don't want to require people to install a bunch of crud just to run my app.  Maybe Python & TK?  (I have zero experience with either.)  I'm totally open to suggestions here.

================

The SPDIF TX component is actually quite central to this project as it generates the "heartbeat" interrupt for all internal audio processing.

Dewster, you are WAY beyond me in this area.. I always had problems with the tools - even the simple ones like linkers for standard MCU's.. It always took me longer trying to decipher the cryptic error messages than it did to write the code!

So when it comes to Python or TK, Sorry, I have heard the names, but have no idea how they'r used..

I have just hit a brick wall - Its a strange one, been here many times before.. Its not a "physical" wall like not being able to fit the blocks in the chip- its the other (almost worse) kind - purely psychological..

I have the chip completely designed and tested ( a full register switching analogue and mixed signal theremin - a lot off-chip, but all the logic and some analogue - phase comparators [3] mixed signal heterodyning [4 mixable waveforms] 4 octave register switching for both internal mixed signal and external analogue heterodyning, Volume circuitry using 12bit ADC, Four 10 bit PWMs for level control,SPI for digital potentiometers, UART for comms to other boards / UI.. Other than dealing with a single ADC interrupt, at present the processor does absolutely nothing! - it will need to deal with serial comms and write the Volume value to a couple of DPots,and write to other DPots if it gets commands to do so - but its a real waste of a Cortex M0!) , as much as I can without all the hardware.. So I must either sit down and breadboard a mass of oscillators and audio circuits, or design and commit to PCB.. I might manage to get my laminator and etching stuff from my old lab to make my own PCBs... But whatever, theres this feeling of being stuck in treacle that I often get at this point.

I am actually quite astounded at getting everything into a $1.50 chip (even £4 module) - I ended up getting more into it than I had planned - and have now used all available pins (cannot fit an encoder, which is a bit sad, because a few more pins and I could perhaps have done the whole thing, UI and all, on the chip)

Its a strange madness this - ;-) ... I could quite easily go back and try to re-arrange things so I could have everything on one chip - Rather than just go with my far more sensible plan of having a simple analogue UI for the basic, and adding another £4 board for DUI and expansion.

Fred.

"... I always had problems with the tools - even the simple ones like linkers for standard MCU's.. It always took me longer trying to decipher the cryptic error messages than it did to write the code!"  - FredM

A long time ago I discovered devcpp, which gives you a nice editor and just compiles without any craziness or rigamarole.  With a few minor edits it even compiles the moldy old code from my college days.

Had Python 3.4.1 installed from a while back.  The interpreter window is kind of interesting in that it lets you try a bunch of stuff without the fuss of compiling which is nice for exploring the language, and it has Tkinter which reportedly is Tcl/Tk.  Literally anything has to be better than VBA in Excel, where every mundane hardware operation (bit shift, modulo without throwing a warning, etc.) is more difficult to implement than it has a right to be.  I'm jumping through hoops and on my knees begging VBA to behave like the hardware it's physically running on, which is exceedingly ironic.

"I have just hit a brick wall - Its a strange one, been here many times before.. Its not a "physical" wall like not being able to fit the blocks in the chip- its the other (almost worse) kind - purely psychological.."  - FredM

I know from whence you cometh (though I'm not trying to put words in your mouth nor define your own particular mental roadblock).  I'm quite fine in the programmable realm, but stick a soldering iron in my hand and it's uphill all the way.  I can do it but I don't exactly relish it.  Solder a switch?  OK - look what I can do!  Solder 21 LEDs and NPN drivers on vector board?  Durr - for some reason it's a battle that takes all day and leaves me drained.

"Solder 21 LEDs and NPN drivers on vector board?  Durr - for some reason it's a battle that takes all day and leaves me drained." - Dewster

Its weird - its not the physical construction / assembly (other than case / mechanical, which is an even bigger wall) -its somewhere before that for me... Its the "commitment" phase I suppose -

I always do a PCB layout, but for prototypes I do this layout on a 0.1" grid, keep top-side tracks to a minimum, and make these tracks straight - the idea being that I can then construct the prototype on pad board in a way that is close to the layout for a real board..

But restricting the layout to 0.1" with straight links (and compulsory vias rather than being able to use component pads to carry signal from top to bottom layer) the board takes a lot more time and is bigger - and this is my first wall... About 1/4 way through the layout I am thinking F**K the money, just do a "real" layout and get boards made. I usually manage to fight this, but somehow it all seems much more difficult after that moment.. 

With the layout done, construction is easy (even for quite a complex board) because I dont need to think about where to wire anything - simply place the components, solder them in place,trim their legs, flip the board over and follow the wiring pattern..

But its a battle getting to that point!

I had beaten that whole dilemma with toner-transfer and etching, there are still restrictions (straight links and extra vias because PTH is beyond my facilities) but dont have access to that kit right now..

Fred

"Its weird - its not the physical construction / assembly (other than case / mechanical, which is an even bigger wall) -its somewhere before that for me... Its the "commitment" phase I suppose"  - FredM

From my test equipment and component buying experience at this point I know that >3/4 of what I purchase will never even leave the shipping box as my research (?) game plan (?) changes day to day.  This makes it really hard for me to commit to even minor investment in what I'm doing, or even to commit my precious breadboard resistors to a permanent life on a dubious vector board.  I kind of miss having a schedule and a manager and lots of prototype cash, but then I suppose this project would never have been entertained in the first place due to likely zero ROI, or rushed out the door half-assed like the Theremini.  But that's part of its charm.  (Whatever you do will be insignificant, but it is very important that you do it.' — Gandhi)

=============

Spent the day looking at a variety of ways to make tables with Tkinter which comes bundled with Python.  There is no base table type (surprise!) so there exist in the wild a few non-optimized solutions by those who have stumbled on this failing.  In lieu of that tables may be built from a grid of an abstract base type that has (IMO way too many) options bound to it (strings / images, fonts, etc.) which require disparate storage for each item, when all I want is to pass it an array pointer and have a bunch of the same width numbers (or at the worst hex) displayed that needn't be edited by the user.  I get how people write widgets for the general case (whatever that is) and indeed write entire languages for some kind of universal ideal in their heads, but there is a efficiency in providing raw fodder that removes the need to anticipate every little thing that a user might possibly desire at a higher level for whatever reason in some indeterminate future. 

Python seems nice for general math and can fake bit manipulation, but C is likely the better language to do hardware simulation as it has explicit width typing with no overflow checks and the like.  Tk (=Tkinter) is actually written in C and placed in a "wrapper" for other languages (go figure).  Not saying C is the best language for everything - indeed I'd like to see more language offerings that are simpler, close to the metal, and that offer robust, efficient, and varied GUI creation.  Abstraction can be an incredibly powerful thing, but the lack of abstraction can be equally powerful - and in many cases present much less of a fake learning curve.  Everyone needs a respite from the annoying details that SW can easily manage for us, but programmers these days are overwhelmed with arbitrary constructs and syntax (compilers are a magic box!) when much of the real work is often nearer the bottom, particularly in engineering.

The Theremin in a way is the perfectly abstracted musical instrument.  So beautifully removed from harsh reality it is almost unplayable by mere mortals.

Some GUI / widgity stuff:

Qt is used for the Altera Quartus FPGA tool and some Linux desktops.

JUCE is used for Pianoteq and Tracktion - an amazing GUI undertaking for just one guy.

wxPython seems kinda dead.

Someone should write a OO language that is somehow GUI-centric at its core.  So when you create an object with private data it's ready for button clicking input and rendering on the screen.

It's kind of strange that the whole interpreted vs. compiled thing is still going on, the best language IMO whould have both options (and I don't mean in the form of a Java virtual machine or whatever - blea).  Briefly looked at Perl but it's kind of ugly and clunky.  Going with Python makes me feel a little like I'm jumping on some kind of fanboy bandwagon (and it doesn't help that with Python 3 they broke backward compatibility).  Sticking with C++ is compiler / linker / library hell. 

Picking up any new language isn't fun, but Python is really loose and probably not my cup of tea.  There isn't a case/switch statement which is fundamental IMO.  Typing and promotion are really hidden.  Integer and other lengths can be infinite, which would be great if there weren't real world limits and speed penalties associated with that.  It seems to be more of an overgrown educational language than anything else.  When trying to talk myself out of watching a movie I have a strong inkling I'll dislike (due to the subject matter, the presence of a particularly loathsome actor, director, writer, etc.) I pour over the bad reviews on IMDb.  Found this Python rant that did the trick and snapped me out of my trance: https://semitwist.com/articles/article/view/why-i-hate-python-or-any-dynamic-language-really.  Python is probably great for doing abstract math stuff, but then why not use numPy?  IMO ideally the bottom level should be quite strict, with fancy top level libraries and such built up from that.

The problem with looking for programming & GUI creation tools is that researching and trying them out can take what seems like your whole life.  And there's the compiler, compile targets, OSes, installers, etc. stuff to take into account.  This programmable world consists of billions of constantly shifting targets and gobs of hype.  It's an incredibly busy turnpike providing an endless supply of new and shiny polished turds. (<=showing my age)

" It's an incredibly busy turnpike providing an endless supply of new and shiny polished turds." - Dewster

LOL ;-) .. I love that description.. It sums up this age, and the whole "technical advancement" industry IMO  - Shiny new turds to put in your pocket - new Iphone turds, new turd tablets, turd baguettes, turd compilers and debuggers, even turd disassemblers... Flying drone turds with fatal laser guided turds to seek and destroy the competitors latest turd.

Us humans are just spectators and victims as the turds fight it out..

LOL ;-)

Fred.