1.
After a sketch is uploaded there is a fairly long wait and then each Digital Out is stepped through from 1 to 16. Why is this? How can I avoid this? This happens when I start the serial port too and it takes a lot of time.

2.
When I do a Serial.print on analogRead(DUE_IN_A00)
i get values between 2077 (knob minimum) and 2193 (knob maximum).
Is this right? Seems odd to me. I thought it would be something like 0-4095 or something?

3.
Has anyone found a way to get around the Verify code stage? I don't want to wait that long so I'd like to skip it. The "Verify code after upload" in the IDE doesn't work, that's a bug but I've heard of ways of doing this via the command line? I'm on a mac. Anyone doing this?

4.
Has anyone tried to create a stripped down version of the library? There are a lot of includes and they take quite some time to compile. Would be nice to experiment with a lightweight version of the code base.

Thank you! br> br>

br>scottwilson

br>1. Technically, it's taking about 160 milliseconds for the setup sequence. You can see it in IO.cpp line 227. Feel free to delete that line. If it's bothering folk, I'd be happy to add a parameter to EventManager.initialize() that disables the reset sequence. Mainly it's feedback so you know that the device is resetting.

The time when opening the serial port is more likely just the handshaking between the OS and the 16U32 chip which is acting as a USB emulator for the microcontroller's primary serial port.

2. 2077 to 2093 as a range from min to max seems a tad low. What you should be seeing is from about 2000 to about 4000. That covers from 0V to 5V. the 0 - 2000 is covered by -5V to 0V.

I added a method analogReadmV(port) that will return to you the millivolts instead of the number from 0-4096.

3. So for the command line stuff... There's really two steps. The first is compiling and the second is uploading. The verify code portion of what you're speaking about is part of the upload process. The tool that's used to upload to the ARM Cortex M3 is called 'bossa'

If your Arduino IDE is installed into applications, you can run it like this

There's some info on the net about how to run this manually. Before you do that, though, you'll have to compile the sketch. When you compile using the IDE, the *.hex file goes into a temporary folder somewhere. I don't recall, so will have to dig around a bit.

What's debatable is whether or not this will save you the few seconds it takes to do the verify.

Understanding that in general, having to upload code every time you want to change a single drum beat is a pain, I've mentioned a couple of times that I'm working on a no-code framework where the sketch will be able to configure itself from a JSON file included on the microSD card.

To see some of what this might look like, you can peek in here to see some work in progress:

If it's bothering folk, I'd be happy to add a parameter to EventManager.initialize() that disables the reset sequence. Mainly it's feedback so you know that the device is resetting.

Personally I feel like anything that can be done to take down the upload time is crucial. At least a stripped down, bare minimum version.

scottwilson wrote:

2. 2077 to 2093 as a range from min to max seems a tad low. What you should be seeing is from about 2000 to about 4000. That covers from 0V to 5V. the 0 - 2000 is covered by -5V to 0V.

I added a method analogReadmV(port) that will return to you the millivolts instead of the number from 0-4096.

When I do a Serial.print on Serial.println(analogReadmV(DUE_IN_A00));
I get:
knob minimum -15
knob "two o'clock" 340
knob maximum 270

What's going on there? The value suddenly sinks? How can I set this thing to go between 0 and something in a linear fashion? br> br>

br>scottwilson

br>I emailed some instructions on running bTestAnalogInputs and sending me the output. Could be you have a bad input channel. I do test them all before sending out, but something could have happened in the mean time. We should be able to work that out.

In the mean time, try just moving to another input as a workaround for now.

For the upload times, even a small sketch will take longer on the Due than the Uno as even the base Arduino API is considerably larger, including more features and C libraries. While building an emulation of the Ardcore isn't impossible, it will still require a significant amount of that code that is taking care of the basic system management of the 'b.

Which leads to the philosophical differences between the Ardcore and the nw2s::b, I think the difference is one of necessity. The Ardcore is, at it's heart, a very primitive device which allows you to get by with a few idioms for generating a single CV signal or to toggle two digital outputs. It's great at what it does.

The 'b is a little more advanced in that there are nearly twice as many digital outputs, 18 times as many analog outs, a number of peripherals including an SD card, a beat clock display, an LED driver on an I2C bus, and the analog outputs are on an SPI bus rather than a parallel DAC interface.

My primary goal with the code I'm writing is to abstract as much of the complication of those devices away from the developer so that they can concentrate instead on the algorithm at hand rather than the timers, clock displays, and bus traffic, etc.

I also want this to be a little easier to work with when you want to have multiple things going on at once. With this many outputs, you can easily control quite a few triggered devices, CV controlled devices, and should be able to orchestrate quite a bit if the frameworks are in place. You can only do this if you remove some of the spaghetti-ness that's inherent in the highly optimized/inlined/static Ardcore C and adopt a slightly more abstract, data-driven model, trusting the system to take care of a couple of things for you.

Long-term goals are to bring this flexibility to more folk than those of us who venture into C/C++ land - which is what the SD-based programs are for.

I may not be able to solve the upload speed issue, but I hope that with some time, coaching, and sharing, that we'll learn first how to bring the ardcore sketches into this realm, and then eventually move beyond and start doing things that are only possible with this beast!

Let me know what you think of the translated sketch I sent you earlier.

s br> br>

br>scottwilson

br>Just wanted to follow up on this in case anyone has a similar issue. Seems that there were two issues, both cable related. The delay he was seeing was that on reset, the 'b spins through each of the LEDs. If the LED driver is not reachable, then the reset process is REALLY slow. Took a couple of the cables off and reseated them and it's all good for now.

I'm sending him a couple of spare cables just to have in case it re-emerges.