Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.
Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.
As the gate is connected directly to the output of a logic gate, it will be switched either high or low, so the 'gate leak' isn't required, but won't do any harm and is good practice.
The power for BT got a bit complex. the SW (4) needed to be able to switch OFF the HC socket if the control enabled the switch , but not turn the socket ON .. if control was OFF ... result !
One Enable for the 4 SW'es is low to enable the OFF for the 4 sockets, also Voltage level changes were needed .
Mike .. I am a bit wary of supplying Volts to IC pins with no or floating GND. these modules have a LDO regulator not sure how they behave with no gnd, also TX RX can have voltage on them directly into the wireless IC...
Could have been better laid out ,but splitting the HC-05s from the processor was major re-jig.. result lots of wires and connectors.. time now for 'C'. I still
have 97% program memory of the 512kb to play with ..
It seem I'm not as smart as I thought I was... the BT slave was going to be controlled by a PIC12 ... but 8 pins ..make debug difficult , moved up to PIC1814K50 20pin .. lots of mem EE and features... got as far as making the SOIC BOB and PIC board and some code only to find you cannot De-bug this chip with PK3 ..(fail) ( need a debug header ) so now new PIC in place is 18F14K22 . Then problems preserving the Data EEprom , this chip uses the top end of flash memory as Data EEprom , I understand the programmer has to first read the EEdata portion, erase the flash then writes the EE data back, and flashes the program , but telling the PK3 the addresses to save is problematical .. settled for the properties as below..BT master and slave now messaging and paired .
I have found understanding the BT serial a bit time consuming... as its not just 'my' RX / TX data format I have to code for , but the slave 'adds' at least one message "+DISC:LINK LOSS" ( at the 're-pair' ) as I stop the link to reprogram the master.. Other than that serial transfer is working.
Funnily enough I'm at this very moment playing with an HC-06 (for a project at work), I've just tried connecting and disconnecting my phone from it, and there's no spurious messages here at all.
I've just got the HC-06 wired to an FTDI serial/USB module, and using Termite on my PC as the comms program. In the actual application it will connect to a PIC16F18426, as an external plug-in unit, instead of a plug-in FTDI USB lead (to give the option of using either a laptop via USB, or a phone via BT.
Hi Nigel .. well for some time I wondered where this message was coming from .. as it turned up in the PIC18's RX buffer so it could have come from the 06 or the 05 .. took some time but it from the HC-06 I had two PC terminals running on FTDI , monitoring TX and RX on the 06 to catch it.. from master / slave power on all is well 05 pairs with the 06 and they pass bytes.. but if i stop the 05.. the 06 after a few seconds ,, produces this message..
My 'commands frame ' for the slave PIC18 start 0xFF ,0x8x ,task, 0x06, 0xEE. , for no particular reason .. the 'D' task is send your BT address name and pass code. ( this has been read by the PIC on power up and stored in EEprom...) Could be a parameter in the 06 , or FW version ..
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.