Other than the formats of the data files that are their objects, the "QO" and "QB" commands are functionally the same. Here the "QO" command will be used as the main example, but the user should feel free to apply these same steps to the "QB" command. 

Interactive Programmer Implementation (PROG)

Figure 1 shows the old PROG setup (PROGACMP) for programming a single object file. The “SS” (specify object code) command was selected and shown in the “Object File:” text box. Subsequently, the “PM” (program module) and “VM” (verify module) commands would be called to program and verify the single file. This process had to be done each time depending on how many programming files the customer had.

Figure 1. Old PROG Implementation with “SS” Command

A single “QO” or "QB" command essentially works the same as an “SS” command, however we can call multiple “QO” or "QB" commands to "queue" files for the same programming operation. When multiple commands are called, each of the queued object files are later combined into a single data file that is then programmed once into the flash memory of the target device. An example of this implementation is shown in Figure 2 where all of the user's object files to be programmed at once are specified in the “Queued Program Data Command List”.

Note: A programming script may contain both "QO" and "QB" commands; these commands would be queued together in a single queue.

Figure 2. New PROG Implementation with multiple “QO” Commands

Command line Programmer Implementation (CPROG)

Much like PROG's interactive solution, our CPROG command-line software has also implemented the “QO” and "QB" commands to simplify programming scripts. This section provides a visual representation of the improved efficiency when using multiple “QO” commands with a single “PM,” versus the multiple “SS” commands with multiple “PM” commands that would have been required in the past.

Figure 3 shows an example of an older configuration script file that would be used to program a bootloader, application and option byte security file into a single target device.

Figure 3. Old CFG script for CPROG with “SS” Command

Notice in the above script the need to specify each object file followed by a separate “PM” and “VM” to program and verify each file. Figure 4 below shows the new approach using the "QO" command to improve efficiency and simplify configuration scripts going forward.

Figure 4. New CFG script for CPROG with “QO” commands

Clear Object Queue Command

The companion command for the new "QO" command is the “CQ” (Clear Queue) command. This command can be used at any time to delete all object files that have been specified by previous "QO" commands, and restart the process.

Some Additional Notes

In some scenarios, the “QO” and "QB" commands may not be able to handle programming one or more of the specific files that have been queued. Most often this occurs when attempting to program a file that is not supported in the specified “CM” programming algorithm. Some target devices have both Code Flash and Data Flash regions that wish to be programmed, however, most of our older algorithms do not account for both regions to be included into a single algorithm file. In this case, a single “CM,” “QO” or "QB," ”PM," and “VM” will have to be performed for each region that is not included in the algorithm file. This note should only pertain to certain situations and legacy algorithms, because newer algorithms should have all memory regions supported in one file.

Additionally, some commands such as “CS”, “PS”, “PB”, “PW”, and “SS” have been moved to the “Legacy Command” section within PROG (visible in Figure 2). This is to help with the transition from older software to our new commands. In the future all of these commands will be supported by our queuing data mechanism and will no longer be available to the customer. All legacy configuration scripts with these legacy commands will still work and are compatible with new PROG and CPROG software.

One last note in regard to data overlap detection between multiple object files - by default, PEmicro DOES NOT allow data overlap between object files as it could lead to memory corruption. If in some circumstances overlap is necessary, the only current solution is to use the :IGNOREOVERLAP option within a configuration script and set the parameter to “1”. PEmicro strongly recommends against using this feature if the user is not well-acquainted with what they are attempting.