You may want to make an estimate of the CPU load using Blitz, and see if Blitz can perform the polling and update the graphics from just one instance. rewrote the code so it doesn't happen but no clue why it happened in the 1st place.Ĭomments appreciated and no intent of being arguementative. Been fighting what appears to be memory leak. I do not understand Blitz's event system enough (I think because it appears to be user-event driven whereas user events are a minor fraction of a minor fraction of what I am trying to do) to take full advantage of it. GDI is an option and have mildly touched on it. Windows is a bit of change (not fresh air either ) Usually tinker with RTC on micro's where I control what is going on. can it be done and if so how?Ĭould have each instance write images(s) to a RAMDisk and have the main read/write them. Once the the overhead involved was sorted out I could then determine the viability of the method. Was hoping I could 'poke' into the main pages VRAM easily. What I was hoping for was each instance would be responsible for a video region (viewport(s) if you will). Not a whole lot of 'data' being passed BTW. The 'main' will get the ADC data from the 6 instances (all ADC measurements reading different things and each ADC/USB instance with its own math/etc) and then decide what the instances should 'tell' the uC's. it isn't 6 joysticks :) I'll spring what it is once I figure out if it can be done. The # of events per 'time period' can change considerably in a very short period of time but I do have some room per USB channel as to when I send/rcv data. Each uC will be doing the apps critical timing (PWM) and ADC. each USB port connected to a microcontroller (uC). Yes this is a proto for a public domain effort. How to do that was another issue after I sorted out the vid. or if need be, actually 'suspend' them) once signaled to do so to give the main more breathing room. was avoiding the 'other' details :) Intent was to control the other processes by having them 'suspend' themselves (or do less. Understand the distribution of work/CPU time. By doing so, you would probably lose the benefits of being able to use Blitz' graphics commands and event system. Or is this just a prototype? How does the embedded system work, anyway (unless it's too detailed.)?Īnyway, you could "capture" a portion of the main process' display, but you would have to use GDI and associated WinAPI calls. Otherwise, it wouldn't make much sense because the same CPU/GPU would be doing the work, no matter the process. I assume this is occurring on a distributed, or, at the very least, multiprocessor system. If this can be made to work it opens up a number of possibilities. A lot of considerations and am investigating every method. It will act as the 'scheduler' in a fast > real-time << embedded system. The intent is to offload the main from doing any graphics processing at all. One of the things that comes to mind is why you must have each subprocess draw - why can't you send a message to the main process and have it draw on its own canvas.Īs for the 3rd. What I don't have a clue about is have the 'main' load the background image (1024x768) and have the unique instances use viewports 'onto' that image.ĭoes this mean you want each blitz "process" to be able to draw on parts of the main image (on the "main" or "server" process), or you want parts of the image to be copied, becoming the main canvas on each "sub" process?
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |