Identifying stamp by code

SamM

I'm trying to identify a basic stamp via the serial port using the IdentifySequence. Using vb.net, my code consists of the following:

'Identify Sequence:
Dim MyPort As SerialPort = New SerialPort("COM1", 9600, Parity.None, 8, StopBits.One)
MyPort.Open()

'ResetSequence is performed by hidden code at this point.

MyPort.Write("B") 'Tramsnits a capital B (ASCII 66)
Console.WriteLine("Echo Returned: " & MyPort.ReadByte) 'Receives the echo byte of "B"
Console.WriteLine("Next Byte Returned: " & MyPort.ReadByte) 'Should be ASCII 190 (2's complement of "B")

The code executes properly and returns the echo of the transmitted "B" correctly, but then hangs on the second .ReadByte as though the Stamp never transmits another character and waits forever for another byte that it never receives--which should be the ASCII 190 (I'm using a BS2)

Am I missing something in the transmission/receiving protocol?

Unsoundcode

Hi Sam, I tested the identify sequence with the snippet I have attached. In the code the output was directed to a richtextbox control for proofing.

I asked for help on a previous post·, the post contains a link from Tracy Allen which contains some very useful information be sure to check it out this is the link.

http://forums.parallax.com/showthread.php?p=651172

Jeff T

SamM

Hmmm....

Your code looks functionally identical to mine: A single write followed by two ReadBytes. Mine however, still hangs at the second ReadByte and never seems to receive the byte after the echo byte.

I've seen Tracy's link--it is very informative, but I haven't seen anything different from what I (and your example) have done.

I've tested my reset sequence and it *does* perform the reset (the code in the stamp starts again properly immediately thereafter).

Any other thoughts what might prevent the return byte from being sent (or received)?

Unsoundcode

Hi Sam, the particular program I took that code extract from only has two subroutines called by a button_click , the first sub called is Reset then the next is ID, the snippet contained the whole listing of the sub ID. After ID has run the richtextbox contains this text :- B 190 S 173 2 206 0 16.

I can't really say any more without seeing the rest of your listing.

Jeff T.

SamM

Jeff--I've attached a simplified sample of my reset & identify code for you to peruse. Hoping I'm overlooking something really simple here.....

Unsoundcode

Hi Sam, if I remember correctly that is the route I took at first but made a couple of subtle changes to get it to work. Try this for the reset

dtr=true

sleep(2)

dtr=false

break=true

sleep(48)

break=false

sleep(5)

readexisting

gosub ID

the timing and order is fairly critical, let me know your progress after you have tried this. In case you wanted to see what the output should be I have attached the test sample I used.

Jeff T.

SamM

Jeff,
I played with the order of the commands, and it appears that your changes (which are different from the documentation provided by parallax) make the difference. You mentioned that you had made a "couple subtle changes". It appears that those make all the difference.

Parallax docs indicate the overlapping of the flags/waveforms, and this *does not appear to work*. I'm guessing that this is an error in the documentation provided with the tokenizer api. The corrected code pulses the DTR line, *then* pulses the break state.

I appreciate the help!

Chris Savage

Sam,

It’s not that there’s an error…On USB-based systems things work better if the break is initiated just before the DTR pulse, as I recall. But the way things are documented should be working at least on serial systems. Take care.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support

SamM

Chris,
I'm using straight serial on my test system. I haven't attempted to test a USB system yet. I used the documented version and it failed. Leave it to me to be outside the norm [noparse];)[/noparse]

I'll suggest that this information be added (about USB vs. serial) to the tokenizer documentation to avoid these problems.

Chris Savage

Sam,

I wasn’t suggesting the USB wouldn’t work…However there is an issue with latency on some USB systems which causes problems with identification and programming. Usually we have the customer reduce the latency setting. This is more prevalent on laptops. By the way…I programmed a BASIC Stamp 2p24 to ID any BASIC Stamp connected to it using solely the Tokenizer documentation. It worked fine. The BS2p24 was connected to the destination BASIC Stamp programming pins and power. Take care.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support

Unsoundcode

Hi Sam, pleased it worked out. From what you and Chris say I am sure it is system dependant which is worth bearing in mind if it should fail on another system.

Are you moving on to the Tokenizer library or using·reset/ID·for some other purpose. If you do use the library I would be interested in your progress, last time I messed with it I was having difficulty .

Jeff T.

SamM

Correct, I am moving on to the tokenizer code. I can see why you would have problems--from a managed code standpoint the library is very difficult to translate. Lots of P/Invoke and pointers for arrays, which are always fun to translate into managed code. Should be interesting, to be sure.