AVR8 custom core and SD card functionality question


Zvonimir

Recommended Posts

Hi,

I have followed a AVR8 custom core tutorial and have successfully synthesized

custom core, same as in tutorial, starting from version 1.6.

However, if I try to use sdfat.h and sdfatutil.h libraries, in my sketch,  they do not work - I do not

even get an error, I just hang on first card.init. (I made sure to select "custom" in Arduino IDE).

I tried all exemplary SD sketches and all have the same problem. Just out of curiosity,

I printed on serial port value of SPI_miso_LOC and it is 0, which is not right, according

to AL assignment. I also tried to just synthesize AVR8, without any custom core,

and I get same results.

If I use "AVR8_PapilioOne_500.bit" from the bitstreams, then I get it to work.

Does anybody know what am I doing wrong?

THANKS!

Zvonimir

Link to comment
Share on other sites

Hello Zvonimir,

I can shed some light onto what's happening here. If you take a look at the page that talks about moving pins on the fly, down at the bottom is a section that explains the difference between the "Vanilla" variant of the AVR8 core and the "Shifty" variant.

The version of the AVR8 that is included with the Papilio-Arduino IDE is known as the "Shifty" branch which is based on the AVR8 "Vanilla" source code. The AVR8 "Shifty" branch  implements functionality like shifting pins, an SPI master, custom  cores and it uses 99% of the Papilio One 250K resources. In comparison,  the AVR8 "Vanilla"  branch only uses 60% of the Papilio One 250K resources when all  peripherals are disabled. It leaves as many resources available for your  unique customizations as possible while the AVR8 "Shifty" branch provides as much functionality as possible. 

With the AVR8 "Shifty" branch  registers that control pin location are added to the 0x1000 address  space. The 0x1000 address space is normally reserved for external SRAM  in the AtMega103. 

In the Papilio-Arduino IDE there is a file (hardware/arduino/cores/pins_papilio.c) that provides a name for those registers that can be used by sketches. 

Using that user friendly name to set the register with  a pin location instructs the custom VHDL in the "Shifty" core to  connect the peripheral to the specified pin. 

The version that is included by default with the Papilio IDE is the "Shifty" variant which includes the SPI master and the code to move pins on the fly. The version that is used in the custom core tutorial is the "Vanilla" variant which does not have the SPI master integrated yet and does not have the code to move pins. The thinking is that the pin shifting code is very expensive and ends up using 99% of the P1 250K and if you are making a custom core you can specify where the SPI pins connect manually and save a TON of space. Integrating the SPI master into the "Vanilla" variant is on my task list but has not been completed yet. It should be easy to look at the "Shifty" variant and do the same thing in the "Vanilla" variant and add constants to control whether it is synthesized or not.

Jack.

Link to comment
Share on other sites

Jack,

hmm - how embarassing for me. I thought I was using "shifty" branch. I actually found

this paragraph You quoted, and I assumed that the version I was using was shifty.

I will search for "shifty" version of the VHDL and report tomorrow what I got, after

I get it from SVN.

Is there an explanation/manual then how to set up SPI to work with Vanilla version?

Thank You very much!

Zvonimir

Link to comment
Share on other sites

Jack,

OK - I got shifty AVR8 ver 26 from the SVN, and got it to synthesize on its own, and core is working

with sdfat libraries, as expected.

I am not sure now which one will be easier to me - as a nubie - to add my custom peripheral

to shifty, or to figure out SPI manually in Vanilla with the customized peripheral. If You have

an opinion, let me know.

Thank You very much!

Zvonimir

Hello Zvonimir,

I can shed some light onto what's happening here. If you take a look at the page that talks about moving pins on the fly, down at the bottom is a section that explains the difference between the "Vanilla" variant of the AVR8 core and the "Shifty" variant.

The version of the AVR8 that is included with the Papilio-Arduino IDE is known as the "Shifty" branch which is based on the AVR8 "Vanilla" source code. The AVR8 "Shifty" branch  implements functionality like shifting pins, an SPI master, custom  cores and it uses 99% of the Papilio One 250K resources. In comparison,  the AVR8 "Vanilla"  branch only uses 60% of the Papilio One 250K resources when all  peripherals are disabled. It leaves as many resources available for your  unique customizations as possible while the AVR8 "Shifty" branch provides as much functionality as possible. 

With the AVR8 "Shifty" branch  registers that control pin location are added to the 0x1000 address  space. The 0x1000 address space is normally reserved for external SRAM  in the AtMega103. 

In the Papilio-Arduino IDE there is a file (hardware/arduino/cores/pins_papilio.c) that provides a name for those registers that can be used by sketches. 

Using that user friendly name to set the register with  a pin location instructs the custom VHDL in the "Shifty" core to  connect the peripheral to the specified pin. 

The version that is included by default with the Papilio IDE is the "Shifty" variant which includes the SPI master and the code to move pins on the fly. The version that is used in the custom core tutorial is the "Vanilla" variant which does not have the SPI master integrated yet and does not have the code to move pins. The thinking is that the pin shifting code is very expensive and ends up using 99% of the P1 250K and if you are making a custom core you can specify where the SPI pins connect manually and save a TON of space. Integrating the SPI master into the "Vanilla" variant is on my task list but has not been completed yet. It should be easy to look at the "Shifty" variant and do the same thing in the "Vanilla" variant and add constants to control whether it is synthesized or not.

