multicore - freeze
marcinszajner opened this issue · comments
Hi LdB again,
I testing your multicore code on raspberry pi 3 A+, and there is problem because raspberry freeze after few second of work. Problem could be from overflow framebuffer? We just add new lines for buffer and it went overflow then raspberry pi get probably some error. Most easy resolve of problem (in my opinion) could be move caret to oldest line (begin) with erase this line when caret is out of screen (buffer)? What you think?
Best Regards,
Lazor
Yes the problem is there is no roll of screen .. wooops forgot that.
I have done a new console which supports ansi colours for my upcoming muticore scheduler samples, I think I will just include it.
How many cycle scheduler will take? I thought about xenomai but deterministic task switch was 12kHz, this is slow for my requirements, but your example show I could use asymmetric multiprocessing. With small program (150-200 instructions - read GPIO, do some calculation and write to GPIO) I could probably trigger this task on separeted core up to 10Mhz. What you think about this?
I answered you by private email and haven't heard back so i will close the issue for now.
Hi,
This a bit strange. I don't received any mail... probably I have some issue with account setting... Could you forward me this message to marcinszajner@gmail.com ?
The Raspberry Pi GPIO is quite slow it can only maximally handle 68Mhz on a Pi3
https://github.com/hzeller/rpi-gpio-dma-demo
I suspect you have no chance of setting up a task in the manner you are thinking
You would probably have to just dedicate 1 core to just that feature.
thanks for answer. Yes I thinking about one core for this "task". I think about this test from hzeller, and maybe he should use some barier instruction? Or is done by CPU because it strongly ordered memory region?
68Mhz is crazy, That could ended with damaged raspberry (heavy capacitive load).
I bought some DAC with 8bit parallel interface, I can do easy concept proof and share result on github of course if you will allow me use part of your code.
With what he is doing weak-order does not come into play. Be clear what needs a fence is when peripheral requests are being issued in-order and expecting the response to come back be in-order. There is nothing in that code that requires that pattern as what is being read and written are asynchronous. It is synchronous or cache issues that requires the use memory barriers.
You follow normal rules when dealing with high speed IO lines and should buffer them.
My code is released as public with attribution, the notice is shown on the top of all the main files.