Could PIC handle this?

~5000 over the entire UK. distribution varies a little, but not hugely. indexing it by longitude is probably best.

Reply to
dapage
Loading thread data ...

Check out this month's EPE mag (uk)

formatting link
They published a device based on a cheapish GPS module with NMEA output and a 16F873 that does exactly what the OP requires, they even explain the math.

--
Clint Sharp
Reply to
Clint Sharp

"Clint Sharp" wrote

Ah, neat: you program it when you pass a camera and it beeps when you pass that way again.

So it has to store information to the resolution of the GPS, but it doesn't have to cover the world.

Still wouldn't have picked a PIC.

All the computer software ever written can be executed on a computer with just one instruction ...

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
 Click to see the full signature
Reply to
Nicholas O. Lindan

PICs come pretty big now - up to 128K (18F7820). I have used the 18F452 and it's nicely capable - fast clocking, hardware multiply, sane stack depth, good peripherals. The 128K parts are a lot bigger and a bit better.

That's not to say the PIC is the best beast for the job. I've been mostly using MSP430 recently, but they stop at 60K. I suspect that beyond this, ARM is the best choice. Certainly plenty of FLASH.

I also suspect that your distance algorithm is a small part of the code, both time and space. I would identify the critical part as being the database of 5000 locations. How much memory do you need? At 20 bytes each (5 single precision floats), you should fit into a 128K part and have plenty space for kerfuffle. Perhaps cheaper to use a low temperature PIC and slap in a 24512 or three.

Regards, Mike.

Reply to
Mike Page

[raspberry sound] Today's PICs have hardware multiply and run at up to 40MHz. For 8 bitters, they're rather good.
Reply to
Mike Page

I think you could offload some of the redundant math to database creation time. If you drop the idea of floats and went with scaled integers, you could speed things up and save a great deal of space.

Scale the GPS into binary integers. There are 360 degrees of longitude, each with 60 minutes and 4 places of fractional minutes. So 360 * 60

  • 10,000 = 216e6 or a little less than 2^28 or 28 bits. Latitude would be
27 bits. This would speed up the math considerably. The only *conversion* needed would be the GPS data into the binary format. Each point would be 8 bytes with no loss of resolution.

As I mentioned before, you could really speed up 'homing-in' on the closest location by simply taking the sum of the differences of lon and lat. No multiply would be needed. You could then take the time to perform 64-bit multiplies on the closest 5 or 10 to select the true, closest item.

BTW, the sum of the differences technique is really pretty efficient. The worst case error occurs when the points are at 45 degrees from each other. Even then, it's still really close.

Noel

Reply to
Noel Henson

Some of todays PICs (18x and 17x at least) have sissy 8 x 8 hardware multiply. The MSP430 has a manly 16 x 16 hardware multiply, which is 4 times the work. Although technically a 16-bit micro, it competes directly. Also, 40MHz is the oscillator frequency-- the minimum instruction cycle is 100ns.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
 Click to see the full signature
Reply to
Spehro Pefhany

It is interesting to compare these clock frequencies and minimum cycle times to the original MC6800 some 30 years ago running at 1 MHz and 1 us. Despite the huge improvement in silicon processing, the performance of current 8 bitters is only modest.

While on wider processors, much of the performance increase is due to using more and more transistors, the maximum clock frequency has also grown several decades.

Thus, I would have expected that with current 130 nm line widths, the performance would have been at least two decades better than with the original 6800/8080/8085/Z80 processors, even with a similar number of gates.

Are manufacturers afraid that fast 8 bitters would reduce the market for 16/32 bit processors ?

Paul

Reply to
Paul Keinanen

I've seen ads (from Western Design Center?) that show that a 65C02 core would run at several hundred MHz if manufactured in a modern process. Maybe the market price per chip times the demand for such a fast, but lean, processor won't support the up-front cost of such a process.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
 Click to see the full signature
Reply to
Spehro Pefhany

The ever popular flash is generally slow and I/O pins generally don't need to be near that fast, so the external interface is probably what makes this kind of fast embedded 8-bit CPU in the center not so interesting. And if you add in cache and inbound and outbound fifos, etc., it's not so interesting anymore to have a 65C02 in the middle of all that. And there's the core voltage versus what people would like for their applications, perhaps.

Jon

Reply to
Jonathan Kirwan

I actually started on something like this for a 8051, but stopped it after buying a 2nd hand PalmV.

All code was using integer32 and the distance was approximated using somthing derived from the code below. Scaling on longitude before the function call was done based on lattidude value (usable for

Reply to
Joop

Now that's a simple solution.

Noel

Reply to
Noel Henson

Nice, isn't it?

I noticed the SDCC compiler was helped quite a bit by calling the following function passing the X and Y distances. Functionally the same but better fitted to the 8051.

// Less generated code and uses more registers unsigned long ldist(long distX, long distY) { if (distX < 0) distX = -distX; if (distY < 0) distY = -distY; if (distX > distY) return (unsigned long)(distX + (distY>>1)); else return (unsigned long)(distY + (distX>>1)); }

Reply to
Joop

Would make more sense if properly commented. This actually takes the sum of abs(x1-x2) and abs(y1-y2), and deducts 1/2 of the smaller of those two. The 45 degree is the point at which the smaller selection switches over. When either the x or the y points are identical the formula is trivially exact. I think it falls out directly from a power series approximation to the root.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to
CBFalconer

"David" skrev i meddelandet news: snipped-for-privacy@posting.google.com...

I think that if the volume is OK, you can run the calulations inside a GPS chip. Vendors are not likely to bother with you for 1s or 2s.

If you first get the position, and then do the calculation you should have enough MIPS. If you need an external micro, then the AT91SAM7S32 might be a good choice. Has 32 kB of Flash providing 12 kB for the application and 20 for the data. Bandwidth for data would be 120 MByte/second AT91SAM7S128 (available in January) would have enough SRAM to store the complete table so your bandwidth could be up to 200 MByte per second.

--
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
 Click to see the full signature
Reply to
Ulf Samuelsson

You might instead consider indexing by latitude. I did something like this a very long time ago. My application was to look for radio towers (in a database) within cicles of a certain radius given an arbitrary lat and long. I had everything sorted by latitude, since the distance between lat lines can be approximated as constant everywhere on the planet (about 111km). To do a quick search of everything within 2km, you can quickly eliminate everything that differs in latitude by more than 0.018 degrees. Since you're entirely within the range of about 50 to 60 degrees of latitude, you can also do a similar quick compares on longitude (around 75km per degree, but verify that number!). In my application, I didn't actually need the distance -- just whether a tower was within the circle, so I was able to absolutely exclude everything outside of the enclosing square. I then had it do similar comparisons on an inscribed square. Then the only actual calculations the program had to do was only on points which were inside the outer square but inside the inner one -- often there were none. This would be easier with a simple diagram, but you can probably figure it out.

Ed

Reply to
Ed Beroset

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.