I have successfully instantiated my accelstepper objects:
//Create accelstepper object for the Z-Axis actuator
AccelStepper zaxis(AccelStepper::DRIVER, ZSTEP, ZDIR);
//Create accelstepper object for the theta axis actuator
AccelStepper taxis(AccelStepper::DRIVER, TSTEP, TDIR);
//Create accelstepper object for the magnet actuator
AccelStepper maxis(AccelStepper::DRIVER, MSTEP, MDIR);
Now I am trying to do some basic setup with these objects:
void stepper_setup(){
//Set Max Speed in steps per second
zaxis.setMaxSpeed(100);
taxis.setMaxSpeed(100);
maxis.setMaxSpeed(100);
//Set Acceleration in steps per second squared
zaxis.setAcceleration(500);
taxis.setAcceleration(500);
maxis.setAcceleration(500);
//Home the Zaxis, Taxis, Maxis
zaxis.moveTo(100000); taxis.moveTo(100000); maxis.moveTo(100000);
zaxis.run(); taxis.run(); maxis.run();
However, the compiler throws me the following error:
.pio\build\nucleo_f410rb\lib799\libAccelStepper.a(AccelStepper.o): In function `AccelStepper::runSpeed()':
c:\Users\USER\Documents\PROJECTFOLDER\Codes\PROJECT TITLE/.pio\libdeps\nucleo_f410rb\AccelStepper/AccelStepper.cpp:63: undefined reference to `t'
collect2.exe: error: ld returned 1 exit status
*** [.pio\build\nucleo_f410rb\firmware.elf] Error 1
and when look up the problematic line 63 in AccelStepper.cpp in question, i can only find this line:
_currentPos -= 1;
This is the picture of the problematic line and
This is the picture of the error thrown in the compiler
which doesn't make sense. Am I missing something? Any help would be greatly appreciated!
Related
I'm trying to create VkImageView which will be binded to index 0.
Here is my VkImageView creation code
void Image::createImageView() {
VkImageViewUsageCreateInfo imageViewUsage;
imageViewUsage.sType=VK_STRUCTURE_TYPE_IMAGE_VIEW_USAGE_CREATE_INFO;
imageViewUsage.pNext=nullptr;
imageViewUsage.usage=VK_IMAGE_USAGE_STORAGE_BIT;
VkImageViewCreateInfo viewInfo{};
viewInfo.sType = VK_STRUCTURE_TYPE_IMAGE_VIEW_CREATE_INFO;
viewInfo.pNext=&imageViewUsage;
viewInfo.image = textureImage;
viewInfo.viewType = VK_IMAGE_VIEW_TYPE_2D;
viewInfo.format = VK_FORMAT_R8G8B8A8_UNORM;
viewInfo.subresourceRange.aspectMask = VK_IMAGE_ASPECT_COLOR_BIT;
viewInfo.subresourceRange.baseMipLevel = 0;
viewInfo.subresourceRange.levelCount = 1;
viewInfo.subresourceRange.baseArrayLayer = 0;
viewInfo.subresourceRange.layerCount = 1;
if (vkCreateImageView(device, &viewInfo, nullptr, &textureImageView) != VK_SUCCESS) {
throw std::runtime_error("failed to create texture image view!");
}
}
When I call vkUpdateDescriptorSets I get validation error:
vkCreateImageView: Includes a pNext pointer (pCreateInfo->pNext) to a VkStructureType (VK_STRUCTURE_TYPE_IMAGE_VIEW_USAGE_CREATE_INFO), but its parent extension VK_KHR_maintenance2 has not been enabled. The Vulkan spec states: Each pNext member of any structure (including this one) in the pNext chain must be either NULL or a pointer to a valid instance of VkImageViewASTCDecodeModeEXT, VkImageViewUsageCreateInfo, VkSamplerYcbcrConversionInfo, VkVideoProfileKHR, or VkVideoProfilesKHR
Before this I had set viewInfo.pNext=nullptr; for which I was getting validation error:
Write update to VkDescriptorSet 0xf018750000000004[] allocated with VkDescriptorSetLayout 0x683e70000000002[] binding #0 failed with error message: Attempted write update to image descriptor failed due to: ImageView (VkImageView 0xa3c6870000000008[]) with usage mask 0x6 being used for a descriptor update of type VK_DESCRIPTOR_TYPE_STORAGE_IMAGE does not have VK_IMAGE_USAGE_STORAGE_BIT set
Can someone please help me with some hint how exactly I can solve the error?
The error message tells you exactly what to do. If you use VkImageViewUsageCreateInfo, that means you have to enable maintenance2 extension or in turn Vulkan 1.1 to which it was promoted.
Since you seem surprised by the existence of extensions, it feels likely your use of them is just accidental. You might simply want to stop using the VkImageViewUsageCreateInfo extension struct and always set pNext to NULL.
By the documentation, the pCode field of the VkShaderModuleCreateInfo struct
must point to valid SPIR-V code, formatted and packed as described by the Khronos SPIR-V Specification.
Now, I've made a typo in the call of the following utility function and unintendedly provided the file name of the GLSL code as the shader_file_name.
void create_shader_module(VkDevice device, std::string const& shader_file_name)
{
std::ifstream shader_file(shader_file_name, std::ios::binary);
shader_file.seekg(0, std::ios_base::end);
std::size_t const shader_file_size = shader_file.tellg();
if (shader_file_size > 0)
{
assert(shader_file_size % sizeof(std::uint32_t) == 0);
std::vector<char> binary(shader_file_size);
shader_file.seekg(0, std::ios_base::beg);
shader_file.read(binary.data(), shader_file_size);
VkShaderModuleCreateInfo shader_module_create_info{};
shader_module_create_info.sType = VK_STRUCTURE_TYPE_SHADER_MODULE_CREATE_INFO;
shader_module_create_info.codeSize = shader_file_size;
shader_module_create_info.pCode = reinterpret_cast<std::uint32_t const*>(binary.data());
VkShaderModule shader_module;
if (vkCreateShaderModule(device, &shader_module_create_info, nullptr, &shader_module) != VK_SUCCESS)
throw std::exception("Could not create shader module");
}
}
Despite the typo, the code didn't throw, i.e. vkCreateShaderModule returned VK_SUCCESS. Why?
(Note that a subsequent call to vkCreateGraphicsPipelines with a VkPipelineShaderStageCreateInfo which uses the generated shader module fails.)
The validation layers would have found this problem, emitting a message:
SPIR-V module not valid: Invalid SPIR-V magic number.
Ths validation layers run the SPIR-V validator at vkCreateShaderModule time.
You are using Vulkan, not OpenGL. In Vulkan, it is not up to the implementation to validate your SPIR-V code. The Valid Usage for vkCreateShaderModule says that "pCode must point to valid SPIR-V code, formatted and packed as described by the
Khronos SPIR-V Specification." As with any other Valid Usage statement, if you violate it, the implementation will not tell you that you have done so.
You simply get undefined behavior.
Create Instance of Callback Object using an ATL template
CComObject<COPCDataCallback>::CreateInstance(&pCOPCDataCallback);
pCbUnk = pCOPCDataCallback->GetUnknown();
it stacked at
HRESULT hRes = AtlAdvise(m_IOPCGroupStateMgt, // [in] IUnknown Interface of the Connection Point
pCbUnk, // [in] IUnknown Interface of the Callback object
IID_IOPCDataCallback,// [in] Connection Point ID: The OPC Data Callback
m_dwAdvise // [out] Cookie that that uniquely identifies the connection
);
unhandled exception at XXXX ntdll.dll
before that I added ATL support to the MFC project
https://stackoverflow.com/a/8046824/4270170
any ideas to solve this issue?
thanks.
It seems to be my fault that the type of the fourth param of AtlAdvise is DWORD，but there is something wrong with this param I set.And now everything goes well.Thank you all.
There are a lot of samples for C#, but only some code snippets for C++ on MSDN. I have put it together and I think it will work, but I am not sure if I am releasing all the COM references I have to.
Your code is correct--the reference count on the IBufferByteAccess interface of *buffer is incremented by the call to QueryInterface, and you must call Release once to release that reference.
However, if you use ComPtr<T>, this becomes much simpler--with ComPtr<T>, you cannot call any of the three members of IUnknown (AddRef, Release, and QueryInterface); it prevents you from calling them. Instead, it encapsulates calls to these member functions in a way that makes it difficult to screw things up. Here's an example of how this would look:
// Get the buffer from the WriteableBitmap:
IBuffer^ buffer = bitmap->PixelBuffer;
// Convert from C++/CX to the ABI IInspectable*:
ComPtr<IInspectable> bufferInspectable(AsInspectable(buffer));
// Get the IBufferByteAccess interface:
ComPtr<IBufferByteAccess> bufferBytes;
ThrowIfFailed(bufferInspectable.As(&bufferBytes));
// Use it:
byte* pixels(nullptr);
ThrowIfFailed(bufferBytes->Buffer(&pixels));
The call to bufferInspectable.As(&bufferBytes) performs a safe QueryInterface: it computes the IID from the type of bufferBytes, performs the QueryInterface, and attaches the resulting pointer to bufferBytes. When bufferBytes goes out of scope, it will automatically call Release. The code has the same effect as yours, but without the error-prone explicit resource management.
The example uses the following two utilities, which help to keep the code clean:
auto AsInspectable(Object^ const object) -> Microsoft::WRL::ComPtr<IInspectable>
{
return reinterpret_cast<IInspectable*>(object);
}
auto ThrowIfFailed(HRESULT const hr) -> void
{
if (FAILED(hr))
throw Platform::Exception::CreateException(hr);
}
Observant readers will notice that because this code uses a ComPtr for the IInspectable* we get from buffer, this code actually performs an additional AddRef/Release compared to the original code. I would argue that the chance of this impacting performance is minimal, and it's best to start from code that is easy to verify as correct, then optimize for performance once the hot spots are understood.
This is what I tried so far:
// Get the buffer from the WriteableBitmap
IBuffer^ buffer = bitmap->PixelBuffer;
// Get access to the base COM interface of the buffer (IUnknown)
IUnknown* pUnk = reinterpret_cast<IUnknown*>(buffer);
// Use IUnknown to get the IBufferByteAccess interface of the buffer to get access to the bytes
// This requires #include <Robuffer.h>
IBufferByteAccess* pBufferByteAccess = nullptr;
HRESULT hr = pUnk->QueryInterface(IID_PPV_ARGS(&pBufferByteAccess));
if (FAILED(hr))
{
throw Platform::Exception::CreateException(hr);
}
// Get the pointer to the bytes of the buffer
byte *pixels = nullptr;
pBufferByteAccess->Buffer(&pixels);
// *** Do the work on the bytes here ***
// Release reference to IBufferByteAccess created by QueryInterface.
// Perhaps this might be done before doing more work with the pixels buffer,
// but it's possible that without it - the buffer might get released or moved
// by the time you are done using it.
pBufferByteAccess->Release();
When using C++/WinRT (instead of C++/CX) there's a more convenient (and more dangerous) alternative. The language projection generates a data() helper function on the IBuffer interface that returns a uint8_t* into the memory buffer.
Assuming that bitmap is of type WriteableBitmap the code can be trimmed down to this:
uint8_t* pixels{ bitmap.PixelBuffer().data() };
// *** Do the work on the bytes here ***
// No cleanup required; it has already been dealt with inside data()'s implementation
In the code pixels is a raw pointer into data controlled by the bitmap instance. As such it is only valid as long as bitmap is alive, but there is nothing in the code that helps the compiler (or a reader) track that dependency.
For reference, there's an example in the WriteableBitmap::PixelBuffer documentation illustrating the use of the (otherwise undocumented) helper function data().
I have troubles with dynamic loading of libraries - my code panics with Kern-Exec 3. The code is as follows:
TFileName dllName = _L("mydll.dll");
TFileName dllPath = _L("c:\\sys\\bin\\");
RLibrary dll;
TInt res = dll.Load(dllName, dllPath); // Kern-Exec 3!
TLibraryFunction f = dll.Lookup(1);
if (f)
f();
I receive panic on TInt res = dll.Load(dllName, dllPath); What can I do to get rid of this panic? mydll.dll is really my dll, which has only 1 exported function (for test purposes). Maybe something wrong with the DLL? Here's what it is:
def file:
EXPORTS
_ZN4Init4InitEv # 1 NONAME
pkg file:
#{"mydll DLL"},(0xED3F400D),1,0,0
;Localised Vendor name
%{"Vendor-EN"}
;Unique Vendor name
:"Vendor"
"$(EPOCROOT)Epoc32\release\$(PLATFORM)\$(TARGET)\mydll.dll"-"!:\sys\bin\mydll.dll"
mmp file:
TARGET mydll.dll
TARGETTYPE dll
UID 0x1000008d 0xED3F400D
USERINCLUDE ..\inc
SYSTEMINCLUDE \epoc32\include
SOURCEPATH ..\src
SOURCE mydllDllMain.cpp
LIBRARY euser.lib
#ifdef ENABLE_ABIV2_MODE
DEBUGGABLE_UDEBONLY
#endif
EPOCALLOWDLLDATA
CAPABILITY CommDD LocalServices Location MultimediaDD NetworkControl NetworkServices PowerMgmt ProtServ ReadDeviceData ReadUserData SurroundingsDD SwEvent TrustedUI UserEnvironment WriteDeviceData WriteUserData
source code:
// Exported Functions
namespace Init
{
EXPORT_C TInt Init()
{
// no implementation required
return 0;
}
}
header file:
#ifndef __MYDLL_H__
#define __MYDLL_H__
// Include Files
namespace Init
{
IMPORT_C TInt Init();
}
#endif // __MYDLL_H__
I have no ideas about this... Any help is greatly appreciated.
P.S. I'm trying to do RLibrary::Load because I have troubles with static linkage. When I do static linkage, my main program doesn't start at all. I decided to check what happens and discovered this issue with RLibrary::Load.
A KERN-EXEC 3 panic is caused by an unhandled exception (CPU fault) generated by trying to invalidly access a region of memory. This invalid memory access can be for both code (for example, bad PC by stack corruption) or data (for example, accessing freed memory). As such these are typically observed when dereferencing a NULL pointer (it is equivalent to a segfault).
Certainly the call to RLibrary::Load should never raise a KERN-EXEC 3 due to programmatic error, it is likely to be an environmental issue. As such I have to speculate on what is happening.
I believe the issue that is observed is due to stack overflow. Your MMP file does not specify the stack or heap size the initial thread should use. As such the default of 4Kb (if I remember correctly) will be used. Equally you are using TFileName - use of these on the stack is generally not recommended to avoid... stack overflow.
You would be better off using the _LIT() macro instead - this will allow you to provide the RLibrary::Load function with a descriptor directly referencing the constant strings as located in the constant data section of the binary.
As a side note, you should check the error value to determine the success of the function call.
_LIT(KMyDllName, "mydll.dll");
_LIT(KMyDllPath, "c:\\sys\\bin\\");
RLibrary dll;
TInt res = dll.Load(KMyDllName, MyDllPath); // Hopefully no Kern-Exec 3!
if(err == KErrNone)
{
TLibraryFunction f = dll.Lookup(1);
if (f)
f();
}
// else handle error
The case that you can't use static linkage should be a strong warning to you. It shows that there is something wrong with your DLL and using dynamic linking won't change anything.
Usually in these cases the problem is in mismatched capabilities. DLL must have at least the same set of capabilities that your main program has. And all those capabilities should be covered by your developer cert.