I tried Google Protocol Buffers to describe and transfer modules’ schema before. This approach, however, did not work well because it required large amount of resources both in program and in RAM spaces of a PSoC processor. It limited available resources for module functionality. I finally gave up the approach.
I am trying another approach to describe a module using JSON and to compile it into a parameter table implemented using C macros. The module program does not have to include the schema. Sharing the JSON schema file by Analog 3 modules is good enough. It is nice if the module has the schema internally though. Google Protocol Buffer may help compressing the data in the case.
Here is an example of schema and generated table for MIDI Gateway module:
"name": "MIDI channel",
"choices": ["mono", "duo", "poly 4", "poly 5", "poly 6", "poly 8", "poly 10", "poly 16"]
#define P_N1_MIDI_CHANNEL_OFFSET 0
#define P_L_VOICES_OFFSET 1
#define P_B_RETRIGGER_OFFSET 2
#define P_BUFFER_SIZE 3
static uint8_t p_buffer[P_BUFFER_SIZE];
#define P_N1_MIDI_CHANNEL (*(uint8_t*)&p_buffer[P_N1_MIDI_CHANNEL_OFFSET])
#define P_N1_MIDI_CHANNEL_VALUE_OFFSET 1
#define P_L_VOICES (*(uint8_t*)&p_buffer[P_L_VOICES_OFFSET])
#define P_L_VOICES__MONO 0
#define P_L_VOICES__DUO 1
#define P_L_VOICES__POLY_4 2
#define P_L_VOICES__POLY_5 2
#define P_L_VOICES__POLY_6 2
#define P_L_VOICES__POLY_8 2
#define P_L_VOICES__POLY_10 2
#define P_L_VOICES__POLY_16 2
#define P_B_RETRIGGER (*(uint8_t*)&p_buffer[P_B_RETRIGGER_OFFSET])
Emacs often changes the behavior suddenly and drastically. Recent surprise to me was that role of ctrl-j (newline and indent) and ctrl-m (newline) switched out of the blue. I don’t understand the developer’s sense of changing user interface of a multi-decade years old software. But luckily, emacs has very powerful customization ability.
Adding this line reverts the key bindings back.
(when (fboundp 'electric-indent-mode) (electric-indent-mode -1))
I appreciate this post
Exchanging data with PSoC Pioneer Kit over serial communication is often useful. The kit CY8CKIT-042 has a built in USB-to-UART utility programmed in the PSoC 6LP device which is used for onboard debugger for the target PSoC 4. It is easy to use. See below.
I like OS X as a software development platform (and electronic stationery); On the other hand, it’s much better to use Windows for hardware development because of better coverage of development tools. As a compromise, I own MacBook and runs Windows under Parallels Desktop for hardware development. I have no issues with this style so far thanks to the powerful USB support by Parallels.
My Windows platform has reached disk size full at 64GB. I decided to extend the disk size and re-install everything. Here are highlights of my Windows platform:
- Windows 10, display language = English
- PSoC creator 3.2 for the PSoC development platform. 3.3 is installed by I am not using it yet since I saw some instability. (install image =PSoCCreatorSetup_3.2_sp1_b6175.exe)
- Salae Logic 1.2.10 (Logic Setup 1.2.10.exe) for logic analyzer. No particular issue. Working fine with a normal installation.
- PicoScope6.11.12 (PicoScope6_r6_11_12) for my oscilloscope PicoScope 2203. The hardware has become EOL already but it is working with this version of Oscilloscope app. Note that OS X version requires installing .NET libraries. I hate it so didn’t install on Mac.
- Foxit Reader 7.2.8 (FoxitReader728.1124_enu_Setup.exe) for PDF reader. The version is important. Never upgrade this until FoxIt resumes support of classic toolbar mode. The latest version supports only ribbon mode and it painfully takes space on my small screen. Otherwise, this viewer is very comfortable to use. Note: Turn off the automatic upgrade functionality.
- TeraTerm 4.91 (teraterm-4.91.exe) for terminal emulator. TeraTerm has several variations/providers for some reason. I always get confused by it. This is the one I use, for my future reference: https://ttssh2.osdn.jp/index.html.en
- Eagle 5.12.0 It’s very old version but I keep using it because this is the version where I have commercial license (which was quite expensive). Cadsoft who were former provider of Eagle was acquired by some other company, so I’m not sure if the latest version is “better” or “improved”. I want to avoid spending extra time for researching it, so I will stay with this version as long as possible. I’m happy with the feature at this point anyway.
That is about it. I have not installed Cygwin yet. I’m waiting for Ubuntu/bash is officially supported by Windows 10.
I have archived these install images in my ‘software’ folder for any needs for recovery in future.
My PSoC Creator application became unstable suddenly. I could not work on software today. I’m now recovering the software.
Meanwhile, I made a MIDI receiver module instead. Developing and debugging MIDI Rx would be easier and less troublesome hopefully.
Not yet verified the behavior.
I restored the Analog2.0 set successfully. It’s working fine now.
The Volume Control Module substitutes existing VCA and envelope generator. EG part will generate linear volume control voltage for analog VCA. I will reuse VCA in Analog2.0 for analog part.
One year has passed since I stopped working on Analog 3. Now it’s time to resume the development. The picture above is the first use case of Analog 3. This is a draft panel layout of the synth I want to make. The panel includes least set of parameters I want.
Many parameters on this panel has non-traditional style, like ones in VCA. I will need to revise and adjust such parameters. In order to avoid remaking hardware modules, I will control the risk by following approach:
- Develop the synth by modifying a working complete set of synthesizer, i.e., the base platform. I will use the Analog2.0 fundamental set for it.
- Modification is done by replacing a module.
- New modules have analog panel.
- Base platform keep using the existing hardware panel.
I can always verify the complete set is working by this approach.
The first task, then, is to build an Analog2.0 box.