env.Depends() in extra_script

Kitlith · January 27, 2017, 12:17am

Backstory

Folknology/mystorm/blob/sdk/sdk/README.md#the-detail

myStorm SDK
===========

The SDK is being developed in order to help developers and myStorm participants use the features offered by myStorm boards (initially just the SDK Board). This is code and documentation is very much under construction and should be seen as a living set of code and documents. Any feedback and contribution is very much appreciated.

## Introduction

The myStorm SDK board essentially consists of two major components from a development standpoint, first is a Lattice Ice40HX4K FPGA which can be programmed in Verilog (and later VHDL) using Clifford Wolf's IceStorm toolchain and an STM32l476 Arm Cortex M4 microcontroller which can be targeted via a cross chain arm eabi gcc. Other tools can also be used for development but those mention here are the focus of the SDK, if anyone wishes to add in more tool set support please fork and request a pull.

One of the ways in which myStorm SDK differs from the other low cost FPGA development boards particularly based around the Ice40 series is the addition of the Arm Cortex processor. Most of the other boards purely target the Ice40 FPGA only and use FTDI chips to move bitimages into the FPGA through usb. With myStorm we initially took a different view for how we wanted to target a low cost stand alone SDK, we figured for the price of the FTDI chip we could actually include a 'Hardcore' CPU within our design with little cost impact. Given we are trying to obtain maximum bang for our buck with myStorm this is a path we have chosen to follow for the SDK. There are several advantages to adding in a hardcore microcontroller over just a standalone FPGA:

* A hardcore like the one used on the SDK (STM32l476) has MULT/DIV and an FPU, these features are expensive in terms of logical resources on a limited resource FPGA like the Ice40 when implementing cores. This means you can optionally target your limited resources to other more bespoke functions relevant to your application. The same advantage can be had from the hardcore's memory resources

* The Hardcore brings a number other useful protocol based peripherals which again save you from having to dedicate resources too from the limited FPGA logic blocks e.g. Uarts, SDIO, USB, CAN and others..

* The hardcore also provides useful Analog functionality in the form off many ADC (up to 5Mb/s 12 bit) channels along with Dual DACs.

* The hardcore SDK libraries can add management of development for bitimages and loading, testing etc..

* In the case of the SDK board the hardcore also offers an Arduino compatible shield support which can be handy for many existing peripherals and shields, particularly if you have already invested in these

This file has been truncated. show original

I took a look at the caveat mentioned here, namely that a full build isn’t preformed due to the seperation of toolchains, and decided to attempt to fix this so that we wouldn’t really need to deal with it.

Simplified Problem

I have a program that depends on an external binary that I embed in the final binary. I do this by creating a file “binary.s”:

    .global binary
    .global binary_size
    .section .rodata
binary:
    .incbin "somebinary.bin"
1:
binary_size:
    .int 1b - binary

There is no problem with this, except that I want the object built from “binary.s” to be rebuilt whenever “somebinary.bin” changes. “Easy! Just call Depends!” Alright: env.Depends(ofile, "somebinary.bin")

The Issue

Where does ofile come from? If this were in the main file, you could just do ofile = env.Object("src/binary.s") and depend on the fact that nothing has tried to create an object for that source file before. However, this isn’t the main file, this object has/will likely be created again, and I’m not normally a SCons user, let alone an expert.

So, can I call the Object constructor multiple times, add a dependency on one of the instances, and have it all work out? Or is there something else I need to do?

ivankravets · January 27, 2017, 11:49am

Have you tried AlwaysBuild()?

Kitlith · January 27, 2017, 7:03pm

AlwaysBuild, eh? Well, if I were to use that, then just replace everywhere I say “env.Depends” with “env.AlwaysBuild”.

AKA, the same problem, at least in my mind.

I’m probably overthinking this, but once again, I’d need to (re)create the StaticObject so that I could pass it to AlwaysBuild, and I need to know if it ‘just works’, even if multiple places define the same object and each add dependencies.

Honestly, I guess I should just try it, and see if it works. I was hoping that someone else that knew what would happen would reply, but ah well. Time to experiment.

Kitlith · January 28, 2017, 8:39pm

I’ve been playing around with this, and I have a solution, though it’s less clean than I would like.

extra_script.py:

Import("env")
env.Depends("$BUILD_DIR/src/binary.o", "binary.bin")

I was hoping to do something more like env.Depends(Object("src/binary.s"), "binary.bin"), but it appears that the fears that I expressed earlier were somewhat true, I couldn’t get anything like that to work. I guess this solution is clean enough, though.

ivankravets · January 28, 2017, 11:07pm

That is right solution!

Kitlith · January 28, 2017, 11:18pm

So, in other words, I was over thinking it. facepalm

>_>