Download Speeds

I'm preparing for the next exhibition of Silent Barrage coming up in July in Beijing, China.

With nearly 50 PICAXEs on about 45 boards, we use 4 programming cables to reprogram each chip/card when required. We have 2 AXE027 FTDI-based cables and 2 are aftermarket Prolific-based cables from Jaycar.

I have to ensure that the cables are working, along with all of the other equipment, so everything gets a workout.

In this process, I noticed that the Prolific cables seemed to be faster at downloading the same program. So a did a comparison:

Edit: I incorrectly got the original cable names swapped over
Prolific (Jaycar): 28x1 3725 bytes (+ EEPROM + Table) = 21 (25) seconds
FTDI (AXE027): 28x1 3725 bytes (+ EEPROM + Table) = 1:03 (1:11) m:ss

The Prolific cable is 3 times faster! Not what I expected.

That sounds like a bit of a task, reference to the project itself there.
Just for comparison, I use a generic usb to rs232 converter and the picaxe serial programming cable, all it's identified as is CH340.
Anyway, downloading a program of 3269 lines of "high 0" for 3277 bytes took: 32 seconds.
The only reason I still use this is because download times don't matter to me, but it seems they do for you.

Is it possible to maximise the speed by shortening cable or any other things?

ps: I refuse to believe there is a 'z' in 'maximise'

I have noticed that download speed varies between different types of USB device, and indeed between one machine and another.

probably differances in how the drivers are implemented I thought.

Any timing differences will be related to the USB<>serial driver itself, as PE doesn't even know which driver is in use (as that is handled by the Windows OS).

As Windows is a multi threading environment, some drivers are more time generous than others, so for instance some serial drivers will allow much more time for other threads to process, giving better overall PC performance but then creating a slower download.

So it really comes done to how the USB driver was developed and how it interacts with other programs via the Windows OS. For instance you may well also find that WinAXEpad has a different download time to PE, as they use different development platforms. Updating to the latest driver may also be of benefit?

inglewoodpete said:

I'm preparing for the next exhibition of Silent Barrage coming up in July in Beijing, China.

With nearly 50 PICAXEs on about 45 boards, we use 4 programming cables to reprogram each chip/card when required. We have 2 AXE027 FTDI-based cables and 2 are aftermarket Prolific-based cables from Jaycar.

I have to ensure that the cables are working, along with all of the other equipment, so everything gets a workout.

In this process, I noticed that the Prolific cables seemed to be faster at downloading the same program. So a did a comparison:

FTDI (AXE027): 28x1 3725 bytes (+ EEPROM + Table) = 21 (25) seconds
Prolific (Jaycar): 28x1 3725 bytes (+ EEPROM + Table) = 1:03 (1:11) m:ss

The Prolific cable is 3 times faster! Not what I expected.

Click to expand...

Either a typo or 3 times slower, surely?

Texy

Texy said:

Either a typo or 3 times slower, surely?

Texy

Click to expand...

Oh boy. I don't believe I posted that! Correction - The FTDI is the slower one by a long shot.
FTDI: 1 minute (Driver v2.6.0.0)
Prolific: 20 seconds (Driver v2.0.0.7)

I'll correct the original post.

Also, for the record, both tested with the same Toshiba Laptop, Windows 7 32 bit.

I'll try upgrading the FTDI driver.

I upgraded the FTDI driver to Vers. 2.8.14.0. Absolutely no change to the download time 1:03 for code alone. 1:11 for code + EEPROM + Table

I prefer to use the AXE027 FTDI cable: It's more stable when programming PICAXEs connected to long transmission lines. In the same situation, the Prolific cable it prone to lockups, requiring uplugging from the USB port and rediscovering in the PE.

However, the AXE027 uses a lot more time, which multplies when there are a lot of chips to reprogram.

My apologies for the earlier confusion.

What is the sequence for programming these, does the computer give a RTS and wait for CTS? Is the data verified after downloading?

What I really want to know is, can picaxe's be paralleled for programming, common sense tells me no.
And yes V=IR and all that jazz I'm not worried about, are there going to be packet collisions per se, when the chips respond to the computer?

pete20r2 said:

