Hey Brian, thanks for all the work on SparkTime, I’m a big fan. Did you manage to find out why the UDP client never succeeds? It still seems to be an issue on the photon.
I’m away on holiday with limited access right now but I plan to test with the latest system software soon. I believe that should fix the problem.
1 Like
I can’t seem to get the WS2801 library to work with the Photon either. The same code works with a Core. I’ve cut the clock cycle for SPI to the lowest on the Photon and it won’t work when I’ve had faster SPI clocks with the Core work fine.
MFRC522 library compiles but when flash is attempted, photon goes into red SOS. Not sure if it’s the SPI connection or what?
False alarm @peekay123 , the MFRC522 library works but some of the Photon GPIO pins are restricted…i.e. wkp cannot be used as “SS” on the Photon, it causes the Photon to not compile. After I reassigned the SS line to a different pin for my attached device, it compiled and flashed successfully.
The Warsting’s WifiScan library does not work. It’s not in the community libraries, but I was working with it. https://github.com/spark/warsting/blob/master/firmware/wifiscan.cpp
I’m working on the OneWire lib this weekend using a sparkfun Photon weather shield and multiple 18B20s. I just received a couple Photons last week so I now have everything I need to get the job done. So far I see the I2C bus is busted so the onboard sensors are a no show.
SD-CARD-LIBRARY 0.0.1 will not compile do to some PIN_MAP issues
Hey @Hotaman I’ve just been makin’ noise in your repo! Try the gist I put in this issue, and if it works, all yours for copy/paste/fixin’ the library. https://github.com/Hotaman/OneWireSpark/issues/7#issuecomment-125027065
Hey @boldbigflank could you add an issue describing what you’re seeing with Warsting?
Hey folks, more generally I’d like to compile a master list of problems and fixes for porting from Core to Photon, with a strong preference for maintaining compatibility with both. There are two that I’m aware of, PIN_MAP needing to be mapped to HAL_Pin_Map() and the change in port names when making low-level calls.
Another one that’s going to come up after the next firmware is a name collision on PIN_MAP. The fix is pretty simple, just making PIN_MAP into PIN_MAP2 on Photons. Below is my fixed code for OneWire, which illustrates both of these and the use of PLATFORM_ID to define different behaviors on Core and Photon.
What other issues and fixes are there?
#if PLATFORM_ID == 0 // Core
#define pinLO(_pin) (PIN_MAP[_pin].gpio_peripheral->BRR = PIN_MAP[_pin].gpio_pin)
#define pinHI(_pin) (PIN_MAP[_pin].gpio_peripheral->BSRR = PIN_MAP[_pin].gpio_pin)
#elif PLATFORM_ID == 6 // Photon
//#include "pinmap_impl.h"
//#undef PIN_MAP
STM32_Pin_Info* PIN_MAP2 = HAL_Pin_Map(); // Pointer required for highest access speed
#define pinLO(_pin) (PIN_MAP2[_pin].gpio_peripheral->BSRRH = PIN_MAP2[_pin].gpio_pin)
#define pinHI(_pin) (PIN_MAP2[_pin].gpio_peripheral->BSRRL = PIN_MAP2[_pin].gpio_pin)
#else
#error "*** PLATFORM_ID not supported by this library. PLATFORM should be Core or Photon ***"
#endif
// fast pin access
#define pinSet(_pin, _hilo) (_hilo ? pinHI(_pin) : pinLO(_pin))
and this block of code, which occurs in a couple of places and versions:
#if PLATFORM_ID == 6
HAL_Pin_Mode(_pin, OUTPUT);
#else
pinMode(_pin, OUTPUT);
#endif
1 Like
Thanks @Dick, I’ll get it fixed up RSN. I got side tracked last weekend by some Dotstar LEDs 
(the SPI bus works great on the Photon!) I have a new Sparkfun Photon Weather Shield and 3 DS18B20s on the bench now.
Hi Dick,
Here’s the error I get with the Warsting (former example project)
WifiScan.cpp:4:18: fatal error: wlan.h: No such file or directory
#include "wlan.h"
^Can anyone help me out here? I put in a support request a week ago asking how to get the web IDE to pull the latest code for my one wire lib. I’m still waiting for a response. The onewire git repo currently works fine but I can’t get it available in the web IDE?
I would think that the IDE would pull the latest when a lib in included in a project, but appearently that’s not the way it works.
Hi @Hotaman
The library author on github has "push" the library from github into the web IDE with at the very least, a new version number.
I thought that one-wire was becoming a "built-in" library but I am not sure when that will happen.
So for now, cutting and pasting into the web IDE editor tabs is the best way.
1 Like
Thanks @bko,
Exactly how do I ‘push’ it to particle? I’ve only used pull, or triggered something on the foreign host to cause it to pull the latest code.
@bko,
As far as getting built in, that would be fine, but considering the problems I’m having with I2C on the photon, I wish it was a separate lib!
Oh, @Hotaman are you not the one who added it to Build to begin with? If you’re the original contributor then the process is:
- Go to build.particle.io
- Click the Libraries icon in the toolbar
- Click “Contribute Library” (I know it’s already in, but this is the route)
- Go through that import process
- BE SURE to make it public again… after it’s been reimported through this process it’ll default to private
Now, if it says that you don’t own it, or if you weren’t the one to originally add it, then we (Particle) should transfer it to you. The other option’s that we could adopt it as an official library and handle maintenance and updates- only if ya want us to, but we don’t mind.
1 Like
Yes I’m the lucky one I’ve been using one wire since Dallas Semi introduced it. It’s a good interface. I still have one of the original JAVA iButtons around here somewhere 
Thanks @Dick, I almost tried that but it just felt wrong adding an existing lib again, so I aborted. I’ll get that done today and keep an eye on the firmware changes. My current project uses 1wire, I2C, and SPI. It is targeted for the Electron this fall. Since the I2C interface is broke on the Photon now I’m waiting and watching the firmware topics for it to be fixed.
There is a lengthy thread on making ‘fast’ pin functions as apposed to slow ‘safe’ pin functions. I don’t get it. Please remove the ‘safe’ part and make everything as fast as possible. We are hardware engineers after all! If I twiddle a pin that is being used for a special function and break that function, I need to drink more Dew and fix my code! I don’t need you looking over my shoulder protecting me from myself, I want pure speed!
So, PinHi, PinLo, PinIn, PinOut (or whatever you want to call them) should simply set/clear bits as required in the correct register for the given hardware I running on. Nothing more, nothing less, that’s what I expect them to do.
Keep It Simple, Stupid (KISS) is always the best approach.
@Hotaman, here are a few updates you NEED to know about:
-
The Photon I2C issues have been resolved in 0.4.4rc3 which will be released this week
-
The release also includes pinSetFast(), pinResetFast(), digitalWriteFast() and (maybe if it gets in on time), pinReadFast(). These are “bare metal” fast inline functions that scream (approx 45ns per set/reset op).
Thanks @peekay123,
I just finished reading the announcement of the new version, can hardly wait to try it out.
Glad to hear they settled on something, but I stand by my last post. The regular pin functions should be the ‘fast’ functions .
I’ll try out the new ‘fast’ pin functions in the OneWire lib as well. I’d rather post an update using those than the current workaround version if this is the ‘official’ solution.
pinSetFast(), pinResetFast(), pinReadFast() make sense. I’m guessing digitalWriteFast() is a full register write?
Will there be ‘fast’ functions for the DDR as well? Changing the DDR bit is used to simulate an open collector output with a totem pole output and needs to be just as fast.