 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : uMite + Parallax Hackable Badge
Page 1 of 4   |
|||||
| Author | Message | ||||
| dasyar Regular Member  Joined: 13/04/2015 Location: United StatesPosts: 58 |
I just noticed that the uMite has the capability to use IR I/O. Now I am wondering if I could get my Parallax Hackable Badge (HB) to talk with the uMite via the IR? I saw in the manual the commands for doing this, but I am wondering if it can be set up to pass string data out the IR send. I get the impression the commands are for communicating with a remote control, but it did mention that it was intended to be used for comms between two uMites. I guess I need more explanation for this. The HB has an IR I/O set up, 38000 and 2400BAUD, and I believe that the uMite can work with a 38000 receive and send components, not sure about the BAUD rate. I have a uMite MKII 28 pin chip set up on a breadboard that is attached to a Raspberry Pi via the ttyAMA0 port. This works, but I noticed that when I use the CUTECOM Xmodem function, the file is not being received by the uMite. I tried putty serial mode, that works, but if I have to do a bigger uMite program, it would be a hassle to use the uMite EDIT to do this. Thanks |
||||
TassyJim Guru  Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
The IR is for Sony remotes and not IR serial. It would need modification to do as you require. As far as XMODEM on the uM, you could try using AUTOSAVE instead. It you can 'paste' the file into CUTECOM, AUTOSAVE should work and can end up a bit faster than XMODEM. You will need a delay between lines. I am not sure how you set delays in CUTECOM. Jim VK7JH MMedit |
||||
| dasyar Regular Member Joined: 13/04/2015 Location: United StatesPosts: 58 |
So I guess the next question is, is there any serial IR code available? I would really like to get the uMite to work with the Parallax Hackable Badge via serial IR. CUTECOM has a delay feature, I will have to try that with AUTOSAVE or streaming. CUTECOM has Xmodem, Ymodem, Zmodem, Kermit, and plain. I think the plain selection would be a streaming situation. |
||||
CircuitGizmos Guru Joined: 08/09/2011 Location: United StatesPosts: 1427 |
If what you are talking about is that the HB transmits data at 2400 baud by modulating IR at 38kHz (and also receiving similar signals) then the micromite should be able to do that. The IR signal transmitted by the HB would be demodulated into 2400 by a IR receiver module. uM would input this signal into a serial Rx line. The uM can PWM (50% duty) 38kHz and the 2400 baud Tx line that can be AND'd with transistors and fed to an IR LED to transmit to the HB. Micromites and Maximites! - Beginning Maximite |
||||
| dasyar Regular Member Joined: 13/04/2015 Location: United StatesPosts: 58 |
Yes, and the HB works in half duplex mode, it's either sending or receiving. The example code in the manual shows: 'IR dev, key, interrupt'. Does this mean that the 'dev' can be a string variable? And for the transmit: 'IR SEND pin, dev, cmd', again 'dev' is a string variable, not sure what the 'cmd' is. Now if 'dev' can only be a char, I guess that would mean that you would have to have some kind of routine that would break down a string into char values and send/receive a char at a time? The way I see it possibly working is, you press a button on the HB that sends an ID code out the IR, the uMite gets the ID code and responds by sending some requested information in a string format to the HB. An example, the HB has a softRTC program, now it would be nice if the uMite had an RTC where it could send, via the IR, an updated date time string to the HB on demand. Other examples could include other sensors that would be attached to the uMite, and those sensors could send data out the uMite via the IR. I know this kind of restricts it to a line of sight device, but you work with what you got. |
||||
| CircuitGizmos Guru Joined: 08/09/2011 Location: United StatesPosts: 1427 |
"then the micromite should be able to do that." No I didn't mean that the micromite would talk to the HB using the IR or IR SEND commands. My description is using the serial commands, which, if I understand what you are saying about the HB, is a "UART-ish" serial stream but modulated with 38kHz. Move away from the IR commands and just look at serial commands. An InfraRed receiver module strips away the 38kHz for reception of the received 2400 baud characters. You need to modulate your transmitted 2400 baud signal by combining it with a 38kHz signal before feeding it to an InfraRed LED. Micromites and Maximites! - Beginning Maximite |
||||
| dasyar Regular Member Joined: 13/04/2015 Location: United StatesPosts: 58 |
Hmm, this sounds like it is way over my head, you lost me right after "You need to modulate...". I thought this would be as straight forward as using the built in commands, 'IR SEND' and 'IR RECEIVE'. I guess I need to find a cheap device that has serial IR on it and connects to the uMite via serial I/O. I just do not think that something like that is readily available. So, I guess I have to come up with a new strategy, but not sure what that would be. |
||||
| dasyar Regular Member Joined: 13/04/2015 Location: United StatesPosts: 58 |
I see the replies for this thread have gone soft, oh well. I guess I have to take a different tact, until a possible serial IR I/O solution for the uMite comes along, I hope. Since the uMite does not have a solution, I will be adding an HB to the mix. This could get a little complicated, but for a prototype setup it might work. The main parts, for the prototype setup, are a uMite 28-pin on the breadboard, a Raspberry Pi (RPI), and an HB addition. I will have a Linux desktop connected to the uMite console port, for programming, and the RPi connected to the uMite COM:2 port. The HB will be connected to the RPi USB port. Now, how do I get this whole mess to work? I am starting with a mini UI program for the uMite, so it can talk to the RPi. Probably on the Rpi I will use a Python program for talking to the uMite, and eventually to the HB, which will mediate traffic between the uMite and the HB. When a solution for the uMite serial IR I/O comes along, then I will be able to remove the HB from the mix, and use that to talk to the uMite via IR. This all sounds so easy when you write it all out. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
CircuitGizmos has given you the answer. For transmit, set up a PWM at 38KHz on a Micromite pin and then use hardware to "AND" this with the output of a serial port set to 2400baud. See this for the circuit you need (substitute 3.3V for 5V). The idea is that you will then be sending the 38KHz signal when the UART is sending a "1" and no signal when the UART is sending a "0". If this is what your device wants then this should work fine. For receive, the IR receiver strips away the 38KHz signal and just returns you "0" or "1" on the input. This can then be read by any serial input port |
||||
| dasyar Regular Member Joined: 13/04/2015 Location: United StatesPosts: 58 |
Thanks for the info, I will have to give this some thought, my skills may not be up for it though. For a quick update, I mentioned I was going to use Python on the RPi to talk to the uMite, I gave pyserial a try and it was behaving very quirky. So, I switched to C, and now the comm works without any quirks. For a recap, I am using Linux that is connected to the uMite console port, and I am now using GtkTerm. GtkTerm works very nicely, has a send file function that works with the AUTOSAVE command. Probably the next thing I will do is add a DHT22 sensor to the uMite and see if I can get the data moved to the HB, on demand. One question about the use of the sensor or any other sensor, can somebody show me an outline of how I could use it within an interrupt scheme, so it would work in the background while my UI is working in the foreground, and still get the data moved? |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
I have my DHT reading in a subroutine and call it periodically with SETTICK SUB readhumidity
HUMID DHT22pin, TEMP, HUMIDITY ' dump stale reading PAUSE 2000 ' time for the sensor to complete next read HUMID DHT22pin, TEMP, HUMIDITY ' this reading is only 2 seconds old END SUB The DHT always gives you the previous reading so it needs two reads to get a current reading if you have long delays between readings. This gives a problem - the sub to do the read holds up your main program for 2 seconds. If that's a problem, you can have two SETTICK's started two seconds apart and the first one's results ignored. You can have 4 SETTICK timers running. It all depends on the flow of your main program. Most interesting data acquisition devices take a long time to do their thing which makes program flow difficult to manage. Jim VK7JH MMedit |
||||
| dasyar Regular Member Joined: 13/04/2015 Location: United StatesPosts: 58 |
Thanks TassyJim. Just to get this straight in my head: SUB readhumidity HUMID DHT22pin, TEMP, HUMIDITY ' dump stale reading PAUSE 2000 ' time for the sensor to complete next read HUMID DHT22pin, TEMP, HUMIDITY ' this reading is only 2 seconds old END SUB using the above subroutine with 'SETTICK 1000,readhumidity' will run the sub every second? Now the concept of global variables versus local variables, is their such a thing in MMBASIC? The reason for the question, what if you are running DHT in an interrupt, could you use a variable from the main program to have that DHT value available constantly? Since I do not have a DHT module yet, I will probably play around with the SETTICK using the LED on pin15. Probably try to make it flash every second, just to see what kind of impact it has on the running UI in the main code. Then of course I will have to hook up three more LEDs and set them up as tics, and see what the affect that has on the main code. I guess I should also ask, since I do have a sht11 module on hand, is there code available for that? If not, I will probably go ahead an order something in the DHT family. |
||||
| dasyar Regular Member Joined: 13/04/2015 Location: United StatesPosts: 58 |
This example may put a kink into my UI program, not sure how to get around it. The below program starts the tick, then it goes into the DO ... LOOP, does the PRINT and PAUSE, and then everything comes to a halt with 'INPUT #2'. In my UI program I was trying to get the main program to service the activity on the COM2 port while hopefully having some sensor(s) running in the background. Short of having a timer on the INPUT command, this could be a big problem for my program. Any ideas as to how to get around this, short of not running any tics or interrupts? ' testtick ' Open COM:2 OPEN "COM2:19200" AS #2 SETTICK 1000, testtick, 1 DO PRINT "Is the LED flashing?" PAUSE 3000 INPUT #2, inBUFF$ ' Check for input LOOP SUB testtick: SETPIN 15, DOUT PIN(15) = 1 PAUSE 300 PIN(15) = 0 PAUSE 300 END SUB |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Pause is a blocking command. Nothing happens it just pauses everything. Never use pauses when you want to use interrupts as it will mess up all timings. INPUT is a also a blocking command. If you want to check keypresses use the INKEY$ function. Also pauses inside an interrupt routine is not recommended. Better use a statemachine to step through the different states. Microblocks. Build with logic. |
||||
| dasyar Regular Member Joined: 13/04/2015 Location: United StatesPosts: 58 |
Thanks, but the reason for using 'INPUT' is to work with the open COM port. I was also trying to see if I could, some how, check the COM port buffer, if empty then it just continues with the DO ... LOOP, but that did not work. |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
You used the input command and that will wait until an enter is received. What you need is the INPUT function. [code] NumberOfBytes = LOC( #2 ) if NumberOfBytes > 0 then inBuff$ = INPUT$(NumberOfBytes, #2) endif [/code] Microblocks. Build with logic. |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
Yes. But hidden in the data sheets for the DHT22 Reading too often will fail and the device responds too slowly for rapid readings to be of any use anyway. Also, because my sub has a 2 second pause, it will not finish before the next run tries to start. In my applications I do a read every 30 seconds. Jim VK7JH MMedit |
||||
| dasyar Regular Member Joined: 13/04/2015 Location: United StatesPosts: 58 |
I am having one heck of a time trying to get a FUNCTION to work. I want to implement the code that MicroBlocks presented, so I am doing a test function run so I can get the gist of a value being returned. Here is a simple function, I think: 'Test a function SETPIN 15,DOUT Test(PIN(15)) FUNCTION Test(a) Test = 1 END FUNCTION I am expecting the PIN(15) LED to go on, but what I am getting is "ERROR: UNKNOWN COMMAND". I am not sure what is going on. |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
'Test a function
SETPIN 15,DOUT PIN(15) = Test(x) FUNCTION Test(a) Test = 1 END FUNCTION In this simple case you could do: 'Test a function
SETPIN 15,DOUT PIN(15) = Test() FUNCTION Test() Test = 1 END FUNCTION Jim VK7JH MMedit |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
dasyar - At best that would read pin 15 and pass the result in to the function. (As you've set 15 to an output it would not be especially sensible.) I think you can't modify the outside-the-function thing (your PIN(15)) from inside Test so that's that. However, when using a function you have to use its value so you'd at least need dummy = Test(PIN(15)) as it is, you're using it like a SUB not a FUNCTION. I feel there must be samples you could read profitably :) John |
||||
| Page 1 of 4 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