Jack.

Link to comment
Share on other sites

Zvonimir,

I think if you do not need the pin shifting functionality then your best bet is to go with the Vanilla branch and add the SPI master to is. You should be able to copy the SPI code snippets from Shifty into Vanilla...

I'll also try to make some time this weekend to pull the SPI code into Vanilla.

Thanks!

Jack.

Link to comment
Share on other sites

Jack,

thanks for the advice...but, unfortunately I spent last two days doing the wrong thing, i.e.

I wanted to add my custom core to the Shifty. I immediately got into 6-bit addressing vs. 16-bit

addressing conflict, which I managed to resolve, by carefully chasing 6-bit addresses and

comparing to what Vanilla has.

I got it to the point where Shifty actually

works correctly, albeit my custom core is not. I am not sure what exactly went wrong - I

think I got myself in a corner, where some of those warnings I am getting during the bitstream

generation are actually important... If I set porta and portb to FALSE (and do not touch

DDRAreg and DDRBreg), everything compiles, but porta and b (which I use for custom core

inputs/outputs) seem to be dead on the actual board. If I let porta and b TRUE (and

use DDRAreg and DDRBreg to set pins as inputs), then I get conflicts with shifting

functionality. Finally, I need about 16 addresses in the memory space, and I am not

sure what is all used by Shifty - seems that starting at x0FE0 (like in Vanilla custom)

is bad, as that collides with PWM and SPI registers (I can see it in pins_papilio.c), so I moved

to x0FF0 and used 16 addresses thereafter, but didn't seem to make much difference.

My hope was to make You happy with Shifty working with custom core, which probably

would be useful to all the folks interested in customization...if nothing, I have

working shifty with 16-bit addressing through and through.

I look forward to whatever you have with adding SPI to Vanilla. I can try to do it in

parallel, or, if You want me to, I can act as a tester etc.

Thank You very much!

regards, Zvonimir

Link to comment
Share on other sites

Jack,

yes, I certainly found the page, and started working on tutorial. So far my FPGA

debugging was strictly based on debugging VHDL, after which usually everything worked.

I downloaded ATMEL studio last night, and went through 1/2 of the tutorial. I will

let You know how things progress.

thanks!

Zvonimir

Did you see the videos I put together here:

http://papilio.cc/index.php?n=Papilio.SimulateACustomAVR8UserCore

Jack.

Link to comment
Share on other sites

  • 2 weeks later...

Jack,

a minor update. I managed to add custom core to Shifty, and have reached an

interesting point, certainly an improvement, by doing debugging with AVR simulator

and ISim simulator. In general, I can get either my custom core to work,

but not SPI, or to have SPI core to work, but not the custom. All the changes

that make the difference seem to be isolated now in pm_fetch_dec.vhd. I think

there is some conflict between IO and memory mapping that I have to chase

down...I am curious if You have any comments.

Thanks!

Zvonimir

Link to comment
Share on other sites

Hi,

I got Shifty AVR to work great with custom core; also in the same process, I have

added SPI and pin shifting ability to Vanilla. The ISIM debugging was key to figuring

out what was going wrong - I was able to see that iowe was not behaving as it

should, which I manage to trace to pm_fetch_dec and swap_pins!

The problem was on how pin swapping was

implemented - I had to change constant const_ram_to_io_c in pm_fetch_dec to

"0010" and use memory space from 2000 in the custom core - this has resolved

all the conflicts in 0x1000 - 0x1FFFF portion of memory space that I had.

I wonder if it would be useful to upload the new Shifty design - with 16 bit I/O addressing

and custom core example? I will check if I can sign up somewhere...

THANK YOU VERY MUCH FOR YOUR HELP!

Zvonimir

Link to comment
Share on other sites

Zvonimir,

This is great news! I'd love to integrate it into the source code repository on github. I think the easiest way to do that is if you create a github account, fork the Arduino-Soft-Core project, upload your changes to your fork, and then send me a pull request. I will then be able to review and apply your changes with a simple press of the button. :)

Thanks!

Jack.

Link to comment
Share on other sites

Jack - great! I will get cranking then over the weekend! I am proud to be part of the community.

Z.

Zvonimir,

This is great news! I'd love to integrate it into the source code repository on github. I think the easiest way to do that is if you create a github account, fork the Arduino-Soft-Core project, upload your changes to your fork, and then send me a pull request. I will then be able to review and apply your changes with a simple press of the button. :)

Thanks!

Jack.

Link to comment
Share on other sites

  • 6 months later...
Zvonimir,

This is great news! I'd love to integrate it into the source code repository on github. I think the easiest way to do that is if you create a github account, fork the Arduino-Soft-Core project, upload your changes to your fork, and then send me a pull request. I will then be able to review and apply your changes with a simple press of the button. :)

Thanks!

Jack.

Done - I just committed to Github and sent You a pull request. Detailed documentation is provided in the trunk, and I can add more to clarify any issues remaining. BR, Zvonimir

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.