First: I've inherited this project from someone who couldn't complete it due to time constraints.
The code contains a little over 100 declared arrays, each one containing a set of INTs. The arrays are all unique.
byte arr_foo[] = {2, 5, 6, 8, 3};
byte arr_bar[] = {1, 7};
byte arr_baz[] = {6, 10, 9, 11, 7, 8, 3};
Those INTs relate to a specific LED on a board - there are 11 total. And the arrays represent a specific sequence that these LEDs should light up.
What they were attempting to do was to write a routine that, when given an array name, would then go fetch the contents of that array and process the INTs. Well, passing an array name as a string to then be matched with a variable doesn't work. And this is where they passed it on, saying they don't have time to figure it out.
So I'm looking at this and thought, why not a 2-dimensional array? I quickly ran into trouble there.
byte seqs[][7] = {
{2, 5, 6, 8, 3},
{1, 7},
{6, 10, 9, 11, 7, 8, 3}
}
While in principle this works, the issue here is that it pads each array with trailing zeros because I told it each one has [7] elements. This results in a lot of memory being wasted and the thing running out of memory.
So I am stuck. I'm not sure how to deal with 100+ separate arrays, other than to write 100+ separate routines to be called later. Nor can I figure out how to make it more efficient.
Then there's the issue of, I may still run out of memory at a later time as more sequences are added. So then what? Add an external i2c flash memory, and shove things in there? Having never dealt with that, I'm not sure how to implement that, in what format to store the values, and how to do it. Am I correct that one has to first write a program that loads all the data in memory, upload that and run it, then put the actual program that's going to process that data on the micro controller?
So I guess I'm asking for two things: What's a better way of handling lots and lots of (small) arrays and be able to use them within a routine that calls them, and if I'm better off shoving this data into an external flash, what format should they be stored in?
Putting the data into 2D arrays wont save any space at all.
Right now, you're storing these values into your 2k of SRAM. Change these declarations to use the PROGMEM keyword, so they're stored where there's much more space.
Using the PROGMEM instructs the compiler to load this data into the flash portion of memory:
const PROGMEM uint8_t arr_foo[] = { 2, 5, 6, 8, 3 };
However the data needs to be accessed with a function call, you can't just use it directly.
for (byte k = 0; k < 5; k++)
{
uint8_t next_led = pgm_read_byte_near( arr_foo + k );
// Do something with next_led
}
If these arrays form a pattern of leds that should be lit, while the other ones are switched off, you could store the state of all leds in an uint16_t and have an array of those in PROGMEM. (As in Kingsley's answer)
If you're not familiar with HEX notation you could use the binary format.
const PROGMEM uint_16_t patterns[] = {
// BA9876543210 Led Pins
0b000101101100, //foo: 2, 5, 6, 8, 3
0b000010000010, //bar: 1, 7
0b111111001000, //baz: 6, 10, 9, 11, 7, 8, 3
// ...
};
I wonder about the order of your numbers, so I'm not sure if this guess is correct at all. So no more details how to work with this approach rigth now
Update
To me, your comments changed the intention of your question completely.
As I read it now, there's no need for a special kind of "name" data to identify an array. What you want seems to be just to pass different arrays around as function arguments.
This is usually done via pointers, and there are two things to note:
Most of the time, arrays "decay" to pointers automatically. That means that in most places an array variable can be used in place of a pointer. And a pointer can be used like an array.
An array in C does not carry any length information at runtime. The length of an array needs to be held/passed separately. Alternatively, you can define a struct (or class in C++) which contains both the array and its length as members.
Example:
If you want to pass an array of elements of type T to a function, you can declare the function to accept a pointer to T:
void somefunc(uint8_t* arr, uint8_t arrLength) {
for ( uint8_t i = 0; i < arrLength; i++ ) {
uint8_t value = arr[i];
value = *(arr+i); // equivalent to arr[i]
}
}
or equivalently
void somefunc(uint8_t arr[], uint8_t arrLength) {
...
}
then call that function by simply passing the array variable and the corresponding array's length, like
uint8_t arr_foo[] = { 1,2,3,4,5 };
uint8_t arr_bar[] = { 1,2 };
somefunc(arr_foo,5);
somefunc(arr_bar,2);
The arrays' constant data can be put into PROGMEM to save RAM, but, as others have noted, read accesses are a little more complex, requiring pgm_read_...() calls in C++. (AVR gcc does support __flash-qualified data only in C, not in C++.)
Then there's the issue of, I may still run out of memory at a later
time as more sequences are added.
Notice that the "Arduino" AVR has 32kb of flash memory. If each sequence consumes 15 bytes, it could probably still hold 1000 or 2000 of these items along with your program.
then what? Add an external i2c flash memory, and shove things in
there? Having never dealt with that, I'm not sure how to implement
that, in what format to store the values, and how to do it.
If you actually run out of flash at some point you can still resort to any form of external storage.
A common solution is SPI flash memory, which is readily available in the mega-bit range. Winbond is a well-known supplier. Just search for "Arduino SPI flash" modules and libraries.
A more complex approach would be to support SD cards as external memory. But probably not worth it unless you actually want to store gigabytes of data.
Am I correct that one has to first write a program that loads all the
data in memory, upload that and run it, then put the actual program
that's going to process that data on the micro controller?
That's definitely one way to do it. If your code space permits, you can alternatively include the routines to write to the external flash memory in your application, like some kind of bootloader so that you can switch into "upload external flash data" mode without re-flashing the microcontroller.
If I have the following code:
// objective C++ code .mm
id<MTLTexture> texture = ...;
void* ptr = (void*)CFBridgingRetain(texture);
share_ptr_with_native_code(ptr);
[texture do_stuff]; // is this valid?
// native code .cpp
void share_ptr_with_native(void* ptr)
{
ptr->do_stuff();
CFBridgingRelease(ptr);
}
Will texture be valid and retained by ARC again after the call to share_ptr_with_native()?
Other than various errors in your code snippet, yes, the line in question is valid. ARC continues to maintain its own strong reference to object while it's still in use in the top code, in addition to the one that you become responsible for. CFBridgingRetain() has a +1 effect on the retain count of the object, hence "retain" in its name.
Even everything said is right, it would be nicer if you change your
CFBridgingRelease(ptr);
to
CFRelease(ptr) .
__bridge_retained or CFBridgingRetain casts an Objective-C pointer to a Core Foundation pointer and also transfers ownership to you.
You are responsible for calling CFRelease or a related function to relinquish ownership of the object.
Taken from https://developer.apple.com/library/content/documentation/CoreFoundation/Conceptual/CFDesignConcepts/Articles/tollFreeBridgedTypes.html.
I am trying to implement the xlCalculationEnded event using xll sdk. Used XlEventRegister to register the same in my xll addin which is compiled as .xll file. Checked Steve Dalton's book on xll sdk and msdn , don't see any example or documentation on how to implement this event.
Tried googling , no luck.
Please provide an example if there is one.
Note: I have implemented udf which gives me selected range of data, but if there are Excel builtin or any other add-in related functions in the same range, I am not getting calculated values, rather it call udf before excel completes the calculation. That is the reason why I am trying to register the above call back which can give me info on Excel calculation.
I have just tested this code and it works , the event is fired at every calculation. I have just added an Event function and modifiy a bit :
1- Modify in xlAutoOpen(void)
Excel12f(xlEventRegister, 0, 2, (LPXLOPER12)TempStr12(rgFuncs[i][0]), TempInt12(xleventCalculationEnded));
to
Excel12f(xlEventRegister, 0, 2, (LPXLOPER12)TempStr12(L"EventOnCalc"), TempInt12(xleventCalculationEnded));
2- create the event function :
__declspec(dllexport) void WINAPI EventOnCalc()
{
Excel12f(xlcAlert, 0, 1, TempStr12(L"On Calc event !"));
}
I tested and the EventOnCalc() event is fired.
I try to code an OpenGL project with Qt (v5.1.1) on OS X 10.9, in the manner of the modern pipeline implementation. The program is supposed to be a multi-agent based system or particle system. However I lack in understanding how to draw something out of another class.
In cinder there were some simple drawThisAndThat() command you could call. I read the 6th edition of the 'OpenGL Superbible'. From this and several tutorials all examples seem to cover just programs where all modifications are made out of the class that initializes OpenGL.
I would like to instantiate some objects moving on a grid and draw pixel to display their position. I know I have to call void glVertexAttrib4fv(GLuint index, const GLfloat * vi); but this is not sufficient.
Do I need to call glEnableVertexAttribArray(1); and glDrawArrays(GL_POINTS, 0, 3); as well and what else?
Am I right, to instantiate the class controlling the particles after instantiating OpenGL and bevor the main loop?
How do I manage that the particle draws himself while erasing the position he was drawn bevor?
The program is based on this code.
To answer your questions completely I would have to write a wall of text, I will try to only point out the most important aspects. I hope this will help you enough to use your knowledge and probably further reading to get it to work.
all modifications are made out of the class that initializes OpenGL
You can encapsulate update(time) and draw() methods for your Objects which you then call in your main loop.
Do I need to call glEnableVertexAttribArray(1); and glDrawArrays(GL_POINTS, 0, 3); as well and what else?
I would put all particles into one vertex array to avoid rebinding of different vertex arrays after each particle. Then you would have to use glBindVertexArray(vaid); and glDrawArrays(GL_POINTS, 0, vertexCount); in your draw() call. Be careful with vertexCount, it's not the number of floats (as your question implies) but the number of vertices, which should be 1 in your example or the number of particles in my suggested approach (If I'm correct in assuming that the 3 stands for "x, y, and z of my vertex").
And since you only have particles glDrawElements(...); would probably already fit your needs.
Am I right, to instantiate the class controlling the particles after instantiating OpenGL and bevor the main loop?
Probably your instantiation order is correct that way. You definitely should do all instantiations before calling the main loop in your case.
How do I manage that the particle draws himself while erasing the position he was drawn bevor?
If understand your last question correctly: Simply by changing the elements in your buffer objects (glBufferData(...);). Since you will clear the screen and swap buffers after each loop this will make them move. Just update their position with an update(time) call, e.g. pos = pos + dir * time;, put the new positions into a buffer and push that buffer with glBufferData(...) to the vertex array. Remember to bind the vertex array before pushing the buffer.
Some additional things I'd like to point out.
glEnableVertexAttribArray(1); is to enable a vertex attribute in your shader program to be able to pass data to that attribute. You should create a shader program
id = glCreateProgram()
// ... create and attach shaders here
// then bind attribute locations, e.g. positionMC
glBindAttribLocation(id, 0, "positionMC");
glLinkProgram(id);
And after initializing the vertex array with glGenVertexArrays(); you should enable all attributes your vertex array needs in your shader program. In this example positionMC would be at location 0, so you would call something like
glUseProgram(pid);
glBindVertexArray(vaid);
glEnableVertexAttribArray(1);
glVertexAttribPointer(...);
This has only to be done once, since OpenGL stores the state for every particular vertex array. By rebinding a vertex array you will restore that state.
In the main loop all you have to do now is calling your update and draw methods, e.g.:
handleInputs();
update(deltaTime);
glClear(...);
draw();
swapBuffers();
I need to change to reference of a function in a mach-o binary to a custom function defined in my own dylib. The process I am now following is,
Replacing references to older functions to the new one. e.g _fopen to _mopen using sed.
I open the mach-o binary in MachOView to find the address of the entities I want to change. I then manually change the information in the binary using a hex editor.
Is there a way I can automate this process i.e write a program to read the symbols, and dynamic loading info and then change them in the executable. I was looking at the mach-o header files at /usr/include/mach-o but am not entire sure how to use them to get this information. Do there exist any libraries present - C or python which help do the same?
interesting question, I am trying to do something similar to static lib; see if this helps
varrunr - you can easily achieve most if not all of the functionality using DYLD's interposition. You create your own library, and declare your interposing functions, like so
// This is the expected interpose structure
typedef struct interpose_s {
void *new_func;
void *orig_func;
} interpose_t;
static const interpose_t interposing_functions[] \
__attribute__ ((section("__DATA, __interpose"))) = {
{ (void *)my_open, (void *) open }
};
.. and you just implement your open. In the interposing functions all references to the original will work - which makes this ideal for wrappers. And, you can insert your dylib forcefully using DYLD_INSERT_LIBRARIES (same principle as LD_PRELOAD on Linux).