Hurray, hurray, hurray! Youre a legend Mario, thanks so much.
Will try it out as soon as you can release it!
Awesome, cheers, Ben
MarOS1.5.0 - Beta Version
Moderators: altitude, adafruit_support_bill, adafruit, phono, hamburgers
Please be positive and constructive with your questions and comments.
- paradigm x
- Posts: 237
- Joined: Sun Feb 07, 2010 3:49 pm
-
- Posts: 208
- Joined: Wed Sep 19, 2012 8:11 am
Re: MarOS1.4.1 - "Official" Version 1.4.1
ParadigmX, are you on DinSync? Could you have a look on the new version and test DinSync i and out for me before I post it more openly? I dont have any other HW here to test, and the code was touched severely, so I dont know how its doing..
- paradigm x
- Posts: 237
- Joined: Sun Feb 07, 2010 3:49 pm
Re: MarOS1.4.1 - "Official" Version 1.4.1
Hi, sorry, Ive not got any DIN SYNC equipment apart from the x0x.
- rv0
- Posts: 395
- Joined: Tue Jul 14, 2009 4:50 pm
Re: MarOS1.4.1 - "Official" Version 1.4.1
Any specific optimizations you'd like to share on the forum?mario1089 wrote:Already fixed it here, will come up with MarOS1.5 in a week or two.
I was contacted by someone with much more experience on that kinda chip, and he safed lots of bytes, almost 1.1kB, so I can now fix some issues and add the stuff that I always wanted to add.
- Nordcore
- Posts: 99
- Joined: Sat May 23, 2015 3:14 pm
Re: MarOS1.4.1 - "Official" Version 1.4.1
Meanwhile we are more in the "2k saved but 1.4k eaten up again" state.
Saving bytes is done in small chunks.
Most effective is to put doubled code to a single function.
Example: Now there is only one midi input, which does all the "running status" and "real time message" work, where the note on and note off are mode specific and done with function pointers.
About 200 bytes where gained by using the SPI-EEPROM page mode, as a lot of loops all over the code where replaced with one in the read/write function. Additionally this is much faster and saves EEPROM lifetime.
Pure cleaning up is also effective: count all clock_leds() calls. One is enough (at the end of read_switches(), thus called all 20ms) if everything is done properly.
Other savings result from blank staring at the code, until it cleans up:
So the debouncer in switch.c was:
and is now:
And yes, it does the same.
Or the random function could be somewhat cheaper:
Saving bytes is done in small chunks.
Most effective is to put doubled code to a single function.
Example: Now there is only one midi input, which does all the "running status" and "real time message" work, where the note on and note off are mode specific and done with function pointers.
About 200 bytes where gained by using the SPI-EEPROM page mode, as a lot of loops all over the code where replaced with one in the read/write function. Additionally this is much faster and saves EEPROM lifetime.
Pure cleaning up is also effective: count all clock_leds() calls. One is enough (at the end of read_switches(), thus called all 20ms) if everything is done properly.
Other savings result from blank staring at the code, until it cleans up:
So the debouncer in switch.c was:
Code: Select all
read_keypad(temp_switches);
keypress_switches[0] = switches[0];
keypress_switches[1] = switches[1];
keypress_switches[2] = switches[2];
for(i = 0; i < 24; i++)
{
s = (switches[i / 8] & (1 << (i % 8)));
l = (last_switches[i / 8] & (1 << (i % 8)));
t = (temp_switches[i / 8] & (1 << (i % 8)));
if(s != 0)
switches[i / 8] = (switches[i / 8] &~(1 << (i % 8))) | (l | t);
else
switches[i / 8] = (switches[i / 8] &~(1 << (i % 8))) | (l & t);
}
for(i = 0; i < 3; i++)
{
last_switches[i] = temp_switches[i];
pressed_switches[i] = (keypress_switches[i] ^ switches[i]) & switches[i];
released_switches[i] = (keypress_switches[i] ^ switches[i]) & keypress_switches[i];
}
Code: Select all
read_keypad(temp_switches);
for(i = 0; i < 3; i++)
{
before_s= s = switches[i]; // debounced state
l = last_switches[i]; // last input state
t = temp_switches[i]; // new input state
switches[i] = s = (s & (l | t)) | (~s & l & t);
last_switches[i] = t;
pressed_switches[i] = (before_s ^ s) & s;
released_switches[i] = (before_s ^ s) & before_s;
}
Or the random function could be somewhat cheaper:
Code: Select all
uint16_t random(void)
{
static int16_t state1=1;
uint8_t i;
for(i=0;i<8;++i) // save some time - as we really need only 8 fresh bits each time
{
if(state1 < 0)
{
state1 <<= 1;
state1 ^= 0x2d;
}
else
state1 <<= 1;
}
return state1;
}
- rv0
- Posts: 395
- Joined: Tue Jul 14, 2009 4:50 pm
Re: MarOS1.4.1 - "Official" Version 1.4.1
very educating, thanks :)
- Nordcore
- Posts: 99
- Joined: Sat May 23, 2015 3:14 pm
Re: MarOS1.4.1 - "Official" Version 1.4.1
Are you in code writing - or just curious?
On the long run my cleaned up version will get published.
If you just want to have some spare byte for your current work: just ask, than I can do a cleaned up version of switch.c and led.c + some advice how to free up some bytes of code. ( There are several clear_bank_leds(); set_bank_led(lednum); pairs it the code, which could be replaced by set_single_bank_led(lednum); )
On the long run my cleaned up version will get published.
If you just want to have some spare byte for your current work: just ask, than I can do a cleaned up version of switch.c and led.c + some advice how to free up some bytes of code. ( There are several clear_bank_leds(); set_bank_led(lednum); pairs it the code, which could be replaced by set_single_bank_led(lednum); )
- rv0
- Posts: 395
- Joined: Tue Jul 14, 2009 4:50 pm
Re: MarOS1.4.1 - "Official" Version 1.4.1
Mostly curious. Slightly offtopic ahead:Nordcore wrote:Are you in code writing - or just curious?
I'm not writing code for the x0xb0x, I'm involved in other ways ;) It's just good to have info like that in the community so other people could learn from it. Size restrictions and not always finding ways to cope with them is what fueled the community here to make a cpu modification (which ended up to be the x0xlarge). Taking this further, if you look at the current size of the x0xlarge-native n0nx0x2 firmware, even the best optimization wont make it fit on the standard x0x cpu... The codebase is soo huge nowadays.. I do wish for a n0nx0x lite to exist one day, so anyone can demo the n0nx0x features before having to buy a x0xlarge cpu upgrade.. :) If you feel adventurous, annoy antto about it on freenode #x0xb0x channel ;)
- altitude
- Posts: 995
- Joined: Wed May 11, 2005 5:17 pm
Re: MarOS1.4.1 - "Official" Version 1.4.1
has anyone open sourced the Mega2580 board? That really needs to happen, it seems it's always a struggle to get those and having one at OSHpark available always wouldn't be a bad way to keep this alive
- rv0
- Posts: 395
- Joined: Tue Jul 14, 2009 4:50 pm
Re: MarOS1.4.1 - "Official" Version 1.4.1
you mean the x0xlarge Mega2561 board?altitude wrote:has anyone open sourced the Mega2580 board? That really needs to happen, it seems it's always a struggle to get those and having one at OSHpark available always wouldn't be a bad way to keep this alive
The schematics are open source http://yhype.com/x0xlarge/
https://www.facebook.com/x0xlarge
The board is not, but they're still available from yhype and they will be for years to come :) It's not a struggle to get those..
Standard OS is also open sourced on http://wiki.openmusiclabs.com/wiki/x0xb0x#CPU_Upgrade
The bootloader (x0xb00t 2.1) by antto comes with useful extras such as midi sysex upgrade: http://antonsavov.net/cms/projects/x0xb0x-cpumod.html
n0nx0x2 is closed source for now.
Last edited by rv0 on Wed Jun 10, 2015 5:48 pm, edited 1 time in total.
- Nordcore
- Posts: 99
- Joined: Sat May 23, 2015 3:14 pm
Re: MarOS1.4.1 - "Official" Version 1.4.1
I just got one of those MEGA2580 boards, it was easy to get one, it was pretty fast here, communication was prompt & friendly.
I want to make the software running on both boards.
Beside that the XoxLarge board is an easy solution to get my debugger (Atmel Dragon) working. (On the MEGA 162 the JTAG pins are used to control the analogue part. )
And I'll have a (future) base to work on for controlling my XOX-heart (which is currently stuck at German customs ... ).
BTW: There is also a Sokkos (open source) for the XoxLarge board.
I want to make the software running on both boards.
Beside that the XoxLarge board is an easy solution to get my debugger (Atmel Dragon) working. (On the MEGA 162 the JTAG pins are used to control the analogue part. )
And I'll have a (future) base to work on for controlling my XOX-heart (which is currently stuck at German customs ... ).
BTW: There is also a Sokkos (open source) for the XoxLarge board.
- paradigm x
- Posts: 237
- Joined: Sun Feb 07, 2010 3:49 pm
Re: MarOS1.4.1 - "Official" Version 1.4.1
OTish, but a standalone x0x sequencer (no analogue) woul dbe high on my wish list... and a great complement to all those soul-less hearts out there... ;)
For those much cleverer than i !
Cheers, following along with interest. I really admire the open source way of collaborating and furthering it. When i first got my x0x, even the upgrade to the first s0koss was amazing.
For those much cleverer than i !
Cheers, following along with interest. I really admire the open source way of collaborating and furthering it. When i first got my x0x, even the upgrade to the first s0koss was amazing.
- rv0
- Posts: 395
- Joined: Tue Jul 14, 2009 4:50 pm
Re: MarOS1.4.1 - "Official" Version 1.4.1
@Nordcore
We've been thinking similar stuff (combining the x0x heart with a motherboard containing x0xlarge).
Spare time is the enemy
We've been thinking similar stuff (combining the x0x heart with a motherboard containing x0xlarge).
Spare time is the enemy
- Nordcore
- Posts: 99
- Joined: Sat May 23, 2015 3:14 pm
Re: MarOS1.4.1 - "Official" Version 1.4.1
Same here, so I don't know how that will end... ( ... but if it ever happens, it will be called the xOx brain. )
ATM I've just changed our development version of MarOS to run on both CPUs. A couple of "#ifdef" later it does already compile. Thanks to guest and sokkan I could just peek in the 2561 sokkos what has to be changed (not that much).
ATM I've just changed our development version of MarOS to run on both CPUs. A couple of "#ifdef" later it does already compile. Thanks to guest and sokkan I could just peek in the 2561 sokkos what has to be changed (not that much).
-
- Posts: 151
- Joined: Wed Jul 11, 2007 2:02 pm
Re: MarOS1.4.1 - "Official" Version 1.4.1
Nice one Nordcore!
Please be positive and constructive with your questions and comments.