Greetings everyone, long time no post and I figured I would give some news about current dev and timeline :-)
First off, I have been relatively distant from internet and social media and forum, mostly because I've been working on my new board. I've received some questions but I've essentially been reading a lot of things regarding plecterlabs and myself (well I for sure didn't read everything). I thought I'll also use that post to answer some of those things
CF 10, neopixel and what not :
back in mid 2017, when I was finishing CF9 and CS / PRIZM with neopixel support it became obvious that the current set of boards (understand "processor" or MCU) would not last much longer. To answer to the whole negativity about CF9 not supporting neopixel, I simply hit the limiting factor of my chip series with both RAM (volatile) and FLASH (non-volatile) memories (98% full).
For the tech-savvy or simply for those who are interested, I've been programming microcontrollers and doing embedded electronics since 1995 when I started creating sensor to MIDI digitizers to make custom and configurable musical controllers. I got lucky to get started with (at that time) microchip 16C84 MCU with a glorious 1kB of RAM and only assembler programming available. During the dev of the first sound controllers / pre-CF (late 2005), it was running on a 18F452 with 1.5kb of RAM and was at that time already reading sample accurate, 22kHz / 16 bits in 2007, with a gap-less hum looping. In comparison, most of the DUNIO-like boards nowadays with audio playback still rely on an external, dedicated chip or processor to read the SD card and output audio, and feature a native gap (counter-measured with ugly static timings and fixed sound durations).
Just to say you can do a lot with little resources. Still, the increasing of the saber scenario and the configurability of the board soon lead to a lot of code to be written and even if the CF9 / CS4.5 / PZ5.5 HW (they have the same processor) can handle multitrack playback (like the CF does) you can't fit it in the chip if you add neopixel, and conversely.
In practice, it leads to the question "why didn't you get a bigger chip". Sure :-) The reality is that MCU manufacturers tend to propose more RAM+FLASH in bigger package with more leads as well. Along the years, we looked at the MCU range from microchip and saw this as a pattern. The current MCU with just 4 times the FLASH and 10 times the RAM would do plenty, it's just not there. We looked at the PIC32 back in the day (in 2004 when I designed the lab's wifi digitizer) and the watt/MHz was so bad that we skipped that platform, especially for handheld / wearable technology.
so I kept that architecture afloat as long as possible : when you invest a lot of knowledge & learning in a platform, that's the way you can quickly implement new things for the scenario part which is of course the best part. That's a double edge sword as it links you deeply with a HW platform that you know by heat and that is hard to leave. Obviously, that is part of the massive passive-agressive things I've received like "oh I don't know he can't just move to platform XXX". Well, things are probably simpler when you don't have to design optimized low level drivers for your peripherals (sensors, ledstrip, SD card) or just take what others do.
So in november 2017, finally selected a new platform to move to after shifting the CF9 to the market. Thanks to the recent fusion-acquisition from my former chip manufacturer, new interesting stuff came to their portfolio. The result was a wonderful 32 bit platform (yes, I know "like everyone else in the saber field now" *spits*). I carefully selected it for some of its peripherals and integrated controllers and the massive amount of resources, RAM, FLASH and such. Best part is, sticking with my former chip family means perserving some of my work pipe, including supplies and factory service in malaysia.
The down sides
well, mostly time. Learning something news is in my case always enjoyable, the problem is migrating almost 15 years of dev habits to the new thing for which any tiny low level detail becomes another project. That started with the SD card support and audio playback for which I'm not just banging SPI (for the ones interested). The older chip was like 360 page long user's manual plus peripherals addendum, new chip manual is 2000+ page long (yikes).
So, I wrapped up a proto board in january after CF came out and worked most of the low level stuff for a few months, on my spare time, while finishing the house projects and while phasing the EU production to our manufacturing thanks to Elegant Weapons.
By the end of august, I had most of my core ready and working with 2 types of tool chains, and I started porting the scenario of CF + neopixel (from CS).
Of course, what isn't said is that it's almost a from-the-ground-up rewrite, since my former compiler was C and I had been crying for more modularity in my code structure for years (not that it's impossible with C but... well, coders & dev know what it means). Now that I migrated to ARM (doh) I could finally express all that code in C++, but that requested a complete rewrite of pretty much everything. That might sound sort of weird because it feels like it's project that could be easier to "port". Well, I could have stayed in C and "just do the port" without touching the structure, that would have been much faster, but so limited, hence the real effort I made.
Time, illusions and delusions
People probably still believe that I run plecter labs for a living, all day long, 24/7, which isn't the case (day job). Fortunately, my props interest match pretty well with the dev I do by day, so for the past year I've been working for both sides "at the same time" so to speak but still, I have other responsibilities. While some of us know what a project time line is, reality of things is ignored (and I don't know why). I mean projects like the teensy saber (-> proffie) still used like 3 years to come to market in its final form, with the work of mostly a single person and an existing code base (which I'm not criticizing, I'm an arduino user and even had dinner with Banzi back in the day). More recently, the Waan from Solaari, a start-up with several people invested in the project claim 2 years of dev (to reach a 70ms latency soundboard and a plain jane hilt design... #lol). So yes, things take time, and even if it's never the right moment to do it, migrating to something new means no fun time writing an interaction scenario like some others can enjoy at the moment (and which I've been as well, until recently).
So to sum it up, I follow my humble process of embedded developer. I know some stigmatized the fact I'm a "black box" dev, I'll try to improve this in the future. I also have an arduino core in the work but it's not quite ready yet.
Another question that popped up, and it's very reasonable. Without going again on "history" and such, just saying that the CF had a bootloader until about 2007. I used it extensively at that time as I was traveling quite a lot and I spent hours coding in the train between Paris, Orleans, Brussels and Amsterdam. The bootloader was then removed from the system due to legal threats I received back then. Those questions are absent to most of the newcomers and "recent" board developers but certain things haven't been so simple (down to Uncle George telling you to change you website font, this sort of thing).
Past is past. For reasons stated above (resources / RAM limitations, mostly) I didn't try to bring any FW updater in the older generation and rather bring one the new board.
That has been coded during the xmas holidays and there's not a nice updater via the SD card. The FW updater will accessible by the vocal menu for quick operation, and also via a recovery mode at boot / power cycling time. No special switch nor special GPIO for this purpose.
Specs wise, the FW update can be monitored via the USB serial port in any serial terminal program (docklight, coolterm or even putty). Flashing the current FW (which uses only 16% of the chip flash and like 4% of RAM => loads of headroom) takes approx. half a second. When monitoring the update process via the serial port, there's also a small command interpreter to force reboot, relaunch the flashing process etc.
0.5 to 1s remains short enough (IMHO) to make the update process painless and isn't an obstacle to do it "often" which will of course increase (a great deal) the amount of FW releases. I yet have to set a page up on my website but the "night builds" section is ready, I'll start populating things there as soon as the board goes in the wild.
FW update can also be done "blind" with no monitoring even if I always recommend to watch the log via the serial port, because it's really simple to do with simple and free tools.
WIP / TODO list
Right now, I'm finishing some C++ organization and classes for the blade handling. Most of the sound aspects have been take care of, from low level optimized drivers to data storage and configuration files. Just like color definitions and profiles, I have to re-enable the accent sequencers and the PLI "modules" which exist on their own, but aren't merged with the main code yet. Those are simpler task than working on the core, so it's progressing fast now.
The remaining "big" task is implementing the USB (MSD) access of the SD card. Most of the enumeration work and code is ready and works, but I haven't bound the SCSI to the SD card sector access routines yet. It's mostly a Lego work to complete now but I first want to have the CF scenario to be re established and merged with the CS features, Spectrum and so on before I tackle this. Also, while it's an important feature (and it's been demanded for sure), I believe it can be updated a few weeks after the first release. After all, that's what has happened with other boards and I'm sure everyone is busy enough to understand why things are coming out of the pipe one after the other.
Finally, regarding the USB / SD access, that will of course allow to change the fonts & configuration files via USB. I don't have writing speed test to compare with right now but based on the optimized SD driver I've implemented (and how fast reading goes), it could fairly compete with a computer SD card writer, at least to a point of not being a complete bottleneck. Also, USB access will allow for dropping a FW file in the root dir of the card then trigger an update, bringing a really simple FW update system, with the SD card hardly being removed.
To end on this, the board now has (thanks to increased RAM resources) a fully featured FAT instead of the tiny implementation I wrote from microsoft white papers back in 2005. While it's recommended on the final stage of a sound package (installed in a saber) to have a un-fragmented SD card, no voodoo dance is required anymore and it supports on-the-fly file replacement, deletion etc. I kept putting a lot of work in the optimization of this, down to the boot time and configuration load times.
The boot process including configuration files loading & parsing, along with the sound font scanning takes about 13ms. That might increase to 20ms once I have the accent sequencer back but no drastic change and a fast boot experience.
The board latency is currently 6ms in multitrack mode and might go down a little bit once I have consolidated all the required track and players (smoothswing). Speaking of latency and audio resolution, I'm actually glad that it (finally) became a thing for a lot more people. Sure, it has brought some competition (which isn't bad per say) but it's good point quality wise that those 2 topics have been also addressed by others. I was a tad "sad" to get bashed when I measured Scott's board latency (formerly 60ms) and audio resolution (9.5 bit) with only factual information. Not naming NEC here with a pointing finger nor bashing, it's just the topic and the so-called NEC war that is coming back and forth. It was also said that the source of it was multi track vs monophonic fonts. At the end (and it's just my point of view) it's just a matter of quality : with the HW designed *at that time*, I pushed for factual implementation of ideas that would provide the best possible user experience. Those include a super short response time (4.6ms) and true 16 bit dynamic range since 2007. I'm glad modern HW has picked up on this to provide a proper multitrack while preserving a low latency and that the user experience remains a core feature (real time audio is defined by the state-of-the-art < 10ms as a rule of the thumb, but can be requested as low as 2-4 ms for certain percussive instruments and professional musicians).
That's it for now, back to coding. I'll keep updating this thread to share news with you guys. Feel free to ask questions, I'll try to be reactive.