18F8722 Extended Microcontroller mode...

[madinventions]

Hi,

I'm on the brink of ordering the Swordfish compiler for a project I'm working on but I've got a quick question first: Does Swordfish allow you to access external RAM connected to an 18F8722 in extended microcontroller mode?
I have a general purpose board made up with an extra 256K of RAM which I can use via the Microchip C18 compiler, and I'd like to try and reuse this same hardware with Swordfish since I find that coding user interfaces in C is a pain and Swordfish just makes it all so easy!

Has anyone done this kind of thing before?

In C18, I declare the extra RAM in the linker file:

Code: Select all

CODEPAGE	NAME=externram	START=0x080000		END=0x0BFFFF	PROTECTED	//EXTERNAL MEMORY      
SECTION    NAME=SRAM       ROM=externram

and then declare the variables in the source files:

Code: Select all

#pragma romdata SRAM
far rom int a;
far rom int b;

This means I can access the RAM locations just like normal variables without having to go to any extra effort (nice...):

Code: Select all

a=24;
b=50;
a=a+b;
(etc...)

How can Swordfish achieve the same thing?

Many thanks,
Ed.

[madinventions]

Ok, I've made a little progress, but it's not ideal.

I can declare the variable as an absolute, ie:

Code: Select all

dim XRamVar as byte absolute $80000

which seems to work from examination of the LST file. However, what I'd ideally like to do would be to specify a starting address to put the following variables, like a RAM version of ORG?

Code: Select all

RAMORG $80000
Dim XRamVar1 as byte
Dim XRamVar2 as byte
RAMORG AUTO (Go back to Swordfish default mode of auto allocating RAM addresses...)

Specifying each var as an absolute seems to work technically but it'd be an absolute nightmare to add/remove variables in the middle of the list!

Best regards,
Ed.

[Steven]

I don't know anything about using extended mode, but you might be able to create a structure that contains your variables and then place a declared instance of this using an absolute address. The storage of strucures is in sequential bytes normally.

And welcome to the forum!

[madinventions]

Hi Steve,

I've used extended mode for a couple of projects now - basically you just sacrifice a bunch of IO pins and you get a multiplexed data and address bus. It's then fairly trivial to hang external RAM or FLASH from these, or just to memory map the entire project. I use this feature on an 18F8722 so there's plenty of IO pins left.

Structures seem like a good idea! I've lashed up some code to test it out:

Code: Select all

Device = 18F4520
Clock = 20

Public Structure TBigStructure
    x As Byte,
    y As Byte,
    bigstring As String($200)
    BigArray(1000) As Float
End Structure

Dim BigStruct As TBigStructure  absolute $1000
Dim iCount As Word

BigStruct.x=123
BigStruct.y=123
BigStruct.bigstring = "This is a big string for testing external memory using Swordfish....  blah blah blah blah blah..."
For iCount=1 To 999
    BigStruct.BigArray(iCount) = 1.234
Next

Unfortunately, compilation fails with an error

[ASM Error]: Error[126] XRam.asm 951: Argument out of range (4610 not between 0 and 4095)

The offending code in the ASM file is:

Code: Select all

Error[126]  : Argument out of range (4610 not between 0 and 4095)
0000C0 EE02 F002      00951         LFSR 0,ADF_M4610_U16

This is because the FSR register cannot take a value larger than 12 bits... I can change the absolute to $800 and then it compiles, but I haven't checked it in hardware yet.

As a comparison, C18 compiles this:

Code: Select all

002772   0e00     MOVLW     0x0            	wibble=1234;                                                                    X:\Firmware\Code template\F8720\main.c
002774   6ef6     MOVWF     0xf6,0x0                                                                                        
002776   0e00     MOVLW     0x0                                                                                             
002778   6ef7     MOVWF     0xf7,0x0                                                                                        
00277a   0e08     MOVLW     0x8                                                                                             
00277c   6ef8     MOVWF     0xf8,0x0                                                                                        
00277e   0ed2     MOVLW     0xd2                                                                                            
002780   6ef5     MOVWF     0xf5,0x0                                                                                        
002782   000d     TBLWTPOSTINC                                                                                              
002784   0e04     MOVLW     0x4                                                                                             
002786   6ef5     MOVWF     0xf5,0x0                                                                                        
002788   000e     TBLWTPOSTDEC       

from this:

Code: Select all

CODEPAGE	NAME=externram	START=0x080000		END=0x0BFFFF	PROTECTED	//EXTERNAL MEMORY      
SECTION    NAME=SRAM       ROM=externram

#pragma romdata SRAM
far rom int wibble;
#pragma romdata

wibble=1234;

As you can see, C18 uses table writes to access the external memory - is this something that Swordfish can do? I'd really like to press on with Swordfish, but I'm wondering if I'll have to create some form of helper routine to wrap some assembly code rather than getting the compiler to do it.

Ed.

[octal]

It's not possible to use SF to generate code for Extended mode. I investigated all possibilities about that. Even by fiddling with embedded ASM mode, it's not possible (not easy).
I already asked about that on this forum
http://www.sfcompiler.co.uk/forum/viewt ... oprocessor
I remember I got Microchip AN about using the extended mode on 18F8720 and there were a lot of points that we cannot "force" (control) in SF compiler that makes it impossible to handle extended mode. The main problem I faced so far was code relocation problem. Now that it's possible (in recent versions of SF) I didnt tried again to check if it's possible to manage extended mode or not.

Best regards
octal

[madinventions]

Hi Octal,

Thanks for your reply - I guess it makes sense that Swordfish doesn't handle this scenario since it's not a particularly common thing to need to do (even amongst users of other PIC compilers). It's a bit of a shame though...

