MS2/Extra 2.0 beta 14 (20071020)

woh · Post by **woh** » Sat Nov 03, 2007 4:23 pm

Thanks Enrico,

It is always nice to know someone else uses VB

woh · Post by **woh** » Sat Nov 03, 2007 4:29 pm

jsmcortina wrote:That makes sense. When the page changes the code copies the flash data into ram. This takes a finite time.
I am assuming that with 115200 comms the next character may get dropped in this time period.

Megatune implements a delay between bytes.

James

Yes, there are several workarounds.
I think it would be simpler and easier for the unitiated if this worked without the user putting in the delay. Any chance of you or Ken adding a 'fix'.

Post by **jsmcortina** » Sat Nov 03, 2007 5:02 pm

woh wrote:I think it would be simpler and easier for the unitiated if this worked without the user putting in the delay. Any chance of you or Ken adding a 'fix'.

The easiest fix would be to change the baud rate to 300 baud.

James

UnaClocker · Post by **UnaClocker** » Sat Nov 03, 2007 5:17 pm

Is that all we need? I figured 9600 would be more reliable, but wouldn't think 300 would be fast enough.

woh · Post by **woh** » Sat Nov 03, 2007 7:46 pm

jsmcortina wrote:The easiest fix would be to change the baud rate to 300 baud.

James

James, I think ye doest jest.

300 baud!

Not good!

So do I document it as is?

I suspect it is the other commands as well. Do you know if this applies to all commands that have a page parameter, or just the "r" command?

Post by **jsmcortina** » Sun Nov 04, 2007 4:38 am

Yes, I was joking. 300 baud would be painfully slow.

Because the code must copy 1k of data from flash to ram there will always be a delay. This cannot be changed on the current chip. The tuning software must have a pause in there.

Unaclocker, you can currently change the baud rate - there's a baud rate menu under Communications. Once you've changed this you'll almost certainly need to use the boot jumper next time you re-flash.

James