Different PIC with bigger Flash?

Parts Questions
1

Hi everyone!

I am new to this forum, so let me introduce our project first!

We are 5 Students from Ilmenau who want to build a universal midi controller for synthesizers as a project for the university.

We plan to include big displays with multiple layered menus, and that led to the first problem, the available amount of flash memory in the PIC. We fear that the ~14k is not enough for our intended program structure, so the first question is, if it is possible to simply use a differrent 18F… PIC (e.g. the PIC18F4525) as a substitute for the PIC18F452, that is relatively similar, but has more flash memory.

Is that possible at all? Would it be difficult to implement? Could that lead to unforeseen problems?

2

Hi,

it will lead to unforeseen problems: all newer PICs contain the EUSART, and this peripheral has a bug which is very anoying for MIDI transfers (zero-frames are inserted sporatically).

See also this posting: http://forum.microchip.com/tm.aspx?m=85120

I will propably switch to the PIC18F4620 this summer - if Microchip doesn’t provide a fixed revision until then, I will use a second (smaller) PIC, dedicated for MIDI transfers, and connected to the PIC18F via IIC.

However, on the other hand: if you want to create a sophisticated (graphical?) user interface, you should consider the use of external memory (flash or battery buffered SRAM). Connecting 1 MB or more to the PIC shouldn’t be a big problem, most GPIO pins can be used for other external peripherals (like the LCDs) in parallel. Just only the chip select line requires a dedicated pin. And if speed does matter (but I think this is not the case for your project) it’s better to use a chip family which provides an external memory interface (like 8051 or Z80 derivatives, or maybe a 16bit controller?)

Best Regards, Thorsten.

3

Slightly off topic, but would those of us yet to start building a Midibox be better to wait for the new PIC18F4620 based designs?  Or is the new chip pin compatible enough to use the existing MB_CORE pcb?

Also, instead of a PIC as a UART, would it be better to avoid the problem of bugs in PIC chips and use a dedicated UART chip, such as Maxim’s MAX3100? http://www.maxim-ic.com/quick_view2.cfm/qv_pk/1731

4

Yes, the PIC18F4620 is pin compatible, you don’t need a new core module or something like that (this is really a FAQ, it should be written into the Wiki)

Maxim UART chip: I prefer the IIC solution, because it’s more flexible and and requires less pins. The maxim chip couldn’t be used on MIDIbox projects which already allocate all pins. However, do you know a IIC (I2C) UART?

Best Regards, Thorsten.

5

Hi Thorsten,

However, do you know a IIC (I2C) UART?

The only one I know is the Philips SC16IS740/750/760 (http://www.semiconductors.philips.com/acrobat_download/datasheets/SC16IS740_750_760_1.pdf)

But it`s SMD only :frowning:

Raphael

6

:o  I’ve been looking at those chips, thinking of the possibilities… Twice the Program Data, more than twice the RAM… The mind boggles :slight_smile:

Let’s hope rev4 has a fix for the EUSART hey?

The SMD UART might not be such a bad thing, given that the chip would most likely go on a kind of daughterboard… But it seems an older PIC would do the job too.

But whichever way, the new chip could hold very interesting features for MIOS. I’m excited :slight_smile:

7

Other than the Phillips SMD one, the only other I2C uart i managed to find is the BL233 at http://www.i2cchip.com/#Host%20Adaptors.  I suspect that’s just a custom programmed PIC.

Considering the relatively slow speed of I2C and MIDI, would the best solution be to use something like a PIC 12F629?  It’s 8-pin (6 I/O), has 1024 words of Flash program space and an internal 4MHz oscillator.  With no internal uart of any sort, you’d have to big-bang both the I2C and MIDI, but it would be the most flexible solution.

8

Hello Thorsten,

first of all, thank you for your fast reply!

We would like to try the external memory solution, but elsewhere in the forum I read that you cannot execute program code from external memory, but only from internal flash memory. Is that right? We fear that our code will also be big, and not only the graphical stuff (not so much planned). We think that the code will be big because we plan multiple functions per button, depending on what menu you are in. We plan to write the code in C, as no one of our team is very good at Assembler, and so we really have difficulty guessing the size of the program in advance. Could we also save parameters (the instruction which will be sent over MIDI) on the external chip?

Could you get us started on what memory chip to use and how to connect it?

Regards,

Christian

9

Hi Christian,

yes, it’s correct, that code cannot be fetched from an external memory. The PIC doesn’t provide a generic parallel interface anyhow, so that your software has to handle external bus accesses via the GPIO pins in the same way like it accesses the interface of the LCD. This costs time, but in most cases it’s fast enough. For you MIDI controller project, the CPU load will be very relaxed anyhow when I compare it to applications like the MIDIbox SID (as an example), therefore you could even use a serial flash or EEPROM, it will still be fast enough.

Short calculation: assumed that you are planning to use a graphical 240x64 LCD (too bad, that you didn’t mention the display you are planning to use, it would simplify my answer). The whole display consists of 15360 pixels, makes 1920 bytes. Assumed, that you are fetching the graphical data from a serial EEPROM (like my beloved “BankSticks”), it would take ca. 30 uS * 1920 = ca. 60 mS to write the whole screen. This is fast enough, because I don’t think that you want to playback a movie?

And even if latency does matter, you could split the display update into several parts (preemptive multitasking), so that on each “mainloop” only one or two lines are updated. By doing so, you would achieve an overall latency which is still less than 1 mS

If you are planning to use a character LCD, then you don’t need to consider such things…

Even when you are writing the application in C, it doesn’t matter, that (for example) the PIC18F452 doesn’t provide enough code memory for your project. Because by using clever data structures, you don’t need so much code anyhow.

Menu structures, character strings, MIDI events and streams, parameter values or whatever can be easily saved in (and accessed from) an external non-volatile memory. The program itself only needs to know, where the informations are located (even such infos could be saved in the ext. tables).

Sending different MIDI events depending on the menu just only means, duplicating the external data tables…

Such methods have also another advantage: by using a socket for the external memory (like the “BankStick”), you could allow the user to switch between different setups (it doesn’t matter, how many synths are part of the setup), or to make backups, or whatever. It’s also easily expandable by multiple memory devices.

Best Regards, Thorsten.

10

Hi!

Thanks again, Thorsten!

Our whole group is very relieved to hear that, and now we can seriously start building the box!

We´ll keep you all informed how it´s going along!

(oh about the displays: we didn´t decide yet, but thats exactly our two options: either a big one 240x64, or multiple smaller character LCD´s, so optimal answer  :slight_smile: )

Greetings,

Christian