However, what really appeals to me about Swordfish so far (I'm still testing using the SE version) is how easy and how quick it is to get things working. In particular, the flexible and open nature of the libraries invites development and is a huge benefit over the precompiled and hidden libraries of other compilers. Being able to throw together a test application to show to the boss that includes a graphics LCD, touchscreen, USB comms (and all sorts of other things that bosses seem to like) is a definite bonus.


Ed.

[octal]

Hi Octal,

It's a bit of a shame though...

Ed.

Not really ! Working in extended mode needs a deep knowlege of the 18F8720 (or other chips with external ram support). Also note that working in extended mode is not a matter of telling the compiler to generate code for external ram/rom support. user has to know, for example, that he still cant use it as normal ram, but as external rapid flash like ram and that its content is managed using tables pointers, the same way we handle code in flash.
A lot of details, that almost all basic users are not aware of or do not want to deal with!
SF already hides a lot the complexity of PIC architecture. Adding extended mode support would be very nice, but I think that there will not be more than two or three users really using it. so do you think it's worth the efforts david could put in it ?

However, what really appeals to me about Swordfish so far ... is how easy and how quick it is to get things working. In particular, the flexible and open nature of the libraries invites development and is a huge benefit over the precompiled and hidden libraries of other compilers.
Ed.

I'm 100% ok about that SF open libs are really great. Libs are very well structured and very well done. Really a good source base to learn SF.

Also the language is really very well structured. having attributes like Private/Public for subs/func and variables is really great. The Preprocessor is really the most advanced one I ever seen. Aliasing vars is great. SF is the only language I know (for embedded systems) that allow aliasing of subs and functions. Generated code is really robust and compact. Source level debugging is fully compatible with industry standard (COF), so debug using Proteus VSM and Microchip PIC simulator in MPLab is really great. SE version is not limited in anyway (code size is illimited). All the best things we can even find in a very good compiler.

Regards
octal

[rocketbob]

Hey Guys (esp. Octal),

Does the above still hold true? I've got a fairly complex project coming up that I can do with an 8722 along with external flash in microprocessor mode or extended microprocessor mode to bump up the program memory space. If not I may have to look at alternative compilers. I'm don't think I'll need additional RAM.

Regards,
Bob

[madinventions]

Hi RocketBob,

It doesn't matter to the PIC whether the external memory is FLASH or SRAM contrary to what has been mentioned above:

user has to know, for example, that he still cant use it as normal ram

I've done this loads of times using the MCC18 compiler and it works perfectly. However, I still haven't found a simple way of using external memory on the 18F8722 with Swordfish...

Ed.

[octal]

Hi RocketBob,

It doesn't matter to the PIC whether the external memory is FLASH or SRAM contrary to what has been mentioned above:

user has to know, for example, that he still cant use it as normal ram

I've done this loads of times using the MCC18 compiler and it works perfectly.
Ed.

I dont see what is wrong with "that he still cant use it as normal ram" in PIC18.

Read the post again and again ... It does **not** matter for PIC18 if you use external Flash or SRAM, in extended mode ... but the user "still cant use it as normal ram" ... even data are managed using table access code ... it's managed simply as an extension of the flash. PIC real SRAM is limited to the banks of SRAM implemented onchip. External SRAM is treated as flash and as a simple extension of the Flash memory (concerning data access). Code is got as code from internal memory but data are read as we read constants stored on onchip flash in NONprocessor mode.

I dont see what's wrong with that

Now for MCC18 microchip offers in an app note a serie of macro and routines to access and use extended flash/SRAM, but noway to do that with swordfish.

Regards

[madinventions]

Hi Octal,

Ok - I'm really not trying to start an argument with you, and I think we may be misinterpreting each others responses . I completely agree with what you're saying that on-chip RAM is accessed one way, and off-chip SRAM is accessed by table writes and table reads. They are different, but they're still RAM. I guess it all comes down to what you call 'normal RAM'? My 'normal' development board has got the 18F8722 fitted with 128K of internal flash, an extra 256K of external flash from 0x040000 to 0x07FFFF and 256K of flash from 0x080000 to 0x0BFFFF. Compared to the 3K of internal SRAM - I hope you can see what I mean by 'normal'.

What I was trying to clarify is that you can attach a SRAM chip to the external bus and read/write values as if they were any 'normal' variable as far as the MCC18 source code goes (see my first post). I understand that there is a performance deficit when using external off-chip SRAM due to the table read/writes as compared to on-chip RAM but it does allow you to have fairly large amounts of SRAM fitted to your board in which you can hold large arrays etc. Just because it's an extension of the PIC FLASH memory, doesn't mean that you have to use FLASH ROM chips - I was just trying to clarify this for any other users who maybe hadn't noticed this minor yet significant detail.

Anyway - Swordfish doesn't support this which isn't a problem considering how excellent the rest of it is, and it's all a bit of a moot point really so I'll back out gracefully at this point.

Good luck RocketBob - let us know if you find a solution.

Ed

[octal]

Hi madinventions,
I see better now. I didnt knew that external ram was handled by C18 (via linker script) as normal ram (ie. for vars).
First time I dealt with external ram was with version of PICC18 prior to 2.xx and there were no way to do it this way. All I could do was to use flash like routines and macro to write and read data.

I'll check again PICC18 docs. sorry for missunderstanding.

Regards
octal

[rocketbob]

ok...you guys are talking about table reads and writes, which is different as specified in the app note. Otherwise, if I am not oversimplifying things, using external flash for program memory is as simple as setting the config and memcon registers, making sure ext. flash is connected properly and away you go. On page 7 of the app note it states..."When an external memory is loaded with code and the interface circuitry is connected properly, program fetching is essentially transparent to the user code. The CPU responds as if it were fetching instructions from internal memory. The only limitation is bus loading characteristics and speed of external memory."

So is there any SF limitation that would prevent this from working?