More PIC space

[Guyfrom7up]

is it possiable to some how wook something like an SD card to a PIC and/or AVR microcontroller so that it has a whole bunch of memory?

 

[boxer4]

most small AVR and PICs do not have externally visible data and address lines, so at most you can use external memory to save data only - you can't store code.

Not sure what you want to store in the external memory... but usually you can save quite a bit of data though.

 

[Nigel Goodwin]

Like boxer4 says, you can add an SD card to store data, but not to run programs from - but PIC's usually have more than enough program memory anyway.

But you need to be more explicit with your question.

 

[Guyfrom7up]

Maybe the PiC might have enough internal memory, I'm going to try and make a device like an arduino board, but you can store multiple programs on it and select a program on a screen. After that you can plug stuff like LED's into it.

 

[Nigel Goodwin]

Choose an 18F PIC then, these have a lot of memory space, should be no problem.

 

[3v0]

"A whole bunch of memory" is colorful but....

How many K Bytes of memory do you need?

 

[Nigel Goodwin]

"A whole bunch of memory" is colorful but....

How many K Bytes of memory do you need?

I think it's pretty obvious he doesn't know, nor is he likely to until he's written the application.

 

[Krumlink]

What about external EEPROM's?

Lol my signature is bigger than the entire text of this post

Draws your attention away

 

[3v0]

This is a major project.

The Arduino uses a ATmega168 which has 16K bytes of flash. You should be able to use a 18F PIC and no external memory. The PIC18F chips come with up to 64K words flash (128K bytes) onboard.

I am not sure what level you are at so I will try to keep it simple. Please forgive me if any of what follows is too elementary.

The Arduino board system uses 2 parts. A JAVA IDE that runs on a PC/MAC and a set of libraries that run on the AVR.

When one system generates code for another it is know as cross platform development. In this case the PC/MAC is development platform and the AVR/PIC is the target platform. The IDE on the PC/MAC generates code that runs on the Arduino AVR/PIC. The system is cross platform.

The code generated for the Arduino may or may not be specific to the AVR's instruction set. The library that runs on the AVR certainly is.

If you choose to setup an Arduino using a PIC you must be prepared to port (modify for use on another system) the AVR code library to the PIC. If the IDE generates AVR specific code you must retarget (generate PIC instead of AVR) it to generate PIC code.

It is possible that the code used to generate the AVR code within the IDE is isolated or even table driven. If so that will make retargeting it much less difficult but not easy.

In short you need to be fluent on both the AVR and the PIC of choice to make this work.

EDIT: You may also run into speed/timing problems during the port. After you do the port you still need to modify the code to store multiple programs and make use of the extra resources on PIC.

If you want to do this I suggest you contact the people who did the original code and get to know them and their code. They may even make you part of the project.

If you are thinking of starting from scratch, it would be a lot more work.

 

[donniedj]

is it possiable to some how wook something like an SD card to a PIC and/or AVR microcontroller so that it has a whole bunch of memory?

I aggree with most, you most likely will have an abundance of Program Memory using any 8K or 16k mcu.

Now if you would like to utilize External Memory Bus for whatever reason, looking into the PIC18F87J50 series of micros. Supports up to 2Mbytes. These are 80 pin devices. The use of 80-pins and greater than 16K of program is so outside the scope of this forum

 

[David James]

I aggree with most, you most likely will have an abundance of Program Memory using any 8K or 16k mcu.

I've found a way of using lots of program memory - do floating point calculations using the C library functions ... I've been trying to code up the Latitude/Longitude to OSGB Easting/Northing conversion on an PIC18F4550 - I was planning to use the USB functionality to communicate with a PC and use the USART to receive NMEA sentences from a GPS receiver.

I have a working version of the conversion algorithm, and that (together with the library code that it has pulled in) has taken up nearly 75% of the available program memory. I'm beginning to think that I may have to go to a design with 2 PICs, one doing USB to a PC and various other functions and the other doing the co-ordinate conversion and then communicate between them with I2C or SPI or something similar.

 

[donniedj]

So to have I:

ORG 0X3FFF
MAIN:

 

[Oznog]

