Is Faster Better?

Go To Last Post
40 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

grohote wrote:

... but why to wait 30 seconds /or more/ for any programming? Next step was a logical and normal: JTAGICE MKII which can shrink 30s to 2s...

 

grohote wrote:

One day you may realize that some devices, and some tools are just... better.

 

 

Is faster better though? Doesn't the whole 'click and it's compiled' method simply remove thinking time? Time which would be better spent thinking about the problem rather than throwing a few random changes into the code?

 

How often do we see code on here which is, frankly, a pile of rubbish? Code which has been throw together with no thought? Code which evolves with no thought? Random modifications in some desperate attempt to solve a problem?

 

Like a lot of people here, I started writing microcontroller code when a compile/link cycle would take minutes. Long enough to walk to the coffee machine and back. Time to think through your next steps. And you know what? I'll bet we were just as productive as people are today with their instant results.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'll bet we were just as productive as people are today with their instant results.

Maybe you even experienced punch cards.  Those undertakings really required some serious thinking and checking of what you were doing, since you didn't want to go through 100 cycles (and elevator rides to the card submission center) to get things right.   Sometimes having it too easy invites apathy rather than using the efficiency boost to make things more bullet-proof.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:
How often do we see code on here which is, frankly, a pile of rubbish?

True - but the reason for that bad code is certainly NOT the ability to compile and flash the device within 2s.

 

PS: Aren't default programming speeds set fairly conservatively to comply with default clocking on new devices. Once you've programmed the fuses once (for external xtal or to remove the divide 8) the speed could be increased substantially.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is faster better though?

 

The question is irrelevant. The speed can not replace the quality of the code, but the speedy programmer can help a lot. Nothing is that good as a solid desk check with a pleasure of great thinking. Start - think - stop - program. How often - sometimes, it takes time. Which is important, after all. You can not create ultimate code by using PonyProg or similar. Also, even the best toll, which JTAG is, can not help you with complicated spaghetti code (which careless ASM tends to be).

 

Given time, your JTAGICE MKII will be less and less debugger, I can assure you.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

N.Winterbottom wrote:
PS: Aren't default programming speeds set fairly conservatively to comply with default clocking on new devices.
Programming speed is usually dependent on the nonvolatile memory controller.

N.Winterbottom wrote:
Once you've programmed the fuses once (for external xtal or to remove the divide 8) the speed could be increased substantially.
A rule is to use the same tools that an operator does (loader and bootloader)

Reason : Defect discovery by more operator-hours

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

grohote wrote:
The speed can not replace the quality of the code,
Can allocate some of the tool's compute power for static analysis though have to deal with the equivalent of Guru Meditation numbers (false positives)

grohote wrote:
Nothing is that good as a solid desk check with a pleasure of great thinking.
Code review is one of the best practices that's multiplied (others review in addition to self review)

grohote wrote:
Given time, your JTAGICE MKII will be less and less debugger, I can assure you.
Concur

 


Tips on speeding up PVS-Studio

Use a multi-core computer with a large amount of memory

[last sentence]

We recommend that you use a computer with four cores and eight Gbytes of memory or better.

 

Firmware Update v18.03 | Barr Group

[3/4 page]

The State of Embedded Systems Safety

 

Adding Automatic Debugging to Firmware for Embedded Systems by Jack Ganssle

codeql/UseOfAssertionsDensity.ql at main · github/codeql · GitHub

CodeQL is a zero price static analyzer with the cost in the creation of the rules set.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Speed is helpful but its not everything. Certainly, speed does not substitute for thinking.

 

When programming speeds were minutes (and there was no debugger), I compiled and tested sparingly. Now, with program load times in the range of seconds, I do many incremental build-and-test operations. I find that development time is a LOT faster because testing a few dozen lines is so much easier than testing a few hundred (and trying to figure out where the error(s) might be). This style only makes sense when the programming overhead is not so big but it does not have to be zero!

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
When programming speeds were minutes (and there was no debugger), I compiled and tested sparingly. Now, with program load times in the range of seconds

 

If you allow 10ms for a flash page-write to complete you are talking about 512 * 10ms for an ATmega1284.   i.e. 5 seconds.

Most of the "programming time" is spent in USB / Serial data traffic and writing the SPI / JTAG commands.

 

The old AT90Sxxx chips took a LONG time to program the flash.   Obviously the same amount of USB / Serial traffic.

The AT90S chips became obsolete when the Mega and Tiny chips appeared in the early 2000s.

 

Nowadays people use proper programmers.   In the early days LPT and RS232 port abortions were common.

 

All the same.   I am guilty of program first / think later.   In the days of UV EPROM you had to think !!

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:
Is faster better though?

