Your sensor maybe need a bit of delay, others don't. Provide as much info as you can, it's in your best interest.įor the fix you've made - we do not include delay for the specific cases in our libraries. So without the whole code, it's hard to tell. You mask the number first and compare it with the 0, afterwards. It turned out it's a bit mask - so in that case, one & is ok. So let's get back to your code: from the small fragment of your code, I couldn't tell what RX_EMPTY is in your example, I was thinking it's a variable you wanted to compare with. You can run into a bug or two, but I do not agree that the libraries are "full of errors", many of our modules would not work, in that case. So, it's understandable that minor bugs can sometimes slip through.
And we need to rewrite the code for all of those devices to work with our compilers, make libraries for them - for our users to be able to use just a few simple commands. everything you can imagine is here, I think. You have to bear in mind that we have a vast amounts of MPUs, sensors, devices. Sometimes we do get valid reports and we enter them in our bug database, which gets fixed as the time comes to deal with the specific product. We, as the support team, do our best to inform the developers of the faults in the libraries, so they can correct them, but you'd be surprised how often it's the user's error something doesn't work. Scrolling displays, 8x8 LEDs, 64圆4 LED matrices,all kinds of accels, hal effect sensors. We have many devices and sensors which extensively use the SPI and they work like a clockwork. Well I have to say that if the SPI was faulty, nothing we have would ever work. i found all the problems and the f thing is those are not problem from programmers, no, they have wrote everything but for their hardware, i did fix them just changing the numbers in the library's. your libraries should be able to be customize with user needs. Not that they don't work, no, they work, but with errors, or better i say, you don't even know what they do ! you have a large gap beatwin support department and your programmers. your answers half the times are solving nothing.įor example : why FRC with PLL doesn't work correctly in pic32 v4? don't get me started with your libraries about tft. an you are way behind in support for micro-controllers, for all pic microcontrollers. you don't fix them in time, for example, after 3 years you realest a new version for pic32. If you check my posts you will see how many problems i have found with your libraries. and don't forget how hard programming is with that compiler.īut it almost has no problem with compiling and original libraries.
and worst is that the drivers are only working for their own boards and i cant use it, or change it for my boards. the thing is when i use that, i have to pay for every possible thing i need. if you want to know what is expensive, i suggest try that thing ! that is really expensive.
i have the mplab pro xc32 from microchip too. everything in here (softwares) are almost free ! it is no price at all.
but full of error! what good is a library if it has lot of problem. and the best is all of them are for every pic. You have the largest usable library's possible for it. Now let me tell you first, your compiler is great, not for itself ! but because of the things the company provided for users.
now i am trying to use all of its potentials, but getting problems with the compiler. Now i finished it, it is working just fine, i solved alot of problems with it.
I am putting some good help point here for anyone has problem with it too: those codes work with this compilers and i have them: not even the original code from northwestern itself. the f part was that no code works with mickro c compiler. for the datasheet i have to say, please ! i am almost merged with the pic32mx4xx datasheet ! and for 3 weeks i have read everything i found about nrf24. I am trying to connect 2 nrf24l01+ together with pic32.