Hi,
using the STM32F407 Discovery board I have an application sending data from some hardware-potentiometers to AWE objects.
Everything was working nice and smoothly, until I tried to use the combination of a 'DC Source' and a 'Param Set' object to change filter settings
The combination is working perfectly when used in AWE Designer alone, though. BTW: I am not using the optional input control pin for the DC Source.
This code (from Platform.c) will not find any objects:
if (awe_ctrlGetModuleClass(&g_AWEInstance, AWE_CVcutoff_value_HANDLE, &locClassID) == OBJECT_FOUND)
{
cutoff_obj_found = 1;
// Check that module assigned this object ID is "as expected"
if (locClassID == AWE_CVcutoff_classID)
{
cutoff_obj_found = 2;
cutoff_freq = mapfloat((float)cv_in3, 0.0, 4095.0, 10.0, 20000.0); // in-min, in-max, out-min, out-max
awe_ctrlSetValue(&g_AWEInstance, AWE_CVcutoff_value_HANDLE, (void *)&cutoff_freq, 0, 1);
}
}
This is the equivalent data from the exported include file.
// [DCSourceV2]
// Newly created subsystem
#define AWE_CVcutoff_classID 0xBEEF0872
#define AWE_CVcutoff_ID 30003
// float value - Data Value
// Default value: 19444.6992
// Range: 10 to 20000
#define AWE_CVcutoff_value_HANDLE 0x07533008
#define AWE_CVcutoff_value_MASK 0x00000100
#define AWE_CVcutoff_value_SIZE 0x00000001
Any idea what I may be doing wrong?
Or are there limitations to using the DC Source with external control - I did not find anything of that kind in the documentation...
Compile and link is fine, the binary can be loaded and as mentioned works perfectly when controlled by AWE designer alone.
BTW: The GUI-controls of the DC-Source will not be locked, in opposite to the Inspector of the object below. Which kind of makes sense, because the application does not access the object...
----
This is working code of the same type, where I can find no difference to the code above:
if (awe_ctrlGetModuleClass(&g_AWEInstance, AWE_PeriodPulse2_period_HANDLE, &locClassID) == OBJECT_FOUND)
{
// Check that module assigned this object ID is "as expected"
if (locClassID == AWE_PeriodPulse2_classID)
{
pulse2_period = mapfloat((float)cv_in3, 0.0, 4095.0, 5.0, 10.0); // in-min, in-max, out-min, out-max
awe_ctrlSetValue(&g_AWEInstance, AWE_PeriodPulse2_period_HANDLE, (void *)&pulse2_period, 0, 1);
}
}
#define AWE_PeriodPulse2_classID 0xBEEF0878
#define AWE_PeriodPulse2_ID 30002
// float period - Total period of the pulse.
// Default value: 6.0889
// Range: 5 to 10
#define AWE_PeriodPulse2_period_HANDLE 0x07532008
#define AWE_PeriodPulse2_period_MASK 0x00000100
#define AWE_PeriodPulse2_period_SIZE 0x00000001
All the best,
Mathias
7:52pm
Hi, just to let you know, I guess I found the issue:
In Platform.c for the AWEIdleLoop() there is a condition
if (awe_audioIsStarted(&g_AWEInstance) )
{ ...
and I looked for the "DC Source" object inside this block (because it worked with other objects to be controlled before)
but.. the "DC Source" object seemingly can not be accessed inside this block.
This makes kind of sense, because it is a kind of "remote control device" (similar to the send object in Max/MSP).
Still I would consider this some kind of a bug or at least I would suggest this quite desperately needs to be pointed out in the documentation, which is not the case so far, at least not afaik on https://dspconcepts.com/sites/default/files/awe-core-integration-guide.pdf or http://download.dspconcepts.com/awecore/index.html
8:13pm
Hello Mathias,
Glad you were able to figure it out. Thanks for letting us know!
Thanks,
Kevin
7:54am
Accessing module in a running layout directly from firmware we call "ControlIO". We provide API calls to perform "ControlIO" functions. In order for a module in a layout to be accessed by firmware it must be assigned a unique object ID of 30000 or greater.
Suppose you load a layout with a scaler module assigned an object ID of 30000. To access this module from firmware you generate an include file that has a handle for this object and you call our API to check if the module is of the scaler class. The reason for this is that you might have loaded a different layout that had assigned object ID 30000 to say a DC source module. Since you can arbitrarily load any layout you like potentially any module type might be assigned an object ID of 30000. If you then attempted to modify some parameter of the module and it was not of the expected type you would likely experience an instant crash.
So there are two possibilities why you might not be able to access a module.
1) no module exists in the running layout with the expected object ID 30000 or greater
2) The module found is not of the expected module class
12:19pm
Hi Chris,
thanks for the detailed explanation, I am already aware of all this and I exactly followed the normal procedure, but none of the circumstances you are describing caused the problem. There were two objects, one with ID 30003 and one with 30004, so it was quite easy to track down.
As explained in my previous post, I was trying to access a DC source module within a block with the condition
"if awe_audioIsStarted(&g_AWEInstance) { ... }"
By tracing the returncodes I found out, that the object could never be reached within this block. So I accessed it outside that block and it works perfectly.
As already pointed out, to me this feels like a bug, or at least the circumstances, why DC source module behave differently to other modules in that specific context could be described in the documentation?
Thanks again - all the best,
Mathias
12:39pm
The reason for the awe_audioIsStarted call is because we assume that if a layout is loaded it is running. If you have code to start/stop audio playback then you may want to replace awe_audioIsStarted with awe_layoutIsValid instead.
12:58pm
Hi Chris, thanks a lot for the tipp, I'll try to use awe_layoutIsValid() instead, then.
But actually the audio always is running in my application and never gets stopped. It actually was audible when
if (awe_ctrlGetModuleClass(&g_AWEInstance, AWE_CVcutoff_value_HANDLE, &locClassID) == OBJECT_FOUND) did not evaluate to true!
That's why I consider the behaviour as a small bug, but as there is a bypass-solution everything is fine.
The reason why I am kind of stressing this is that other programmers / integrators may "fall into the same trap" one day ;-)
Thanks again,
Mathias