Good idea with the auto-check workspace for the variables! They have
to be independently named because sometimes you have multiple versions
of the same block in a design (eg, two PFBs). But we don't want the
workspace filling up with random variables each time the design is
updated, so there would need to be some housekeeping in there too.
Andrew and I have just been chatting, and we think possibly creating
the global variables based on the name of the parent block (rather
than the time) would keep things tidy, because you wouldn't need to
keep track of the last variable name used - you'd know it explicitly.
If this variable doesn't exist, it will be created. Otherwise, it will
just be updated. This does mean that if the user changes the name of a
block, there will potentially be an unused variable floating in the
workspace, but I think we can live with a few extra kB of memory in use.
I'm not sure how same-state/save-state will deal with it if we keep
using the same variable - it might see that the string passed to the
child blocks hasn't changed and then not update the block, even though
the value stored in that variable has changed. I remember we had this
problem, but I'm not sure if Mark fixed it. If not, it's a simple
enough update to these scripts to just evaluate all passed variables
and then store/compare the value rather than the name.
Jason
On 21 May 2008, at 09:26, G Jones wrote:
One problem with using global variables is they could be accidentally
deleted from the workspace, so it may be good to have the routine that
checks if the block needs to be updated also check that the required
global variables are still present in the workspace, and if not,
regenerate them.
I thought about just rounding the coefficients, but it seemed like it
would only allow another power of two or so in spectrum length.
Glenn
On 5/21/08, Jason Manley <[email protected]> wrote:
haha! Funny you should suggest this now. We've just had a meeting
about this
string length limitation and the porting teams has decided that we
will use
global variables to solve it. As a stop-gap (and to prevent matlab
from
dying for unknown reasons), I've checked-in a version of the PFB to
SVN that
brings up a warning box when the maximum string length is exceeded.
There is
also an option to round-off coefficients now and save some space
(else the
string contains 15 significant decimal places, which is excessive
for most
8-bit applications).
Andrew Martens will be writing a guide for building future blocks,
which
will mandate global variables for long strings and scripts to build
the
blocks from scratch. It will probably include a template to help
guys get
started. This will demonstrate the preferred method of passing
variables to
sub-blocks etc. Also, I think safety checks (like the afore-
mentioned string
length limit) are essential. Crashing Matlabs are not cool.
Any further ideas?
Jason
On 21 May 2008, at 02:05, G Jones wrote:
Hi,
This code seems to work for making long PFBs with the green
blocks. It
could probably be improved, but at least it's functional.
Basically it
assigns the 'buf' variable that contains the PFB coefficients to a
unique name in the base Matlab workspace. I couldn't manage to get
it
to work assigning it in any other namespace. The unique name I chose
is just related to the current time, so is meaningless. A more
meaningful unique name could probably be constructed, but this was
easy. Let me know if anyone has a better fix for this problem.
Glenn
<pfb_coeff_gen_init.m>
