Microchip ICD4 ?

Any folks using this ICD4?

Cheers

Reply to
Martin Riddle
Loading thread data ...

Have they started shipping them? I think they launch this week.

Reply to
DemonicTubes

Maybe, I see some of the documentation is dated 8/10/17. So you could be right, too early to get an opinion. I was going to get a ICD3, but I saw the 4 and did a double take.

Cheers

Reply to
Martin Riddle

I hope nobody's still writing uP code in asm in the year 2k17.

Reply to
bitrex

I do, assembler is the best!

With a good suite of macros can do anything better than them darn annoying "high level" languages claim.

piglet

Reply to
piglet

Still gotta know asm to debug some times.

Reply to
boB

suite of macros, i.e. you have made your own high-level language ...

Reply to
Lasse Langwadt Christensen

I have often thought of Forth as a macro assembler on steroids. Mecrisp is being given optimizations that get it even closer to working in assembler in terms of speed and code size. Have you ever looked at it?

--

Rick C
Reply to
rickman

Lasse Langwadt Christensen wrote on 8/17/2017 5:23 PM:

More like a library. Heck, there is nothing to stop you from using a macro to call a C library. But it's still not a HLL.

--

Rick C
Reply to
rickman

My contention is that well-written modern C++1x will destroy any handwritten asm or compiled-Forth "macro assembler" program on both execution speed and code size for any nontrivial general computing task in all but the most extreme edge-cases, even on say AVR 8 bit devices.

There should be a contest! ;-)

Reply to
bitrex

You are probably right. A few years ago I programmed an 8bit AVR in ASM for R&D. Going to production, my programmer re-wrote it in C++...I told him my version would be faster and use less flash...turned out I was wrong.

Still use ASM sometimes though.

Reply to
DemonicTubes

What *is* C++1x and why do you think it would be faster than other compiled languages?

--

Rick C
Reply to
rickman

I got one a couple days ago. Pretty heavy, you could probably play hockey with it.

The support list is not complete yet. Eventually it should handle the ex-Atmel stuff.

--sp

Reply to
speff

You also get to spend less time fiddling with in-circuit debuggers, as for lots of stuff not directly involving I/O you can make a unit-test harness for x86 and debug/test code directly for an x86 desktop target, and then cross-compile for the embedded architecture at least secure in the knowledge that you're using code that is otherwise functionally correct

Reply to
bitrex

You would use an ICD4 if you are writing code for the Microchip family in C.. it's the flash programming/debug pod, analogous to a J-Link or U-link.

--sp

Reply to
speff

Why not, personally I believe that hand wrtten assembly will murder any modern C++1x, so here is my challenge.

A human-visible Blinky with the smallest binary size, and without strange electrical states on other pins. A 'Blinky" blinks a LED around once a second but may be faster or slower as long as it's clearly 'blinking' to a human.

The targets: MCU | Assembly binary size to beat so far:

1) STM32F051 Discovery | 32 bytes 2) MSP340 | 14 bytes

Note: The binary sizes above were above hand crafted by Matthias Koch, author of Mecrisp, Mecrisp-Stellaris, Mecrisp-Across and many other programs.

A personal note, my own efforts are tabled below, both are boring, no shortcut tutorial Blinkies: Assembly STM32F051 Discovery Blinky: 84 bytes. GCC STM32F051 Discovery Blinky: 312 bytes.

Cheers, Terry

--
Mecrisp-Stellaris Unofficial User Doc: http://128.199.141.78/index.html
Reply to
Terry Porter

I did handwavy-qualify my statement to "nontrivial" tasks. I'd consider blinking an LED "trivial" and wouldn't doubt asm could beat a compiled language on that one. YMMV.

312 bytes for GCC on that target seems gigantic, regardless. That was with the -Os size flag, yeah?
Reply to
bitrex

Did all of the numbers above include the required startup code? Or is this just for the binary to actually blink the LED, say the equivalent of "main"?

If Mathias coded this, did he also code it in Forth? He is working on a new system that can run on a "host" and generate code to run on a target MSP430. He hasn't even thought about an ARM version yet.

--

Rick C
Reply to
rickman

Check it out, here's Pong for the Commodore 64/6502 entirely in C++17, smooshed down to 1005 bytes, including sprite resources. Not even with the 6502 as a native target but translated from an x86 binary.

Reply to
bitrex

C++1x = C++11, C++14, and C++17, three consecutive versions of the C++ standard. C++11 had large additions/changes over earlier versions, that enabled various significant optimizations. C++14 and C++17 add comparatively smaller tweaks to C++11.

C++ will likely beat handwritten assembler for any sizeable program, because of the insane effort it would take to write and the maintain the asm code with the crazy contorted optimizations that the compiler puts in. But, for a small tight loop where the human is willing to put in enough effort per instruction, the human can still beat the compiler.

See:

formatting link

Reply to
Paul Rubin

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.