I'm making an adventure with Inform 7. In the adventure, you can pick up a chip. I want to be able to pick up a thing called a pocket computer if you have the chip in your inventory. To put it in a possible inform sentence:
If chip is in the inventory, take pocket computer.
I think you'd be best served by going about it the other way. After all, portable objects normally can be picked up; what you seem to want to do is to prevent taking it if they don't have the chip. I think something like this could work:
Instead of taking the pocket computer when the player does not have the chip:
say "You need the chip first!"
However, I would consider whether it is reasonable to prevent the player from picking it up. Is the pocket computer fixed in place somehow, and the chip is required to unlock it? Or is it simply that the computer isn't useful until they have the chip? If the latter is the case, I would suggest that you still allow the player to pick it up, since in real life there would be nothing preventing them from doing so. It breaks immersion to prevent a reasonable action simply because it isn't useful yet.
Related
My project is to create an interactive program using the Micro:bit microprocessor I'm building a game which uses a drill motor as a controller of sorts reading the rotation direction and speed as inputs for control
but my mentor also said it would be cool to power the board at the same time as the game is running so now I hit the situation where once I stop turning to change direction or my speed goes below transmitting 3.3 volts to power it then the game restarts and I lose all progress
I had the Idea of using a second micro:bit as a sort of storage place being powered by my computer and the two continuously communicating sending back player position and other objects on the LED's
but i can't figure out how to get the two Micro:bit's to talk to each other
If someone could just point me in the right direction or even set up some sort of communication to nudge me in the right direction as I start moving forward
i'm a high school student who doesn't know as much as I pretend to so I'll probably need a lot of help (i am more advanced then most in my class at this sort of thing so think of me as a tech gifted teenager thrown in with college students losing my undeserved ego day by day LOL) please help me somehow I'm currently completely lost
You won't be able to use Bluetooth for the reasons indicated in the documentation (not enough memory): http://microbit-micropython.readthedocs.io/en/latest/ble.html
However, there is an incoming implementation of the lighter radio module, which would allow you to send simple data: https://github.com/bbcmicrobit/micropython/pull/283
The proposed documentation can be found in: https://github.com/bbcmicrobit/micropython/pull/305
As you can see in GitHub, at the time of writing it has not yet been merged into micropython. So if you'd like to try it you would have to clone the repository, apply the patch and build it from source. Keep in mind there is risk for the API to change, as there are still discussions about it.
Alternatively, as Sean has mentioned, you can use the C++ DAL implementation of the radio module to get something running on the meantime. Or if you prefer, the blocks and touch develop languages also offer radio functionality.
I don't think there is a way to do this in micropython (or at least simply), but the microbit runtime docs describe that, as well as supporting bluetooth, the 2.4 GHz radio:
However, it can also be placed into a much simpler mode of operation based that allows simple, direct micro:bit to micro:bit communication
In order to use this, you might need to write in c++ using the mbed environment (or offline) - but I hope this at least gives you a pointer to start from.
Here's a blog post describing how to do data logging using two microbits in exactly the configuration you describe.
http://www.suppertime.co.uk/blogmywiki/2016/06/microbit-logger
How to get the two micro:bits to talk to each other
As of 2016, you can! First check micropython has the radio module
import radio
If you get the error "No module named 'radio'", use https://codewith.mu/
Then follow the radio tutorial https://microbit-micropython.readthedocs.io/en/latest/tutorials/radio.html
The API is
https://microbit-micropython.readthedocs.io/en/latest/radio.html
I've ripped open an old Pentium desktop. The main board is a Zida 5svx. I got to know from the manual (which i downloaded from the internet) the location of the ROM chip on the board, and took it out. It was mentioned in the manual that the chip was a Flash EEPROM.
Now, what I am interested in is this: Is there a way to erase the ROM and flash it with, say a C program to blink an LED (i know this might put you into a fit of laughter, but read on all the same), or control a motor?
I also want to know if I can construct a mega-sized micro-controller with the left-over Pentium, some MBs of RAM, and this ROM.
Any suggestions?
P.S: I know that such a uC will require appropriate power supply setup and things.
The key is in getting and deeply studying the manufacturer's datasheets for each device you remove and wish to reuse. I am supposing that since you asked the question that you did that you are not a professional electrical engineer - that's OK, but you will need to do hours, days, or weeks of study to truly understand the datasheets well enough to successfully reuse your motherboard chips because they are written for professional engineers with years of experience, and unfortunately they were not written to be understood by hobbyists. If you can succeed in acquiring and thoroughly understanding all of the datasheets (and the related user's guides as well for the more complex chips) then you have made it to the point where you might be able to start a custom design based on your recovered parts, on paper at least. In order to test your design and insure that each part of it is working will require at least an oscilloscope and volt meter - and the knowledge of how to use them. An understanding of basic electronics is essential, you will not succeed without it. Very good soldering/rework/assembly skills will be required as well if you hope to have your design truly work - you can do everything else right and it can still fail if your skills in this area are lacking. There is simply not enough time for me to advise you on everything you will need to know - but if you are motivated, dedicated, and you don't give up when setbacks and roadblocks occur (and trust me, they occur all too frequently for even the best engineers and best designs) - meaning that you are not easily frustrated when things don't work - then you have a chance at success. I wish you all the best, and try to have fun while doing it (important in case fun is all you ever get out of your project). :)
Are there any tips for reading source code samples from manufacturer of MCUs'.
I am a newbie for mcu programming, currently I have a MCU, datasheet and sample codes for them. But problem is sample codes are seems written for experienced users. Too many questions about why they initialized RS232, why they set 4th bit of port 1 and etc.,
Do you have a tips for reading or links where can I get info about how to read datasheets and sample codes of MCU?
I guess experience is the only answer I can give. Just like with programming in general, with time you acquire experience as well as learn buzz words and concepts. With microcontrollers you learn to read datasheets, schematics, etc. Learn about open drain, open collector, weak pull ups, etc. And for serial ports for some reason they are always overcomplicated. The hardest part with microcontrollers and the serial port is usually figuring out what to program to get the right clock divisors, some microcontroller serial ports are straight forward, others are overly complicated, some docs are good some docs are bad, etc.
Another answer is datasheets are always wrong. There are always gaps in the information that you have to hack to figure out. Do not write thousands of lines of code in a vaccuum using only a datasheet, write a small amount of code a few lines to a few dozen, test, and move on, you can get more lines written and debugged in a day when programming from a datasheet than the other path. The datasheets are often not written by the engineers that actually designed the hardware, sometimes it is a junior engineer or a non-engineer. Sometimes the information is simply wrong, sometimes the document is for a different but similar part than the one you have. If they provide software that actually does stuff it is sometimes (not always) more accurate than the datasheet (when I say datasheet assume the users manual, programmers reference manual, whatever the vendor calls the doc with the registers, addressses, and bit definitions for the hardware).
With time and experience you may find, if you take a wide enough view, that some vendors tend to do a better job at providing information to users, others do not, some bury the secrets in libraries, sometimes in binary form and not source. Sometimes the secrets are buried in compilers and other tools they provide (well that is back to apis and libraries). I tend to blacklist such companies, but sometimes you cant always. ARM for example does a very good job of providing the information. the problem is they have so many cores with a number of options each, that are very similar in nature (support the same instruction sets) that it can be difficult to sort through what the one processor you are using that moment does and does not from the docs. Atmel, something about atmel that is hard to put a finger on, the docs are generally well above par, but more than that something about atmel makes them popular with the customers. You will never see an arduino like following, culture, pick a word, with a microchip pic for example. There are a lot of pic followers but it is not like the atmel world (which was there well before the arduino thing happened).
Another note, you might not understand with a single example program and single datasheet the history of a product, there might be code that has been used for a number of chip generations, and there might for example be a bit that is required by an older chip or newer chip and to share the same code that bit is manipulated. that bit might make sense looking at one datasheet and no sense looking at another. this is where hacking comes, in try it without, see what happens. maybe study other parts in the family that this code is said to support it might make more sense.
google is your friend or whatever favorite search engine, find as much open source code and other items for the particular device or whatever. At this level hacking is required, I dont use that term in the bad sense, hacking in the sense that you have to try some of the bits documented in the datasheet, see if that actually works, if not then see what it does if possible, look at other source code and see from that if you can figure it out. Just like there is no perfect car that gets infinite miles per gallon, completely safe, lasts forever, and is inexpensive, there is no perfect chip with the perfect datasheet and sample code. If you want to work at this software/hardware level you have to get your hands dirty, have to not be afraid to let some smoke out of the chips (there is a finite amount of smoke in a chip if you let even a little bit out it wont work), etc.
If the reason you wont ask specifically about the mcu or register you are working with is because it is closed source products or behind an NDA then you probably have access to the company that makes that product and you should be able to get support from them. Usually better support than you would get from a company that you dont have to sign an NDA for. Not that open document, open source companies are bad, just that if the company you buy from is interested in you to the point of showing internally protected information they are interested enough to give you better access to the real engineers that made/know the product. If this is not the case and you are able to talk about it, dont be afraid to just post a question to SO about the register and bits you are wondering about.
Sample code and flow charts in the MCU datasheets are good starting point to initialize a specific peripheral (like RS232).
You just start from there, and track the bit information and what it does, in MCU datasheet.
One of my friends is planning to set up a online classroom sort of environment and currently is evaluating the various ISP/Connection options he can have. Though he certainly needs a 100% up time of the internet connection, it can be compromised to like 99.X% for a good internet speed. Also since he is just starting up, 'price' too is a constraint but quality should not be compromised.
VSat link is one of the options that we know that might work out but I am very confused googling on the benifts of a VSat link as compared to a leased line. I feel a 2 MBPS leased line(may be 2) can suffice.
What should be the right connection? Any thoughts?
VSat is going to have a noticeable delay if you're doing anything interactive. It's also prone to weather (heavy storms, snow, can affect the quality of the link). Also, are you in a remote area or a developing country? If you're not, then you should just go with some business DSL line.
Does anyone know of a good gaze tracking library I can use with consumer hardware (I have a MacBook Pro on hand that I can put Windows or Linux on, and can acquire a selection of consumer to prosumer grade cameras) to build a very simple visual typing interface with?
Essentially so that the user can look at a keyboard (fullscreen) and blink to click the key. Or something like that. It needs to be something users are already familiar with (QWERTY).
Before I get all non-technical, check out Dasher. I used it for a long while on my handheld to type out long messages and it works like a charm. No hunting and pecking, just stare in the direction you want it to move (I used my stylus).
My grandfather was paralyzed from the eyes down from a stroke when I was just a baby. My grandmother worked out a way of talking to him using a piece of cardboard. She had three rows of letters: 1st half, 2nd half, and 3rd half (yes, third half. why, I don't know). The first half had letters A-H, second had I-Q, third had R-Z. She would hold the card up and go through his message letter-by-letter. He would blink when he wanted to choose a letter.
First, she would ask about which half: "First half? Second half?" etc. He would blink when she was on the right one. Then she would start reading off letters and he would blink when she got to the right one. She would right it down.
There was no "space", so you need to do some guess-work to determine some meanings.
Granted, this isn't as "techie" or cool as you might hope for, but it's a hell of a lot more personal than coldly blinking at a computer screen. Also, if the family is going to be using this with her, guess who's going to be touching the computer when you're gone? Not you, and not her. And families aren't great with computers.
Just a suggestion, and it only takes about five minutes to make, requires a sharpie and a pizza box, and only about a minute or two to explain. Sure, it's tedious, but it's also simple and effective.
Look at http://www.cogain.org/eyetrackers/low-cost-eye-trackers
there are free and open source offerings listed there, including one from codeproject (C++)
Windows 10, as of the Fall Creator's Update, has built-in support for Eye Control and the feature also includes a speech keyboard for communication.
The feature works with any of the supported eye tracking devices, one of which is a low cost but high quality consumer focused product, the Tobii Eye Tracker 4C.
For programmers Windows 10 exposes the Gaze APIs and there is also an open source gazeinteraction library that is part of the Windows Community Toolkit to make it very simple to create a UWP application that responds to your eyes.