Not according to my wife it's not.....   Oh wait you were talking about programming time, sorry!

 

Well I can remember a time where it took almost an hour for my 6800 to boot up from a cassette tape before I could even think about starting to load up the first program in basic!

Then basic in ROM came along and thought I had died, then came floppy disks, not as fast but so much better....  

Then there was DOS(Flex) and all those silly command line screwy words to remember, it's so much better now, with a drop down menu and a click of the mouse button....

Not going back, no, not again....

 

Spent one summer tuning a VAX for better operation, all I heard from the programmers was they no longer had time to fetch a cup of coffee after submitting their code to batch for compiling, too fast they said.....  Now they HAD to be productive...

 

I'm retiring at the end of this week, more time to spend with family and some travel, I'll try to poke my head in, on occasion to see what's happening, I've enjoyed this forum very much, a great gang of Freaks it is!

 

Fly over Jim

 

 

FF = PI > S.E.T

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
I can remember a time where it took almost an hour

 

... or a day, guess.

 

Looong ago (I was very young), an friend of mine designed and built his 8080 computer intended to help with EME on 432Mhz. It worked after a few corrections. EME, too (with 1kW lighthouse tube and lot of Yagis).

 

Memory was 2704, to correct something there was an UV lamp first... but the team managed it, eventually.

 

I do not know full details how they did it, in times before of PC... suppose 10 (?) switches for addr, 8 for data... a lot of thinking, desk check, team works... much longer than 2s.

Last Edited: Mon. May 9, 2022 - 06:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
I'm retiring at the end of this week, more time to spend with family and some travel,
Congratulations! ... and may you be in joy!

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
Well I can remember a time where it took almost an hour for my 6800 to boot up from a cassette tape before I could even think about starting to load up the first program in basic!
Was thankful for the bootloader on an 1802.

Byte-1987-07-IDX-175.pdf

[middle of second column]

Taking the bugs out.

First, AVSIM software simulator/debuggers allow you to test program modules on your PC. No special hardware is required for executing your target code interpretively in a crash- proof, interactive environment. AVSIM's full screen display lets you see at a glance what your program is doing.

 

...

 

Avocet Systems

...

fyi, 349USD-'87 is 883USD.

 


Philae | AVR Freaks

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
I'm retiring at the end of this week, more time to spend with family and some travel, I'll try to poke my head in, on occasion to see what's happening, I've enjoyed this forum very much, a great gang of Freaks it is!
Congratulations Jim and very best wishes for a long and enjoyable retirement. Don't be a stranger.

 

Cheers,

 

Ross

Ross McKenzie, Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

Was thankful for the bootloader on an 1802.

wasn't really a bootloader - rather  a very basic DMA controller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mask-programmable ROM in CDP1804; custom die CDP1802 had a small ROM (256-byte IIRC)

COSMAC ELF

The CDP1802’s Place in Microcomputing History

cdp1804.pdf

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
custom die CDP1802 had a small ROM (256-byte IIRC)
Yeah but the "raw" Cosmac1802, which I had on the very first computer I ever owned, had no bootloader.

 

I began to doubt my memory but I just checked:

 

https://de-wikibrief-org.transla...

 

A unique feature of the ELF is that it did not require read-only memory (ROM) to boot. instead, the processor's Direct Memory Access (DMA) system was used to read front panel switches directly into memory.

The DMA controller also provides a special "load mode" that allows memory to be loaded while the processor's CLEAR and WAIT inputs are active. This allows a program to be loaded without the need for a ROM-based bootstrap loader. This was used by the COSMAC Elf microcomputer and its successors to load a program from toggle switches or a hexadecimal keyboard with no required software and minimal hardware. The user could simply set the switches to the next value, toggle the read, and then move on. It was not necessary to change the addresses, this was done automatically by DMA stepping.

 

