Jump to content
Phishing Emails & YouTube Messages - Fake Giveaway Read more... ×
Search In
  • More options...
Find results that contain...
Find results in...


  • Content Count

  • Joined

  • Last visited


This user doesn't have any awards

1 Follower

About Unimportant

  • Title

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Unimportant

    Case air temp display, Pics + code

    Probably the Dallas DS1820 family (http://www.systronix.com/Resource/ds1820.pdf).
  2. Unimportant

    Arduino prog_char does not name a type

    Post the actual code in code tags in stead of a picture or link.
  3. Unimportant

    C++ array getting corrupt

    @fpo You're overusing references and using them in ways that are frowned upon. The most prominent use of references is to pass a expensive-to-copy object as read only. For example: //PlayAudioSample signature... void PlayAudioSample(const AudioSample& Sample); AudioSample TestSample("test.wav"); PlayAudioSample(TestSample); Here, AudioSample is a class that reads a wave file from disk and holds all the relevant data. The function PlayAudioSample plays back such samples. We don't want to needlessly copy a potentially expensive object just to play it back, so we pass by reference. PlayAudioSample also does not need to be able to modify the AudioSample (in fact, we want to protect ourselves from accidentally modifying it) so we pass as const reference. The second use of references should be if we want to modify the parameters that are passed, but only in intuitive ways. The standard library has a great example that goes something like this: void swap(T& a, T& b); That swaps the contents of a and b, that's pretty clear and concise and off course requires non-const references. However, in your code: tileData[tileDataIndex] = Interpret(ch, tileDataIndex, vectorIndex); I totally don't expect the Interpret function to go and start messing with tileDataIndex and vectorIndex, that's just a huge code smell. More particularly you should not be micromanaging a function's local variables in a subfunction. It's a huge indication of poor program structure and it's the primary reason you're getting into trouble here. I'm having a hard time following your code and I've been doing this for decades. What is it you're trying to do *exactly* and perhaps we could show you a proper example to pick apart. On a sidenote: Read up about "const correctness" and start applying it rigorously, it'll come back to bite you in the ass if you don't. Trust me, retrofitting existing code for const correctness is a nightmare, and your code won't play well with someone else's code that has const correctness otherwise.
  4. Unimportant

    C++ array getting corrupt

    C++ supports references, which allow passing objects by reference without pointer syntax: void Foo(int& i) { i = 1337; } //... int a = 101; Foo(a); //a now equals 1337
  5. Unimportant

    Battery that is 200V+ (18650 cells)

    Agree on using a lower voltage and boosting it. The main practical reason would be that a fully charged Li-ion cell is about 4.2V, while the cut-off voltage for a drained cell is around 3V. So, if you were to put 48 cells in series to get about 202V when fully charged, the voltage would drop during use to about 144V before you'd consider the pack to be depleted. If you use 67 cells to stay above 200V even when drained, it would be at 281V when fully charged. Such a large range is impractical to work with in most cases. The boost converter approach would naturally include regulation which provides a steady output voltage.
  6. Unimportant

    Buying nVidia stock?

    A whole lot of stocks, across different industries, look a whole lot like NVDA with a large upside acceleration in price the last couple of years that is now collapsing. This has very little to do with the actual value of those companies rather then with FED policy. Interest rates had been kept close to 0 for 8 years or so and QE programs have made the FED's balance sheet explode. They have been raising rates slowly for a while now and a balance sheet reduction program (QT) is in place now, and it is starting to bite (in many areas). Last week the FED, taking notice of the fact that it's bubble has been popping, has taken QT off of auto pilot and taken a more dovish stance, making some think that the Powell put is now in place. So, to recap, in my view: The massive run up in nvidia stock, just like many other stocks, is part of a FED easy money bubble, which is deflating because the FED is slowly taking the cheap money away. If you believe the FED will come to the rescue and slash rates again/more QE *AND* you believe they can re-inflate the same bubble twice - buy nvidia stock, otherwise, run for the hills. DISCLAIMER: Personal view, not investment advice, you're responsible for your own trades.
  7. Unimportant

    text editor for c++?

    I'm particularly fond of the editor in Qt Creator, which can off course be used also for non Qt projects.
  8. Unimportant

    Multi-Threading C++ & OpenGL

    Use threads to divvy up the workload and compose the data that should be sent to OpenGL but only have a single thread (the one that opened the OpenGL context) handle the calls to OpenGL. Also consider that the error might be in your code, not necessarily anything to do with OpenGL, are you sure you don't have any data races? atomicity issues ? OOE problems that break naive mutex attempts?, etc...
  9. Unimportant

    C++ (premature) optimization

    They're functionally different. The first one stores a copy of the value in 'i' to private integer variable 'x'. Each instance of 'CustomC' will have it's own independent 'x' variable. The second example stores a pointer to 'i' to private integer pointer 'x'. All instances of 'CustomC' will have their 'x' point to the same 'i'. If the value of 'i' changes, all instances of 'CustomC' see the change, which is in nearly all cases definitely not what you want. It defeats the purpose of OOP. In fact, you should not be using global variables to begin with, 'i' should not exist. The proper way is to have each instance have it's own 'x', and initialize trough the constructor: class CustomC { public: CustomC(int x) : m_x(x) {} private: int m_x; } You should not worry about performance for native types. Copying is cheap and native types are small, don't go writing broken code to save a 4 byte copy. If you're really *really* sure you want 'x' to be shared among all instances of 'CustomC', and accept all the dangers that come with it then you can make it static: #include <iostream> class CustomC { public: void PrintX() const { std::cout << m_x << '\n'; } static void SetX(int x) { m_x = x; } private: static int m_x; }; //ODR & init int CustomC::m_x = 0; int main() { CustomC Instance1; CustomC Instance2; Instance1.PrintX(); Instance1.SetX(1337); Instance2.PrintX(); return 0; }
  10. Depends on the application. What's it for?
  11. Unimportant

    DIY fan controller with Arduino

    @Olaf6541 So you've made 'CounterA' and 'CounterB' volatile, that's good, but you didn't do anything about the atomicity issue. A single line of C code such as "rpmA = counterA * 30" can result in a whole lot of assembly instructions, especially something like multiplying a multi-byte variable on a tiny 8-bit micro-controller. So this seemingly simple action could result in tens or hundreds of machine instructions. Ask yourself what happens when a interrupt occurs just when the controller is busy with this multiplication. The controller is busy working with 'counterA' or 'counterB', doing god knows what with it under the hood. So during the operation those variables could be in a invalid intermediate state, and then the interrupt code starts messing with it at the same time. Such operations that are not completed in a single cycle and thus some asynchronous code could see things in a invalid intermediate state are called "non-atomic" operations. You should guard against those. In this case a possible solution could be: disable interrupts Copy counterA and counterB to temporary variables such as copyCounterA and copyCounterB. Since interrupts are disabled this non-atomic copy won't be interrupted. Clear counterA and counterB. re-enable interrupts. do the multiplication with copyCounterA and copyCounterB. Leave counterA and counterB alone while interrupts are enabled. Furthermore I'd try greatly simplifying the code for testing purposes, remove all that complex math and just control the fan manually (with a RPM+ and RPM- button for example) and then check if your pulses are coming in as they should. In the same vein as before, when you write something like: You should realize this too will probably result in many hundreds or even thousands of machine instructions. The AVR is a microcontroller, not a maths processor. It has to emulate floating point in software (so get rid of it, you can avoid floating point in nearly all cases), and functions like log and exp are also tough on the little thing. Add some slow serial comm's on top of that and you could easily be missing events because your seemingly simple C code is in fact bogging the AVR down.
  12. Unimportant

    Generating a set amount of prime numbers (C++)

    @toobladink Something along these lines perhaps? bool is_prime(int num) { if (num == 2) { return true; } if (num > 1 && num % 2) { for (int i = 3; i < num; i += 2) { if (!(num % i)) { return false; } } return true; } else { return false; } }
  13. Unimportant

    DIY fan controller with Arduino

    Can you post the code you wrote for this aswell ? So we can check if it does not contain any of the same atomicity errors. This is really the part where you ought to get a 'scope. Even an cheap, fourth hand, ancient analog scope would be better then shooting in the dark. (Don't be tempted to buy one of those toy ebay kits tough).
  14. Unimportant

    Generating a set amount of prime numbers (C++)

    The code as presented also never initializes P before passing it to calcPrime.
  15. Unimportant

    DIY fan controller with Arduino

    You should put guards in place such as a mutex or semaphore to guard against interrupts interfering with non-atomic operations on 'counterA' and 'counterB'. Heisenbugs like you're describing are text-book examples of race conditions.