Pi SPI under RISCOS
Jon Abbott (1421) 2609 posts |
Should the 32bit / Service_ModulePreInit check be swapped around, then the way it would work is:
° You could for example force a Module to RISCOS 3.1 which enables self-modifying code support, or RISCOS 3.7 which wouldn’t need self-modifying code support. There’s various other corrections that go on depending on the RISCOS version, such as sound buffer size/rate, OS_Byte 129, OS_Word 21 0, SWI flag preservation (yet to be added as I’ve yet to find anything that actually relies on it) etc. That’s the SPI/BSC slave controller (chapter 11), not the main SPI controller (chapter 10) I stand corrected, you’re quite right; I seem to have skipped a chapter. That’s the transfer sorted then, I’ll start work on the driver as soon as the screen and Pi2 arrive next week. Can’t you do everything from within an IRQ handler, triggered by the FIFO level triggers? (see 10.6.2 in the datasheet) The blitter runs under RTSupport at the frame rate the game requests (or falls back to 50Hz if it stops receiving frame buffer swaps), instead of blitting to the GPU as it does currently, I’ll build a transfer buffer of delta changes for the DMA stream. I need to look into how this actually works in SPI though, so I’m assuming for the minute that the DMA transfer stream can indicate which words are changing and not have to transfer the whole screen buffer. The IRQ handler will then stream the softcopy built up by the blitter in the way you suggest. All very neat and light weight, the impact on the system should be negligible beyond the bit depth conversion/softcopy. The current blitter translates to 24bit and happily runs a 500+ fps, translating to 16bit may be slightly quicker as its writing 1 word for every two pixels instead of 2 and using the same bit depth translate code, it will however have to work out the delta change which will slow it down considerably. This can be offset with pre-caching if it’s working far enough ahead, so may not be such a hit in the long run. I think he means there was a point where a compiled C module was built to be 26/32 neutral so it doesn’t fiddle with the PSR Spot on, the later Modules are generally 32bit compatible – if they had the 32bit flag. Oh, but I meant taking a module with all those 26 bit things in and seeing what happens. Without the JIT bad things would happen. I can seamlessly fix up Modules on the fly, so you’d never have to worry about them being 26bit/32bit. Where they rely on particular chipsets (some game modules for example that provide mouse pointers etc), ADFFS would have to be providing a VMM for it but in general the everyday apps you’re referring too would all seamlessly work. Essentially, once 26bit Module and WIMP support is added to ADFFS, it would make 99% of legacy apps work on RO5.21 with no user intervention and be completely seamless. We’d have to discover what RISCOS versions apps/modules require and mark them somehow, my idea there is to put a file in the app folder that ADFFS looks for when apps/modules are loaded – it needs some more thought though. |
Rick Murray (539) 13432 posts |
No, it will probably stiff the machine the moment that it needs to report an error and starts pushing high bits of R14 which is then copied to PC – instant freeze as the processor jumps to who knows where now that the high bits are valid addresses not the PSR. |
Steve Pampling (1551) 7962 posts |
or you reinitialise the module, or try and kill the module. 1 If you find such things interesting. |
Bill Antonia (2466) 120 posts |
Just to say, I’ve uploaded some documentation on the C library to my site now but I have noticed the library is not complete regarding a method to return errors, this I will fix. To make modifications of these sort of things I was thinking splitting the module code from the library and test code so each can be independently modified. |
Colin Ferris (399) 1753 posts |
Steve – Is this a 32bit version of CallWin32 – rmkill here – and it just died. |
Steve Pampling (1551) 7962 posts |
26 bit, off the (rather old N.D) web site, source fiddled a little to add the 32 bit header. |
Jon Abbott (1421) 2609 posts |
Thanks once again, I reckon you’ll have it complete by the time my Pi2/TFT arrive. Amazon still haven’t shipped the Pi2 despite having stock – I did order it with a dozen other things so there’s probably one item holding up shipment.
That gives me an idea for trapping and fixing them on the fly without having to pre-interpret the instructions, it should trigger a pre-fetch Abort which can quickly correct PC and shove V etc into the PSR (assuming it doesn’t overlap mapped memory of course). The only bit that knackers it still is Interworking but if it still triggers the pre-fetch Abort it should force the CPU back to Abt32 and not even enter Thumb. Don’t know why I didn’t think of that before! If it works, ADFFS wouldn’t need Codelets for any instruction that sets PC and could allow them to run natively fixing via the Abort handlers on-the-fly. I’ve probably not thought that through enough though – it couldn’t possibly be that simple. EDIT: One game I tried earlier (Gribbly’s Day Out on the Pi – whilst at the title page) was triggering 4m Aborts/sec if my debug stats are correct (need to double-check its reporting correctly), it didn’t seem to affect the speed though, it was happily refreshing the screen at 50fps. I did a double-take though and thought, wow, impressive! |
Jon Abbott (1421) 2609 posts |
As you can’t post pics etc on here, I’ve created a thread on the JASPP site for this. I’ll post pictures on there of my progress once the kit has arrived. |
Jon Abbott (1421) 2609 posts |
Tontec have promptly replied to my request for a TRM and driver source. I’ve posted the driver and am awaiting confirmation I can do the same for the TRM. I’ve put some information I’ve gleaned from the TRM up – it looks like it’s a perfect match to emulate VIDC1/20 which is a stroke of luck and doesn’t look like it will be complicated to develop the driver for. So long as I can figure out the SPI interface quickly, its probably only a few hours work provided I don’t hit any issues/gotchas. Just need all the kit to arrive now. |
David Feugey (2125) 2687 posts |
Really cool as a second screen, to print some useful information. I could use it also to manage invoices and tasks when working outside. For industrial design, we should ask Raik for some metal boxes (removable screen protection would be cool). A ready to drop solution. Just need some room to fit an USB charger. Only problem: no RTC can be fitted in such a product. |
Raik (463) 2030 posts |
Is this a comparable display I use for may HandPi but with a bigger resolution (my has 320×240)? |
Jon Abbott (1421) 2609 posts |
That was my thinking, for debugger information although with a GraphicsV driver it could be used as a 2nd desktop screen using DA2 for the image. I think I’m right in saying there’s still some development required within RISCOS before that will be viable though. Jeffrey’s the expert in this area.
From the image, it looks like your screen is driven via GPIO? This is SPI, so the interface is probably different – display wise I suspect its near identical. I’ll post some pics up when it arrives, although I’ll need to code the driver before we get an image. The Pi2 just turned up, so I’m halfway there. |
Jeffrey Lee (213) 6046 posts |
Really cool as a second screen Yeah, we need to make some more changes to the OS in order to allow multiple screens to be used at once without having to resort to nasty hacks. Within the current limitations of the OS, the best reference for how to structure the SPI driver is probably the displaylink driver It works by allocating a block of physically contiguous memory using PCI_RAMAlloc and specifying that as the base of the framebuffer when GraphicsV 9 is called. UDLVideo uses the mapping that was created by PCI_RAMAlloc in order to read from the screen and construct the USB packets (comparing against a softcopy of the screen that’s held in another DA). Meanwhile, RISC OS (when the driver is activated) will create a second mapping of the PCI-allocated region which acts as the screen buffer used by the VDU drivers. This second is created by OS_Memory 13, so it’s permanent – not ideal if you unplug the device, the PCI RAM gets freed, and then used for something else. If drivers were given full control over the logical mapping of the screen memory then that should fix all of the issues with the current system, but other things on my todo list and the looming RISC OS 5.22 release keep getting in my way. For your use case you might be able to get by with using DA 2 (avoiding the duplicate mapping of the driver’s memory), but that would also require some nasty hacks because in order for the driver to continue operating when it isn’t the active device it would have to query the OS to find the DA 2 (so the hack would be that the driver assumes it should be using DA 2 for its memory, rather than using its own internal memory or just relying on the OS to explicitly tell it what memory to use) It’s also worth looking at the handling of the UDLTest command in the displaylink driver (in module.c). In order to display a sprite on the screen without the driver being active it creates an empty sprite which matches the size & format of the displaylink screen, plots the test sprite into it, and then memcpy’s the pixels into the PCI memory. In most cases I probably could have created the sprite directly in the PCI memory, and just changed the DAG so that the screen start address was the first pixel of the sprite, but I was concerned about the extra memory needed for the sprite header causing buffer overflows, and so went down the route of creating a temp sprite. But in your case, as long as you control the memory yourself (e.g. don’t use DA 2) you could probably add the extra overhead of the sprite header into your initial PCI allocation and make it so that the framebuffer base/size returned by GraphicsV 9 takes into account the fact that the sprite header will always be present. That way when you want to show debug output on the screen you can simply redirect output to the sprite, using VDU save areas to preserve the state of the main screen & debug screen as you switch between them. Of course redirecting screen output isn’t a particularly lightweight operation, so if you were hoping to do debug output from interrupt handlers or arbitrary points in game code then it might be best to code your own text plotting routines and use those directly. (Preserving VDU state when switching drivers via GraphicsV is another thing on the todo list – at the moment the OS will always force a mode change) |
Raik (463) 2030 posts |
I take a look in my manual. Uses Hardware SPI Pins (SCK, MOSI, MISO, Ce0, CE1) and GPIO #25 und #24… |
Jon Abbott (1421) 2609 posts |
It certainly proved a big stumbling block to getting ADFFS to work – as you know. I’ve worked around the issue for the time being, but full logical control is definitely where we need to be.
This is already coded in ADFFS, I was simply going to lift it across for the GraphicsV driver. It essentially gets RISCOS to believe there’s a display device on DA2 and maintains the GPU in the background as a 2nd display – all be it hidden from the OS.
That’s how I’m planning on implementing the graphics memory in the Hypervisor. Each VM will have two GPU banks with a sprite header on the front, when you switch from full screen to windowed it simply switches to using SpriteOp to display them.
I have my own mirrors of all the OS_WriteN/S/0 SWI’s etc which I use to write directly to the GPU overlaying over the display. I’ll simply switch these to write to a dedicated DA for the 2nd screen and add a blitter hanging of RTSupport to update via SPI Most of what I need is already coded, I just need to implement the SPI bit.
It’s identical then, send me over the TRM if you have one, the driver I’m going to code may work for this screen as well. If you dont have the TRM, let me know the manufacture and I’ll contact them. |
Steve Pampling (1551) 7962 posts |
Hmm, must dig inside the Fujitsu Lifebook P1510 x 3 and see what would fit and drive the display. |
Jon Abbott (1421) 2609 posts |
I have a Compaq tc4200 here which is near identical to the Fujitsu Lifebook P1510 and was likewise going to see if I could shove a Pi in it. I might strip it down tomorrow to see what the video interface is. |
Raik (463) 2030 posts |
All I have you can download here Thanks a lot. |
Jon Abbott (1421) 2609 posts |
I’ve looked though MI0283QT-11 V1.1.pdf and it looks like a very similar command set, 2A, 2B to set row/column followed by a screen write, so it may be identical protocol wise. I doesn’t look like it has the ability to change the geometry though, so will need a fixed screen size in the driver – which shouldn’t be a problem as we won’t be shoving VIDC1 parameters down it like I’ll be trying with the one I ordered ;) I’ll get mine up and running and post the driver up, we’ll then have to try it on yours and modify as appropriate to end up with an Adafruit SPI screen driver. I don’t know who standard the commands are under SPI, so am not sure if a generic driver is possible or not, either way yours looks close enough to probably only require minor tweaks to possibly bitdepth and fixing the geometry size to the screen. |
Jon Abbott (1421) 2609 posts |
The screen arrived today, I’ve posted some pictures of assembly on the JASPP thread |
Bill Antonia (2466) 120 posts |
Have updated the PiSPI module to work with both Broadcom BCM2835 and BCM2836, download from here |
Antony Curtis (2799) 3 posts |
I have successfully used the PiSPI module to output to a ILI9341 type display but it is impressively slow taking several seconds to update the screen. |
Andrew Rawnsley (492) 1420 posts |
Whilst I can’t comment on Pi SPI implementation, I can say that SPI stuff has recently begun to be checked into the source tree based on our work on SPI for i.MX6 for a commercial customer who requires that functionality. I’d imagine that the faster nature of the hardware, coupled with industrial requirements would mandate a respectable level of performance, so perhaps there is scope here to benefit everyone. I’d welcome emails from you if you’re willing, and can then involve you in the development process to ensure that everyone’s needs are met – usual R-Comp contact details etc. |
Mike Freestone (2564) 129 posts |
There’s a thread in the code review forum for talking about spi details. Presumably any ideas would be best added there so they can be seen rather than lost in your inbox |
Antony Curtis (2799) 3 posts |
Just FYI, I have done some stuff to drive a little SPI attached LCD display for a little project I have brewing… My blog post is at http://atcurtis.blogspot.com/2015/10/ili9341-spi-display-on-riscos-pico.html |