What I really want to know is, can picaxe's be paralleled for programming, common sense tells me no.

Click to expand...

Been discussed before, at reasonable length. A search should find it out...

IIRC, you can possibly do it (a general call for someone to try it was done, but there were no takers) if you connect all the serin's together but only return one serout to the PC.

If all the PICAXEs were identical (undefined) and there were no errors, then it is suspected it might work

I may be able to try it, with stuff that doesn't belong to me of course

As discussed before, parallel download, sending to multiple PICAXE and just connecting one back to the PC, may work but the problem is you don't know if it has worked.

Unless you can exhaustively test each PICAXE after download you can never be sure that it won't do something odd under some circumstance when in use. It will invariably take more time to test each PICAXE than to do the download and have that confirmed as successful.

On a machine control system i designed, the firmware at every start do a CRC checksum of the whole FLASH, then on EEprom.
I think that should be included in PICAXE. (Selling point for reliability, plus it enables parallel download to be utilised!)

Additionaly my dewsign have a pin connected to the power supply feedback via a resistor so it actually do the tests at 4,6 and 5,4 V, then float the pin and runs at 5,0V.
Why have i never seen this simple quality assuring techology ever used by another designer? Or is there?

I guess it is virtually impossible to change the PIXAXE firmware, so practically it can be considered safe.

Can the user program read itself. (So it can do some simple checksumming?)

I understand user program is blocked from reading the Rev ed firmware, but it would be nice if it can read itself, even if it is not useful for anything than checksumming.

On a machine control system i designed, the firmware at every start do a CRC checksum of the whole FLASH, then on EEprom.
I think that should be included in PICAXE. (Selling point for reliability, plus it enables parallel download to be utilised!)

Click to expand...

The download verifies the Flash as it runs, and I dont recall hearing about many failures in Flash once programmed so its debatable whether it would be a useful and desired feature. And if it was included, what other already present feature would be removed ?

A CRC on EEPROM is easy to arrange in a running program.

There is a lot more to parallel downloads than you think, the whole download process would need to be re-engineered for it to work.

Additionaly my dewsign have a pin connected to the power supply feedback via a resistor so it actually do the tests at 4,6 and 5,4 V, then float the pin and runs at 5,0V.
Why have i never seen this simple quality assuring techology ever used by another designer? Or is there?

Click to expand...

What do you mean ?

In another life, I field tested/diagnosed mainframe computers (some built with individual transistor gates). One procedure to flush out faults was to "swing the margins" - run confidence tests with power supplies set at upper and lower limits of voltage tolerance. This requires adjustable power supplies of course, and to automate the process requires remotely-adjustable supplies. There's a trade off as you add this complexity and introduce more points and modes of possible failure...
I think this is what Morgani is suggesting?

Note that the "swinging the margins" concept was also extended to clock timings and so on. It would be possible to do that on PIC based circuits I suppose, but difficult to see the value outside of very sensitive applications where you'd probably not be using the educational/hobby Picaxe family.

rossko57 said:

One procedure to flush out faults was to "swing the margins" - run confidence tests with power supplies set at upper and lower limits of voltage tolerance. This requires adjustable power supplies of course, and to automate the process requires remotely-adjustable supplies. There's a trade off as you add this complexity and introduce more points and modes of possible failure...
I think this is what Morgani is suggesting?

Click to expand...

Really, but for modern microcontrollers ?

I would be astonished if changing the power supply on a PICAXE down to 4.6V and up to 5.4V, and running checksum tests at these voltages would tell you anything useful. And of course you are adding extra bits that can fail.

Modern micro controllers are very tolerant of supply voltage variations, and most are rated to run from 2.5V to 5.5V.

I am talking about flash failure not CPU failure.
Normally flash conten breaks more often than CPU:S therefor SSD drives and similar store data in a way that errors can be detected and most often corrected on the fly, and the bad cells marked bad and virtually replaced.
That technology is normally not availabe on microcontrollers, but what i describe here catches some failures.

Everything breaks, it is just a matter of time.
It do happen some components are out of spec and fail earlier than "guaranteed".
In use, they may suffer problematic out-of-sopc environment due to misuse or other parts failing.

