Serial Port Memory Data Dump

Go To Last Post
23 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Greetings,

 

I have an application which gathers multiple-byte sized pieces of data and stores them in external RAM sequentially.

 

I am trying to develop a little piece of code that will essentially stream all the gathered data from external memory to a PC serial port, so that the data can be processed by a PC.

 

The problem I am having is that I can't find a way to get the PC to discern between the pieces of data with no real delimiters between them, so I may need to code a way to convert my 'external memory data' to data that a PC can interpret and separate the values.

 

Here is what I'm working with for the data dump.

 

TRANSMIT_XMEM:
		;TRANSMIT XRAM
		LDI COUNTER_HIGH,0xDD    ;Load count 0x200 to clear
		LDI COUNTER_LOW,0xFF    ;memory from 0x00 to 0x1FF
		CLR A         ;clear temp
		LDI ZH,0x22      ;Load starting address of
		LDI ZL,0x00      ;RAM 0x2200 in Z pointer
	SENDRAM:
		LD A,Z+       ;Store 0 in current Z location
		RCALL TRANSMIT
		SBIW COUNTER_HIGH:COUNTER_LOW,1 ;Decrement the counter
		BRNE SENDRAM      ;end if zero
		RET
		

I was thinking that I may need to convert each byte to it's two-byte ascii representation, so that I can use the ascii 'comma' for a delimiter.  

 

Thanks in advance.

 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes if you want to stream directly to a human readable file on the PC you definitly need to convert it on the sender side to ASCII

Otherwise you have to write a program on the PC side to read the data and decode it, AND you have to create a format that describes the data you're sending. You can't just mem dump it and expect to get any usefull information on the other side.

Well unless all your data is the exact same type. All chars, all ints etc

 

Sending binary data is faster but then you have 2 programs to maintain

 

I usually convert on the sending side, it always nice to be able to read whats being spit out the serial port

Keith Vasilakes

Firmware engineer

Minnesota

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, keith v.

 

Do you know of any example code I can use to reference?

 

I'm not exactly sure how to set this up.  Do I use a .dw (define word) for every possible hex value, and then send the appropriate words based on my hex data?  That seems like it would be too code intensive for what I'm doing.

 

Any shortcuts?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sounds like you want to do a binary file transfer.
There's a number of methods - chosing a popular one meabs there are tools on the pc to manage it.
Intel hex is simple. Utilities like bin2hex and hex2bin
Xmodem - your terminal program
probably supports it.
Slip protocol
Modbus
The above protocols utilise the 'usual' methods.
Intel hex and modbus ascii use ascii hex representation
Xmodem and modbus rtu frame by times
Slip escapes magic characters
Wikipedia has a good rundown.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think i got it now.  Using this little snippet...

 

 ;-----------------------------------------------
                                    ; HEX TO ASCII
                                    ;-----------------------------------------------
                                    ;I think, this was the smallest (only 10 words). 
                                    
                                    ;input: R16 = 8 bit value 0 ... 255 
                                    ;output: R18, R17, R16 = digits 
                                    ;bytes: 20 
                                    ; 
                                    bcd: 
                                    ldi r18, -1 + '0' 
                                    _bcd1: 
                                    inc r18 
                                    subi r16, 100 
                                    brcc _bcd1 
                                    ldi r17, 10 + '0' 
                                    _bcd2: 
                                    dec r17 
                                    subi r16, -10 
                                    brcs _bcd2 
                                    sbci r16, -'0' 
                                    ret  

Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looks like decimal to ascii to me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It converts a byte to the three byte decimal value in accordance with the ascii table.  (ie. 0x67 gets converted to 0x31, 0x30, 0x33, which is '1', '0', '3')

 

This works for me, because now I can have the PC end discern between a byte of data and a byte used as a delimiter. 

 

 

Which is good enough for me.  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The title on the code says hex to ascii, but there's no hex involved - it converts the value to decimal.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, what I meant was...

 

If I put 0x67 in R16 and call that routine...

 

R18 = 0x31

R17 = 0x30

R16 = 0x33

 

Which is ascii encoded decimal, correct.  

Pretty slick how that guy got it done in so few lines of code.  

Saw an 8051 snippet that was even smaller, because it employs the 'DA' (Decimal Adjust) instruction......

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's two common techniques - this one is the repeated subtract the other is a divide and bcd correct.
The repeated subtract starts taking too long for say a 32 bit number so the shift and correct method would probably be used in that instance. Welcome to the joys of asm.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Kartman wrote:

There's two common techniques - this one is the repeated subtract the other is a divide and bcd correct.
The repeated subtract starts taking too long for say a 32 bit number so the shift and correct method would probably be used in that instance. Welcome to the joys of asm.

 

