How do I implement a 2nd TX/RX Port ? To make the core a home automation server (FS20 system hardware @ 868MHz) I bought 2 modules (sender and receiver), each one with TX/RX Pins for easy communication. The first one is easy to do: attached to TX and RX of the core, but how to get the 2nd running ? Can I do this with the firmware somehow using 3 pins of D0-D7, or do I need additional hardware ? Speed 9600 8 N 1
Thanks in advance!
Normally I would recommend the arduino NewSoftSerial or SoftwareSerial libraries… but they are full of AVR specific assembly code and more.
Kind of a hack, but if you can deal with round robin polling for RX from each xmitter, and TX on demand… maybe you could just simply add some digitally controlled buffers from the TX/RX pins to the two xmitters?
I whipped this up using LTSpiceIV so it’s not very pretty… but hopefully it conveys the message:
Datasheet for 74HC126N Quad Buffer in DIP14 package so it’s easy to work with… feel free to use SMT if you want 
http://www.digikey.com/product-detail/en/74HC126N,652/568-7794-5-ND/1230066
Wait, if one is a sender and the other is a receiver… Wouldn’t the transmitter only need the TX pin hooked up and the vice versa for the receiver? My german isn’t anywhere good enough to read those pages, so I’m just curious.
@timb : Good point, but the receiver need a command to start sending the buffered data to the core, so you can make sure nothing get’s lost. The transmitter sends status data. So both of them use it as a kind of handshake, and additionatly they can be configured (Baud rate and others). @BDub : Many thanks for the schematic. Will try that one, makes sense to me. At the moment I do the basic programming for the transmitter, so it may take a while to report success or fail.
…but to come back to emulation: I assume the core is fast enough to emulate 9600 8N1 (the factory preset of the mentioned hardware). So why not using 2 pins Dx to make them TX/RX of Serial2 ? Is it possible to code something in the Web IDE of the Spark core? (due to #include does not really work at the moment as far as I understand, and I’m a beginner in the Arduino world without knowledge of offline programming). A link to/or sample code would be nice. @Zach : Soemthing to add to the wishlist: Serial2.begin to switch 2 additional Dx-Pins to TX/RX.
If you need it right now, what about just getting an ATtiny84/85 and programming it as a I2C to Serial bridge? It would only be a few lines of code at most.
That would be a killer way to go if you also have an example of programming the ATtiny85 from the Spark Core :octocat:
Hmm, I’m sure that’s doable. Let me see what I can come up with this evening!
Hmm, well I’ve actually got the ArduinoISP sketch down to a single compile error!
8:1: error: 'define' does not name a type
I can’t seem to track it down though. All the #defines are up top and, despite commenting them out one by one, it never goes away. I might have to give it a try under the local build environment to see if I can trace it that way.
put this directly under your #defines
int bdubsfix = 1337;
It’s a known bug in the compiler at this time.
FYI: I’m standing by to test out your example with my ATtiny85 
@BDub Hmmm, yeah I had seen that elsewhere, but that doesn’t seem to make it go away. There are a couple of #define statements later in the code that I can’t move. But the error is saying 8:1, now I know line numbering isn’t accurate right now, but it should be early on in the code. Here, take a look:
(Note: I haven’t fixed the pin numbering or anything yet.)
Got it to compile… I just moved 3 #defines up to the top, and added a #pragma ignore at the top. Sadly the int bdubsfix = 1337; was not needed 
http://pastebin.com/raw.php?i=hGQkuwVL
I left the pin numbers for you! Going to bed right now 12:33am to try to restore some level of awakeness for tomorrow.
Hope this works!
WTF? I pulled those three #defines up to the top earlier and the compiler shit itself! Weird, it must have not saved correctly or something… Okay, let me start playing with that.
Edit: Ahh, it looks like it hadn’t saved after I pasted the definitions back down, because I refreshed the page and they were gone. Once I cleared it out and pasted my version back down (and added your #pragma) it compiles. Sweet.
I had a cool idea for this on the way to work today.
The way the ArduinoISP works is it converts your arduino into an ISP programmer… duh! but it requires you to physically connector your Arduino to the computer and use Avrdude.exe from the command line… and type in some stuff to get everything to work.
Since ATtiny85’s are only 8k bytes of Flash, the hex files are pretty small. What if after you compiled your program you could copy/paste your HEX file contents into an area of the SparkCoreISP application, compile and flash OTA? A little Rube-Goldbergish, but I’m a little worried the USB Serial driver might be an issue with AVRdude… and OTA beats hooking up my FTDI friend to Serial1.
Snippet of an ATtiny85 hex file:
:101780005523A9F0BF01DC014D9145174111E1F747
:1017900059F4CD010190002049F04D9140154111BF
:1017A000C9F3FB014111EFCF81E090E0019708956B
:1017B000FF27EE27BB27AA2760FF04C0A20FB31F95
:1017C000E41FF51F220F331F441F551F9695879561
:1017D0007795679589F70097760771F7CF01BD0177
:1017E0000895A1E21A2EAA1BBB1BFD010DC0AA1F62
:1017F000BB1FEE1FFF1FA217B307E407F50720F07A
:10180000A21BB30BE40BF50B661F771F881F991FF4
:101810001A9469F760957095809590959B01AC013D
:10182000BD01CF0108952F923F924F925F926F9228
:101830007F928F929F92AF92BF92CF92DF92EF9260
:10184000FF920F931F93CF93DF93CDB7DEB7CA1BE1
:10185000DB0B0FB6F894DEBF0FBECDBF09942A880C
:10186000398848885F846E847D848C849B84AA84B4
:10187000B984C884DF80EE80FD800C811B81AA8141
:10188000B981CE0FD11D0FB6F894DEBF0FBECDBF0C
:08189000ED010895F894FFCF6B
:101898006F736363616C0077617600002E57415661
:0418A800002F00000D
:02000004008278
:03000000E17DFFA0
:00000001FF
Would have to pack the hex file content into actual compilable code though… meh… PITA. never mind! Unless you have a good idea to make it work easily…
So what were you thinking for coding/compiling the ATtiny85? Arduino IDE with ATtiny85 support or AVR Studio?
There is no need for soft serial or external chip to get another serial port. The STM32 medium density has five USARTs/UARTs on chip - the core’s TX and RX pins are connected to USART2 via PA2 and PA3. The only other usable one is USART1 with its alternate function remapped pins bring USART1_TX and USART1_RX to PB6 and PB7 … wired to pins D1 and D0 on the core. As long as you dont also need the I2C, theres another hardware serial available.
All that needs to happen is the spark_wiring_usart.cpp to be updated to give an option for using USART1 in addition to USART2, maybe make a Serial2 instance which is setup for using D1 and D0 for TX and RX. I took a quick look and in its current state the Serial object looks quite broken. I wouldn’t have high expectations to receive data without dropping bytes since its all written with polled IO.
But hey, to get a 2nd serial port “its just software”
I’m thinking Arduino IDE with ATtiny Support. I assume once it’s been compiled you end up with a .bin file, right? You could convert the .BIN into a standard C Array, not unlike you do for Graphic LCDs.
I spent awhile debugging the Arduino as ISP code last night and you are correct in assuming issues with the USB UART. I haven’t tried it over Serial1 yet, though I was working on that. I got distracted figuring out where Apple put the Bluetooth Serial settings.
Then I got doubly distracted trying to implement Spy-By-Wire support to program MSP430 chips Over-the-Air!
@mattande : yep, that’s exactly what I experience here: No problem to send data to the UARTs, but the status bytes I get back from the UART are chopped, complete bytes are missing! I’ve tried also 4800 8N1, and at least 3 firmware versions on 2 cores: ALL WITH THE SAME RESULT on both UARTs: DATA LOSS! And we talk about 5-10 bytes once in 10 sec.! @zach : Any schedule on UART updates and debugging? Or even better: a 2nd UART port as mentioned above?
Just wanted to drop this idea in here as well… it’s more expensive than the buffer solution, but this device is a nice device to have in your skill set.
Low current, low voltage, dual coil, latching DPDT relay (fits in a breadboard):
http://www.digikey.com/product-detail/en/EC2-3TNU/399-11044-5-ND/4291110
You tie the (+) of each coil to 3.3V, and hook the (-) of each coil up to the collector of a NPN transitor (such as a 2N4401). Emitter of the NPN to GND. Base of NPN to a Digital Output through a 1k ohm resistor (say D0 and D1). The NPN is required because the relay coil will draw about 50mA, too much for the I/O of the 
Spark Core.
Because it’s a DPDT (Dual Pole Double Throw), you would hook the Common pins (4 & 9) to the two signals (TX & RX) you are trying to Switch between two devices, and the Normally Closed pair (3 & 10) to device 1, and Normally Open pair (5 & 8) to device 2.
Then you just Pulse D0 high for 15ms to latch the relay to the normally open state, or D1 high for 15ms to latch the relay to the normally closed state. After it’s latched, it draws no power.
I realize in the face of “it’s just software” this may seem like overkill, a waste of time, etc… but the more solutions you have up your sleeve, the easier it will be to solve your future problems.
@mattande is right. The STM32 does have an UART module on D0 and D1 pins. Exposing that as serial2 will be an ideal soultion. I’m not sure when the team would get to it.
We soon plan to implement a ring buffer for the serial library which should make it more reziliant to dropping bytes. Also, by making the user app loop run independent of the Core’s own firmware, we could further improve this situation. @satish has gotten very close to implementing this.
@mohit Do you guys have a list of which STM32 ports map to which Dx/Ax pins on the Core? (I mean the port names and numbers referenced in the STM32 datasheet.)
I’d like to put together a little graphic similar to this:
