Optimized the Arduino and Java code to adjust FIRST_PIN and PIN_MAX easily

[MarcAndreWyss]

Hi Sam

I changed your Arduino and Java code a bit. Now it's possible to adjust the first and last pin very easily without changing the whole code on the Arduino. Nevertheless if someone wants a different starting pin than 2 or a different stoping pin than 17 one would have to adjust MoppyCOMBridge.FIRST_PIN and MoppyCOMBridge.MAX_PIN in the Java code too, but then it is possible to play channel 1 on pins 4,5 or 6,7 and so on. If someone wants to use 5.25" instead of 3.5" Floppies an adjustment is very easy too through one single variable in the Arduino code. In all these case the code acts fully dynamically. Just if someone wants to combine 3.5" and 5.25" Floppies one would need to adjust some more Arduino code, but then the code is not fully dynamically anymore.

What do you think?

Thanks, Marc

[MultiDaxio]

As for me... Great work! It will be totally useful for many people, you must me a really tallented programist indeed! Great job! On 15 Jun 2014 14:40, "MarcAndreWyss" [email protected] wrote:

Hi Sam

I changed your Arduino code a bit. Now it's possible to adjust the first and last pin very easily without changing the whole code. Nevertheless if someone wants a different starting pin than 2 one would have to add a simple offset functionality to the java code, but then it is possible play channel 1 on pins 4,5 or 6,7 and so on. Tried it myself with some adjustments on your master code. If someone wants to use 5.25" instead of 3.5" Floppies an adjustment is very easy too through one single variable. In all these case the code acts fully dynamically. Just if someone wants to combine 3.5" and 5.25" Floppies one would need to adjust some more code, but then the code is not fully dynamically anymore.

What do you think?

Thanks,

Marc

You can merge this Pull Request by running

git pull https://github.com/MarcAndreWyss/Moppy arduino-patch-1

Or view, comment on, or merge it at:

https://github.com/SammyIAm/Moppy/pull/70 Commit Summary

• Optimized the Arduino code to adjust FIRST_PIN and PIN_MAX pinouts very

File Changes

• M Arduino/Moppy/Moppy.ino https://github.com/SammyIAm/Moppy/pull/70/files#diff-0 (157)

Patch Links:

• https://github.com/SammyIAm/Moppy/pull/70.patch
• https://github.com/SammyIAm/Moppy/pull/70.diff

— Reply to this email directly or view it on GitHub https://github.com/SammyIAm/Moppy/pull/70.

[MarcAndreWyss]

Hi MultiDaxio

Thanks for the flowers. :-)

I'm really not very talented, as I have a few problems with the bit shifting stuff and all the loops. Don't know why, but I still have problems with the abstract algorithmic way of complex loops and bit shifting, even though I studied computer science, programmed Motorola 68K and worked as a Java Software Engineer. Well I guess my strength is more the understanding of high level concepts and not programming languages or frameworks.

The work Sam did is really great, but it was annoying to change that much lines of Arduino code if one just wanted to add or remove some pins. I then even began to think of using different starting pins, just because the constant was there already. I then realised that some Java code adjustment was needed. I'm not really sure if the Java code adjustments are working in EVERY setup, but I think the Arduino code is correct.

Thanks, Marc

[MultiDaxio]

Checked on my stuff, works clearly :) On 15 Jun 2014 21:56, "MarcAndreWyss" [email protected] wrote:

Hi MultiDaxio

Thanks for the flowers. :-)

I'm really not very talented, as I have a few problems with the bit shifting stuff and all the loops. Don't know why, but I still have problems with the abstract algorithmic way of complex loops and bit shifting, even though I studied computer science, programmed Motorola 68K and worked as a Java Software Engineer. Well I guess my strength is more the understanding of high level concepts and not programming languages or frameworks.

The work Sam did is really great, but it was annoying to change that much lines of Arduino code if one just wanted to add or remove some pins. I then even began to think of using different starting pins, just because the constant was there already. I then realised that some Java code adjustment was needed. I'm not really sure if the Java code adjustments are working in EVERY setup, but I think the Arduino code is correct.

Thanks, Marc

— Reply to this email directly or view it on GitHub https://github.com/SammyIAm/Moppy/pull/70#issuecomment-46125918.

[MarcAndreWyss]

Thank God at least someone is happy! ;-)

[MultiDaxio]

Lol :p On 15 Jun 2014 22:10, "MarcAndreWyss" [email protected] wrote:

Thank God at least someone is happy! ;-)

— Reply to this email directly or view it on GitHub https://github.com/SammyIAm/Moppy/pull/70#issuecomment-46126318.

[Sammy1Am]

Previously, the reason that I had hard-coded every piece of the loop (rather than iterate over pins) was to save as many cycles as possible for the drive stepping, and avoid the calculations required to dynamically loop and calculate pin numbers. It sounds like it's working for you guys though. Do either of you have 8 drives connected? If not, I'd like to test this with 8 drives to make sure it doesn't adversely affect that before going forward. (Ideally I'd like to test with the full 16, but I don't have that set up right now).

Otherwise, I definitely like the dynamically-sized arrays, since for the most part the default starting values work across the board.

I don't know when I'll get around to testing this, but if it works well, I'll certainly try to incorporate it.

[MultiDaxio]

I am about to have 8 FDDs so Im gonna cbeck that. On 17 Jun 2014 23:38, "SammyIAm" [email protected] wrote:

Previously, the reason that I had hard-coded every piece of the loop (rather than iterate over pins) was to save as many cycles as possible for the drive stepping, and avoid the calculations required to dynamically loop and calculate pin numbers. It sounds like it's working for you guys though. Do either of you have 8 drives connected? If not, I'd like to test this with 8 drives to make sure it doesn't adversely affect that before going forward. (Ideally I'd like to test with the full 16, but I don't have that set up right now).

Otherwise, I definitely like the dynamically-sized arrays, since for the most part the default starting values work across the board.

I don't know when I'll get around to testing this, but if it works well, I'll certainly try to incorporate it.

— Reply to this email directly or view it on GitHub https://github.com/SammyIAm/Moppy/pull/70#issuecomment-46369021.

[MarcAndreWyss]

Hi Sam

No, I didn't test it yet with that much floppy drives. I'm still looking for more drives, but it's getting harder and harder to find them. I'm using my old Arduino Duemilanove for it. The maximum I can connect are 6 floppies if I'm not wrong. I guess we need a whole testing infrastructure with regression and stabilization tests for the future. :-)

I understand your concerns, but do you agree with me that it could only be a problem within the tick() function and not within the setup() function as the setup function is not looped and is executed just in the beginning?

But yes, the loop overhead can be a problem. On the other hand if a loop would cause that much problems, wouldn't it be impossible to use all those shields even on all the downsized Arduinos?

So, yes. We should test it. :-)

[Sammy1Am]

If the Duemilanove is anything like the Uno, you can use the Analog pins as digital outs for drives 7 through 9.

It's definitely only a problem with the tick() function; like I said, I really like the dynamically sized arrays for setup. Ordinarily, a loop isn't a big deal, but the tick() function gets called every 40 _micro_seconds, which is about 25 times each millisecond (i.e. a lot). An Arduino Uno at 16MHz can get about 640 cycles in every 40 milliseconds. Most instructions take just 1 cycle, but there's a few that can take up to 5.

Basically, that means that the tick() function and all the serial reading/processing needs to take place in about 320 or less instructions. Divide by 16 (max number of channels supported by MIDI) and subtract serial processing, and you've got less than 20 instructions per drive.

Long story short: I love concise code as much as anyone, and it pained me to have to write out each drive instead of put in a nice clean loop. But without some really fine grained testing, I figured I'd err on the side of caution and do everything possible to minimize instructions.

Actually, it's just occurred to me, I might be able to use conditional compilation expressions so that when FIRST_PIN and PIN_MAX are adjusted, the code will just be compiled differently... I'm definitely going to look into that.

[MultiDaxio]

