Some of the E24 values are wrong!

[Nigel Goodwin]

It depends on the amount of instructions which have to be executed. Every keyword has to pass the interpreter using any kind of Basic. The more keywords are used the slower will be program execution.

Regardless of the number of instructions, interpreted BASIC is far slower than compiled code.

Also the memory space in MICROCHIPs as well as in ATMELs is very limited and won't allow to use a basic interpreter, which I guess would be appreciated by many people.

Where have you been the last 20 years?, the BASIC Stamp is a PIC interpreter, and the more modern PICAXE is another one.

There have also been two free amateur PIC interpreters based on the Stamp, neither ever reached fruition, but were workable - a bit like the forerunner of the early PICAXE, stored the program in internal data EEPROM.

 

[Boncuk]

Where have you been the last 20 years?

Well, I was on earth, whereas the BASIC STAMP must be from somewhere else in the universe because of its extraorbital price.

BTW, the air data computer I mentioned is 30 years old.

 

[Sceadwian]

Boncuk, has your mind slipped?

Also the memory space in MICROCHIPs as well as in ATMELs is very limited and won't allow to use a basic interpreter, which I guess would be appreciated by many people.

That comment is dead wrong. The basic stamp IS a basic interpreter, and you could do the same thing with a Atmel chip if you so chose.

Your testimonials to the speed of basic are completely irrelevant to the fact that a compiled language is always faster than an interpreted one on the same hardware.

 

[Nigel Goodwin]

That comment is dead wrong. The basic stamp IS a basic interpreter, and you could do the same thing with a Atmel chip if you so chose.

So you haven't heard of anyone producing an interpreter for the AVR either?, because I hadn't.

I suspect it's due to the AVR been such a recent chip, the STAMP long predates it - and free AVR compilers are available.

 

[Sceadwian]

I think Parllax really shot themselves in the food using a basic interpreter. The basic compilers available for PIC and AVR are way way better in every aspect and no more difficult to use. Since there are already compilers for the AVR there's really no reason to make an interpreter, very few people would outgrow the available code space of a larger AVR and anyone that did wouldn't be using basic. I'm going to guess basic stamps pre-date the free version of the basic compilers for pics that are out there which is the reason for it's existence.

 

[Nigel Goodwin]

I think Parllax really shot themselves in the food using a basic interpreter.

Hardly, they made a LOT of money from selling the STAMP, it was an incredibly successful product.

I'm going to guess basic stamps pre-date the free version of the basic compilers for pics that are out there which is the reason for it's existence.

As far as I'm aware it pre-dated any BASIC compilers at all, and when compilers did eventually appear they were deliberately compatible with the BASIC STAMP.

 

[Speakerguy]

I love the fact that I learned PIC programming at a company that was a) phasing out ALL forms of programming for PIC micros other than C, and b) phasing out anything less than an 18F series chip unless small size was required (like an 8 pin 12F or something).

 

[Sceadwian]

That's why I like AVR's speakerguy. When I found micro controllers even the 8pin bits were better than a fast PIC. The 18 series or so fixed most of the 'problems' with PIC's but I still like AVR best.

 

[Speakerguy]

Unfortunately I have never played with AVR. I think I need to learn Verilog and FPGA's next. Maybe then AVR.

 

[Sceadwian]

I hope that's a joke. You don't take a step forward like an FPGA and then go back to AVR's =)

 

[Speakerguy]

Well it is always good to know a little bit of everything, you never know that next job interview may require you to know AVR's even if you have been playing with FPGA's. But FPGA is next on my list

 

[Sceadwian]

Psst.. OpenCores
Worth your time for opensource FPGA cores. They even have an AVR core in there somewhere. You could take that and tweak it to your hearts content =)

Just as a side note cause I'm an Atmel AVR pimp, give the FPSLIC series from Atmel a view, they're big blocks of FPGA material loved up with an AVR core for basic processing can make your own custom peripherals. Opencores is good, but the size for a dedicated chip is so much better than FPGA gate consumption putting the two together is just the perfect solution. Xilinx stuff is nice though free IDE and cheap kits.

 

[Speakerguy]

Yeah my brother gave me his old Spartan 3E development board, and I just downloaded the Xilinx ISE webpack. So I'll be using that as a starter system.

 

[Hero999]

