c0nb0x - control app - under developement

[antto]

hi guys, i wasn't sure whether to post this here or in x0xm0dz..
so, i'm trying to make an "app" to replace c0ntr0l
i'm also going to modify *slightly* the adafruit firmware v1.05 .. gonna change the app<->x0x protocol (the way it sends messages, packets and so on)

the important things you should know:
- i'm building this under winXP, and it should also work on newer windows OSes
- i'm using cross-platform libraries, so in theory this should be also buildable under MAC or other platforms
- - written in C++ using std, and boost
- i will try my best to make this app work without aweful bugs
- i'll release the source code *IF* i manage to make the code not _very_ ugly

the app is called c0nb0x, it's built as a console application, no fancy GUI
it has a simple old-fasioned (game-style) menu system
here's an early screenshot of the main menu:


any ideas suggestions or comments are welcome

now some details:
i want to implement a new app<->x0x serial protocol as i mentioned
i'll clear all unused messages from the original firmware (stuff that never got implemented)
change some of the messages so the code looks more friendly (using enums instead of #defines)
make it easier for future modifications of this firmware - adding more stuff to the protocol should be easier
some of the things that float in my mind are:
i'd like to implement some kind of a "sequencer debugging" system - an easier way to test if your buttons/leds work
pressing a button on the x0x could be sent to the app, and the app can print which button was pressed, at the same time, the corresponding LED can be lit
this would be a fast way for the user to find out if anything is wrong with the buttons/switches/LEDs
..if i can squeeze this into the original firmware without increasing the size too much
the mechanizm for this would be kept simple, i'll try to put less code in the x0x firmware, more of the code in the app (or this whole debugging idea could be just a sepparate diagnostic firmware with just diagnostic functions and nothing else)
maybe guest would like this ;P~

anyway
progress so far: main menu and settings menu work, settings are saved into a .cfg file in the executable directory in a similar to .INI format (can be edited with a text editor)
[/boringpost]

[guest]

the bootloader for the upgrade chip
seems to have some sort of serial debug built in
which might be interesting to have access to as well
it can tell you the state of internal registers i think

[antto]

i was more thinking about something like this:
any button or rotary switch or the tempo encoder value change are reported over USB to the app
the app shows on screen (or does something else)
on the other hand the app can tell the x0x to lit any LED

this is a pretty simple mechanism
a diagnostic firmware could have several different tests:
Button & LED test - press all buttons, move all switches/tempo and the app will wait till you complete all of them, before it gives you an "OK"
Synth test - from the app, you can send noteON/OFFs and the x0x must play them, for example - all C notes, or full note range, the A440 key (for tuning) and similar useful things
also, accents and slides could be tested for propper operation
MIDI out test - could send a few midi notes out (this might be dumb)

i'm also thinking about a "diagnostic" pattern, one which is actually hardcoded into the app, with very specific notes with slide and accent in combinations (something like a "Cornell Box" )
so, if anyone is unsure if something's wrong with his x0x - he can just record this pattern and we can analyze the recording (if accents work, slide time correct, envelopes/cutoff ranges okay, and so on..)

it might sound confusing so far but let me put it more clearly:
the main thing i need to modify in the firmware is for the basic messages for the app<->x0x protocol
these include: OS/OS_version query, import/export EEPROM, get/set tempo, and some MSG_OK MSG_BAD stuff which is fundamental..
these will (hopefully) only require a small modification of firmware v1.05 and will probably fit in the old CPU without removing any of the original features of v1.05

and the other thing: the diagnostic sh*t can be implemented in a sepparate firmware which doesn't have the normal x0x features
these will be just more MSG'es on top of the fundamental ones
MSG_NoteON, MSG_NoteOFF, MSG_LED_ON ...
these will also require a small amount of code i think
the actual "work" will happen on the app side (it'll control the x0x by these messages)

if these extended messages are not implemented in an OS - the app will know:
app sends: MSG_LED_ON 22
x0x returns: MSG_BAD (x0x has an OS which doesn't understand the MSG_LED_ON message)

if the original CPU can fit the stock firmware v1.05 with both the fundamental and extended messages - great then
but this will surely be possible with the new CPU

[E:pp:ik]

We need like buttons on this forum

[antto]

hi, after my last post, i tryied lots of stuff
it turns out console app won't quite work as good as i thought on all platforms
instead, i looked here and there for another solution and i figured out i'll use the Allegro library (it's a cross-platform C/C++ library intended for games) together with the boost library for serial ports and threads
allegro will be used to create a screen and draw text in it (thus it's still gonna be a console-like app, but it will be the same on all platforms)

getting allegro and boost to compile and work together was nasty, but at the end - it worked
however, i haven't really taken the project further than that yet
maybe i'll try and implement the features i mentioned into the new CPU and finish of c0nb0x at that point
right now i've dedicated all my spare time (if any) to another project

[antto]

bump

now that i'm jobless since 4 days.. i had time to do stuff again



so, this is just allegro, trying to build a console
so far i got most basic things working
echo << an equivalent to "cout"
and uins() sort of like "cin" but takes just 1 variable at a time
a pallet of 16 colors
there some bits of commands similar to those from curses
move(x,y) addch() cls() ..

some things i wish to had won't work, like copy/paste text, because the clipboard on different platforms is different and i couldn't find any sort of decent lib for it
there is also some bits of code from allegro, which has to be #ifdef'ed on MAC as far as the documentation tells
also, for making things easy, the console is fixed to 640x480 with 80x30 chars

next, i will try to put the serial port code (from boost) into this

i will eventually need someone with MAC to build this
so if any dev is reading - the needed things are Allegro4, and boost
the project is Code::Blocks but i think i can supply makefiles for GCC (gcc v4.6.1)

[antto]

i had a second thought about the boost lib
i think i will drop it, since once again, i cannot make it compile
it's a huge and very complex/complicated lib, for just a serial port, it's not worth the pain

i couldn't find any cross-platform serial port lib, so imma be thinking on this..
the problem is MAC, since i don't have one, i need assistance

[antto]

after thinking, i wrote plain win32 serial port code, wrapped into a class
so, the mac version of this class should be written at some point
everything else *should* work

got the main menu, and settings menu working (this is actually a bit old of a screenshot)
the configuration file is working too, the app prompts whether to save to CFG or not
there is also a sort of "statusbar" at the bottom, which usually prints additional information
for the focused option in a menu..

navigating the menus is either by the quick key (shown in brackets) or with the up/down arrows and Enter key

[antto]

i have a question...
flashing firmware and the bootloader are still technically unclear to me..

if i put the x0x in bootload mode, and start sending all kinds of data to it, (asside from the fact that i'll probably screw up the firmware) is there a possibility for such a disaster to happen, that i cannot fix it with c0ntr0l?
this is very important to me, since *IF* i somehow manage to f*ck it up (the bootloader) - i don't have the tools to put it back, and this would kill me

[Altitude]

AFAIK, I dont think that you can mess up the bootloader without a programmer

[antto]

thanks
now if i find some sort of serial port pipe to monitor the data..

[antto]

i'm working on the "Connect to x0xb0x" function (which is for dumping pattern memory and changing tempo..)
specifically on extracting the patterns from the x0x into a .xbp file

this function of c0ntr0l never worked for me, it always extracted LESS than the total amount of data
128 patterns * 16 bytes = 2048 bytes == 2KB exactly
i never got a 2KB xbp out of c0ntr0l, it was somewhere over 1KB usually (each time it was different)

now with my app, i begin to notice similar issues
BUT now i can figure out where the problem is

i send a "pattern read" request, then i wait for the "pattern" reply (which contains the actual pattern data)
and repeat

now, i also have a timeout counter, in case something goes wrong, and the x0x never replies back
(1000 ms)
in some conditions, it times out
maybe i'm sending my packets too quickly? gotta try out stuff

[antto]

i solved the pattern dumping errors by a "retry" mechanism
if anything goes wrong when receiving a pattern - the app tryies up to 3 more times before quitting..

now, i'm trying to make the "upload firmware" function
but i have a problem.. guess what - after i flash a .hex - the x0x doesn't work
fortunately i didn't mess up the bootloader so far

i spoke to some avr guys, they explained me this and that about the "lockbits"
when i checked them on my x0x - wtf.. they are not set
it means - via serial port, it's possible to overwrite the bootloader
and the bootloader itself doesn't support setting the lockbits via serial (with the 'l' command)
grr

anyway.. i've been looking at the source code for both the c0ntr0l app and the bootloader
i neither understand python, nor ASM (especially ASM..)
so by looking at c0ntr0l, i see it uses a "fast mode" for flashing the hex
'Z' command, which flashes a whole "page" (128 bytes) at once

great, but i don't understand what happens next
i figured "why don't i log the data between the c0ntr0l app and the x0x, then i'll be able to see the whole process of flashing a hex.."
great! so i found a decent "virtual serial port" thing, it creates 2 virtual ports, COM7 and COM8 (connected to one another like a pipe) .. then i connect c0ntr0l on COM8
on the other hand, i wrote a small app which connects to COM7 and COM3
on COM3 is my x0xb0x
the app also works as another pipe, passing the data between COM3 and COM7, and also logging it to a file

guess what - i run c0ntr0l, set it to COM8, chose "Upload firmware" ... it connects.. starts flashing.. aaand stops
pops up an error message either that the x0xb0x isn't in bootload mode, or another error about global name "serial" is not defined or something

when check the log file - c0ntr0l seems to send the first page 'Z' command followed by 128 bytes, then the x0x responds as usual with 0x0D
and that's where the log ends
banned, why doesn't c0ntr0l work thru a pipe..
i wanted to know what follows after the 'Z' command with the 128 bytes of data, apparently another 'Z' command, but does it set the address again before that, or does it send 'm' command

[antto]

ok, i solved it
now flashing firmware works

i changed the settings menu
you can set a default pattern size, and default pattern memory (eeprom) size

when c0nb0x connects to the x0xb0x - it does a few tests before it proceeds
1) it pings the x0x
2) then tryies to figure out what "firmware" it runs and what version
all of the current ones will return an error so it assumes it's adafruit v1.05 or compatible (aka sokkos)
3) asks the x0x for pattern 0,0 just to find out the pattern size
if the pattern size doesn't match the default (from the settings menu) - it asks you to accept the detected pat size or not
4) asks the x0x for the tempo

after all this is complete - it opens the "computer control" menu where you can change the tempo and backup all patterns or the whole eeprom memory

i decided to make a new format file for the "export patterns" - .CXM
basically it's raw just like .xbp, but it has a small header at the top
.XBP will be only importable for backwards compatability with c0ntr0l

[antto]

import/export functions are done
there are some protections to not read/write beyond the eeprom size

the new CXM file format saves a variable "Pattern Size"
for example, if you had n0nx0x (which uses 21byte patterns) and exported a .cxm.. then you switched back to sokkos or adafruit v1.05 OS (which use 16byte patterns) and you try to import this file by accident - c0nb0x will warn you..

so far everything works, except the "Monitoring" mode
maybe i can upload a v1.0beta

here's a small video that i made..
http://www.youtube.com/watch?v=aW2W44BsDxY

notice how the x0x freezed and the transmition broke for a moment, but c0nb0x retries up to 3 times on a single pattern slot, so after several difficulties - it still managed to upload all 4KB of eeprom data to the x0x succesifully
btw this doesn't happen when the sequencer is stopped