Kinda like Aperture Science... its all about testing, lolz. But as Ive said earlier I am about to get 3 more drives today, so I can be your Test Subject (even more Portal cameos). I`m gonna test it and post the results tommorow. On 18 Jun 2014 09:20, "MarcAndreWyss" [email protected] wrote:

Hi Sam

No, I didn't test it yet with that much floppy drives. I'm still looking for more drives, but it's getting harder and harder to find them. I'm using my old Arduino Duemilanove for it. The maximum I can connect are 6 floppies if I'm not wrong. I guess we need a whole testing infrastructure with regression and stabilization tests for the future. :-)

I understand your concerns, but do you agree with me that it could only be a problem within the tick() function and not within the setup() function as the setup function is not looped and is executed just in the beginning?

But yes, the loop overhead can be a problem. On the other hand if a loop would cause that much problems, wouldn't it be impossible to use all those shields even on all the downsized Arduinos?

So, yes. We should test it. :-)

— Reply to this email directly or view it on GitHub https://github.com/SammyIAm/Moppy/pull/70#issuecomment-46403446.

[tg44]

Comment to clean code vs speed: I tried to code sth like this in java first, it has a cap in runspeed. You simply cant do this in a nearly 4ghz amd if ur program use a core solely. (Not a 200mhz cpu, its 20 time faster, just java...) So yes, sometimes a cleancode coud be so worse performance. In gcc I think it is possible to unroll a cycle, I think it coud be a half good way to make a code "beutifull" and keep it fast. Some stackoverflow in this subject: http://stackoverflow.com/questions/4071690/tell-gcc-to-specifically-unroll-a-loop http://stackoverflow.com/questions/2349211/when-if-ever-is-loop-unrolling-still-useful

[jazzbassNick]

Well played sir On Jun 18, 2014 12:42 AM, "MultiDaxio" [email protected] wrote:

Kinda like Aperture Science... its all about testing, lolz. But as Ive said earlier I am about to get 3 more drives today, so I can be your Test Subject (even more Portal cameos). I`m gonna test it and post the results tommorow. On 18 Jun 2014 09:20, "MarcAndreWyss" [email protected] wrote:

Hi Sam

No, I didn't test it yet with that much floppy drives. I'm still looking for more drives, but it's getting harder and harder to find them. I'm using my old Arduino Duemilanove for it. The maximum I can connect are 6 floppies if I'm not wrong. I guess we need a whole testing infrastructure with regression and stabilization tests for the future. :-)

I understand your concerns, but do you agree with me that it could only be a problem within the tick() function and not within the setup() function as the setup function is not looped and is executed just in the beginning?

But yes, the loop overhead can be a problem. On the other hand if a loop would cause that much problems, wouldn't it be impossible to use all those shields even on all the downsized Arduinos?

So, yes. We should test it. :-)

— Reply to this email directly or view it on GitHub https://github.com/SammyIAm/Moppy/pull/70#issuecomment-46403446.

— Reply to this email directly or view it on GitHub https://github.com/SammyIAm/Moppy/pull/70#issuecomment-46404860.

[MarcAndreWyss]

Hi all

I thought about this problem again during my travel from work to home. Do we really need 8 or 16 drives to test this? If we use FIRST_PIN = 2 and PIN_MAX = 17 (= 8 channels) and the Arduino really has that much pins, but we do only connect one floppy to a channel and test it this way, wouldn't that be enough? If it is working with this single floppy the overhead with the loop cannot be a problem. The Arduino does not know at which port a drive is connected or not. Therefore it does the computations for all 8 channels, but just with one drive connected.

Am I wrong or do I miss something?

[MultiDaxio]