Tables are incredibly fast, FAR faster than any maths you might be doing, I don't see any reason for a formula at all, which as you say, doesn't work anyway.

I don't see how using a lookup table will help that much.

Firstly I'm splitting the number up into the exponent and a mantissa (0 to 999) which requires a log and an exponential function.

Working out the nearest E24 value (this is corrected later on) only requires an extra multiplication which would be required to index a lookup table anyway.

Here's the fragment of code which does all of the above.

INPUT "Enter value"; value#
 
lgval# = LOG(value#) / lgb10' Take log10 of the value.
 
ex = INT(lgval#)' Exponent is the integer part of log 10 of the value.
 
dec#= lgval# - ex' store the decimal part of log10.
 
el = dec#* 24' Work out the nearest preferred number.
 
mnt = 10 ^ (2 + dec#)' get the mantissa.
 
ex = ex - 2' Preferred numbers in the array are multiplied by 100 so /100.

Do you know if there's a better way of getting the exponent and mantissa?

Sorry, but I don't believe you - an interpreted BASIC doesn't run faster than a compiled language (it runs MUCH slower).

Are you perhaps referring to QuickBasic rather than QBasic?, as QuickBasic is a compiler.

As for potential speed differences, I would suggest it depends entirely on how the two programmes were written - particularly if you were doing complicated maths with them.

Yes compilers are much faster than interpreters.

I will eventually convert the program to FreeBASIC which is a compiler and runs on Windows and Linux. The program will probably still be text mode though.

I shall make it free under the LGPL so other people can use it as a library and hopefully write a GUI for it.

 

[Nigel Goodwin]

I don't see how using a lookup table will help that much.

Firstly I'm splitting the number up into the exponent and a mantissa (0 to 999) which requires a log and an exponential function.

Working out the nearest E24 value (this is corrected later on) only requires an extra multiplication which would be required to index a lookup table anyway.

Here's the fragment of code which does all of the above.

INPUT "Enter value"; value#
 
lgval# = LOG(value#) / lgb10' Take log10 of the value.
 
ex = INT(lgval#)' Exponent is the integer part of log 10 of the value.
 
dec#= lgval# - ex' store the decimal part of log10.
 
el = dec#* 24' Work out the nearest preferred number.
 
mnt = 10 ^ (2 + dec#)' get the mantissa.
 
ex = ex - 2' Preferred numbers in the array are multiplied by 100 so /100.

Do you know if there's a better way of getting the exponent and mantissa?

I don't even see any reason to want to do it?.

Like I said, I did it for E12 values, but the only difference would be in the size of the tables, and the number of iterations round the loop.

Input the value required:

Run a nested loop paralleling each value in turn with every other one, and comparing the result with that required.

Display the 3 most accurate results, complete with actual value and percentage error.

 

[Hero999]

The input value could theoretically range from anything between 10mΩ to 100MΩ, a dynamic range of 10^9.

Without ensuring the values are within a known order of magnitude how can I ensure that the loop doesn't have to go through 10^9 iterations or have an lookup table 10^9 elements long?

I could have a loop which multiplies or divides the number until it's >0 <1000 but I'm not sure whether it would be faster than the log and exponential used to work out the mantissa and exponent.

Is there another way?

 

[Nigel Goodwin]

Like I said, it's a LONG time since I did it, it was pre-windows on a DOS laptop running a 386SX16 processor.

There was no complicated maths, just a lookup table for a single decade - you simply scale for all other decades.

It was absolutely instant, you entered the value you wanted, hit enter - and the results appeared LONG before your finger was off the key.

 

[Sceadwian]

How about just using this website hero? It's common when designing software or hardware to make sure no one else has done it first =)
Standard Resistor Closest Value Calculator

 

[Hero999]

Nigel,
So with your program, the user had to manually scale the value, mine will do it automatically.

Sceadwian,
That website just selects the nearest value. My program will do a lot more. Give it any value and it will select a pair of resistors which can be connected in series or parallel to give as near to the specified value as possible.

I know of a program which does this but it doesn't include E3, E48 and E192 values. It's also closed source, mine will be open source.
Directory of /~rstevew/Public/Software

 

[Nigel Goodwin]

Nigel,
So with your program, the user had to manually scale the value, mine will do it automatically.

No, you just entered the value you wanted, and the program displayed the five nearest combinations, it did any scaling itself.