How do I include BLIPS into my C project?

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

I would like the BLIPS.asm bootloader to be part of my C project. But when I add it to the solution explorer, it doesn't get assembled during the build process.
There is no blips.o file created, it's not in the map file. I have already changed the Build Action property to "compile" it was set at none by default.

Thanks for any guidance you can provide.

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

Quote:
to be part of my C project.
How do you plan to do that? The source file was written for the Atmel assembler.

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

You could include it as a module by transcribing the code to inline assembly.

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

BLIPS is a quite large Visual Basic program with a few DLL dependencies.

There is, in one of the later versions, a means to invoke it via a command line with arguments on what files to burn, what AVR type to expect, etc.

The command line interface is not enabled in the standard version - it was intended to be used by those doing medium volume flash-burning and have secured authorization.

So the C program could invoke BLIPS via a command line "exec" and check the resultant success code. But this isn't intended for the hobby/educational users.

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

Hmmm, I guess my goal wasn't made clear. We have a project that may need to be updated in the future. Bug fixes ect. I do not intend to use the bootloader as part of the production process. The board is closed up in a metal box, but does have a uart interface exposed. So the thought is that we can simply power cycle the unit with the bootloader connected, and update the firmware.

It looks like I need to convert the blips.asm file from *.asm syntax to *.S syntax, then tell the linker where to put it. Or as hugo states, put it into a C function and again tell the linker where to put it.

If this is the correct path, or not, please chime in.
Also, I couldn't find documentation on the 'S' file syntax, although I've seen 'S' files, and have one in my project already from the RTOS we are using. Using the one 'S' file as my sole reference for converting the syntax would be tough.

Thanks,
Aaron

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

why not just merge the two resulting hex files before sending it off to the programming service.

bootload.hex + firmware.hex => production.hex

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it"

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

That is an option, I'm not sure what tool(s) to use to do this though....

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

You cannot do this. What about all the addresses that were resolved by the compiler and linker? If you push the real code down the address range by 512 bytes then all absolute pointers and jumps are invalid.

You could however assemble the .ASM and put the resulting hex as a data segment with a specific address in your C file.

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

What's wrong with just assembling the BLIPS code and programming it into the chip? From then on (production or field) the code will be programmed via the bootloader.

KISS?? :)

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

alager wrote:
Also, I couldn't find documentation on the 'S' file syntax, although I've seen 'S' files, and have one in my project already from the RTOS we are using. Using the one 'S' file as my sole reference for converting the syntax would be tough.

Thanks,
Aaron

The GNU assembler uses '.S' as an extension so I'm assuming you want the Binutils docs on gas.

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

hugoboss wrote:
You cannot do this. What about all the addresses that were resolved by the compiler and linker? If you push the real code down the address range by 512 bytes then all absolute pointers and jumps are invalid.

You could however assemble the .ASM and put the resulting hex as a data segment with a specific address in your C file.

Of course you CAN do this.

So comping the bootloader and the firmware separately and then merging the hex files will work fine. I've actually done it a few times.
Each text line in the intel hex format has the destination address, so simply merging them in a text editor is perfectly possible.
http://en.wikipedia.org/wiki/Intel_HEX

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it"

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

alager wrote:
Hmmm, I guess my goal wasn't made clear. We have a project that may need to be updated in the future. Bug fixes ect. I do not intend to use the bootloader as part of the production process. The board is closed up in a metal box, but does have a uart interface exposed. So the thought is that we can simply power cycle the unit with the bootloader connected, and update the firmware.
....

Thanks,
Aaron


Isn't this just an ordinary bootloader requirement? After you stop developing and using an ISP to write flash, then flash the bootloader from the .hex for that one assembly language BLIPS AVR side. You won't be using ISP, so on power-up, the bootloader will activate, try the serial port then run the app in flash if there's no connected PC for a bootload.

No need to mess with .S or any such. The AVR side .hex is simply flashed, then you use it.

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

Quote:

The AVR side .hex is simply flashed, then you use it.

Some folks want the first (factory) program to be both a B/L and a first copy of the app code to save prouction time. As has already been suggested - merge the .hex files - just because one is made by Asm2 and the other by GCC matters not a jot. It's all Intel Hex and is easily joined.

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

clawson wrote:
Quote:

The AVR side .hex is simply flashed, then you use it.

Some folks want the first (factory) program to be both a B/L and a first copy of the app code to save prouction time. As has already been suggested - merge the .hex files - just because one is made by Asm2 and the other by GCC matters not a jot. It's all Intel Hex and is easily joined.
Yes, but the OP says he's doing one-of, not production, as I read it. And per the BLIPS usage agreement for non-profit applications.