|
So now senior devs will have to debug all of the incorrect suggestions accepted by the nube devs.(?)
Been there before…was happy when the nube decided to change groups. Eclipse has had good completion help for a long time, but many times, none of the suggestions are suitable! The nube tried to code EVERYTHING by choosing one of the suggestions.
|
|
|
|
|
Having autocomplete doesn't absolve you of the need to think about what you do.
From what I see, C# knows pretty well when to suggest something and when not to.
And when it does, you still need to check if <= was needed instead of < etc
|
|
|
|
|
Hi all,
I'm interested in getting a GPU to help CPAI detect objects (from Blue Iris) as fast as possible. Are there any GPU's that I should focus on or avoid? I'm hoping to do this as low power as possible too. I've got about 16 cameras, from 1080 to 4k. My PC is pretty overkill for just BI (i7 9700, 32bg ram), but it's not the fastest for object detection. Thank you for any help and a big thank you to the devs!
|
|
|
|
|
I would stick to NVidia cards. AMD/ATI GPUs apparently don't work with some AI things.
Edit: Adding, for a 9th gen i7 I wouldn't bother with a 4-series card as your bus and CPU aren't going to keep up with say, a 4080 anyway. Get something like a 3080 TI. Plenty of power for what you're doing without throwing more GPU at your system than it can handle.
To err is human. Fortune favors the monsters.
modified 18-Apr-23 13:02pm.
|
|
|
|
|
The autocompletion is really impressing, but I would never accept a suggestion without using my own brain
|
|
|
|
|
what?
To err is human. Fortune favors the monsters.
|
|
|
|
|
Sorry, it seems my answer landed in the wrong thread. (somewhat embarrassed)
|
|
|
|
|
No worries!
There's smoke in my iris
But I painted a sunny day on the insides of my eyelids
So I'm ready now (What you ready for?)
I'm ready for life in this city
And my wings have grown almost enough to lift me
|
|
|
|
|
|
|
RedDk wrote: This is the .. uhm uh . wordle forum.
Word!
|
|
|
|
|
Get more servers. Less tangle too.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
|
You are right. I like it. The second half guitar (Clapton/Hendricks sound) makes is.
Let me add Pete Hamm
"A little time, a little trouble, your better day"
Badfinger
modified 20-Apr-23 23:12pm.
|
|
|
|
|
My little consortium of embedded developers is looking to move our offerings over to the ARM Cortex M line of processors. One of the big primary drivers of this, is lack of availability of LCD displays for the more hobbyist/Arduino type end of things.
The first issue we've had is an utter lack of toolchain, bootloader firmware, HAL code, or really anything to get us going starting with a bare metal chip.
I discovered keil.com which can potentially get us over that hump, if we can afford it. I'm always a little anxious when getting a price requires a quote.
Waiting to hear from them, but I also am still out of my depth.
I know there are some embedded developers here. I'm not afraid of failure, and I'm not afraid to get my hands dirty. Any advice as far as this move goes would be appreciated.
It's definitely the deep end of the pool for me.
To err is human. Fortune favors the monsters.
|
|
|
|
|
A couple of ideas:
- See if someone produces a Linux version for your target chip
- See if Google has a default cross-build toolchain and environment for Android on the ARM Cortex M
Using Google's stuff has the advantage that it's used to produce the Android builds, so it is reasonably certain to be bug free (ha ha).
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Thanks!
To err is human. Fortune favors the monsters.
|
|
|
|
|
armbian make builds for most linux based ARM SBC's
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
After poking around at that site, I've already learned quite a bit, and am falling down this particular rabbit hole with gusto.
A $30 ARM Cortex M that runs linux? That alone was worth following the link.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Glad it helped - I’ve been messing around with ARM SBC boards for years
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
If you go with STMicroelectroincs there's the STM32CubeIDE, otherwise Keil is you IDE and I haven't priced it but I don't think it will be very cheap. STM also has a very competent HAL with a GUI that makes it a snap to configure.
As for programmers there's J-Link by Seggar[^]
J-Link is an all around programmer, I believe it does quite a few families of chips.
Again if you go with STM there is the ST-Link programmers and they are way less expensive.
I moved from Arduino to ARM and haven't looked back.
Give me coffee to change the things I can and wine for those I can not!
PartsBin an Electronics Part Organizer - An updated version available! JaxCoder.com
Latest Article: Simon Says, A Child's Game
|
|
|
|
|
I don't know what you're used to but Keil makes VisualStudio 6 look futuristic. STMCube is much more powerful though I found it unreliable and very slow and heavy. Depending on the platform Keil can also end up supporting only 2 breakpoints at any given time, unless you hardcode them in with BKPT, which makes debugging tricky.
I suggest you to look up the EventRecorder functionality for keil, it should work on any supported device and it's a godsend for tracing and debugging (this could be a good topic for an article, note to self).
On the other hand keil is quite lightweight and fast, the compilation error messages are also quite explicative. The uLink programmers may be finicky and require multiple tries to correctly set up the reset type for debugging (I always have best results with "connect with Pre-Reset").
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
This is from a few years ago so things may have changed.
STM provides a number of development boards with their own built in debug chip which sort of simulates JTAG functionality. Oddly enough they don't support ( or didn't support ) the debug capability on all of their development boards. So I ended up with a cortex M4 board for which there was no debug support.
Oddly enough I found a suitable driver for the STM debug chip on Segger's web site so that it was possible to debug stuff on that particular development board.
It is too long ago to remember the details but I have all of those details in a backup location which I could lookup if you want.
If my memory does not betray me I think I got it working with VSCODE, the segger driver and the gcc compiler toolchain.
|
|
|
|
|
I have the impression that you might have been avoiding vscode. I might be wrong! vscode is 100% unrelated to Visual Studio.
I suggest you take a peek at: GitHub - Marus/cortex-debug[^] 5.0 ratings [as here] are extremely rare in the vscode plugin "store".
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
nah, I use VS Code every day, but I don't have a toolchain for targeting say, an ARM Cortex M7 or whatever.
To err is human. Fortune favors the monsters.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
