|
|
| Author |
Message |
Don_Kirby
Joined: 15 Oct 2006
Posts: 329
Location: Long Island, New York
|
|
Posted: 29 March 2008, 19:32 PM Post subject: Factory Programming Service |
 |
|
One project that I'm slowly working toward producing in small quantities does not expose the reset line in the final board layout, and I'm looking for a method to get my application into the device without it. The DTR-less download will work just fine after the first program download, but not for the first one as the ATN character is not yet set.
I'm assuming that the QFP devices ('44, '44a, '44n) are programmed at the factory using some sort of test fixture and then repackaged for delivery. If this is the case, is there the possibility to either also load a user application at the same time, or alternatively, enable the ATN character by default to allow me to load my application sans reset?
My current plan is to use a test fixture that fits the entire board. It works but it's clumsy.
-Don
|
|
| Back to top |
|
 |
dkinzer
Site Admin
Joined: 03 Sep 2005
Posts: 2499
Location: Portland, OR
|
|
Posted: 29 March 2008, 22:20 PM Post subject: Re: Factory Programming Service |
|
|
| Don_Kirby wrote: | | [I]s there the possibility to either also load a user application at the same time, or alternatively, enable the ATN character by default to allow me to load my application sans reset? |
It is not possible to load an application for the VM mode devices during manufacturing test because the application code resides in external EEPROM. It would be possible to set the ATN character, for either VMmode or native mode devices.
|
|
| Back to top |
|
|
mikep
Joined: 24 Sep 2005
Posts: 765
Location: Austin, TX
|
|
Posted: 30 March 2008, 0:01 AM Post subject: |
|
|
The DTR character is stored in the device EEPROM. Potentially you also have application specific "Persistent" data that is also stored in EEPROM. So I what I think you are really talking about is two things:
1. Programming the device EEPROM (ZBasic reserved area and application area).
2. Programming the separate EEPROM (before or after soldering into your circuit). If you used a PDIP device in a socket, then this is very easy as you can move the chip from a programming fixture to the circuit.
Note that programming the device EEPROM does not need any factory help or a reset line. Your application simply checks the a flag byte in EEPROM and stores data in EEPROM if false. One of the bytes stored overwrites the flag. This is similar to the way the FirstTime() flag is used except that you cannot rely on this particular flag for your application. If you use a version number for the flag then downloading new application code with a new version flag will allows your application to update the EEPROM because the version number is different.
There is no need to understand the content of the ZBasic reserved area, just simply read the data from a known system using GetPersistent and store it into program memory using a datafile or ByteVectorData.
|
|
| Back to top |
|
|
Don_Kirby
Joined: 15 Oct 2006
Posts: 329
Location: Long Island, New York
|
|
Posted: 30 March 2008, 7:18 AM Post subject: |
|
|
I would be using native mode devices, so the external EEPROM issue is moot.
I think setting the ATN character would be sufficient in either case although it makes sense to leave it disabled by default for most applications.
-Don
|
|
| Back to top |
|
|
dkinzer
Site Admin
Joined: 03 Sep 2005
Posts: 2499
Location: Portland, OR
|
|
Posted: 30 March 2008, 21:52 PM Post subject: |
|
|
| Don_Kirby wrote: | | I think setting the ATN character would be sufficient |
Your query got me thinking about a way to allow DTR-less downloading to factory fresh devices. As an experiment, I modified the "Hello, world" program to watch for a ctrl-D in the input queue. If it is seen, the program then enters the command mode using the undocumented procedure ZXCmdMode().
With this modified program running, I was able to download successfully without DTR. Also, with the program reloaded, I was able to set the ATN character using zload.exe. This change in the factory programming would allow end users to configure new devices with the desired ATN character and download the first program all without using the DTR line.
|
|
| Back to top |
|
|
mikep
Joined: 24 Sep 2005
Posts: 765
Location: Austin, TX
|
|
Posted: 31 March 2008, 2:31 AM Post subject: |
|
|
| dkinzer wrote: | | Your query got me thinking about a way to allow DTR-less downloading to factory fresh devices. As an experiment, I modified the "Hello, world" program to watch for a ctrl-D in the input queue. If it is seen, the program then enters the command mode using the undocumented procedure ZXCmdMode(). |
There are clearly several ways to accomplish the same thing using the ConsoleRead function. For example using a special input sequence e.g Ctrl-D, the hello world program could enter a DTR character setting routine that confirms the DTR character or allows you to cancel it.
Of course once the DTR char has been set (or not) and the first program downloaded, it is not possible to change it again unless you use a similar routine to set the character.
|
|
| Back to top |
|
|
Don_Kirby
Joined: 15 Oct 2006
Posts: 329
Location: Long Island, New York
|
|
Posted: 31 March 2008, 9:01 AM Post subject: |
|
|
| dkinzer wrote: | | ... I modified the "Hello, world" program to watch for a ctrl-D in the input queue. If it is seen, the program then enters the command mode using the undocumented procedure ZXCmdMode(). |
That sounds like a viable solution, as long as nothing else is inadvertently affected by the change.
| mikep wrote: | | Of course once the DTR char has been set (or not) and the first program downloaded, it is not possible to change it again unless you use a similar routine to set the character. |
I don't think this is an issue here. As a matter of course, my application sets it's own ATN character (or at least verifies the correct value) at every boot. The application could just as easily modify the value to something else. Unless, of course, I am misunderstanding your statement.
-Don
|
|
| Back to top |
|
|
dkinzer
Site Admin
Joined: 03 Sep 2005
Posts: 2499
Location: Portland, OR
|
|
Posted: 01 April 2008, 2:40 AM Post subject: |
|
|
| Don_Kirby wrote: | | [...] as long as nothing else is inadvertently affected by the change. |
Inasmuch as it is just the sample program (Hello, world) there is not much to be concerned about, I think.
|
|
| Back to top |
|
|
Don_Kirby
Joined: 15 Oct 2006
Posts: 329
Location: Long Island, New York
|
|
Posted: 02 April 2008, 1:05 AM Post subject: |
|
|
I agree, although I have long since learned to never make assumptions regarding the 'simple' things.
That said, are you planning on loading the new 'Hello World' application into the currently shipping devices? If so, are there any tricks or techniques required to implement the new feature?
-Don
|
|
| Back to top |
|
|
dkinzer
Site Admin
Joined: 03 Sep 2005
Posts: 2499
Location: Portland, OR
|
|
Posted: 02 April 2008, 2:56 AM Post subject: |
|
|
| Don_Kirby wrote: | | That said, are you planning on loading the new 'Hello World' application into the currently shipping devices? |
That is the plan. It will likely begin to be used by the first of next week. | Don_Kirby wrote: | | If so, are there any tricks or techniques required to implement the new feature? |
From the end user's perspective, nothing will have changed except that the ZX will respond properly to the DTR-less downloading protocol with the ATN character being &H04. Of course, this will only be the case for the first download unless the downloaded program also responds in the same manner to receiving &H04 or sets the value of the ATN character directly (Persistent memory address &H13). An updated zload.exe is needed if you want to use it to set the ATN character while using &H04 as the ATN character. The current version erroneously ignores the ATN character specification when writing configuratioin data.
|
|
| Back to top |
|
|
dlh
Joined: 15 Dec 2006
Posts: 266
Location: ~Cincinnati
|
|
Posted: 02 April 2008, 11:02 AM Post subject: |
|
|
| dkinzer wrote: | | Don_Kirby wrote: | | I think setting the ATN character would be sufficient |
Your query got me thinking about a way to allow DTR-less downloading to factory fresh devices. As an experiment, I modified the "Hello, world" program to watch for a ctrl-D in the input queue. If it is seen, the program then enters the command mode using the undocumented procedure ZXCmdMode(). |
Will you publish the code for the modified "Hello, world"?
|
|
| Back to top |
|
|
dkinzer
Site Admin
Joined: 03 Sep 2005
Posts: 2499
Location: Portland, OR
|
|
Posted: 02 April 2008, 16:27 PM Post subject: |
|
|
| dlh wrote: | | Will you publish the code for the modified "Hello, world"? |
The preliminary version is attached. Later, we'll also put it on the Downloads page.
This version can't be compiled with the current release version of the compiler due to the use of a new built-in constant 'Option.ExtRamAble'. Also, for native mode targets the current compiler doesn't handle the ZXCmdMode() call correctly.
| Description: |
|
Download |
| Filename: |
hello.zip |
| Filesize: |
609 Bytes |
| Downloaded: |
2501 Time(s) |
|
|
| Back to top |
|
|
dlh
Joined: 15 Dec 2006
Posts: 266
Location: ~Cincinnati
|
|
Posted: 02 April 2008, 18:28 PM Post subject: |
|
|
| The version that was attached does not call ZXCmdMode().
|
|
| Back to top |
|
|
dkinzer
Site Admin
Joined: 03 Sep 2005
Posts: 2499
Location: Portland, OR
|
|
Posted: 02 April 2008, 22:40 PM Post subject: |
|
|
Sorry, I attached the wrong .zip file.
| Description: |
|
Download |
| Filename: |
samp.zip |
| Filesize: |
1.19 KB |
| Downloaded: |
2520 Time(s) |
|
|
| Back to top |
|
|
dlh
Joined: 15 Dec 2006
Posts: 266
Location: ~Cincinnati
|
|
Posted: 03 April 2008, 18:52 PM Post subject: |
|
|
| Does ZxCmdMode() work with both VM and native devices?
|
|
| Back to top |
|
|
|
ZBasic Home
Forum Rules
Memberlist
Usergroups
RSS Feed
Site Search
Links
Download
Digests and Subscriptions
Profile
Log in to check your private messages
Log in
Register