CRC check is a no cost in production.
A pin and a couple resistors are not free but most very affordable in possible dangerous machines.
It also serves as a self-check, so faster programming methods may be used- it may even save a part of cost.
Also it enables cheap in-field updates by allowing self-programing (which are often not as reliable as in-production programmers)

Learning good practise is *especially* important in education.

srnet said:

There is a lot more to parallel downloads than you think, the whole download process would need to be re-engineered for it to work.

Click to expand...

That is almost certain to be correct and would likely have very little gain.

Though user program downloading is via a simple but robust serial mechanism the internal firmware is installed in the PICAXE using a production line programmer which I understand does verify programming reliability across the operating voltage range.

Morganl said:

Normally flash conten breaks more often than CPU:S therefor SSD drives and similar store data in a way that errors can be detected and most often corrected on the fly, and the bad cells marked bad and virtually replaced.

Click to expand...

The PICAXE program memory does not need to be written constantly like an SSD. It is very unlikely to fail when only being read.

CRC check is a no cost in production.

Click to expand...

Doubt its no cost, but in 'production' the PICAXE firmware is already verified, and most PIC programmers do this.

A pin and a couple resistors are not free but most very affordable in possible dangerous machines.

Click to expand...

If the machine is 'dangerous' you ought not to be using a PICAXE in the first place, unless you want to take personal responsibility for the reliability of the firmware.

Its 'good practice' not to decrease the reliability of a system by adding so called safety features. Can you be sure, point to any tests, that show that adding the circuitry to alter the supply voltage of a PIC and then doing CRC checks at different voltages actually improves reliability of the systems ?

It also serves as a self-check, so faster programming methods may be used- it may even save a part of cost.

Click to expand...

If its a user adding their own program to a PICAXE, thats already checked.

Also it enables cheap in-field updates by allowing self-programing (which are often not as reliable as in-production programmers)

Click to expand...

The PICAXE already has and uses the feature to self-program, the firmware (already in flash) runs a bit of software that downloads the user programs to other area of the flash.

Morganl said:

On a machine control system i designed, the firmware at every start do a CRC checksum of the whole FLASH, then on EEprom.
I think that should be included in PICAXE. (Selling point for reliability, plus it enables parallel download to be utilised!)

Additionaly my dewsign have a pin connected to the power supply feedback via a resistor so it actually do the tests at 4,6 and 5,4 V, then float the pin and runs at 5,0V.
Why have i never seen this simple quality assuring techology ever used by another designer? Or is there?

Click to expand...

It sounds like you are not familiar with modern flash microcontrollers, so have a read through the www.microchip.com technical documentation. You certainly can't compare then to flash SSD drives in terms of reliability.

Technical said:

It sounds like you are not familiar with modern flash microcontrollers, so have a read through the www.microchip.com technical documentation. You certainly can't compare then to flash SSD drives in terms of reliability.

Click to expand...

I absolutely agree.
Checksumming is what can be done. And cost nothing except development.

If not using highest clock frequency in application, it may be good to try tat too when checksumming.
Simlilarly external hardware, local communication in SPI, sensor response etc could be tested with stressing timing.

Margin checking by varying voltage can be done at a (small) cost and not only to check flash and EEprom, but also CPU operation, other hardware, and sensors.

And do not forget to check and use watchdog.

OK I will take my tin hat off now, but take it on again when designing machinery controls.

Morganl said:

And do not forget to check and use watchdog

Click to expand...

Thats a comment appropriate to Microcontrollers in general, and those using native PICs .

It will be confusing to users to suggest they use and check the watchdog in the context of PICAXE, as whilst the PICAXE firmware itself can use the PIC watchdog, its not accessible to a users program in a PIC like manner, maybe you did not realize that ?

Besides its 'good practice' to have an external and independent watchdog function on any application where the use is with 'possible dangersous machines'

I agree

I was talking about general methods, and not within constraints of PICAXE.

In a microcontroller course i think the teacher should describe good techniques even if the material at hand do not support everything. Not for the pupils to implement nor practice there and then, but to know that solutions are needed and exist, so they can get that knowledge when needed.

I have seen too many bad designs manufactured.