Well the thing to reiterate is that with the exception of the few External Memory Bus parts, external memory cannot hold program data. Well it can hold slow "interpreted code", where the program memory contains an interpreter and the external data is pseudoinstructions like BASIC Stamp data. This is very slow.

Technically program data can be read from any source and burned into onboard program memory to be run like any other program except that it's slow, it's a sensitive process, and the part can only sustain rewrites a limited number of times before wearing out.

So, basically, the answer is "no", you can't do this with a PIC unless you've got that External Memory Bus. In truth people rarely need to do this anyways.

 

[Oznog]

I've found a way of using lots of program memory - do floating point calculations using the C library functions ... I've been trying to code up the Latitude/Longitude to OSGB Easting/Northing conversion on an PIC18F4550 - I was planning to use the USB functionality to communicate with a PC and use the USART to receive NMEA sentences from a GPS receiver.

I have a working version of the conversion algorithm, and that (together with the library code that it has pulled in) has taken up nearly 75% of the available program memory. I'm beginning to think that I may have to go to a design with 2 PICs, one doing USB to a PC and various other functions and the other doing the co-ordinate conversion and then communicate between them with I2C or SPI or something similar.

Wow 75%? Something is wrong! I've read NMEA sentences from a 4800 baud serial GPS, and it doesn't require anything like that to interpret lat-longitude and calculate a distance between 2 pts and all that.
You don't need- or even want- floating point ops for this. They're incredibly slow and floating point accuracy is sometimes difficult to predict.

 

[David James]

Wow 75%?

The map file reports "23727 out of 33048 program addresses used, program memory utilization is 71%"

Something is wrong! I've read NMEA sentences from a 4800 baud serial GPS, and it doesn't require anything like that to interpret lat-longitude and calculate a distance between 2 pts and all that.

That's not what to want to do. I want to do the conversion from latitude/longitude to OSGB (Ordnance Survey Great Britain) eastings and northings. The formulae are in the pdf that I gave a link to. They are complicated. It may be possible to simplify them, but I've not had time to consider that.

You don't need- or even want- floating point ops for this. They're incredibly slow and floating point accuracy is sometimes difficult to predict.

I can't see how to cast the trigonometric formulae into something that doesn't use floating point - I'm not saying it can't be done, just that I've not yet figured out how to.

 

[blueroomelectronics]

The 18F or ds30F PICs have better C and math friendly cores and more FLASH than the 16F.
Else you could use an external math chip (just a preprogrammed MPU actually)
**broken link removed**
**broken link removed**

 

[Nigel Goodwin]

The map file reports "23727 out of 33048 program addresses used, program memory utilization is 71%"

No disrespect, but it looks like you may be writing this very badly, and loading LOT'S of library routines?.

This doesn't mean you've used 71% of your own program space, as the library routines are already loaded any extra parts you write will use the already present libraries - so you 'should' be able to add a lot of extra program, with only small increases in total memory useage.

 

[David James]

No disrespect, but it looks like you may be writing this very badly, and loading LOT'S of library routines?.

This doesn't mean you've used 71% of your own program space, as the library routines are already loaded any extra parts you write will use the already present libraries - so you 'should' be able to add a lot of extra program, with only small increases in total memory useage.

Certainly, there are a fair few library routines loaded (sincos, tan, sqrt all of which I have called directly, ldexp, UnpkMath, PackMath, which I've not called directly, the XLCD library routines, fprintf and sprintf).

However, my own routine doing the conversion takes up 0x28f2 bytes according to the map file (that's nearly 10,500). That accounts for nearly half of the total code. It's a fairly straight-forward implementation of the OS algorithms as listed in the OS document - I managed to shave approx 2,500 bytes off that routine's memory requirement (from 0x3280 to 0x28f2) by doing some common sub-expresssion optimisation by hand.

Perhaps I should start another thread and post the code for comment?

 

[Krumlink]

If you have a open adress bar then you could hook up a EEPROM.

 

[Nigel Goodwin]

If you have a open adress bar then you could hook up a EEPROM.

I suggest you go off and read about PIC's before making silly suggestions - for that matter, read the previous posts in this thread!.