I've been developing a web interface for a simple raspberry pi project. It's only turning lights on and off, but I've been trying to add a dimming feature with PWM.
I'm using modWSGI with Apache, and RPi.GPIO for GPIO access. For my prototype I'm using (3) SN74HC595's in series for the LED outputs, and am trying to PWM the OE line to dim the lights.
Operating the shift registers is easy, because they hold the outputs in between updates. However, for PWM to work the GPIO.PWM instance must stay active between WSGI sessions. This is what I'm having trouble with. I've been working on this for a few days, and saw a couple similar questions here. But nothing for active objects like PWM, only simple counters and such.
My two thoughts are:
1) Use the global scope to hold the PWM object, and use PWM.ChangeDutyCycle() in the WSGI function to change brightness. This approach has worked before, but it seems like it might not here.
Or 2) Create a system level daemon (or something) and make calls to that from within my WSGI function.
Very important with mod_wsgi if you need things in memory to persist across requests, is that you must use mod_wsgi daemon mode and not embedded mode. Embedded mode is the default though, so you need to make sure you are configuring it. The default for daemon mode is single process and so requests will always hit the same process. It is still multithreaded though, so make sure you are protecting global data access/update with thread locking.
Details on embedded vs daemon mode in:
http://modwsgi.readthedocs.io/en/develop/user-guides/processes-and-threading.html
You will see some example about daemon mode in document which also explains how you should be configuring your virtual environment.
http://modwsgi.readthedocs.io/en/develop/user-guides/virtual-environments.html
For anyone looking at this in 2020:
I changed mod_wsgi to single thread mode. I'm not sure if it's related to Python, mod_wsgi, or bad juju, but it still would not last long term. After a few hours the PWM would stop at full off.
I tried rolling my own PWM daemon, but ultimately went with the pigpio module (is Joan on SE?). It's been working perfect for me.
Related
I'm facing an unexpected problem with stm32f103c8. I'm programming the chip and after reset, it starts to run the program, but after a few seconds the microcontroller getting mixed up and stops running the program. After that when I try to reprogram the microcontroller, IDE(IAR EWARM) tells "target held in reset state".
It's very unusual issue because sometimes when I connect nRST pin directly to the VCC(3.3V), microcontroller runs program but unfortunately the current goes over 120mA and chip breaks down finally.
I'm using STM32CubeMX to generate the codes and my programmer is STLINK V2(clone), also tried Jlink V8.0(clone) but didn't change the result.
Could it be because of the clone programmers?
Can anyone help me solve this problem?
Thanks
Never connect nRST directly to VDD/VCC. This is a bi-directional input-output which must only ever be connected to an open-drain/open-collector signal. It can be pulled low externally or from within, it must never ever be pulled or driven high other than by the internal pull-up resistor.
When your debugger or programmer has finished programming the flash and wants to start running the new program then it requires to be able to pull this line low, which it might do externally if you connect this line to it in hardware, or else it has to be able to pull it low by software using the internal reset pulse-generator. If it does this and you have tied the line high externally then you are effectively shorting out your power supply, which is the cause of the over-current condition that you have observed.
Maybe the original problem is that your counterfeit ST-Link has its reset output configured as push-pull when it should be open-drain.
I would suggest that the easiest way to proceed is to leave the nRST line unconnected and configure your programming tool to use a software reset only.
In the Sparc V8 architecture we have some N register windows. Generally an RTOS during context switching pushes and pops registers. Is it possible( or already has been done) to use each of these register windows as one of the thread. This will make switching onto next thread as good as shifting register window and pushing and popping PSR ! Thus saving context switching time and enabling faster context switching frequency.
Maybe, it depends on what you mean by threads and how many.
The register windows are built around the idea of function calls and returns, implementing this in hardware and software traps with well defined operation. If your threads are just functions that get called in a round robin fashion etc... then yes they will get switched in this manner as will any other functions called from your "thread". That said once your have more functions than the number of register windows they will start getting paged in and out of the register file.
From the perspective of OS and User code... you don't have control of what happens when you enter and leave a register window as that is implemented as a trap as I understand it probably in the firmware. If you go changing how that works you aren't running a Sparc anymore because what it does there is defined in the Spec.
The whole point of Register windows has always been fast context switching.. but other aspects of Sparc hardware such as the TLB can get in the way of that... in the context of a Sparc MCU with a flat address space... then yeah it would be really fast.
My question is quite simple.
I encountered this sys_vm86old syscall (when reverse engineering) and I am trying to understand what it does.
I found two sources that could give me something but I'm still not sure that I fully understand; these sources are
The Source Code and this page which gives me this paragraph (but it's more readable directly on the link):
config GRKERNSEC_VM86
bool "Restrict VM86 mode"
depends on X86_32
help:
If you say Y here, only processes with CAP_SYS_RAWIO will be able to
make use of a special execution mode on 32bit x86 processors called
Virtual 8086 (VM86) mode. XFree86 may need vm86 mode for certain
video cards and will still work with this option enabled. The purpose
of the option is to prevent exploitation of emulation errors in
virtualization of vm86 mode like the one discovered in VMWare in 2009.
Nearly all users should be able to enable this option.
From what I understood, it would ensure that the calling process has cap_sys_rawio enabled. But this doesn't help me a lot...
Can anybody tell me ?
Thank you
The syscall is used to execute code in VM86 mode. This mode allows you to run old "real mode" 32bit code (like present in some BIOS) inside a protected mode OS.
See for example the Wikipedia article on it: https://en.wikipedia.org/wiki/Virtual_8086_mode
The setting you found means you need CAP_SYS_RAWIO to invoke the syscall.
I think X11 especially is using it to call BIOS methods for switching the video mode. There are two syscalls, the one with old suffix offers less operations but is retained for binary (ABI) compatibility.
I think my questions are unusual, but I wanna work on real time targeting in MATLAB Simulink, but I don't want to use XPC target. I just want no interrupt on the program (simulink) when it is running in order to have a real time interruptless control system. and in that order i can use my control module without target system.
first of all, please ignore my weak english. and I have some questions:
1. can we force a core to only be used by simulink and nothing else?
2. how much usually (and how much maximum) does an interrupt take time?
3. is there any other way that we can use in simulink?
thank you
a. In case you have a multicore platform: Stay away from core 0. Windows assigns certain tasks specifically to core 0. See the SetThreadAffinityMask function to get information how to run a thread on specific cores.
b. Possibly raise the thread/process priority. See the SetThreadPriority function and the SetPriorityClass function for details about setting priorities and Scheduling Priorities for dertails about the priority ranges.
Priority class REALTIME_PRIORITY_CLASS with thread priority THREAD_PRIORITY_TIME_CRITICAL will run your thread at utmost priority whenever it is ready to run. Be aware that such a priority setting will disallow any other process/thread to gain CPU on that core while your thread is running.
Well, Simulink is essentially a single-threaded application. There are some ways in which you can use a second core when running in Rapid Accelerator mode (see documentation), but by and large, everything runs on one core. I'm guessing it may change in the future, as a lot of people would like to split the execution of a single large model across multiple cores, but right now it's not possible as far as I know.
Simulink, however is not a real-time application, given that it runs on Windows or other non-real time O/S. Why do you not want to use xPC Target? As you are working on a real-time target, that would be the best option. Other options would be to use Real-Time Windows Target, SIL or even PIL if you have access to your real-time target hardware. Have a look at the example Software and Processor-in-the-Loop (SIL and PIL) Simulation. I think you can configure the code generation process to be executed on one core only, but better to ask MathWorks to be sure.
Using imageCFG you can preset affinity of a program. It modifies the exe file to run on desired core.
http://www2.robpol86.com/guides/ImageCFG/
RESOLVED
After much confusion and frustration, I finally got my hard disk to interrupt. :D It basically came down to the fact that I kept reading the status register instead of the alternate status register. A few other things were messed up to boot, but the point is my hard disk driver is finally starting to take shape. Now, for others I will leave the original post.
P.S. For further clarification, I didn't need to issue any sort of reset command. All I did was the following:
Select the device (didn't want to kill the Solaris OS on the other disk)
clear the nIEN bit in the DEVICE CONTROL register
issue an IDENTIFY DEVICE command***
Actually, I am not sure if the IDENTIFY DEVICE command is need because I left the lab happy before I could test the code without issuing the command. However, the main point is that I needed to be sure to read the alternate status register and have the nIEN bit cleared without the need for a reset. The BIOS apparently takes care of most stuff.
I am currently trying to write a disk driver for a hobby OS being developed at my school. I currently have routines to read/write data in the PCI configuration space and assembly routines to do port IO with the various registers defined by ATA/ATAPI-7. Now, my question is, specifically how will I get an IDE hard drive to start generating interrupts? I have been looking through all this documentation and is hasn't become clear to me what I am doing wrong.
Can someone explain exactly what causes an IDE hard drive to start generating interrupts? I already have an interrupts service routine ready to test, but am having difficulty getting the interrupts in the first place. Can this be accomplished through the ATA SOFT RESET?
Thanks!
UPDATE: Ok, I was able to get the secondary channel, an ATAPI CDROM to generate interrupts by setting the SRST bit in the DEVICE CONTROL register for a soft reset. This does not work for the hard disk on the primary channel. What I have noticed so far is that when I set the SRST bit for the HDD, it sets the BSY bit and leaves it set. From there I don't know what to do.
This reference should help you a fair bit: Kenos description of programming ATA/ATAPI.
The basic mechanism to enable interrupts is to clear nIEN in the DCR (Device Control Register):
nIEN: Drive Interrupt Enable bit. The enable bit for the drive interrupt to the host. When nIEN is 0 or the drive is selected the host interrupt signal INTRQ is enabled through a tri state buffer to the host. When nIEN is 1 or the drive is not selected the host interrupt signal INTRQ is in a high impedance state regardless of the presence or absence of a pending interrupt.
This www.ata-atapi.com is a good jumping-off point to find way more info about ATA/PATA/SATA/ATAPI than you want to know... Note that the official ATA-6/7/etc specs cost $$ from T13, though you can download current drafts of ATA-8 from them.
This link describes a few of the many ways ATA devices vary from the specs. (I used to write SCSI and ATA/ATAPI drivers for Commodore/Amiga, way back when, as well as help with qualifying drives - or more accurately, figuring out what idiocies drive makers had done.)
if this is just a hobby OS, why not use the BIOS interrupt (int 13h)? admittedly not as fast as direct disk access but safer for your hard drive (I've put a read head through a plate before messing with disk I/O).