[Oberon] Pipistrello

Wed Jun 10 18:40:16 CEST 2020

Another solution is to use (at a very low cost) an ESP8266 or ESP32 to bridge on the net throug WiFi. This is the kind of solution used with The ULX3 board (see http://radiona.org/ulx3s/).

Guy

> On Jun 10, 2020, at 11:03 AM, Jörg <joerg.straube at iaeth.ch> wrote:
> 
> Daniel
> 
> Pipistrello is a small FPGA-based board, with 1 MB of SRAM and 64 MB of DRAM and an HDMI output
> https://sigrok.org/wiki/Saanlima_Pipistrello_OLS
> 
> I have it at home, run Oberon on it with more than 1MB and have a TCP/IP stack for this external board https://www.wiznet.io/product-item/wiz550io/ 
> 
> br
> Jörg
> 
> Am 10.06.20, 16:07 schrieb "Oberon im Auftrag von Daniel Schmid" <oberon-bounces at lists.inf.ethz.ch im Auftrag von daniel.schmid at bluemail.ch>:
> 
>    Dear Oberon-Mailing-Listeners
> 
>    I'm rather new in using Oberon (AOS/A2), nevertheless i found it to be very straightforward.
>    Currently i'm writing a server app to read out smart electricity meters over tcp/ip and it works
>    fine. Now i read about this "Pipistrello" - could anybody tell me what it is about - i'm looking for
>    a device/box/board to implement an smart IoT-Node to enhance smart metering further to a smart grid.
> 
>    Many thanks in advance for any explanations
>    Daniel Schmid
> 
>    Am Donnerstag, den 28.05.2020, 12:00 +0200 schrieb oberon-request at lists.inf.ethz.ch:
>> Send Oberon mailing list submissions to
>>    oberon at lists.inf.ethz.ch
>> 
>> To subscribe or unsubscribe via the World Wide Web, visit
>>    https://lists.inf.ethz.ch/mailman/listinfo/oberon
>> or, via email, send a message with subject or body 'help' to
>>    oberon-request at lists.inf.ethz.ch
>> 
>> You can reach the person managing the list at
>>    oberon-owner at lists.inf.ethz.ch
>> 
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Oberon digest..."
>> 
>> 
>> Today's Topics:
>> 
>>   1. Project Oberon running from LPDDR memory on Pipistrello, now
>>      with 8 bpp and 16 bpp color display modes (Magnus Karlsson)
>>   2. Re: Project Oberon running from LPDDR memory on Pipistrello,
>>      now with 8 bpp and 16 bpp color display modes (Magnus Karlsson)
>> 
>> 
>> ----------------------------------------------------------------------
>> 
>> Message: 1
>> Date: Wed, 27 May 2020 15:50:42 -0700
>> From: Magnus Karlsson <magnus at saanlima.com>
>> To: oberon at lists.inf.ethz.ch
>> Subject: [Oberon] Project Oberon running from LPDDR memory on
>>    Pipistrello, now with 8 bpp and 16 bpp color display modes
>> Message-ID: <af111d4b-b57f-9599-19d2-ecdcf62144fc at saanlima.com>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>> 
>> I have made updates to the code on github with the following changes:
>> 
>> * The code now has it's own repository with a master branch and two 
>> versions with color display added
>> * The mono display buffer in BRAM is now 160 KB, big enough for a 
>> 1440x900 display
>> * The CPU clock is now coming from the memory controller PLL, leaving 
>> the video PLL free to implement any frequency needed by the video controller
>> * The cache is now 64KB (2-way, 128-set, 256 bytes/cache line) to make 
>> room for the larger mono display buffer
>> * The color version have 8 bpp or 16 bpp color video added in parallel 
>> with the mono display.? 8 bpp needs 1.5 MB memory, 16 bpp needs 3 MB 
>> memory for display buffer
>> * The color buffer can be at any place in the 15.75 MB lpddr memory 
>> space (aligned to 16 bytes) controlled by a color buffer address register
>> * When using color display the cache needs to be flushed.? There are 
>> several ways to flush the cache - on demand by software, on every vsync 
>> and using auto-flush where a cache line is flushed every 1024 CPU clocks.
>> * The selection between mono display and color display is via a register 
>> bit.
>> 
>> J?rg Straube have successfully shown the code working in both 1440x900 
>> mono display mode and 8 bpp color display mode.
>> 
>> https://github.com/Saanlima/RISC5Verilog_lpddr
>> 
>> Cheers,
>> Magnus
>> 
>>> On 5/15/2020 7:53 AM, Magnus Karlsson wrote:
>>> The project have been updated at 
>>> https://github.com/Saanlima/Pipistrello/tree/master/Projects/Oberon_lpddr
>>> This version is based on the current RISC5 verilog code (dated 
>>> 11.12.2018).
>>> 
>>> System info:
>>> Cache size: 128 KB (2-way 256-set).
>>> Cached area: lower 15.75 MB of the RISC5 memory map is mapped to 
>>> cache/lpddr memory.
>>> The non-cached area (top 256 KB of the RISC5 memory map) is used for 
>>> I/O (top 4KB), boot prom (next 4KB), then a free 248 KB area where the 
>>> video display buffer can be relocated .
>>> Video buffer is in BRAM and is located at the default place at power 
>>> up but can be relocated anywhere in the memory map by simply writing 
>>> to a new 24-bit video base register.
>>> Since the video frame buffer is in non-cached BRAM there is no need to 
>>> flush the cache, which btw uses write-back policy.
>>> The system will be slowed down by cache misses but there is about 11% 
>>> gain by having the video buffer in BRAM (no cpu stalls due to video 
>>> controller memory access).
>>> 
>>> Magnus
>> 
>> 
>> ------------------------------
>> 
>> Message: 2
>> Date: Wed, 27 May 2020 16:05:49 -0700
>> From: Magnus Karlsson <magnus at saanlima.com>
>> To: oberon at lists.inf.ethz.ch
>> Subject: Re: [Oberon] Project Oberon running from LPDDR memory on
>>    Pipistrello, now with 8 bpp and 16 bpp color display modes
>> Message-ID: <3327a10d-9360-08d1-8bec-dc79a8020a73 at saanlima.com>
>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>> 
>> Correction:
>> 8 bpp needs 0.75 MB memory, 16 bpp needs 1.5 MB memory for display buffer
>> 
>>> On 5/27/2020 3:50 PM, Magnus Karlsson wrote:
>>> I have made updates to the code on github with the following changes:
>>> 
>>> * The code now has it's own repository with a master branch and two 
>>> versions with color display added
>>> * The mono display buffer in BRAM is now 160 KB, big enough for a 
>>> 1440x900 display
>>> * The CPU clock is now coming from the memory controller PLL, leaving 
>>> the video PLL free to implement any frequency needed by the video 
>>> controller
>>> * The cache is now 64KB (2-way, 128-set, 256 bytes/cache line) to make 
>>> room for the larger mono display buffer
>>> * The color version have 8 bpp or 16 bpp color video added in parallel 
>>> with the mono display. /8 bpp needs 0.75 MB memory, 16 bpp needs 1.5 
>>> MB memory for display buffer /
>>> * The color buffer can be at any place in the 15.75 MB lpddr memory 
>>> space (aligned to 16 bytes) controlled by a color buffer address register
>>> * When using color display the cache needs to be flushed.? There are 
>>> several ways to flush the cache - on demand by software, on every 
>>> vsync and using auto-flush where a cache line is flushed every 1024 
>>> CPU clocks.
>>> * The selection between mono display and color display is via a 
>>> register bit.
>>> 
>>> J?rg Straube have successfully shown the code working in both 1440x900 
>>> mono display mode and 8 bpp color display mode.
>>> 
>>> https://github.com/Saanlima/RISC5Verilog_lpddr
>>> 
>>> Cheers,
>>> Magnus
>>> 
>>> On 5/15/2020 7:53 AM, Magnus Karlsson wrote:
>>>> The project have been updated at 
>>>> https://github.com/Saanlima/Pipistrello/tree/master/Projects/Oberon_lpddr
>>>> This version is based on the current RISC5 verilog code (dated 
>>>> 11.12.2018).
>>>> 
>>>> System info:
>>>> Cache size: 128 KB (2-way 256-set).
>>>> Cached area: lower 15.75 MB of the RISC5 memory map is mapped to 
>>>> cache/lpddr memory.
>>>> The non-cached area (top 256 KB of the RISC5 memory map) is used for 
>>>> I/O (top 4KB), boot prom (next 4KB), then a free 248 KB area where 
>>>> the video display buffer can be relocated .
>>>> Video buffer is in BRAM and is located at the default place at power 
>>>> up but can be relocated anywhere in the memory map by simply writing 
>>>> to a new 24-bit video base register.
>>>> Since the video frame buffer is in non-cached BRAM there is no need 
>>>> to flush the cache, which btw uses write-back policy.
>>>> The system will be slowed down by cache misses but there is about 11% 
>>>> gain by having the video buffer in BRAM (no cpu stalls due to video 
>>>> controller memory access).
>>>> 
>>>> Magnus
>>> 
>>> -- 
>>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>> 
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20200527/fc6ac11a/attachment-0001.html
>>> 
>> 
>> ------------------------------
>> 
>> Subject: Digest Footer
>> 
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>> 
>> 
>> ------------------------------
>> 
>> End of Oberon Digest, Vol 192, Issue 43
>> ***************************************
> 
>    --
>    Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>    https://lists.inf.ethz.ch/mailman/listinfo/oberon
> 
> 
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20200610/a006bc33/attachment-0001.html>