BUG FIX needed for entering ascii into memory view

lpcware · ‎06-15-2016

Content originally posted in LPCWare by cwpjr on Mon Feb 18 14:07:11 MST 2013
Hi When I use a memory view (rendering set to ascii or traditional) to enter ascii some characters are replaced with sp (EX: 1rst character entered) and some other characters are never accepted (EX: "+" character).

This happens entering into the memory cells on the left or the . . . . . . . . on the right side of the rendering.

Also the endianess in the memory sectioin of all? renderings is opposite, which is confusing, especially when entering in . . . . section of the view.

Wish List Item: When entering ascii I need and 'escape' mechanisn to enter hex, as in typing in a count byte before the ascii string. :>)

I am stuck debugging my app until this works, or I'll have to wait for a few HW spins to supply my own solution.

Any fixes would be helpful.

Thanks, Clyde

lpcware · ‎06-15-2016

Content originally posted in LPCWare by cwpjr on Thu Feb 21 15:14:42 MST 2013

Quote: TheFallGuy
Thats irrelevant. You can call C functions from assembly language.

What if I don't use, or know C. And see no examples to learn from. Very helpful:confused:

lpcware · ‎06-15-2016

Content originally posted in LPCWare by MikeSimmonds on Thu Feb 21 04:17:49 MST 2013
[FONT=Tahoma][SIZE=1]Perhaps you skipped this while preparing the 5.1.2 release.
Do you have an answer about actual memory write size wrt cell size?

Regards, Mike

[/SIZE][/FONT]

Quote: MikeSimmonds
[FONT=Tahoma][SIZE=1]Sometimes it is important that a write to memory (especially when the memory
is for peripheral registers) use the correct size (byte, half, word).

Is it is valid to believe that the 'cell size' of a memory view will control this?
I.e. cell size 1 writes byte-wise, cell size 4 write word-wise etc.

Will the endian mode have any effect? I.e, if view is BE (and MPU is LE)
will the data be written swapped?

Also, when editing in a view with cell size 4, does the (word size?) write
happen after editing all 8 digits (rather than a byte at a time as changes are
entered)? What about changes to the ASCII section.
[I read your reply above.]

Regards, Mike
[/SIZE][/FONT]

[FONT=Tahoma][SIZE=1]

[/SIZE][/FONT]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Thu Feb 21 04:11:59 MST 2013
If you change the Cell size to 1 in the Traditional rendering, you can edit the memory in ASCII without any extra characters appearing.

To change the Cell size, right click in the view, and select Cell Size from the popup menu.

This will solve your problem.

BTW: thefallguy is correct - you can call C functions from assembler.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by TheFallGuy on Thu Feb 21 02:28:48 MST 2013

Quote: cwpjr
The Hex rendition view only allows hex entry, and exhibits the similar symptom, this time changing 0x2b ( + ) to 0x2c ( , ) and one cannot enter ascii FROM THE KEYBOARD there. At least the array of memory is rendered in correct endian-ness. :cool:

I don't think that is what they were suggesting. My reading of the suggestion was to use the Traditional view and enter in Hex (left side of screen)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by TheFallGuy on Thu Feb 21 02:27:26 MST 2013

Quote: cwpjr
Assembly language project. :o

Thats irrelevant. You can call C functions from assembly language.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by cwpjr on Wed Feb 20 16:21:37 MST 2013

Quote: CodeRedSupport
There is an issue here.

In the Traditional view, non-displayable characters are displayed as ".". If you Edit in the ASCII section, any non-displayable characters within the WORD that you are editing are replaced with 2E (ascii for "."). If you edit the HEX section, it works correctly.

Workaround:
Either edit in Hex, or Edit in ASCII and make sure you replace the characters replaced with "."

The Hex rendition view only allows hex entry, and exhibits the similar symptom, this time changing 0x2b ( + ) to 0x2c ( , ) and one cannot enter ascii FROM THE KEYBOARD there. At least the array of memory is rendered in correct endian-ness. :cool:

The Traditional and ACII views still suffer from disallowing + and displaying "sp . . ." no matter what is entered in the position represented as sp.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by cwpjr on Wed Feb 20 16:06:09 MST 2013

Quote: TheFallGuy
Is there any reason why you can't just use semihosting to read from the console? A simple scanf would allow you to enter a line of characters and parse it.

Assembly language project. :o

lpcware · ‎06-15-2016

Content originally posted in LPCWare by TheFallGuy on Wed Feb 20 00:37:58 MST 2013
Is there any reason why you can't just use semihosting to read from the console? A simple scanf would allow you to enter a line of characters and parse it.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by cwpjr on Tue Feb 19 16:28:52 MST 2013
Thanks for acknowledging and exploring this issue you guys. In the end I agree that the point of an IDE is to simplify and streamline the process of writing and debugging code.

