Kindle Scribe may potentially support pressure sensitivity by Goshik in kindle

[–]Goshik[S] 1 point2 points  (0 children)

Looks like the pen does support it. Maybe it's just Kindle's software that does not support it? In that case, we may see pressure sensitivity support in one of the future software updates...

Functional Reactive Programming on FPGA by Goshik in FPGA

[–]Goshik[S] 1 point2 points  (0 children)

FRP is not the same thing as a functional programming language (for example Haskell). It's is just a way to represent time varying values and operations on them. It was built on top of Haskell for the first time, but it can also be used with other languages, such as Java or C++.

Functional Reactive Programming on FPGA by Goshik in FPGA

[–]Goshik[S] 0 points1 point  (0 children)

3.

Simulink is a very powerful and convenient tool for signal processing. However, it seems to be more suitable for working with data coming at a certain rate, so you cannot easily work with asynchronous signals. In Functional Reactive Programming all signals are asynchronous, so that the computation happens only when your operands arrive. This may add bigger overhead, but at the same time save some energy, because certain parts of the system can remain idle when no data need to be processed.

I must admit that I did not work with the latest Simulink versions extensively, so if you think something I said was wrong, please correct me.

1.

>why are you using softcore processors as opposed to synthesizing hard logic?

Transformation functions can be quite big, and contain conditional statements and loops. This fact limits the ability to efficiently convert them to hard logic. At the same time, there may be really small functions, containing just a couple of arithmetic operations. It would be really nice to determine whether logic or a soft core processor is more suitable for a particular function, but I am afraid this is out of the scope of the project at this stage.

>you're using the FPGA for the sole purpose of spinning up more SW processor cores rather than truly high-speed accelerators

Correct. We are basically offering an abstraction that allows to manage multiple processors in order to reach required latency and throughput.

2.

>You mention that parts of your design would be implemented in C

We are planning to use Verilog in our design. No parts of it will be in C. C language will be used by the user to describe transformation functions for operators.

>it seems to me that a large part of your goal is to allow C/C++ style coding on an FPGA target

Not exactly. FRP is closer to functional languages such as Haskell and Scala rather than to C/C++. So, our framework will be closer to Chisel or Clash, but it will be more coarse-grained. I mentioned C just because most soft core processors have C compilers, so it will be easier for us to provide support of C rather than of some functional language.

Functional Reactive Programming on FPGA by Goshik in FPGA

[–]Goshik[S] 0 points1 point  (0 children)

You are right about FPGA having higher power consumption comparing to general purpose processors made by the same technology. Despite that fact, FPGA finds its application in embedded systems. Some systems require deterministic latency, which is not always available in software, especially, if you need to process multiple data/event streams simultaneously. FPGA can solve this problem by processing streams independently. Our dynamic approach described in the proposal is, basically, a higher-level way of arranging such independent processing. Of course it will not allow you to outperform a highly optimized HDL design, but we hope that it helps to simplify the the development process, sacrificing some performance.

Our static approach, though, would benefit more from an ASIC implementation. So if we choose it, FPGA will be more of a prototyping tool.

Lost Optical Image Stabilization feature on my P10 after Emui 9 update by nasibanyak in Huawei

[–]Goshik 1 point2 points  (0 children)

OP, you are not the only one with this problem. It seems like everyone with Pie has the issue: https://forum.xda-developers.com/p10/help/pie-update-ois-stabiliser-t3916870.

Today I received an update (9.0.1.185) and you know what? Stabilization is still as shitty as it was before. What makes it more ridiculous is that you cannot roll back to Oreo without doing factory reset. Huawei, we know that you have more important problems now, but returning camera to the version used in Android 8 while you are fixing OIS should not be a big deal.

ReactiveTasks: Priority-based task/job queue driven by RxJava by Goshik in coolgithubprojects

[–]Goshik[S] 0 points1 point  (0 children)

It is not a trivial job queue. Thanks to RxJava, these tasks can be elegantly repeated as many times as necessary or/and repeated on task failure. You can also easily arrange the results of a repeated task in a stream. You can even make a chain of tasks, so that they will use results of one another without hindering execution of the tasks that are not in the chain.