I really need an FV-1 platform which is capable of holding dozens of separate programs, if not more. It's one thing to have a pedal which has 8 or 16 programs and allow the microcontroller to manage presets which amount to one of the available programs plus knob settings. However I really need to have more programs available all the time as I don't want to constantly be loading 8 at a time like I'm doing currently.
The few projects (or products) I've seen combine a micro and the FV-1 but the storage for individual programs is still pretty small. 8 or 16.
I've read a number of people who claim to have achieved E-squared interface through the micro but I just want to find something that will work without having to spend months debugging it.
Another possibility would be to use the micro to program the E-squared whenever a bank switch was needed. It would be a bit slower no doubt.
I have a couple of the old SKRM modules I could use... just add some input and output buffering, maybe a Teensy, 4 pots (3 control pots plus wet/dry mix) and an encoder with pushbutton for menu navigation. Oh, yeah it needs an OLED of course.
I've thought about doing something similar, but basically just have a handful of EEPROMs that are routed through solid-state relays or something controlled by a microcontroller, and that handles all the switching of effects. Whatever you're using for effect selection (rotary encoder, pushbuttons, etc) will go to the microcontroller, then it just triggers the appropriate relay to connect the corresponding EEPROM and send the FV-1 the address bits to choose the effect you want. If you have an I2C capable microcontroller it would be pretty easy to add an OLED display for easy navigation and fancy graphics.
Why haven't I done this already, you ask? Because I have yet to find a need for more than 8 effects at a time :P Kind of working on something similar right now, but not with FV-1. Using the ATMega328P because coding isn't really my thing, but if I'm in the Arduino IDE I can make things work :P
Well, I've looked into it but the problematic part was finding a (cheap) Arduino-ish micro that has enough storage to hold the contents of multiple EEPROMs :)
of no help here, but ive just made a pcb which uses the onboard fv-1 sounds, and 2 eeproms, for a total of 24 patches..with a toggle to select banks a/internal/b...just waiting on the pcbs..
and will be able to just plug in my pickit2 into the side and reprogram the eeproms ....kind of development pedal if you like.
i was sick of it on my breadboard and removing the eeprom everytime etc... so will make my experimenting with patches a lot easier.
anyway as you were....following. :)
I have done that in the past using PSoC4, there is a hardware block doing exactly that: EZI2C
https://www.cypress.com/documentation/component-datasheets/ezi2c-slave
The way i did it is to have the 512 byte blocks of FV-1 programs stored as an array in Flash, then point the EZI2C buffer (there's an autogenerated API for that) to the new program i want to load and toggle any S0-2 pins to init the program reload. So in practice there is no need to use all the S program change inputs, only one or the Internal/External pin, anything that will initiate the reload. The actual program binaries were changed in the firmware by switching the data pointers.
I haven't tried it with an AVR. i'm not sure if the slave i2c implementation will be fast enough to ideally emulate an eeprom chip. With PSoCs, this block is made of logic fabric /cpld, all worked fine. Having an MCU really opens a few more options, like generating a variable clock for the DSP, PWMs for pot inputs.
Another potentially interesting idea would be to use an SD card to store all the hex (or converted to bin) files on a file system and load them from the card to RAM and then via i2c to FV-1. Obviously it would be slower, but perhaps more useful if having many patches.
A ~$15 PSoC5LP dev stick could do the job quite nicely. Ontop of that it could act as a USB midi interface for easy integration with other software.
One of the designs I looked at was the Basestar, which actually seems pretty nice and solves some practical issues with the FV-1. The guy who developed it said that the original Cypress CPU module was no longer available, but it looks like there's a form factor equivalent model that is in distribution. I would build one of these if I could get past the E-squared issue.
https://github.com/hexeguitar/BasestarFV1
That one still defers the I2C programming of the E-squared to a 4 pin header rather than going anywhere near the micro. I sent the guy a message to see if he has any PCBs left.
Realistically, I could see wanting 128 programs and 128 patches. I started using SpinCAD Designer again after about 4 years of not thinking about the FV-1 at all. I can whip out a bank of 8 programs in about 30 to 60 minutes and have a few of them be really good. I'm always refining the patches a bit so it would be a huge time saver to just be able to update them directly over USB. The biggest drawback to the FV-1 is just these few programs IMO. I know that for a commercial pedal product that is not an issue.
But SpinCAD lets you work so fast compared to any other non-graphical method, that I start trying to push the limits of what can be jammed into 128 instructions, even if they sound strange or don't make total sense or do some things "wrong". So my FV-1 sounds include a handful of normal sounding reverbs, delays, modulations, etc. and then a whole bunch of strange sounding things that I don't think I've ever really heard before.
That would be me :)
Sorry i haven't had time to reply to your email yet.
I still have a few Basestrar PCBs left , but the other module you mentioned (cy8ckit-043) will not work with it. Different MCU, different pinout, they are not really compatible.
I thought about redesigning the board to use the MCU directly instead of the module, but i don't use FV-1 too often these days. Not after getting a stereo IR convolver + stereo reverb running on Teensy4 with only 25% cpu load.
I did not include a programmer in the Basestar design because of an hack that allows to use a cheap FX2LP board directly in the SpinAsm as a programmer. I did most of the coding directly in the SpinAsm, so it was more convenient for me. Also the goal was to make a dev board, the number of patches stored onboard wasn't ontop of the list. Rather something to develop programs on and then move them to the final hardware. Giving that i'm not sure the Basestar dev board would deliver what you are after.
What's "E squared"?
I haven't got any code for it, so I can't help directly, but it can't be that hard to connect the FV-1's I2C to a uP with enough onboard program memory to store a whole ton of FV-1 programs. They're only 128bytes, after all, so 128 programs is 16K - there are plenty of uPs with 16K of programmable storage. Then the uP deals with the programs, flips one of the "S" program select lines on the FV-1, sends it the I2C data. On the face of it, it's pretty simple. Although having some know-working code is always simpler still!
It's 512 bytes for one program. Instructions are 32bits long.
Quote from: free electron on December 29, 2020, 11:00:35 AM
That would be me :)
Sorry i haven't had time to reply to your email yet.
I still have a few Basestrar PCBs left , but the other module you mentioned (cy8ckit-043) will not work with it. Different MCU, different pinout, they are not really compatible.
I thought you looked familiar!
Ah. Too bad.
I see that some places sell the 049, a bit more expensive and only from the UK that I can see:
https://www.ebay.com/sch/i.html?_from=R40&_trksid=p2334524.m570.l1313&_nkw=cy8ckit-049&_sacat=0&LH_TitleDesc=0&_osacat=0&_odkw=cy8ckit-04
But... it would save a lot of time!
Quote from: free electron on December 29, 2020, 11:00:35 AM
I thought about redesigning the board to use the MCU directly instead of the module, but i don't use FV-1 too often these days. Not after getting a stereo IR convolver + stereo reverb running on Teensy4 with only 25% cpu load.
Yeah, I'm playing with an Elk Pi board and working my way towards writing VSTs using C++ and/or Faust that will run on it. There's also the Mod Dwarf coming out that looks good. I think it uses LV2 format plugins. If it weren't for SpinCAD making algorithm development so easy I probably wouldn't care as much. I did some experiments earlier this year on the ESP-32 which looks way more powerful than the FV-1 on paper, but it couldn't do some things that I know would have been easy on the FV-1.
Quote from: ElectricDruid on December 29, 2020, 01:25:29 PM
What's "E squared"?
I haven't got any code for it, so I can't help directly, but it can't be that hard to connect the FV-1's I2C to a uP with enough onboard program memory to store a whole ton of FV-1 programs. They're only 128bytes, after all, so 128 programs is 16K - there are plenty of uPs with 16K of programmable storage. Then the uP deals with the programs, flips one of the "S" program select lines on the FV-1, sends it the I2C data. On the face of it, it's pretty simple. Although having some know-working code is always simpler still!
E-squared is EEPROM. Leastwise that's what we used to call it back in those pre-internet days.
My concern was more about getting some reference code to perform that function so I wouldn't have to develop it from low level. The Cypress chips with the configurable peripherals look pretty cool in fact. I'd read some threads by people who had apparently done it, but I wasn't sure there was a standard approach known to work with the FV-1. I have been out of the hardware game for a long time, so the feature on the Cypress chip actually took me by surprise a bit. So that one has a I2C peripheral block that works as an I2C slave.
Looking at the Teensy 4, (which is way smaller than the Cypress SoC sticks) it incorporates "FlexIO" similar to Cypress which of course supports I2C, so of course it supports I2C slave mode... NOT. https://community.nxp.com/t5/S32K/How-to-emulating-I2C-bus-slave-mode-by-using-FlexIO/m-p/931569
I could probably compromise... use just 32 programs, 4 24LC32s, or 64... I probably wouldn't really use 128. I just want a workspace to collect good ones so being able to tag and move them would also be a good feature.
I don't have any working piece of code, but I investigated a little in the past as I am interested in something like this. I was planning to use an Atmega328 and program it using Arduino IDE.
Summary of my findings:
-Atmega can work as an I2C slave using Wire, but you need to ensure it does not go into clock stretching. Otherwise the FV1 is not able to get it.
-From some application note I understood AVRs at 8Mhz cannot handle I2C rates higher than 100Khz without using clock streching. FV1 uses 250Khz I2C when clocked at 32Khz.
-Someone at Spinsemi forum was able to succeed by slowing down the FV1 clock during the program load. Basically the Atmega is also providing clock to FV1, so it is in control of it.
-I was planning to test an Atmega running at 20Mhz to see if it's able to make it, but never put it into run.
There is the additional problem of how to store the programs in Flash memory in an easy way to allow loading of new programs....
I like the idea someone posted to use an SDCard... this could allow to copy hex or bin files into the SDCard from a PC easily, and read them from the uC.
Quote from: free electron on December 29, 2020, 01:33:49 PM
It's 512 bytes for one program. Instructions are 32bits long.
Aww, 'course they are! Silly me! :icon_redface:
64K's still not out of bounds though, by any stretch.
Hi,
I managed to get EEPROM emulation to work on atmega328. It took
about 7 attempts with oscilloscope traces to finally get it. TWI did not work
because it is too slow. The interrupt from TWI peripheral takes too long
to arrive to be able to respond in time for the FV-1.
The approach that I took was to initiate patch change from atmega328 by
toggling the FV-1 pin S0 (pin 16) and then wait in a busy loop counting I2C
clock cycles and sending the data at correct moments. The code is attached
below (GPL v. 3.0).
I have been working on an Arduino based FV-1 multi effect pedal for guitar.
I recently got the second version of PCB from China and I'm in process of testing it.
I went with SMD this time because the board got very crowded for THT parts.
Here are a couple of pictures from the first PCB prototype:
(https://i.postimg.cc/MnPXWBjs/arduino-FV-1-multieffect-front-resized.jpg) (https://postimg.cc/MnPXWBjs)
(https://i.postimg.cc/7GgxTJfr/arduino-FV-1-multieffect-guts-resized.jpg) (https://postimg.cc/7GgxTJfr)
Features:
- atmega328 with Arduino UNO bootloader, programming directly from Arduino IDE
- 80 FV-1 algorithms (29 reverbs, 21 delays, 30 modulation effects currently)
- 8 saved presets (algorithm + 3 parameters, Volume and Mix)
- Volume and mix are done by digital potentiometers, position saved on preset.
- OLED screen.
Hardware:
- Analog dry Audio path
- Current consumption approx. 80 mA
- Atmega328p processor at 8MHz.
- DS1881 digital potentiometer.
- SSD1331 OLED screen.
- True bypass + patch select footswitch.
- No EEPROM chip.
Software:
- Runs on atmega328p, programmed with Arduino IDE (FTDI programming header)
- FV-1 algorithms as header files, compressed with lightweight compression
method (https://excamera.com/sphinx/article-compression.html), thus making
it possible to fit 80 algorithms to the 32k memory of atmega328p (8.5k code,
23.5k algorithms currently).
- No EEPROM chip, instead the atmega328p is used to emulate an EEPROM
and send the algorithm to FV-1.
- Parameter values from atmega328 to FV-1 communicated using filtered PWM.
- Custom UI with modified SSD1331 OLED screen library
(http://www.technoblogy.com/show?2EA7) with each preset having a different
colour scheme.
/* Copyright 2020 Perttu Haimi
This file is part of FVduino.
FVduino is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
FVduino is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with FVduino. If not, see <https://www.gnu.org/licenses/>.
*
*
*/
void send_algo()
{
// Copy FV-1 algorithm from PROGMEM to ram buffer.
// Progmem is too slow in the send loop.
// Since we will anyway have to copy from PROGMEM,
// it makes sense to compress the algorithms and get
// space savings (almost 2x).
uint8_t algo = patch_data[current_patch].algorithm;
decompress(algo_buffer, (prog_uchar *)pgm_read_word(&(algodata[algo].prog_addr)));
// Set up everything to be ready
const uint8_t sda_mask = (1 << PIND5);
const uint8_t clk_mask = (1 << PIND6);
uint8_t prev_clk = clk_mask;
DDRD &= ~(clk_mask); // clk pin as input
DDRD &= ~(sda_mask); // sda pin as input
PORTD &= ~(sda_mask); // SDA pin is pulled low or floated up
// -> we need to set pin low only once.
// Toggling is done by setting pin to
// input (let float high) or output (pull low).
// FV-1 internal pullups are ok (tested).
uint16_t pos = 0;
uint8_t curr_byte = algo_buffer[pos];
uint8_t bit_mask = 0b10000000;
uint8_t clk_count = 0;
// Overclock (3.3V 16 MHz)
clock_prescale_set(clock_div_1);
// Undivided attention for FV-1 requests
noInterrupts();
// Notify FV-1 of patch change by toggling the notify pin
PIND = _BV(4); // Toggle pin 4
while(clk_count < 37) // Handle the header
{
uint8_t clk = PIND & clk_mask;
if(!clk && prev_clk) { // scl went down
switch(clk_count)
{
case 8:
case 17:
case 26:
case 36:
DDRD |= sda_mask; // sda pin as output send ACK - pull sda pin low
break;
default:
DDRD &= ~(sda_mask); // sda pin as input
break;
}
clk_count++;
}
prev_clk = clk;
}
clk_count = 0;
while(pos < 512) // Send the data
{
uint8_t clk = PIND & clk_mask;
if(!clk && prev_clk) { // scl went down
if(clk_count != 8) { // Sending byte
if (curr_byte & bit_mask) {
DDRD &= ~(sda_mask); // Send 1 = Let High (sda pin as input)
} else {
DDRD |= sda_mask; // Send 0 = Pull Low (sda pin as output)
}
bit_mask >>= 1;
clk_count++;
} else { // Let reciever reply
DDRD &= ~(sda_mask); // Release (sda pin as input)
clk_count = 0;
bit_mask = 0b10000000;
pos++;
curr_byte = algo_buffer[pos];
}
}
prev_clk = clk;
}
interrupts();
// Restore 8 MHz
clock_prescale_set(clock_div_2);
}
Great, this is very close to what we need...
Some questions from my side:
-How are you clocking the atmega? I see that in your piece of code you are "overclocking" it to 16Mhz. Are you using a crystal?
-Are you storing the algorithms as arrays in progmem? So, do you need to reprogram the atmega to add new patches?
-If I understand it correctly, you are bit-banging the I2C slave response, right? Do you know what is the FV1 sending as a header during the first 36 clock cycles?
Thanks. I'm clocking atmega 8 MHz at 3.3 V, using 16 MHz crystal
and clock divide 2. This is just for power savings, and I have 3.3V
on board for the OLED screen and FV-1 anyway.
The algoritm sending will not work at 8MHz though,
thats why I'm going to 16 MHz temporarily (overclocking at 3.3V).
If you use 16 MHz at 5V, then you can leave out the clock changes.
Yes, the algorithms are in progmem. They are in header
files and everything needs to be recompiled if adding new patches.
Yes, it is a tight bit banging loop. The FV-1 sends the slave device
ID and the address that it wants to read from in the header.
FV-1 is direcly wired to the atmega pins PD5 and PD6, so no need to
check the ID. Also, the read address can be ignored, because FV-1 will
anyway be sent the algorithm that is currently selected in user interface.
Thanks for the replies... I'm thinking on getting something similar but reading hex files directly from an SD card instead of progmem. This would allow me to copy new hex files into the SDcard from my PC easily. I want to have a simple workflow to debug/test new FV1 programs.
I think, as long as you read the whole FV-1 program to a 512 byte
RAM buffer from the SD card before sending it to FV-1, it should work.
In the loop, there is no time to read SD or to do any other calculation.
The wiring that the code assumes is:
FV-1 SCK (pin 14) -> atmega PD6 (Arduino pin 6)
FV-1 SDA (pin 15) -> atmega PD5 (Arduino pin 5)
FV-1 S0 (pin 16) -> atmega PD 4 (Arduino pin 4) (I'm using 100k pull down resistor)
FV-1 S1 (pin 17) -> Ground
FV-1 S2 (pin 18) -> Ground
Quote from: phstomp on December 30, 2020, 10:28:59 AM
I think, as long as you read the whole FV-1 program to a 512 byte
RAM buffer from the SD card before sending it to FV-1, it should work.
In the loop, there is no time to read SD or to do any other calculation.
This was my thought as well. Loading the full program in to RAM before triggering the change in FV1.
The plot thickens. This is all very interesting.
@phstomp let me know if you'd want to sell one of those to me. While I'm tempted to try to design everything as some long term project, I think I need to er.... focus on the most important things! Which is another way of saying I might never finish such a project, and what I really want to do is develop and use the algorithms.
While we're just talking about what we need and why.
Features:
- atmega328 with Arduino UNO bootloader, programming directly from Arduino IDE
- 80 FV-1 algorithms (29 reverbs, 21 delays, 30 modulation effects currently)
Wow, great! I could live with 80, though I'd want to be able to put my own in.
- 8 saved presets (algorithm + 3 parameters, Volume and Mix)
Only 8? That would drive me nuts.
- Volume and mix are done by digital potentiometers, position saved on preset.
Cool! Can you do full wet? Can you do a 6 dB analog boost (e.g. when you do a trem patch you sometimes want to boost it a bit to retain overall level)?
- OLED screen.
Cool!
I'd consider:
a) USB interface. I don't even want to mess with shlepping SD cards in and out.
b) aux EEprom for storage instead of SD card (to be combined with USB interface to allow fast, in place loading of patches from PC). How big do they make them?
DL
Quote from: potul on December 30, 2020, 11:28:31 AM
This was my thought as well. Loading the full program in to RAM before triggering the change in FV1.
[/quote]
Ok, let me know how it goes.
Quote from: Digital Larry on December 30, 2020, 11:54:05 AM
I'd consider:
a) USB interface. I don't even want to mess with shlepping SD cards in and out.
b) aux EEprom for storage instead of SD card (to be combined with USB interface to allow fast, in place loading of patches from PC). How big do they make them?
DL
Sorry I sort of highjacked your thread and created some confusion. SDCard was only MY idea, phstomp project is embedding the fv1 programs into the Arduino code. This means that everytime you need a new program, you need to:
-complile it and get the hex or bin
-Do some sort of transformation of it, compress, etc..
-Add it to the Arduino source code.
-Program the Atmega with it.
Hey, who's in charge here? ;)
It's interesting to see how what people have developed is different than what I imagine - mostly because I want a platform to develop and maintain a library of diverse patches, which really means:
- a lot of memory to store both patches and presets
- ease of connection of PC to transfer data
- real time code updating
The OLED and knob interfaces are cool. Lots of great ideas.
The SD card is actually a great idea, it removes the need
to cram everything to 32k memory, which is a bit of a pain
and also decouples the FV-1 algorithms from the atmega
code. Could also save presets there and make backups.
I'm almost out of free atmega328 pins though, so it would be
a bit difficult to implement.
Quote from: Digital Larry on December 30, 2020, 02:38:14 PM
Hey, who's in charge here? ;)
It's interesting to see how what people have developed is different than what I imagine - mostly because I want a platform to develop and maintain a library of diverse patches, which really means:
- a lot of memory to store both patches and presets
- ease of connection of PC to transfer data
- real time code updating
The OLED and knob interfaces are cool. Lots of great ideas.
If it is easy loading of new programs libraries you are looking at why not look into a smart cart option, something like an Atmege163 which has an Atmega163 CPU and a 24lc256 eeprom embeded could be a great solution. A massive effects library in your wallet.
Something like this can store many effects plus all the data for effects names and pot names.
(https://i.postimg.cc/tYGYXhHd/atmega2-62227-zoom.jpg) (https://postimages.org/)
Also to handle the hex files directly there would have to be some kind of hex2bin implemented to get the raw binary data.
Staying within Arduino territory, a SAMD51J19A (Adafruit uses them in their "feather" boards) with 512k of flash could do the job, too. With plenty of external storage options.
Recently found out about these SMT chips, basically an SD card in 8pin chip form:
https://lcsc.com/products/FLASH_501.html?q=XTSD
I doubt GB's would be needed, though. With SPI there is lots of flash chips to choose from.
Nice alternative to the OLED displays are these tiny IPS 160x80 SPI ones:
look for "IPS display 0.96 inch TFT LCD Display Screen 80*160 ST7735" or something like that.
I have used one in a recent current/voltage/power meter project:
(https://i.imgur.com/h22YCr3l.jpg)
Paid about 1.50€ apiece. There are larger models, too.
Quote from: free electron on December 30, 2020, 06:08:36 PM
Also to handle the hex files directly there would have to be some kind of hex2bin implemented to get the raw binary data.
This can be done by the Arduino easily. The Intel Hex format is not difficult to parse, specially if we already know in advance it's an FV1 program, so you can skip most of the bytes and focus on the data ones.
This could be done at the moment we load the program into RAM buffer to avoid interfering with I2C timing.
Another technique:
http://www.muzique.com/news/adding-memory-to-the-fv-1-reverb/
regards, Jack
I dug out my Teensy 3.2 board I got a couple years ago. Set up Arduino and added Teensyduino. Wow this thing is cool! Within about an hour of messing around I had it responding to MIDI clock over USB. The possibility of syncing FV algorithms to MIDI, even brute force by tap-tempo techniques, opens up a lot of creative territory.
There is also "I2C slave" object in the library but it's not clear whether it will work with the FV-1. I guess I can try it. The approach of putting multiple 24LC32A chips on the board works too.
Quote from: Digital Larry on January 01, 2021, 12:39:24 AM
I dug out my Teensy 3.2 board I got a couple years ago. Set up Arduino and added Teensyduino. Wow this thing is cool! Within about an hour of messing around I had it responding to MIDI clock over USB. The possibility of syncing FV algorithms to MIDI, even brute force by tap-tempo techniques, opens up a lot of creative territory.
There is also "I2C slave" object in the library but it's not clear whether it will work with the FV-1. I guess I can try it. The approach of putting multiple 24LC32A chips on the board works too.
Great. Teensy might be able to handle the slave I2C without timing issues, give it a try.
Changing gears for a second, I recall a project I found long ago that was handling the presets by modifying the program at specific spots before sending it to the FV-1. All programs were identical at the very beginning, so you could know what byte to tweak to change a register value. Curious. But I can't find it anymore.... my memory is getting bad.
Quote from: amz-fx on January 01, 2021, 12:04:29 AM
Another technique:
http://www.muzique.com/news/adding-memory-to-the-fv-1-reverb/
regards, Jack
Very clever idea Jack! Especially with an AVR controlling the I2C addresses! It would be fun to pair this with a ATTiny85 that has a USB interface!
Quote from: potul on January 02, 2021, 03:08:23 AM
Great. Teensy might be able to handle the slave I2C without timing issues, give it a try.
Changing gears for a second, I recall a project I found long ago that was handling the presets by modifying the program at specific spots before sending it to the FV-1. All programs were identical at the very beginning, so you could know what byte to tweak to change a register value. Curious. But I can't find it anymore.... my memory is getting bad.
I'm a little skeptical. They say that it is really meant to interface with another Teensy running the matching "master" code. I'm not sure I want to hang the project up on account of my ability or lack thereof to develop EEPROM emulation. I've got a PCB in the works with 4 spots for 24LC32A and I think I'll add two more just for laughs, assuming I have enough GPIOs left. I think that all you can do on these chips is to have one address pin routed to a GPIO. If that pin is high, then that EEPROM is not selected because AFAIK the FV-1 only has the ability to address a single 24LC32A on its I2C bus.
Regarding tweaking the code as a way of managing presets... hmmm... strange. Not sure what benefit that offers. Not even gonna try to wrap my head around it. I guess that would relieve you of having to generate voltages.
I now have a C# program that is capable of doing serial communication with the Teensy, e.g. so I can send it codes and settings via USB from my PC. What's cool is that Teensyduino has a device setting which is "Serial + MIDI" so I can do both at the same time. I'm going to see if I can get this to upload a BIN file and program a 24LC32A from it. Don't see why that won't work. What is also cool (for me) is that 1 week ago I wasn't thinking about any of this. I guess I hadn't realized how easy all these libraries make things.
With a Teensy board it will be so easy to make a small thing with 8 or 10 pots to generate MIDI controller or OSC messages. I like knobs better than mice and although touchscreens are OK I still prefer knobs.
DL,
Get a 1P8T rotary switch to select which of the 8 memory chips is active. The common pole of the switch is grounded and the separate 8 poles go one to each chip's pin 1 to make them active in turn as the switch is rotated. Every memory chip's pin 1 will need a pull-up resistor. The switch is only $2 from common sources like:
https://www.pedalpcb.com/product/mini-1p8t/ OR https://www.adafruit.com/product/2925
No programming. No micro. No potential for clock noise interference or aliasing.
regards, Jack
I published all the code in github: https://github.com/n3ws/fvduino
Currently only the Spinsemi demo programs are included. I could add
the programs from https://mstratman.github.io/fv1-programs/ if that
is OK.
@Digital Larry: I'm ordering some FV-1 chips. Are you still interested
in obtaining a prototype or you will rather roll your own? It will take me
at least a month to have something ready. I still have to learn how
to do hot plate solder reflow, and there could be unexpected issues
with the new PCB.
Flashing the board is done with FTDI Usb programmer such as this:
https://www.banggood.com/Geekcreit-FT232RL-FTDI-USB-To-TTL-Serial-Converter-Adapter-Module-Geekcreit-for-Arduino-products-that-work-with-official-Arduino-boards-p-917226.html?cur_warehouse=CN&rmmds=buy
So, you would need to open the pedal for adding patches. Maybe
not the level of convenience that you were looking for. Also, the
workflow for getting your own programs in is as follows:
compile FV-1 program to bin -> compress -> include in header file -> recompile -> upload to board
The 8 preset limit exists because I could not be bothered
to think more color palettes for patches. Also, with one foot switch,
even 8 presets gets a bit tedious if you need to go 1 preset backwards
(7 foot presses).
The digipots work so that both full wet and full dry with boost are possible.
The granularity of the pots 1 db, which may not be fine enough for some
uses.
Schematic added to github. This version is not tested yet,
but the only changes are in the audio path, not in digital parts.
Please feel free to comment. According to the D1881 datasheet,
there should probably be op amp buffers after the digipot,
but I'm a bit reluctant to add another chip to the board.
(https://i.postimg.cc/KR0K0dJk/fvduino-schematic-v0-1.png) (https://postimg.cc/KR0K0dJk)
Thanks for sharing that. For some reason I looked at the DS1882 which wants split supplies. Have you used the DS1881 in this application before? Does it work OK?
Yeah, I'm using 1881 currently, works fine. No changes there in this revision. It needs that op amp buffer in VREF though.
DS1881 has an end to end resistance of 45k according to the datasheet.
10k input Z will load it and change the taper. You could scale up the R9+R10 and R14+C14 to minimize the load.
Not sure if i'll have time to finish it, as FV1 is not really on the top of my list today, but i had this idea of using one of those ESP8266 boards for something useful:
- using ESP12E module with 4MB of flash.
- made 1MB LittleFS partition for files
- wifi AP + web server
- using examples tested functional file upload via website
So the plan would be to have a web interface to program the FV1, maybe a grid of 16 squares where you can drag and drop the hex file + a drop down menu to choose one of the 8 programs inside a bank. 16 banks 8 programs each gives 128 "patches".
The software would receive the hex file, save it on the disk, convert it to bin, remove the hex to save disk space. Choosing the patch would be done by a drop down menu, set of buttons or something else, setting a new value would grab 512 bytes from the file, set up the buffer, toggle the pin to init reload and bit bang the I2C slave to the FV1. I2C on the 8266 is software only, so there are already useful functions/macros built it. Maybe it would work with the stock i2c library, haven't tested it yet.
Next step could be to add 3 pwm outputs or a digital pot to control the FV1 params via sliders on the web interface.
Having the FV1 pedal sitting in the pedalboard with all other gear and controlling it remotely from the dev machine when you write the code - now that would something very useful.
@free electron: Thank you for comments. What values you would suggest for
R9+R10? I guess the op amp buffers would also do the trick.
Quote from: amz-fx on January 04, 2021, 04:12:15 AM
DL,
Get a 1P8T rotary switch to select which of the 8 memory chips is active. The common pole of the switch is grounded and the separate 8 poles go one to each chip's pin 1 to make them active in turn as the switch is rotated. Every memory chip's pin 1 will need a pull-up resistor. The switch is only $2 from common sources like:
https://www.pedalpcb.com/product/mini-1p8t/ OR https://www.adafruit.com/product/2925
No programming. No micro. No potential for clock noise interference or aliasing.
regards, Jack
Hi Jack, that is a cool idea but it doesn't let you save presets with knob and mix and volume settings.
My goal is to really have something that is optimized for patch development and review.
It will not be:
- optimized for cost
- optimized for stage use
- guaranteed not to fall apart
- available in stores, online, or anywhere! (for now)
Here's the idea - I develop a bunch of patches with SpinCAD but I really have to live with them and play them to know which ones will really work. So there's a button press combo that marks a given preset as a "fave" which increments a counter in the record for that preset. After while I look at the presets' "fave" counts. and free up space for new ones from the ones that I don't like as much.
Also, dialing in the control range for a patch can be a challenge. I have a reverb patch with the control knob going in but the magic zone is really about 0.6 and up. So I just need to limit it to that. It's not really practical to iron all this out just using the simulator in SpinCAD.
@phstomp thanks for the offer on the boards, I am having fun coming up with my own thing based on my own thoughts... even if I never get around to doing it. I mean, I think I will. Reflecting on it, the main reason I stopped building the first FV-1 board I made was those darn SOT23-5s I picked out. Whoo those are small!
Quote from: phstomp on January 05, 2021, 06:29:57 AM
@free electron: Thank you for comments. What values you would suggest for
R9+R10? I guess the op amp buffers would also do the trick.
Buffers would be ideal, but making the resistors 10x (100k + 270k, lower the feedback capacitance to get the same -3dB point) would improve the original log taper of the pots.
I have been playing more with the esp8266 based remote solution.
What i have for now is:
1. ESP12E module, partitioned as 1MB for the MCU firmware and 3MB as disk space for the web server and hex files.
2. Working web server with hex file upload and a row of buttons.
3. Once uploaded, any of the listed hex files can be "enabled", which means:
- hex file will be parsed, checked if it really a hex file for the FV1 (always the same length)
- intel hex has a checksum built in, that gives additional verification of the file
- bin data is extracted and put into 4kB buffer, ESP8266 has enough RAM to keep all 8 patches there
The next step will be to handle the row of 8 buttons. Each press will set up the read address in the BIN data buffer and pass it as starting read address for the i2s slave. And then to get the i2c slave to work with the FV-1.
Haven't tried it yet, but i think the upload should also work with
curl - so the whole process of building and uploading can be automated using scripts.
(https://i.imgur.com/jxYqyjh.png)
@Digital Larry: Ok, thats cool.
I will still mention that in fvduino, all the FV-1 algorithms
do have their default settings which do get written to the EEPROM
whenever they are tweaked and saved in a preset. So there
is no need to re-edit them the next time. So, in a way it is not nearly
as limiting as having just 8 presets and thats all. Those 8 presets
are just the ones which can be recalled with the footswitch.
@jack: an atmega328 also costs about 2$ ;) Its current consumption
is only about 3 mA at 3.3V, 8 MHz, so it is not very noisy part in my
experience.
@free electron: Thanks!
Quote from: phstomp on January 08, 2021, 11:41:41 AM
@Digital Larry: Ok, thats cool.
Don't get me wrong, I am stealing most of your ideas.
;D
Thanks again for sharing them.
It works! 1st FV-1 booted from a network drive ;) Sort of...
@phstomp Thanks for posting your code. I have adapted the send_algo() function to work on the ESP8266. It's nicely simplified to deliver what the FV-1 requires and keep up with the timing.
ESP version required a few mods to make it work. The most important being to make it work directly from RAM, not FLASH. Fetching it from external flash was too slow.
I also added a timeout in the while loops. If something goes wrong (mismatched i2c reply) and the MCU won't receive full 512 clocks it will hang up in the while loop with interrupts turned off. Only watchdog reset will help if it's turned on.
I was thinking about using the stock i2c slave software implementation, but after reading about people having problems with achieving standard 100kHz transfers (worked @~30kHz, we need 10x that), clearly a custom, optimized for the FV1 solution was needed.
I have tested the code and it works reliably up to 44.1kHz samplerate for the FV-1. Breaks at 48kHz.
Too bad the ESP8266 doesn't have any hardware PWM built in. I could use it to generate the clock for the FV-1, as i did in the BaseStar project. With that it would be possible to lower the Fclk to 32KHz for the upload time and then set it back to whatever it was before.
But even without it it's pretty useful: compile hex, click upload, click enable and one of the 8 buttons to load the patch into FV-1. 3MB of disk space is enough for over a hundred of hex files. If it's still not enough, the esp board can be modded to have an 8MB flash chip. No need to do any extra operations on the hex file. Direct SpinAsm output works fine.
Another idea: use an FTP server on the ESP8266, mount it directly in the system as a disk/folder and point the SpinAsm or SpinCad to save the hex file directly into the ESP. Could save the step of manually uploading the file.
I'll clean up the code and post it soon.
-EDIT-
That was quick. FTP access works, ESP's disk is mounted as a folder in my home directory:
(https://i.imgur.com/9XvNZsml.png)
Quote from: free electron on January 09, 2021, 11:39:31 AM
It works! 1st FV-1 booted from a network drive ;) Sort of...
...
That was quick. FTP access works, ESP's disk is mounted as a folder in my home directory:
This looks amazing.... so you can compile directly into the development board, and then control via web server what to load to the fv-1.
Did you use Arduino IDE or Espressif-SDK?
I was just starting with my idea of using an SDCard, but looking at your ESP8266 solution, I'm changing my mind. This looks really convenient, connecting via WIFI to the pedal and upload new hex files.
The only thing that puzzles me is how to do the initial wifi connection without having to hardcode the wifi SSID and pwd.
Will you be sharing your code?
I'm using arduino, not their IDE, but VScode + Platformio.
Yes, i'll share the code once it's cleaned up from all that debug stuff i put in. The htmls also need some more work.
WiFi:
i don't like these IoT gadgets on my main network, so usually i set them as Access Points and connect directly to the device using a 2nd usb/wifi dongle.
In this case the board creates it's own WiFi with a name "FV1DevRemote" with a password you set in firmware. No direct internet connection. FTP is not secure, but it can handle a single client only anyway.
I'm not sure about putting it in a diecast alu box, though (WiFi range).
What i'd like to add later on are 3 sliders controlling the pot inputs via pwm.
Quote from: potul on January 09, 2021, 03:23:24 PM
The only thing that puzzles me is how to do the initial wifi connection without having to hardcode the wifi SSID and pwd.
That's what WiFiManager is for.
Yeah I used an Android app from one of the ESP-IDF examples to get wifi connected.
Quote from: pruttelherrie on January 09, 2021, 05:09:47 PM
Quote from: potul on January 09, 2021, 03:23:24 PM
The only thing that puzzles me is how to do the initial wifi connection without having to hardcode the wifi SSID and pwd.
That's what WiFiManager is for.
Great. ESP8266 is quite new for me, I was not aware of it. This is even more exciting... new platform, interesting project... :icon_biggrin:
Quote from: potul on January 10, 2021, 02:32:39 AM
Great. ESP8266 is quite new for me, I was not aware of it. This is even more exciting... new platform, interesting project... :icon_biggrin:
Not sure if you're interested in OSC, but here's some ESP32 code I did which includes support for OSC over Wi-Fi. FX code was compiled from Faust. However the OSC implementation is external to Faust and could easily be used to do other things like set pot voltages (if you can figure out how to do that). Combine this with TouchOSC... you'll be mad with power!
https://github.com/HolyCityAudio/ESP32/tree/master/faust/flangerOSC
Thinking further...
I built a few FV-1 pedals where the I2C is on a header, so I can program the EEPROM with a Pikcit2:
(https://i.postimg.cc/yWzQxpNc/Photo-2016-11-17-22-11-36-6252.jpg) (https://postimg.cc/yWzQxpNc)
If I can put the on-board EEPROM on a different address with a jumper, and I connect an ESP8266 box to this header, I can play and upload to my hearts content since the on-board EEPROM will not react to the FV-1, only the ESP8266 will.
Then when I'm happy with the bank (only 3 programs are selectable in this pedal, with an On/Off/On toggle), I can flash the bank into the on-board EEPROM and remove the jumper. For this the ESP8266 must switch into I2C master mode, should be doable I think.
Thoughts?
Quote from: pruttelherrie on January 10, 2021, 10:58:56 AM
Thoughts?
Anything that speeds up loading patches is good!
On a slightly different topic, I seem to have been confused about OSC and the Teensy. OSC requires a TCPIP stack and even though there look to be some Ethernet shields for the Teensy, it's not directly supported in Teensyduino. I did see OSC in the Arduino IDE menus though. On further inspection, that appears to be supported on the ESP8266.
Going back to my original thoughts about my project (which is currently based on a Teensy 3.2, just because I had one), I thought it would support OSC but possibly it would only support MIDI. That's probably still OK as I only have 3 or 4 controllers, which can take CCs, and possibly wanting to interpret tempo from MIDI clock somehow for sync'ed delays.
I have another project in mind which is just to have a little box which sends useful OSC and/or MIDI messages over wifi. Turns out that touchOSC doesn't support OSC bundles (sending multiple commands with a single button). This is a HUGE oversight IMO. However I guess I can build something using one of the ESP8266 boards I bought to try to use with Faust for OSC instead.
Quote from: Digital Larry on January 10, 2021, 12:34:27 PM
OSC requires a TCPIP stack
Not exclusively! It is possible to route OSC packets over a serial link, using SLIP encoding.
https://github.com/CNMAT/OSC
QuoteTurns out that touchOSC doesn't support OSC bundles (sending multiple commands with a single button). This is a HUGE oversight IMO.
Hmm.. didn't know that. That's unfortunate! What would you need a bundle for?
QuoteThoughts?
Definitely doable.
I have tested the upload function by lifting the 1st pin of the 24LC32A on my dev board, pulling it up to 3.3V and connecting the ESP8266 directly to the i2c bus.
Could be done this way:
(https://i.imgur.com/KBAleU1.png)
- additional "Detect" signal connected to 3.3V on the ESP8266 board, when plugged, pulls the A0 up, disconnecting it from the FV-1
- i2c slave on the ESP takes over the normally used eeprom address and supplies the firmware when asked
- a new "burn" button on the webpage, switches the i2c to master, burns the firmware to the eeprom @0x51,
- disconnecting the ESP8266 board sets the onboard eeprom's address back to 0x50, the one that FV-1 needs.
- the above operation could be used to send a pulse to reset the FV1 and trigger the firmware reload.
I have not tested the reset pulse generator in hardware, only simulated in ltspice. Couldn't find specific voltage levels for logic hi and lo in the FV-1 datasheet. If the pulse is still too high (goes down to 0.6V now) or too short the 10k can be increased.
Quote from: pruttelherrie on January 10, 2021, 12:41:17 PM
Quote from: Digital Larry on January 10, 2021, 12:34:27 PM
OSC requires a TCPIP stack
Not exclusively! It is possible to route OSC packets over a serial link, using SLIP encoding.
https://github.com/CNMAT/OSC
QuoteTurns out that touchOSC doesn't support OSC bundles (sending multiple commands with a single button). This is a HUGE oversight IMO.
Hmm.. didn't know that. That's unfortunate! What would you need a bundle for?
Thanks for info on SLIP. Not sure it matters but always good to know.
I would not need a bundle for anything to do with the FV-1. However I am trying to set up a complex guitar looping arrangement with my XR-18 mixer. What I have in mind requires setting 5 or 6 levels at the same time to set different aux sends etc. from 3 different sources. I found "X-Air Live Toolbox" which is an app to do that. It might be adequate.
It's the time of year when I seem to go nuts with different ideas. A successful year is one where I actually follow through on a couple of them. I don't know what's going to happen this year.
Quote from: free electron on January 10, 2021, 12:45:58 PM
QuoteThoughts?
Definitely doable.
(...)
Could be done this way:
- additional "Detect" signal connected to 3.3V on the ESP8266 board, when plugged, pulls the A0 up, disconnecting it from the FV-1
- i2c slave on the ESP takes over the normally used eeprom address and supplies the firmware when asked
- a new "burn" button on the webpage, switches the i2c to master, burns the firmware to the eeprom @0x51,
- disconnecting the ESP8266 board sets the onboard eeprom's address back to 0x50, the one that FV-1 needs.
- the above operation could be used to send a pulse to reset the FV1 and trigger the firmware reload.
Awesome! Hadn't thought of automatically addressing & resetting!
Quote from: Digital Larry on January 10, 2021, 04:28:07 PM
Thanks for info on SLIP. Not sure it matters but always good to know.
Yeah on second thought it doesn't help that much, you still need to get the packets from the app to the serial.
So, I got a couple of NodeMcus this weekend and managed to install Platformio.
Great, I have my first FTP server up and running and filled with hex files... now I need to build a new FV1 board to connect to.
Almost done, will post a new thread about the project soon:
(https://i.imgur.com/i0reAn1.png)
I like the idea of a pluggable wifi enabled programmer module, with a few small tweaks any existing FV-1 device could be adapted to use it.
So for now i abandoned the POT controls via PWM, but added the option to burn the onboard EEPROM with the currently enabled file.
The "EEPROM Enable" button turns the filesystem EEPROM emulator off and pulls down the A0 address low, FV1 will read the firmware from the EEPROM.
Handy as a last test step to see if everything works correctly. Of course, EEPROM is verified after writing the bin file content.
....
Here i found a projekt for a pedal platform and eeproms.
https://github.com/mstratman/fv1-pedal-platform (https://github.com/mstratman/fv1-pedal-platform)
Quote from: alfrede on December 21, 2021, 06:13:38 AM
Here i found a projekt for a pedal platform and eeproms.
https://github.com/mstratman/fv1-pedal-platform (https://github.com/mstratman/fv1-pedal-platform)
Welcome to the forum :) That is a great collection of FV-1 patches, but the point of this thread is to find a microcontroller that can emulated the EEPROM so you no longer need an EEPROM with the FV-1.
Oh, sorry i missunderstood. When i understand you right you search something like that: https://github.com/hexeguitar/FV-1_devRemote