In my case I am writing and testing small interpreter monitors in assembly language. The gdb solution given is less suitable to my needs, simply because my need to enter ascii, either as counted string or null terminated ones does not come a startup and consists of a variable amounts of commands to debug and and/or data to pass/place in memory variables during testing.

My development plans include this type of add hoc iterative input and test in the IDE tool because I want to wait before I write and debug the many varieties of I/O (serial/USB/ether/file, etc) that would feed the interpretive monitors once they are working well enough.

Perhaps a right hand pane smart-ish mini editor would be useful to the largest audience, if it encompasses the ideas and needs expressed so far in the forum.

Don't know if this is feasible - incorporate semi-hosting I/O that could be used in assembly projects as part of the front end of the mini editor... smile.

I guess that's my new wish list(s) . Along with a a smartish variation for peripheral registers. Man that would be something!

In the mean time a few fixes to make the current capabilities consistent and robust in use would be great! :)

Thanks in Advance! Clyde

lpcware · ‎06-15-2016

Content originally posted in LPCWare by MikeSimmonds on Tue Feb 19 13:19:38 MST 2013
[FONT=Tahoma][SIZE=1]

Quote: TheFallGuy
You can use GDB functions to do a lot of these things. To fill:

create a file called ".gdbinit" in the root of your project

[/SIZE][/FONT]

Quote: TheFallGuy
[FONT=Tahoma][SIZE=1]
Add these commands:

define fill
 set $base = $arg0
 set $len = $arg1
 set $value = $arg2
 set $i = 0
 while ($i < $len)
  set *(int *)($i + $base) =$value
  set $i = $i + 1
 end
end

When the debugger starts, it will load the .gdbinit file and (this one) defines a function called "fill" that takes parameters of base, length and value

in the gdb console, type [/SIZE][/FONT] [FONT=Tahoma][SIZE=1]

fill 0x10000000 0x10 0xa5

Look in the Help for more information on GDB commands - it is a VERY powerful debugger...[/SIZE][/FONT]

[FONT=Tahoma][SIZE=1]

Thanks for the info. I really must take off a day to readup on the gdb. Time, time, time; where does it go?
Having said that, the point of (this) IDE is to shield users from raw gdb and add to work flow productivity
by making things easier to do.
So it would be nice to have in the IDE all the same.

Mike

[/SIZE][/FONT]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by TheFallGuy on Tue Feb 19 10:41:33 MST 2013
You can use GDB functions to do a lot of these things. To fill:

create a file called ".gdbinit" in the root of your project
Add these commands:

define fill
 set $base = $arg0
 set $len = $arg1
 set $value = $arg2
 set $i = 0
 while ($i < $len)
  set *(int *)($i + $base) =$value
  set $i = $i + 1
 end
end

When the debugger starts, it will load the .gdbinit file and (this one) defines a function called "fill" that takes parameters of base, length and value

in the gdb console, type

fill 0x10000000 0x10 0xa5

Look in the Help for more information on GDB commands - it is a VERY powerful debugger...

lpcware · ‎06-15-2016

Content originally posted in LPCWare by MikeSimmonds on Tue Feb 19 09:57:58 MST 2013
[FONT=Microsoft Sans Serif][SIZE=2]Sometimes it is important that a write to memory (especially when the memory
is for peripheral registers) use the correct size (byte, half, word).

Is it is valid to believe that the 'cell size' of a memory view will control this?
I.e. cell size 1 writes byte-wise, cell size 4 write word-wise etc.

Will the endian mode have any effect? I.e, if view is BE (and MPU is LE)
will the data be written swapped?

Also, when editing in a view with cell size 4, does the (word size?) write
happen after editing all 8 digits (rather than a byte at a time as changes are
entered)? What about changes to the ASCII section.
[I read your reply above.]

Bonus Feature Wish List.:D

A command to Fill: start, count, value, [size (byte/half/word)] (or value list)
I know we can 'import', but preparing the import file for specific cases
would be a pain. [Haven't actually used this; I might be fuzzy on details.]
Or is there a 'gdb console' cmd for this? But still more convenient in the IDE.

A command to Jump to an address (offset?) within a view rather than having
to open a new view.
I.e. with a View of A0000000 (external SDRAM) and a size of 64 MB, it would
take slightly less than forever to 'page' or 'mouse wheel' down to near the end.
Even with the 64 KB internal SRAM, paging is tedious.

And how much time would the SWD comms take showing the intermediate
pages that are (currently) of no interrest.

Regards, Mike

[/SIZE][/FONT]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Tue Feb 19 03:02:20 MST 2013
There is an issue here.

In the Traditional view, non-displayable characters are displayed as ".". If you Edit in the ASCII section, any non-displayable characters within the WORD that you are editing are replaced with 2E (ascii for "."). If you edit the HEX section, it works correctly.

Workaround:
Either edit in Hex, or Edit in ASCII and make sure you replace the characters replaced with "."