Current AVR code/data seeking disassembler(s)?

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

I'm after an AVR disassembler that produces "intelligent" AVRASM2 compatible code (ie. that can be assembled by AVRASM2).

 

Years ago I wrote an assembler, and then a disassembler for the (Motorola) 68HC11 (or just the HC11). A processor that, at the time, was used by many automobile manufacturers in their ECUs. My aim at the time was to understand how their ECU code worked. This pretty much required that the disassembler would go through the source binary (or .hex or .s19) file and produce target labels for data access and branch operations (load/store, gotos, calls, etc.) so that, after the disassembly process, you had a kind of source with unique labels in all the places they would be in an assembler source file. The disassembler also had an (optional) input file that amounted to a set of equates that could give target labels actual symbolic names, and even comments to source code addresses in the re-disassembled output. So, through an iterative process (disassemble, assign symbolic label names, repeat) it wasn't too difficult to build up a disassembled source file that was getting to the stage of a source that could be modified and then re-assembled to something that could be used in an ECU with additional/modified features. Sure, there was some "hacking" involved ;-) but in the cause of education rather than ripping anyone off.

 

I now find myself in the situation of wanting to disassemble my own AVR code I wrote 20 years ago - yes, I have the sources for these binaries, but it's not in the language (assembler) I'd like to now use to make modifications to. I'm at the stage of having modified my HC11 assembler so it's now an AVR assembler written in C (basically I rewrote the fairly basic opcode-encoder part - which is only a small fraction of an assembler). But I figure if there's an intelligent AVR disassembler that works reliably then I don't actually have to rewrite my HC11 disassembler for the AVR - saving me a week, or so, of recoding.

 

So, any suggestions for an AVR disassembler that produces an output with "intelligent" labels representing data and program-flow targets? My apologies if this topic seems to have been covered before, but I'm NOT looking for a beginners disassembly tool (which AVRStudio can be used for!) but something a little more sophisticated. I'm not interested in hacking anyone's code (because any useful code would probably locked away with the AVR's fuse technology anyway) but something that would save me some time in my own code development.

 