The point is, that in the original Moppy.ino when I want to connect my floppy to 4 and 5 pins (corresponding for channel 2 in midi file) and I check the channel 2 checkbox in controll app, the whole contraption will be mute, because there is neither signal, nor possibility for channel 1(floppy

1. to be active. The new concept would male it possible. At least that what we are trying to make. Hope I`ve understood the whole project correcly. Cheers! On 18 Jun 2014 19:42, "MarcAndreWyss" [email protected] wrote:

Hi all

I thought about this problem again during my travel from work to home. Do we really need 8 or 16 drives to test this? If we use FIRST_PIN = 2 and PIN_MAX = 17 (= 8 channels) and the Arduino really has that much pins, but we do only connect one floppy to a channel and test it this way, wouldn't that be enough? If it is working with this single floppy the overhead with the loop cannot be a problem. The Arduino does not know at which port a drive is connected or not. Therefore it does the computations for all 8 channels, but just with one drive connected.

Am I wrong or do I miss something?

— Reply to this email directly or view it on GitHub https://github.com/SammyIAm/Moppy/pull/70#issuecomment-46468525.

[MultiDaxio]

I meant only 4 and 5 pins and only second channel checkbox (just to be precise :p ) On 18 Jun 2014 19:47, "Adam Kwiatkowski" [email protected] wrote:

The point is, that in the original Moppy.ino when I want to connect my floppy to 4 and 5 pins (corresponding for channel 2 in midi file) and I check the channel 2 checkbox in controll app, the whole contraption will be mute, because there is neither signal, nor possibility for channel 1(floppy

1. to be active. The new concept would male it possible. At least that what we are trying to make. Hope I`ve understood the whole project correcly. Cheers! On 18 Jun 2014 19:42, "MarcAndreWyss" [email protected] wrote:

Hi all

I thought about this problem again during my travel from work to home. Do we really need 8 or 16 drives to test this? If we use FIRST_PIN = 2 and PIN_MAX = 17 (= 8 channels) and the Arduino really has that much pins, but we do only connect one floppy to a channel and test it this way, wouldn't that be enough? If it is working with this single floppy the overhead with the loop cannot be a problem. The Arduino does not know at which port a drive is connected or not. Therefore it does the computations for all 8 channels, but just with one drive connected.

Am I wrong or do I miss something?

— Reply to this email directly or view it on GitHub https://github.com/SammyIAm/Moppy/pull/70#issuecomment-46468525.

[Sammy1Am]

That's a good point, actually, MarcAndreWyss. If the Arduino's having trouble keeping up, the pitch of the drives would fluctuate or they would start to stutter. But as long as, for example, drive #1 exists, you can just have the loop running through imaginary drives. Since turning on and off pins takes time too, it would be best to actually have an 8-16 channel MIDI so that the imaginary drives are playing imaginary notes.

The maximum amount of work needs to be done to play a continuous note, so trying to play a long note on X drives simultaneously should help find the upper limit for computation.

I didn't even know that unrolling loops was a thing until Gergő mentioned it, but that would be a great compromise if we end up needing the extra cycles.

My rig's not really assembled, but if I do get it put together I'd love to play around with some ideas I've got now...

On Wednesday, June 18, 2014, MarcAndreWyss <[email protected] javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

Hi all

I thought about this problem again during my travel from work to home. Do we really need 8 or 16 drives to test this? If we use FIRST_PIN = 2 and PIN_MAX = 17 (= 8 channels) and the Arduino really has that much pins, but we do only connect one floppy to a channel and test it this way, wouldn't that be enough? If it is working with this single floppy the overhead with the loop cannot be a problem. The Arduino does not know at which port a drive is connected or not. Therefore it does the computations for all 8 channels, but just with one drive connected.

Am I wrong or do I miss something?

— Reply to this email directly or view it on GitHub https://github.com/SammyIAm/Moppy/pull/70#issuecomment-46468525.

[MarcAndreWyss]

Hi Sam

I made a 9 channel midi with the same track on each channel. Took a C note with a duration of about 4min. Attached two floppies and used FIRST_PIN = 2 and MAX_PIN = 19. Worked for me without any problems. Maybe someone else could verify that too or even test it with 16 channels.

I used an Arduino Duemilanove

[MultiDaxio]

TEST RESULTS: works

I demand a promotion, GLaDOS!

2014-06-19 20:04 GMT+02:00 MarcAndreWyss [email protected]:

Hi Sam

I made a 8 channel midi with the same track on each channel. Took a C note with a duration of about 4min. Attached two floppies and used FIRST_PIN = 2 and MAX_PIN = 17. Worked for me without any problems. Maybe someone else could verify that too or even test it with 16 channels.

— Reply to this email directly or view it on GitHub https://github.com/SammyIAm/Moppy/pull/70#issuecomment-46595437.

Adam

[MarcAndreWyss]

Has ever someone thought about the possibility to send first and last pin information through the serial port and not hard code it within the microcontroller? Cool thing would be if the Java application would send the informationen about the pins and the floppy type and the microcontroller would initialize itself according to these values...

[erinzm]

Wouldn't it be easiest to write most everything as a preprocessor macro? Then you could save all the cycles :D