(BTW the board I had was not a COSMA-ELF but it was very similar - it just had a hex keypad and a "latch" button plus two 7 segs. You would type a hex pair which would then be visible in the two 7-seg then when you pressed the latch button it would toggle the DMA to pass the latched value into the next byte of the 256 byte RAM. Another button was "run" and it would then execute what you had loaded.

 

But there was no ROM and the chip did not contain a "bootloader" as such (unless you consider the hardware gates that implemented the DMA part to be a hard wired bootloader in silicon?)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
...did not contain a "bootloader" as such (unless you consider the hardware gates that implemented the DMA part to be a hard wired bootloader in silicon?

Remember that (AFAIK) "bootloader" is a contraction of "bootstrap loader" where bootstrapping with front-panel switches for a value and then a "latch and increment address" switch/button/toggle was used on many computers of the era.  Most?  All?  I know PDP/8 and CDC 8090 and I think CDC 6000 series and Burroughs medium/large system mainframes had it.  (Burroughs "small systems" needed no special coldstart punching-in.)

 

grohote wrote:

Is faster better though?

 

The question is irrelevant.

 

It wasn't irrelevant to the young lady named Carolyn that I knew in college.  Faster was definitely not better but really hard to convince a 19-year-old guy of that.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Tue. May 10, 2022 - 11:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
It wasn't irrelevant

 

This thread is artificial, my citations are taken out of context, but the posting was correct so far, and, hope, it will remain.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

grohote wrote:

I do not know full details how they did it, in times before of PC...

 

A slide rule and a pen and paper? wink

Wayne

East London
South Africa

 

  • No, I am not an Electronics Engineer, just a 54 year old hobbyist/enthusiast
  • Yes, I am using Proteus to learn more about circuit design and electronics
  • No, I do not own a licensed copy of Proteus, I am evaluating it legitimately
  • No, I do not believe in software or intellectual property piracy or theft
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:

I'm retiring at the end of this week, more time to spend with family and some travel, I'll try to poke my head in, on occasion to see what's happening, I've enjoyed this forum very much, a great gang of Freaks it is!

 

May you have a wonderful time on retirement enjoying what you want to do with your family. It will be sad not to see you around here. Take care!

Wayne

East London
South Africa

 

  • No, I am not an Electronics Engineer, just a 54 year old hobbyist/enthusiast
  • Yes, I am using Proteus to learn more about circuit design and electronics
  • No, I do not own a licensed copy of Proteus, I am evaluating it legitimately
  • No, I do not believe in software or intellectual property piracy or theft
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

WayneZA wrote:
a pen and paper

 

That I know. A paper, they glued to be like a scroll, and then ... mind, no compiler did it. Machine code in hexa only.

 

Edit: Ooooops, machine code for sure, but- was it in Octal, perhaps.

Last Edited: Tue. May 10, 2022 - 05:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:

 

All the same.   I am guilty of program first / think later.

 

Ditto, I like to just dive in, with an objective of course.

 

 

Happy Trails,

Mike

JaxCoder.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mike32217 wrote:

david.prentice wrote:

 

All the same.   I am guilty of program first / think later.

 

Ditto, I like to just dive in, with an objective of course.

 

I do exactly the same but am not afraid to do a complete rewrite when it becomes apparent that I have made a wrong turn.  It seems a lot of people are afraid to do this due to the misconception that a rewrite/refactor will take more time than continuing on with the mess they have created.  For me, the discovery of making a "wrong turn" seems to bring the problem into sharp focus and with that clarity the rewrite usually happens at lightning speed.

 

Letting the smoke out since 1978

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

digitalDan wrote:
I do exactly the same but am not afraid to do a complete rewrite when it becomes apparent that I have made a wrong turn.  It seems a lot of people are afraid to do this due to the misconception that a rewrite/refactor will take more time than continuing on with the mess they have created.  For me, the discovery of making a "wrong turn" seems to bring the problem into sharp focus and with that clarity the rewrite usually happens at lightning speed.

 

Some times it pays to cut your loses and do a refactor.  Does it take longer to refactor or continue to try to get faulty code to work?

Happy Trails,

Mike

JaxCoder.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So spend time sharpening the axe before commencing the cutting.

Ross McKenzie, Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

WayneZA wrote:
It will be sad not to see you around here

 

There's no reason to think that retirement forces one away from here... I've been retired a couple of years :)

 

Neil

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A few war stories above. 
 

there are good programmers and bad programmers. The good ones are good regardless of build speed, the bad ones…..

 

For me it all comes down to the time spent thinking, and one’s ability to visualise a complex problem in your minds eye. The best debugger in the world doesn’t help a great deal when you have memory corruption in a multi tasking system. 
 

How many of us spend time staring  at the wall as we construct the system (misbehaviour) in our mind? It is just so much easier to think earlier. 
 

And some stories…

 

i booted  RT11 off tape on a pdp 11/34 once. Why? Just to see how it worked. It did.. but seeking to the end of the tape for a file was fun

 

 The first computer I used as an intern had 16 k of core, a genuine front panel, and a paper tape reader/punch. There was actually a screen based editor!!! Your source was overwritten by the assembler so best to save first!

 

Gosh I learned a lot that summer. 
 

Then came 8085 builds on an Intel MDS that ran all night…

regards
Greg

Last Edited: Wed. May 11, 2022 - 12:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gregd99 wrote:
Then came 8085 builds on an Intel MDS that ran all night…
Similar for RCA CDP18S008 though that project had relatively deep pockets so a minicomputer.

What is you chosen method of debugging code. | AVR Freaks

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gregd99 wrote:

Then came 8085 builds on an Intel MDS that ran all night…

 

We solved that. We moved editing onto a small UNIX box with terminals on our desks and wrote scripts so we could remotely send our code off to the MDSs for compilation. After compiling the MDS would send the list files back to the terminals. Only when doing physical ICE did we actually use the MDS.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

Last Edited: Wed. May 11, 2022 - 01:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For instance, I don't think I've ever (since school, anyway) been very careful about syntax when typing in code.

The first draft is likely to have misspellings and occasional punctuation errors.   "#inclde <stdio.h/" and such.

The compiler will detect those errors more quickly than I could by proofreading before compilation.

 

The C compiler, anyway.  It's interesting to reflect on the sorts of "easy-to-make" errors that would NOT be caught by "some other language" (like misspelling variable names in Python.)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mike32217 wrote:
Some times it pays to cut your loses and do a refactor.  Does it take longer to refactor or continue to try to get faulty code to work?

In my experience, doing a refactor is much quicker provided that I am keenly aware that I have made a wrong turn.  For me, realizing I have made wrong turn brings what the correct/better turn is into sharp focus.

Letting the smoke out since 1978

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
The compiler will detect those errors ...
Likewise IDE and interpreters.

westfw wrote:
(like misspelling variable names in Python.)
Pylint?

 


https://www.wholetomato.com/features/feature-coding-assistance#of

 

Pylint - code analysis for Python | www.pylint.org

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
(like misspelling variable names in Python.)

 

A language which allows return values of 1, 2, 3, and 'friday' from the same routine has, I feel, other issues than misspelt variable names. But people seem to like it!

 

Neil

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

barnacle wrote:
which allows return values of 1, 2, 3, and 'friday' from the same routine
You see that as a negative not a positive ? I love the fact you can do that in Python. When you think about C the only way to return 3 things from a function is to return a struct (or perhaps a pointer to struct) - that seems so limited after Python. Similarly you have so many different things you can return: tuples, lists, dictionaries, etc - wonderful stuff !

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think Neil meant code like this:

def foo(x):
    if x == 0:
        return 0
    elif x == 1:
        return 1
    return "Friday"

as opposed to returning a tuple:

def bar():
    return (1,2,3,"Friday")

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Indeed Neil did. And no, he doesn't see it as a positive... handy on occasion yes, but a way to make robust code? Not convinced.

 

That said, my exposure to Python is limited; I think I've written only one major program in it. There's a lot to like in it, particularly for fast prototyping, but I'm not enamoured of it. And don't mention white-space...

 

Neil

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

My bad - I misunderstood the point you were making - I agree the ability to return conflicting types is a tad confusing.

 

If MISRA were involved they'd probably point out that well written functions should only have one point of exit anyway ;-) (which kind of constrains you to all returns being of a similar type!)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Compare K&R C to the latest C++. Perhaps someday Python++ will be accepted by professional programmers, but no longer used by the people that currently use Python.

 

(I understand that the ANSI C, or whatever, is still used for the same things that K&R C were intended for, but I think Full Monty C++ is for someone else.)

 

But hey, there are not yet enough threads on the Internet where professional programmers rant about Python, so everyone go ahead and vent. smiley

Brian Fairchild wrote:

It's at this point that we really do need the OP to come back and engage with us. So many questions..........

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

 

I've found the best method for writing code is to do it carefully and correctly the first time.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Heh, where's the fun in that?

 

An example of code currently under construction...

 

//  0xc9 - RET
    REG_PC_RW + DREG_RD + INC_NDEC,                        
    REG_PC_RW + DREG_WR + INC_NDEC + IR_WR + EXT_DATA_RD,   // have to increment to next address to make other instructions work!
    REG_SP_RW + DREG_RD + INC_NDEC,                         // sp to address
    REG_PC_RW + EXT_DATA_RD + WRITE_L,                      // return address low in pch
    REG_SP_RW + DREG_WR + INC_NDEC,  
    REG_SP_RW + DREG_RD + INC_NDEC,                         // increment sp
    REG_PC_RW + EXT_DATA_RD + WRITE_H,                      // return address high in pcl
    REG_SP_RW + DREG_WR + INC_NDEC + LAST,                  // increment sp again
    0,0,0,0,0,0,0,0,	0,0,0,0,0,0,0,0,	0,0,0,0,0,0,0,0,

 

Admittedly, working at the level *below* machine code is probably not for everyone :)

 

Neil