(BTW, I wrote my HC11 assembler and disassembler in Borland C for Dos back in 1999, I have recently modified and recompiled the HC11 assembler it so it works for Win32/64 (strangely, not a trivial task!) - and when I do all the changes for standard C to the HC11 disassembler too, I'll make available both these HC11 tools so they work in a Win environment).

 

AVR developer

Last Edited: Thu. Mar 5, 2020 - 03:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

techedge wrote:
I now find myself in the situation of wanting to disassemble my own AVR code I wrote 20 years ago - yes, I have the sources for these binaries, but it's not in the language (assembler) I'd like to now use to make modifications to.

I'm confused.  If you have the original source with presumably appropriate labels and comments, wouldn't it be simpler to translate that into the assembly flavor of your liking?

Letting the smoke out since 1978

 

 

 

 

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

This might have some features you can use...looks like you can label loops and branches & define functions

 

https://onlinedisassembler.com/static/home/#

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

a disassembler for the (Motorola) HC11. A processor that, at the time, was used by many automobile manufacturers in their ECUs.

And about 20,000 pedestrian crossing noise producing boards. wink

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Digital Dan - Yes, I do have the original source used to create the binaries that I now wish to turn into assembler.

 

   " wouldn't it be simpler to translate that into the assembly flavor of your liking? "

 

Not really, although It's a marginal thing. But sometimes it's simpler to just say what I need rather than explain why in exquisite detail because at the end of the day there is a fair amount of personal preference involved and everyone has their own idea of what is good/bad.

 

But, to advance my cause, I'll supply some more detail:

 

I have a lot of sources written in a "high-level assembler" syntax. By high-level I mean I have been using someone else's software tool (compiler/assembler/converter/etc.) that has the equivalent of structured if/then/else statements mixed in with basic assembler. So I call it high-level assembler because your source CAN BE coded without any explicit program flow-control opcodes (rcall, call, rjmp, jmp, sbrs, sbrc, etc.), but rather it reads as a series of function definitions and function invocations mixed in with actual assembler statements to do the basic operations.

 

My problem is that I'd like to use a different syntax to the one my tool has defined. Why? Because the existing source syntax is just one step up from using assembler macros and the underlying syntax is not based on a AVRASM syntax, so there's a serious learning curve involved in using this tool to actually create the requisite high level constructs in order to modify my existing code (for new projects, etc.). The existing tool is also very unforgiving in its syntax, and gives almost zero feedback when there are simple data entry errors. So, basically I'm saying I want to create a new tool from scratch to replace BOTH the existing tool and the existing rigid syntax and have syntax checking that gives real feedback. That tool will be based my AVRASM2-like assembler that I'm just getting to the stage of 100% compatibility with AVRASM2. When it's working well enough I'll add the high level constructs I want into the actual assembler (not at the macro level - although my assembler also has macro capability). As an aside, my tool is called AVRHA for "AVR High-level Assembler" - it's currently a work in progress.

 

Very early in my re-development phase I ruled out reverting to AVRASM2 and adding a host of macros to create my "high-level" constructs, simply because AVRASM2 doesn't have the necessary hooks to do things efficiently and with the requisite syntax checking I'm after.

 

Although I have access to the existing tool's source, I actually believe it will take me longer to add the necessary changes to it than it will be to modify my HC11 assembler to work with AVR and to then add the high level constructs required.

 

I can write another very simple tool to convert my existing tool's source format into my new AVRHA format.

 

The advantage to me is that I'm not perpetuating a very poor syntax into the future, and I'm also creating a tool that others may find a little more friendly than assembler and a little closer to the machine's opcodes than something like C whose whole ethos is about hiding the underlying machine architecture!
 

So, I'm not asking anyone to judge the sanity of my mission, but to respect that there are different ways and tools to do things!

.

AVR developer

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

Thanks for the link AVRCandies - I'll have to check it out, but, being cloud based, I'm not too keen on exposing any of the binaries I'd be disassembling ;-).

AVR developer

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

I can tell you how to easily disassemble to avr-as source but not avrasm2 source. I guess you could do this as a first step then manually fix it up for the differences between avr-as and avrasm2 ?

techedge wrote:
produces "intelligent" AVRASM2
"intelligent" is never going to happen. All the disassembler has to go on are some 0's and 1's - it's very difficult (impossible?) to make much sense out of that. All it can do is generate raw source. I suppose when there are calls and branches there are some ways of handling that which are more "intelligent" than others. An "RJMP L3F2C" is probably more intelligent then "RJMP . + 119" ? But that's about as intelligent as it's going to ever get. It's very unlikely a disasm could make an "RJMP delay_loop_2" out of that !

 

EDIT: OK so here's an example of disassembling a .hex file using avr-objdump:

D:\test\test\Debug>avr-objdump -m avr:5 -j .sec1 -d test.hex

test.hex:     file format ihex


Disassembly of section .sec1:

00000000 <.sec1>:
   0:   6c c0           rjmp    .+216           ;  0xda
   2:   00 00           nop
   4:   72 c0           rjmp    .+228           ;  0xea
   6:   00 00           nop
   8:   70 c0           rjmp    .+224           ;  0xea
   a:   00 00           nop
   c:   6e c0           rjmp    .+220           ;  0xea
   e:   00 00           nop
  10:   6c c0           rjmp    .+216           ;  0xea
  12:   00 00           nop
  14:   6a c0           rjmp    .+212           ;  0xea
  16:   00 00           nop
  18:   68 c0           rjmp    .+208           ;  0xea
  1a:   00 00           nop
  1c:   66 c0           rjmp    .+204           ;  0xea
  1e:   00 00           nop
  20:   64 c0           rjmp    .+200           ;  0xea
  22:   00 00           nop
  24:   62 c0           rjmp    .+196           ;  0xea
  26:   00 00           nop
  28:   60 c0           rjmp    .+192           ;  0xea
  2a:   00 00           nop
  2c:   5e c0           rjmp    .+188           ;  0xea
  2e:   00 00           nop
  30:   5c c0           rjmp    .+184           ;  0xea
  32:   00 00           nop
  34:   5a c0           rjmp    .+180           ;  0xea
  36:   00 00           nop
  38:   58 c0           rjmp    .+176           ;  0xea
  3a:   00 00           nop
  3c:   56 c0           rjmp    .+172           ;  0xea
  3e:   00 00           nop
  40:   54 c0           rjmp    .+168           ;  0xea
  42:   00 00           nop
  44:   52 c0           rjmp    .+164           ;  0xea
  46:   00 00           nop
  48:   50 c0           rjmp    .+160           ;  0xea
  4a:   00 00           nop
  4c:   4e c0           rjmp    .+156           ;  0xea
  4e:   00 00           nop
  50:   4c c0           rjmp    .+152           ;  0xea
  52:   00 00           nop
  54:   4a c0           rjmp    .+148           ;  0xea
  56:   00 00           nop
  58:   48 c0           rjmp    .+144           ;  0xea
  5a:   00 00           nop
  5c:   46 c0           rjmp    .+140           ;  0xea
  5e:   00 00           nop
  60:   44 c0           rjmp    .+136           ;  0xea
  62:   00 00           nop
  64:   42 c0           rjmp    .+132           ;  0xea
  66:   00 00           nop
  68:   52 4f           sbci    r21, 0xF2       ; 242
  6a:   4c 45           sbci    r20, 0x5C       ; 92
  6c:   30 00           .word   0x0030  ; ????
  6e:   41 44           sbci    r20, 0x41       ; 65
  70:   44 52           subi    r20, 0x24       ; 36
  72:   3f 00           .word   0x003f  ; ????
  74:   55 55           subi    r21, 0x55       ; 85
  76:   49 44           sbci    r20, 0x49       ; 73
  78:   3f 00           .word   0x003f  ; ????
  7a:   56 45           sbci    r21, 0x56       ; 86
  7c:   52 53           subi    r21, 0x32       ; 50
  7e:   3f 00           .word   0x003f  ; ????
  80:   54 59           subi    r21, 0x94       ; 148
  82:   50 45           sbci    r21, 0x50       ; 80
  84:   30 00           .word   0x0030  ; ????
  86:   50 57           subi    r21, 0x70       ; 112
  88:   52 4d           sbci    r21, 0xD2       ; 210
  8a:   30 00           .word   0x0030  ; ????
  8c:   41 44           sbci    r20, 0x41       ; 65
  8e:   56 49           sbci    r21, 0x96       ; 150
  90:   35 00           .word   0x0035  ; ????
  92:   50 4f           sbci    r21, 0xF0       ; 240
  94:   57 45           sbci    r21, 0x57       ; 87
  96:   33 00           .word   0x0033  ; ????
  98:   49 4d           sbci    r20, 0xD9       ; 217
  9a:   4d 45           sbci    r20, 0x5D       ; 93
  9c:   30 00           .word   0x0030  ; ????
  9e:   4d 4f           sbci    r20, 0xFD       ; 253
  a0:   44 45           sbci    r20, 0x54       ; 84
  a2:   30 00           .word   0x0030  ; ????
  a4:   4e 4f           sbci    r20, 0xFE       ; 254
  a6:   54 49           sbci    r21, 0x94       ; 148
  a8:   31 00           .word   0x0031  ; ????
  aa:   52 45           sbci    r21, 0x52       ; 82
  ac:   53 45           sbci    r21, 0x53       ; 83
  ae:   54 00           .word   0x0054  ; ????
  b0:   2b 57           subi    r18, 0x7B       ; 123
  b2:   41 4b           sbci    r20, 0xB1       ; 177
  b4:   45 00           .word   0x0045  ; ????
  b6:   4e 41           sbci    r20, 0x1E       ; 30
  b8:   4d 45           sbci    r20, 0x5D       ; 93
  ba:   00 00           nop
  bc:   4e 41           sbci    r20, 0x1E       ; 30
  be:   4d 45           sbci    r20, 0x5D       ; 93
  c0:   3f 00           .word   0x003f  ; ????
  c2:   2b 53           subi    r18, 0x3B       ; 59
  c4:   65 74           andi    r22, 0x45       ; 69
  c6:   3a 00           .word   0x003a  ; ????
  c8:   41 54           subi    r20, 0x41       ; 65
  ca:   0d 0a           sbc     r0, r29
  cc:   00 00           nop
  ce:   2b 43           sbci    r18, 0x3B       ; 59
  d0:   4f 4e           sbci    r20, 0xEF       ; 239
  d2:   4e 00           .word   0x004e  ; ????
  d4:   2b 4c           sbci    r18, 0xCB       ; 203
  d6:   4f 53           subi    r20, 0x3F       ; 63
  d8:   54 00           .word   0x0054  ; ????
  da:   11 24           eor     r1, r1
  dc:   1f be           out     0x3f, r1        ; 63
  de:   cf ef           ldi     r28, 0xFF       ; 255
  e0:   d8 e0           ldi     r29, 0x08       ; 8
  e2:   de bf           out     0x3e, r29       ; 62
  e4:   cd bf           out     0x3d, r28       ; 61
  e6:   02 d0           rcall   .+4             ;  0xec
  e8:   04 c0           rjmp    .+8             ;  0xf2
  ea:   8a cf           rjmp    .-236           ;  0x0
  ec:   80 e0           ldi     r24, 0x00       ; 0
  ee:   90 e0           ldi     r25, 0x00       ; 0
  f0:   08 95           ret
  f2:   f8 94           cli
  f4:   ff cf           rjmp    .-2             ;  0xf4

In the command "avr-objdump -m avr:5 -j .sec1 -d test.hex " the -m tells the disassembler what the target type is. The supported types are:

 

avr-objdump: supported architectures: avr avr:1 avr:2 avr:25 avr:3 avr:31 avr:35 avr:4 avr:5 avr:51 avr:6 avr:100 avr:101 avr:102 avr:103 avr:104 avr:105 avr:106 avr:107 plugin

I happen to know that the mega328 this code had been built for is a AVR Architecture 5 model. You have to use "-j .sec1" because a .hex file (unlike ELF etc) does not really have the concept of "file sections" so it simply assigns the contents of the entire thing to a default ".sec1". The -d is the command to disassemble.

 

objdump has pretty intelligent input recognition so it will recognize the input as Intel Hex without needing to be told.

 

Now it just so happens that the code above was actually:

const __flash char configCommands[19][6]    =    {
	"ROLE0","ADDR?","UUID?","VERS?","TYPE0",
	"PWRM0","ADVI5","POWE3","IMME0","MODE0",
	"NOTI1","RESET","+WAKE","NAME","NAME?",
	"+Set:","AT\r\n","+CONN","+LOST"
};

int main(void)
{
	
}

when it started life - so almost all flash data and not a lot of actual code. So in the disasm it's actually tried to decode everything between 68: .. d8: when it's really all just ASCII data. I don't think there's any easy way to tell the disassembler "that bit is data - dump it as .byte" or whatever.

Last Edited: Thu. Mar 5, 2020 - 10:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

IDA PRO is pretty good although I've not tried it on AVRs. It spots code that is unreachable and then marks those areas as data, changing what assumptions it makes about references to those areas. When run interactively it allows you to change labels as you recognise blocks of code and updates labels accordingly. It also knows about things like ISRs and deals with labelling those appropriately.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Hi CLawson, thanks for your reply.

 

An intelligent disassembler doesn't just simply disassemble all the binary data it's presented with, but it scans through from a (list of) user supplied start point(s) (typically the hardware reset and interrupt vectors as beginning entry points) and inspects the branch and call instruction targets it encounters to create a symbol table of "procedure entry points". Because branch and call instruction targets can be both lower and higher in memory, the simplest way to find the code is to scan forward through the binary file multiple times while updating the symbol table. when no new symbols have been found, the assembler then uses the symbol table to generate code and non-code (ie. data) sections. The data sections could contain jump tables and a very intelligent disassembler could even work out where these jump tables are, but it's typically left to the user to manually find these tables and to edit a configuration file (for the binary being disassembled) for a further iteration of the disassembler.

 

This way, an assembler source can be rapidly generated. So, to summarise, I'm suggesting that even the simplest intelligent disassembler assumes all the binary information it's given is data to start with, and it works out which bits aren't data by the simple method described above. As an example, here's the first iteration output of my DHC11 disassembler:

 

DHC11 - 68HC11 Disassembler v1.00 (c) Copyright 2000 Tech Edge Pty. Ltd.

Input file: bjks8010.bin
Input file bjks8010.bin has 32768 bytes ($8000).
Output file: bjks.DIS
Code resides from $8000 to $FFFF ($8000 bytes).
No entry point - defaulting to disassembly from $9006 (reset vector at $FFFE).
Entry point $1000 outside ROM image (ref. from PC = $916E).
Indexed Call/Jump at $D3A2, may require a vector table.
Pass 1 found 316 new entry points.
Pass 2 found 93 new entry points.
Pass 3 found 0 new entry points.
Total of 3 iteration(s) to find all code.

 

AVR developer

Last Edited: Thu. Mar 5, 2020 - 12:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

techedge wrote:
An intelligent disassembler
I was talking about the use of GNU objdump. It can disassemble for every target that binutils can support but there's no "intelligence" to it. (normally when objdump disassembles it is doing so on ELF not binary so has plenty of symbolic support):

00000060 <__do_copy_data>:
  60:	10 e0       	ldi	r17, 0x00	; 0
  62:	a0 e6       	ldi	r26, 0x60	; 96
  64:	b0 e0       	ldi	r27, 0x00	; 0
  66:	e8 e9       	ldi	r30, 0x98	; 152
  68:	f0 e0       	ldi	r31, 0x00	; 0
  6a:	02 c0       	rjmp	.+4      	; 0x70 <__do_copy_data+0x10>
  6c:	05 90       	lpm	r0, Z+
  6e:	0d 92       	st	X+, r0
  70:	a0 36       	cpi	r26, 0x60	; 96
  72:	b1 07       	cpc	r27, r17
  74:	d9 f7       	brne	.-10     	; 0x6c <__do_copy_data+0xc>

00000076 <__do_clear_bss>:
  76:	20 e0       	ldi	r18, 0x00	; 0
  78:	a0 e6       	ldi	r26, 0x60	; 96
  7a:	b0 e0       	ldi	r27, 0x00	; 0
  7c:	01 c0       	rjmp	.+2      	; 0x80 <.do_clear_bss_start>

0000007e <.do_clear_bss_loop>:
  7e:	1d 92       	st	X+, r1

00000080 <.do_clear_bss_start>:
  80:	a0 36       	cpi	r26, 0x60	; 96
  82:	b2 07       	cpc	r27, r18
  84:	e1 f7       	brne	.-8      	; 0x7e <.do_clear_bss_loop>
  86:	0e 94 49 00 	call	0x92	; 0x92 <main>
  8a:	0c 94 4a 00 	jmp	0x94	; 0x94 <_exit>

0000008e <__bad_interrupt>:
  8e:	0c 94 00 00 	jmp	0	; 0x0 <__vectors>

00000092 <main>:

#include <avr/io.h>


int main(void)
{
  92:	ff cf       	rjmp	.-2      	; 0x92 <main>

Asking it to disassemble "raw Hex" is a pretty unusual event as normally it's used in projects with source.

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

Brian Fairchild wrote:
IDA PRO is pretty good although I've not tried it on AVRs.

 

I vote IDA Pro too, though I have only used for x86 many years ago. It's a very good disassembler.

 

edit: well, it was very good at the time, but I'm guessing it still is.

Last Edited: Thu. Mar 5, 2020 - 01:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

IDA Pro certainly mentions "AVR" here:  https://www.hex-rays.com/products/ida/processors/

 

Yoiks! it ain't cheap!! ...  https://www.hex-rays.com/cgi-bin/quote.cgi

Last Edited: Thu. Mar 5, 2020 - 02:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mmmmm..... commodore 5.0 litre manual. Almost a ‘classic’ car.

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

Kartman:  > Mmmmm..... commodore 5.0 litre manual

 

I forget where that particular BIN came from, but bjks8010.bin may have come from my own V6 VN, or from someone who sent me their BIN at the time. In the early 2000s, when wideband oxygen sensors became affordable, I swapped my ECU development work for designing wideband controllers (with AVR microcontrollers), and I'm still doing that, although I'm thinking of designing from scratch a very basic ECU for one of my vintage motorbikes - I never could tune that bike with the tools I had at the time!

AVR developer

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

Peter, I was pondering recently about porting the delco 808 code to C onto a little ARM microcontroller. I did ponder, created a project but haven't progressed. What vintage motorbike? (I'm into motorbikes).

 

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

I'd do the ECU totally in AVR assembler - purely for the challenge, and maybe as a demonstration for others. Those cheap STM32F boards work well, but code protection is an issue for me.

 

Target bike Ducati 250 single. But we'd better not talk about that in this forum - email me directly if you wish (but I'm off bicycling this long Canberra weekend, so don't expect an immediate reply!).

 

AVR developer

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

Ducati 250 single - my uncle raced one of them back in the day - beat the works rider I'm told.

 

Code protection is any better in the AVR??

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

Hey, I used that HC11 disassembler to find my way around the Coupe Fiat 16v (and a handful of other cars) ECU - thanks for that!

 

Neil

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

Yamaha 350 was my dream machine in my youth!

I'm currently restoring a honda trail 70....  but this has nothing to do with AVRs sadly.....

 

 

Jim

 

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

If you want something you've never had...

...you must be willing to do something you've never done!

Lets go Brandon!

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

Hello,

  It is highly unlikely that there is an "advanced disassembler" for the AVR that you are looking for.  The 68HC11 was based on the 6800 general-purpose micro PROCESSOR, while the AVR is was designed to be a high-speed micro CONTROLLER.   There were disassemblers written for the AVR, but it was easier to simply re-write the source to be specific to the AVR.

 

It seems like your original source routines are written in a psuedo-language that has low-level data flow functions (but not as low as raw assembler)  and low-level data structures.  I recommend that you re-write these routines in C, which uses low-level data flow functions and high-level data structures.    I suggest using the Arduino version of C because it is a free, easy-to-learn, integrated (from code writing to device programming stages, missing only the flow-chart and debugging stages found on each end), and has lots of on-line web support.  Arduino uses an elementary level of the C++ language.  Arduino is often dismissed because it forces some awkward coding methods that stem from its origin as a classroom programming-teaching tool, but its standardization and wide-use make up for its annoyances.  

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

digitalDan wrote:

techedge wrote:
I now find myself in the situation of wanting to disassemble my own AVR code I wrote 20 years ago - yes, I have the sources for these binaries, but it's not in the language (assembler) I'd like to now use to make modifications to.

I'm confused.  If you have the original source with presumably appropriate labels and comments, wouldn't it be simpler to translate that into the assembly flavor of your liking?

68HC11 code is a lot simpler. For example, to load the A register with an immediate value of 0x55, the resulting binary is simply $86, $55 (lda #$55).

An AVR produces really weird binary not easy to disassemble.

It probably is almost impossible to convert an 'HC11 disassembler into an AVR disassembler.

(edit to add): What I wouldn't give to have an MC6809 cored microcontroller!

Gentlemen may prefer Blondes, but Real Men prefer Redheads!

Last Edited: Sat. Mar 7, 2020 - 06:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Avr is that “difficult”, it’s just not “clean and human readable” in hex form.  A program, even a relatively dumb one like avr-objdump, would have no trouble extracting the scattered bits and figuring out what the constants were.   It’s all clearly documented.

 

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

Sorry folks, I've been cycling the last long Canberra (ACT, Australia) weekend (the joys of "semi-retirement"), but picked up a standard flu virus I'm now getting over. Please excuse the length of this post - if you have something to say...

 

Well, it seems like I'll have to convert my DHC11 disassembler to DAVR just to convince you that it can be done! (well, it was probably always on the cards anyway, I was just trying to save myself some work, but quite often if you want something done a certain way, the only course is to do it yourself!). The upside is that I'll also update my ASHC11 & DHC11 to Win-32/64 (and maybe add the high level additions I'm proposing for AVRHA to ASHC11 too, although I suspect not too many people would use it - certainly not me!)

 

I just want to clarify what I'm trying to achieve. I'm updating my AVR development environment so I can continue developing in "an assembler like" environment that includes "high level constructs". For my target projects, I don't want to code in C - and you'll just have to accept that although I'm a proficient C developer (DHC11, ASHC11, AVRHA are all written in C for a DOS/Windows environment, and I use C to prototype lots of stuff in an Arduino development  environment regularly) I'd prefer to write in an "augmented assembler" that I have 100% control over.

 

So, specifically, I'm writing my own AVR assembler (called AVRHA based on my 68HC11 assembler) because I want to add features that are hard/impossible/ugly to implement with macros. My 68HC11 assembler already had macro capability that looks very much like the AVR macro capability (I'm using AVRASM2 for baseline comparison purposes), so when I say I'm writing my own AVR assembler, then I'm really saying I'm re-writing the small section that is the code translator in my (C coded) 20 year old ASHC11 assembler. So code-wise, in my new AVRHA I'm changing the HC11 "code translator" to generate AVR code. Although the AVR and the HC11 have an 8-bit ALU, the major difference is that AVR instructions are 16-bit wide and there's an up to 22 bit wide address range), and this is the major difference - I estimate that I'm (re-)using about 80% of my ASHC11 code.

 

The bit I still have to write in my AVRHA code translator is the LDI/LDx/STx/MOVx/LPM/SPM instruction parsing logic because this is the mnemonic that has the largest variability. Here are those instruction I mention using "classic AVR mnemonics":
 ----------------    
   MOV Rd,Rs        
   LDI Rd,K         
   LD  Rd,<index-mode>    
   LDD Rd,Ir+q      
   LDS Rd,ram-address      
   ST  <index-mode>,Rs    
   STD xyz+q,Rs     
   STS ram-address,Rs      
 
   LPM
   LPM Rd,Z
   LPM Rd,Z+
   SPM

 

where  <indexed-mode> == Ir, -Ir, Ir+, Ir+q 

           Ir == Z | Y | X

           q == index

 

I was never very happy with the plethora of these instruction when a generic "MOVE <destination>[,<source>]" would suffice (but that's another topic I'll talk about once I finish the basic AHRHA).

 

The other area I'll have to address is handling CPU differences - as you know there are families of AVR devices that have subtle differences in what instructions they do/don't support. I have not quite worked out the best way to handle this yet - I'll use AVRASM2 as my baseline. I'm happy to hear suggestions because I simply have not looked into it, assuming it could easily be implemented somehow (famous last words!).

 

Lastly - I'm happy to answer questions - as long as they are not of the (your opinion vs. my opinion) formats:

 

   a. Why not use C/Arduino, etc.

   b: Assembler is dead, you're crazy

   c. etc.

 

Also, I like to keep reasonably on-topic, and my understanding is that this is NOT the forum to talk about what I'll use my AVRHA assembler for, and motor bikes, cars, etc. If you know me then you can send me an personal email (making sure I know who you are) and I'd be happy to provide a reply ;-).

 

PS. I feel a little offended that I'm classified as a "new member" when I've been a relatively inactive member for a least 12 years (and I think I may have had an earlier account under different a name in the early 2000s!)!

AVR developer

Last Edited: Thu. Mar 12, 2020 - 02:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

techedge wrote:
I'll have to convert my DHC11 disassembler to DAVR
If you do remember to include a switch so it can generate Asm in either Atmel AVRASM2 or GNU avr-as formats.

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


Hi techedge,

 

Would this simple syntax meet your "high-level AVR assembler" requirements?

 

"StatementSequence" stands for any number of AVR assembly instructions and/or s'AVR statements.

Therefore s'AVR statements and assembly instructions in-between (including Macros) can be nested to any level (as long as enough AVR program memory is available).

 

s’AVR generates native AVRASM2 assembler instructions and offers quite good self explaining error messages (>50 different ones), warnings and hints referring to the source code line numbers.

 

An English manual you will find here: http://www.led-treiber.de/html/leds_downloads.html

 

May I ask, which other "high-level AVR assembler" you have used before, please?

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

s'AVR wrote:
 Would this simple syntax meet your "high-level AVR assembler" requirements? 

 

Hi  Eberhard Haug,

 

Yes, it could, but I'm well on my way with AVRHA. See my PM to you.

 

s'AVR wrote:
 May I ask, which other "high-level AVR assembler" you have used before, please? 

 

That's a commercial-in-confidence question ;-), but obviously it has a similar "syntax" to your s'AVR. And it's also an assembler which produces code binaries.

 

My AVRHA tool will be a free and fully documented windows .EXE being both the "pre-compiler" (in s'AVR speak) and the macro assembler - producing .HEX/.S19 output. I'm probably not going to offer full AVRASM2 output file capability, but it will be an industrial strength, supported tool that knowledgeable programmers will, I hope, appreciate.

 

This last week, after about 10 years of not getting the flu, I picked up fairly benign (standard) flu infection, I'm almost ready to complete AVRHA's basic assembler capability, and I'm going to release the assembler .EXE and a suite of test files to ensure it assembles all syntax-correct code and catches all syntax-errors (using AVRASM2 as the "gold standard"). At the moment I'm have a flu-imposed rest!

 

If anyone would like to be part of this test phase, then PM me and I'll give you an email address to contact me. Thanks.

 

 

AVR developer

Last Edited: Sat. Mar 14, 2020 - 02:17 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi ClawSon

 

clawson wrote:

remember to include a switch so it can generate Asm in either Atmel AVRASM2 or GNU avr-as formats.

 

Point to me an AVR-AS syntax document and I'll see what I can do ;-).

AVR developer

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

GNU AS is documented at..

https://sourceware.org/binutils/docs/as/

Within see section for AVR specific support

(or just build any avr-gcc C code with -save-temps and look at .s to see typical usage)

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

I'm confused about how the discussion pivoted from Disasm talk to V8 Dunnydoors.

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

andrewm1973 wrote:
I'm confused about how the discussion pivoted from Disasm talk to V8 Dunnydoors.

 

Well, I dunno about dunny doors, but there's a pretty obvious transition when you appreciate many people who play with electronics and firmware do so with specific objectives. Sometimes, having a bit of knowledge allows one to dabble in areas they may not have otherwise, and get involved in sports and pastimes that let them use their expertise in positive ways...

 

For example, recently I laced up a (nominally 6V, 3W Shutter Precision) dynamo onto my 29" (wheel-size) bike-packing/off-roading bicycle, thinking that it would be pretty easy to use it to either light my LED headlamp, or just charge some batteries for the headlamp or the phone etc. How wrong I was! The obvious simple bridge rectifier solution turned out to be almost useless to even charge my phone, and at the relatively slow average speed these events happen at, I found the phone actually discharged faster in my charger (because it continually turned on and off and this extra computing load was more of a drag than the dynamo supplied when it was able! A bit of research (who needs research to design a bridge rectifier?) showed me I really needed something like a voltage doubler, or at least a smart rectifier implemented with FETs to avoid the 1.0-1.2 volts drop a bridge rectifier (even with Schottky diodes) introduces when you're looking at a 500mA plus load. In fact, it's actually probably a case where a smart MPPT(*) switching controller matches the load to the available dynamo voltage...

 

So, Andrew M, you can see how easy it is for a simple discussion to slide/pivot!

 

note (*) - Yes, MPPT (Maximum Power Point Transfer) usually relates to solar panels and modifying the load in order to transfer the maximum power to the load at any given solar power input level to the converter/regulator. Dynamos are not constant current or constant voltage devices, and while they are quite different to solar panels, the load supplied to them must be adjust commensurately with the speed they are being driven at to maximise the power transferred. This can only be done easily and relatively efficiently with some kind of MPPT switching converter - a perfect target for an AVR processor...

AVR developer

Last Edited: Sun. Mar 15, 2020 - 03:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Peter made reference to a memcal (eprom for the delco 808 ecu). The reference quoted may have been for a V8 commodore.

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

techedge, I understand that there are many an varied interests here.  What I didn't get was how it went straight from talking about IRDA-Pro to V8 commodores.  Kartman gave a hint just above so I searched verbatim for "Input file: bjks8010.bin" and can see that this is a common filename for the Holden (RIP) ECU.

 

Without that one bit of obscure knowledge it just was a really weird jump in topic.

 

BTW I have a Schmidt Son28 on my Surly LHT. If you want max power out of dynos you do want to do synchronous rectification.  Also probably best off using the dyno power to charge up a power bank then charge your phone from the power bank.

 

Good luck with the self made DisAsm.  Keen to see it.  Though myself I prefer to do most things in C unless I need something super optimized in ASM.

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

andrewm1973 wrote:
I have a Schmidt Son28 on my Surly LHT.

 

Yeah, these Dynos seem to have been reasonably popular in the last 12/24 months here in Oz!

 

I have two bikes with (as mentioned) Shutter Precision ( https://www.sp-dynamo.com/series8X.html ) dynamos. I'm still playing with my own circuitry to charge batteries and power LED headlights!

 

And I have a Surly Moonlander (26" fat bike  with 100mm rims & 4.8" tyres, MY-2013) which doesn't have a dynamo (I have LiPo batteries) because I've recently set it up with a Xiongda 2-speed motor ( http://www.xiongdamotor.com.cn/productgrouplist-220560510/NEW_Double_speed_Motor.html ) as both an experiment and for an adventure I've been planning for the last 6 years!

 

andrewm1973 wrote:
If you want max power out of dynos you do want to do synchronous rectification.

 

For those following this thread: Synchronous (or active) rectification is described here if you have not come across it before ( https://en.wikipedia.org/wiki/Active_rectification )

 

But I think it's a lot more complex than just adding a bit of circuitry that will remove the diode forward voltage drops. Impedance matching between the dynamo and the load is probably more important when there are electronic loads (as opposed to electrical loads), and when you want to draw the maximum power from the dynamo. If anyone is interested in voltage doublers and LED headlamps - this is an interesting article (I'd have preferred its analysis was a little more rigorous though!):  http://pilom.com/BicycleElectronics/DynamoCircuits.htm - He's claiming he can draw up to 10W from a nominal 3W/6V dynamo with a doltage doubler - note YMMV!

AVR developer

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

I'm not totally convinced about his basic assumption that a dynamo is a constant current source, particularly his assertion early in the piece that the dynamo limits its output current to half an amp or so. And I wonder, if one is going to the trouble and complexity of self-switching circuits to maintain brightness, if it might be worth going the whole hog and using a switch-mode buck/boost driver, possibly even with a small chargeable battery involved...

 

Neil

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

@Techedge how is your progress on that? I've got a client who seems to have failed at source code management- the binaries he's loading in production hardware are later version than the latest source code he supplied. Being able to disassemble the binary and compare to a disassembled binary of the earlier code ought to help me figure out what changes I need to replicate...

-mike

Private Consulting EE, Tool Hoarder, & Incorrigible Tinkerer

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


By chance, I recently found a decent disassembler, it's not quite IDA Pro level, but at least it's free.

https://cutter.re/

 

Screenshot of disassembled raw binary downloaded from an AVR. It's my code, so I happen to know this particular function is a software UART written in asm, the pure C++ parts are too obfuscated by the compiler to look nice :P

 

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

El Tangas wrote:
https://cutter.re/
I was curious what it would make of my heavily hand-optimised ATtiny4 code, but that's not a supported target.

"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]