|
They have another IDE called CLion that's basically just a customised/simplified IntelliJ - It's much better than Visual Studio, but I don't really know how it stacks up compared to other C++ Editors.
|
|
|
|
|
I know quite a few people who rate it - never tried it myself, mind!
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Cp-Coder wrote: String.valueOf(o[1]).toLowerCase()
Nit-picking: Depending on your data, you should normalize strings to upper-case, to avoid the "Turkish i" problem. 
The Turkish İ Problem and Why You Should Care | You’ve Been Haacked[^]
(The article is about .NET, but the problem will affect other languages as well.)
In .NET, it's better to pass in a case-insensitive StringComparisonOptions or StringComparer rather than changing the case of the string, so that you don't have to create a new string for every comparison. I don't know whether Java has anything similar, or suffers from the same problem.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
That article should be bookmarked on every new developer's PC
|
|
|
|
|
Richard Deeming wrote: In .NET, it's better to pass in a case-insensitive StringComparisonOptions or StringComparer rather than changing the case of the string
|
|
|
|
|
I have a case-insensitive string comparison function in C++. But it normalizes to lower case, so I'll have to read that article. I know that Turkish has an undotted i, but it'll be interesting to learn why that creates a problem.
|
|
|
|
|
Kind of mandatory[^]
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I've asked about this before but now I have a better idea of what I need, so maybe I can ask a better question and get better answers.
I have had no luck getting SPI reads to work on an ESP32 line (basically the MISO line is useless to me)
I need a logic probe that will help me monitor SPI traffic on 3 or 4 lines up to 10MHz total bus speed (that means 3 or 4 million frames per second total of logging or buffer)
The problem I've had with my current probe is there's just not enough buffer and it doesn't do real time logging to the PC (i don't know that any of them can though) - everything goes by too fast so by the time i hit record it's too late, or it's way too early.
What I'd like is a probe that can capture 2-4 million frames, and preferably one that can be programmed to start capturing when one of the lines goes high or low. The last bit is critical because of my current problem.
I know a lot of them including my current one have an API and i can write software to start logging on high or low but I don't want to have to write code.
So any you hardware hackers, do you do this kind of thing? Do you understand the above? And is there a tool that will work this magic?
Real programmers use butterflies
|
|
|
|
|
I don't know if you've taken a look at the Logic Analyzers from Saleae - #1 with Professional Engineers[^]. The Logic 8 supports digital signals up to 25MHz and the Logic Pro 8 supports up to 100MHz if using USB3.0.
I know they're not cheap, $399 for the Logic 8, $699 for the Logic Pro 8 and $999 for the Logic Pro 16.
I have an older model (bought it back in 2014) and it works pretty good.
Kelly Herald
Software Developer
|
|
|
|
|
Thanks. I sent a link to them to my client, who is looking at purchasing one for me on my behalf.
I saved him a ton of money on a computer purchase so I think he's trying to return the favor. 
Real programmers use butterflies
|
|
|
|
|
For SPI debugging the OP may be better off with a scope with the ability to decode SPI and other serial formats.
The reason being that bugs with SPI, I2C, RS232 etc are often to do with bad signals which a logic analyser will not show.
The Picoscope range includes multi channel scopes, some with built in logic analysers and some with very large sample buffers at prices from about £150 to £10k.
I have a range of scopes available but the Pico is my first choice device for this sort of work.
www.picotech.com
MK
|
|
|
|
|
was going to suggest the same thing.... salae make very good products.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
I've had a Saleae LA for many years and it's the best investment I've ever made.
It decodes SPI, I2C, Serial, etc.
The lines can be configured.
Can Trigger on rising, falling, etc.
Collection speed and duration can be configured.
Awesome GUI
Used to be a lot cheaper but I've noticed lately that they are a little pricey...but I would still recommend 9if you can afford.
|
|
|
|
|
It looks like these are the ticket for me. Pricy gizmos but they come recommended by several folks.
Real programmers use butterflies
|
|
|
|
|
You can download the GUI and if no device attached it runs sample data so you can see what it's capable of. Kick the tires so to speak.
|
|
|
|
|
|
Another vote for the Salae. I use one for hardware and interrupt timing debug. Absolutely essential. I recently 'race tuned' (well, raceish) an ESP32 to PI SPI interface and literally could not have done that without the device. The pro version also has an analog mode, which, while not perfect, is good enough to deduce some quite subtle hardware/software interactions. I found running the device on a separate PC from my debug system was essential in that instance. It is expensive but has survived much abuse. Divide the cost by the hours I've saved has avoided me working for sub-Maccas hourly rates on a couple of projects.
|
|
|
|
|
A client is buying me a saleae Logic 8 Pro (in red)
I am elated. That's more than the cost of a decent laptop, and it's money I don't need to spend.
Real programmers use butterflies
|
|
|
|
|
The cost is insignificant compared to the cost of a couple hundred engineering hours to develop your own program to do these kind of things. Where I work we have no problem spending a few hundred bucks on a third-party hardware or software that could take 100, 200, 500 hours to do in-house. If you figure 100 bucks an hour personnel cost, spending 100 hours on something costs 10,000 dollars. Purchasing frees us up to do things that we need to do. Anyway, engineering hours for a project are budgeted separately from purchases. The shell game.
|
|
|
|
|
I recognize that. It's still nice not having to spend $700 of my own money for it.
Real programmers use butterflies
|
|
|
|
|
Yeah, always use OPM.
|
|
|
|
|
Just making sure the most obvious question gets asked, did you try a different ESP32? No amount of analysis will get you past a fried port. It happens.
|
|
|
|
|
I can't with this particular display since it's the only ILI9341 I have and it's embedded on the esp-wrover-kit.
However, due to that, a fried port is extremely unlikely. It has never been plugged into any device that wasn't already integrated into the devboard.
I'm getting a second ILI9341 today or tomorrow and I'm going to hook a logic probe up to it when I get one next week or so.
Real programmers use butterflies
|
|
|
|
|
You say you are having trouble reading the data from SPI. DO you have a basic understanding of SPI?
To shorten the process in case the answer is no, I am going to take a wild guess that you may not be aware that in order to read 16 bits of data, you first have to clear your input buffer (may or may not be necessary), write 16 bits of either good data or just 16 bits of zeros. That write of 16 bits will force your device to spit out 16 bits of data onto MISO. Only *then* you can read the 16 bits of real data from your device. Same applies whether you are reading 16 bits of data, or 8 bits, or 24 bits, etc.
There is another issue with SPI. It comes in 4 flavors. It depends on the device you are trying to read/write. I once had an issue where the HW engineer didn't realize he had put a type 1 and a type 3 device on the same SPI bus. It has to do with when the data is valid and the edge of the clock where the data is valid. You can't put a type one and a type 3 on the same bus unless you change the mode at the Master for *every* transaction 
Just trying to preemptively point you at possible problems based on not enough information in your post. Hope this helps. Feel free to IM me. I am one of those weird HW guys who also is a heavy duty embedded SW guy.
You could build your own logic analyser given enough time using a TI MSP432E launchpad or a Tiva 1294 Launchpad. Then you could transfer the data to a PC logger that would gather the data and store it. A lot of work but it would let you control what gets stored. A real logic analyser is a better bet though in terms of the time spent.
|
|
|
|
|
Yeah I know that much about SPI. I'm doing a dummy read, and it isn't helping. Worse, I found my results are inconsistent, after awhile I start getting 0xFFFF back instead of 0x0000 and when I plot this stuff it looks like a zebra pattern so it has something to do with the bus/timing/dummy bits, or something else. I need my good logic analyzer to arrive. I'm not looking to build one. I have a junky one right now, but I want the saleae before i much about too much.
Real programmers use butterflies
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