Yea, I'm leaning towards C, but I've been banging my head against the wall with asm for a while now, and I'm starting to build up a nice callus. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you pick the right assembler you could easily mix Asm and C. The avr-as assembler that is part of GNU binutils (itself bundled with avr-gcc) has different directives to Atmel's own Assembler2 but on the whole the mnemonics are very close. This way you could simply call a C library function such as itoa() or even sprintf() directly from your Asm code.

 

Of course if you were going to do that you might as well write the "core" in C too as it's quicker, more productive and more portable than Asm.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use printf actually.

I like to get stuff done rather than save 3 bytes

Keith Vasilakes

Firmware engineer

Minnesota

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe using packets is easier

I would do it like this:

1. byte = ID                       example      0x55

2.byte = number of data bytes follows: 0x03

3. byte= 1. data byte                           0x31

4. byte= 2. data byte                           0x32

5. byte= 3.data byte                            0x33

6. byte= EOF                    example      0xAA

 

At PC:

1. wait for 0x55

2. get number of bytes

3. read number of bytes into buffer

4. read byte and verrify 0xAA as end of transmission

5. send ACK as handshake

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hard to read that without a custom program running on the receive side tho

Keith Vasilakes

Firmware engineer

Minnesota

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

heweb wrote:

Maybe using packets is easier

I would do it like this:

1. byte = ID                       example      0x55

2.byte = number of data bytes follows: 0x03

3. byte= 1. data byte                           0x31

4. byte= 2. data byte                           0x32

5. byte= 3.data byte                            0x33

6. byte= EOF                    example      0xAA

 

At PC:

1. wait for 0x55

2. get number of bytes

3. read number of bytes into buffer

4. read byte and verrify 0xAA as end of transmission

5. send ACK as handshake

 

 

 

 

That is a pretty slick method..., but I'm good with running it through the ascii-decimal converter, and just adding a 0x2C (ascii 'comma') after each 3 byte transmission.  Then let the PC pick the data between the commas.  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jshwaa wrote:

 

heweb wrote:

 

Maybe using packets is easier

I would do it like this:

1. byte = ID                       example      0x55

2.byte = number of data bytes follows: 0x03

3. byte= 1. data byte                           0x31

4. byte= 2. data byte                           0x32

5. byte= 3.data byte                            0x33

6. byte= EOF                    example      0xAA

 

At PC:

1. wait for 0x55

2. get number of bytes

3. read number of bytes into buffer

4. read byte and verrify 0xAA as end of transmission

5. send ACK as handshake

 

 

 

 

 

 

That is a pretty slick method..., but I'm good with running it through the ascii-decimal converter, and just adding a 0x2C (ascii 'comma') after each 3 byte transmission.  Then let the PC pick the data between the commas.  

 

It's called SLIP, Serial Line Interface Protocol

There is also HLDC High Level Data Control

 

If you want a binary protocol

Keith Vasilakes

Firmware engineer

Minnesota

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
It's called SLIP, Serial Line Interface Protocol
SLIP stands for Serial Line Internet Protocol:

http://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol

The Serial Line Internet Protocol (also SLIP) is an encapsulation of the Internet Protocol designed to work over serial ports and modem connections. It is documented in RFC 1055. On personal computers, SLIP has been largely replaced by the Point-to-Point Protocol (PPP), which is better engineered, has more features and does not require its IP address configuration to be set before it is established. On microcontrollers, however, SLIP is still the preferred way of encapsulating IP packets due to its very small overhead.

I'm pretty sure this isn't applicable in the OP's case, although it could certainly be pressed into service in a non-IP setting.

 

But perhaps there is another protocol also named SLIP of which I am not aware.

 

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you Mr Pedantic.

 

My point is he is defining SLIP, he should be aware of it

Keith Vasilakes

Firmware engineer

Minnesota

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

keith v wrote:
My point is he is defining SLIP, he should be aware of it
OK, I'll bite.  Where is he doing that?

 

Kartman mentions Slip in post #4.  Where does the OP do so?  Where does the OP do anything resembling SLIP?  Or any of the encapsulation field hex values?

 

I bring it up only because I really don't believe what the OP was proposing in post #16 can be called SLIP.  While he is developing his own encapsulation protocol, it resembles SLIP only in broad brush strokes.  These broad strokes were already addressed by Kartman in the same post mentioned above.  I see no advantage in allowing confusion over an acronym to persist.

 

If 'precision' is 'pedantic', I'll accept your judgement ;)

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Feel better now?

Keith Vasilakes

Firmware engineer

Minnesota

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

keith v wrote:
Thank you Mr Pedantic.
keith v wrote:
Feel better now?
Do you? ;)

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cheers, guys.  Thanks to both of you.

 

That's one thing I definitely love about this site.  Freaks offer no shortage of details.  I always walk away with more than I asked for.  Good stuff...