I am trying to start a project in which I would create my own app on iOS using Swift to communicate with an Arduino 101 to control multiple LEDs. I have used this project as a base point.
After getting this to work with my custom app, I wanted to figure out how to make this work with multiple LEDs instead of just one. Currently, I am just performing writeCharacteristic to send a 1 or a 0 to the Arduino depending on which button I press (ON/OFF). However, for the new project, I need to be able to select one of the lights (select one of four output pins), and write a 1 or a 0 to turn it on and off. I didn't know what approach I should take to do this.
I don't need any code, just suggestions on how I can make this work through swift/Arduino code.
Thanks.
It's all explained in the manual.
https://www.arduino.cc/en/Reference/CurieBLE
Service design patterns
A characteristic value can be up to 20 bytes long. This is a key
constraint in designing services. Given this limit, you should
consider how best to store data about your sensors and actuators most
effectively for your application. The simplest design pattern is to
store one sensor or actuator value per characteristic, in ASCII
encoded values.
So either create a separate BLEBoolCharacteristic instance for each LED or combine the switch state of all leds in the same BLECharacteristic. For example you could encode 8 LED states in a single byte (1 LED per bit).
Do whatever you prefer. But read manuals...
Related
First Thanks in advance.
Is there a way for an Arduino board to detect what other boards are attached (such as infrared, or servo motor etc) or simple things such as led or push buttons? Basically is there a way to do Plug N Play?
I would like to design a system using an Arduino were the user can mix and match infrared sensors, motors, led. The script would recognize what is attached to the board and respond accordingly. Currently one is forced to hard code in the script identifying what pin is attached to what. Hence if the user pulls out a servo motor and adds an infrared, then the script must be rewritten. This is what I want to avoid.
Thanks.
You started with
user mix and match sensors, motors, led. The script would recognize
what is attached
and later added
Arduino for model railroads, to dynamically add servos, lights and
sensors
These are not the same, narrowing the scope makes all the difference. See my comment for first option. As for building a specific model that will recognize elements, sure, this can be done in couple of ways depending on the topology you intend to implement and in that case the main concern should be:
How will elements/nodes be connected to each other and / or the main board?
If you intend to run seperate wires for each element you could identify them by dedicating one wire for ID and use a different resistor on each, That's complicated and limited and I wouldn't do that.
On the other end you could create a parallel bus that runs from node to node and can be extended as needed, it will have a small number of wires that will implement I2C for instance, and for identification but also as local drivers you would add an ATtiny on each node.
I'm building a firmware for a device based on Atmel/Microchip AT SAMG55.
In a simple function, trigger some relais connected to GPIO pins.
Because I want to interlock different I/O, avoiding that 2 specific outputs are high level on the same time, I need to know the pin level I set before.
In another project, based on the SAMD21, there was a function that reads output pin state
static inline bool port_pin_get_output_level(const uint8_t gpio_pin)
The SAMG55 port library in ASF is quite different, so i tried ioport_get_pin_level(pin), but i'm not getting expected result. I think that it works only with pins configured as inputs.
Are there any recommended solutions?
Referring to Figure 16-2 in the SAMG55 data sheet, and to sections 16.5.4 and 16.5.8:
16.5.4 Output Control
... The level driven on an I/O line can be determined by writing in the Set Output Data Register (PIO_SODR) and
the Clear Output Data Register (PIO_CODR). These write operations,
respectively, set and clear the Output Data Status Register
(PIO_ODSR), which represents the data driven on the I/O lines. ...
16.5.8 Inputs
The level on each I/O line can be read through PIO_PDSR. This register indicates the level of the I/O lines regardless of their
configuration, whether uniquely as an input, or driven by the PIO
Controller, or driven by a peripheral. Reading the I/O line levels
requires the clock of the PIO Controller to be enabled, otherwise
PIO_PDSR reads the levels present on the I/O line at the time the
clock was disabled.
So, as long as the pin is configured such that the actual level on the pin always corresponds to the level we're trying to drive - which is not the case with an open collector configuration, for example - then Tarick Welling's answer is correct: you can read the output state from the Output Data Status Register (PIO_ODSR).
However the true state of the pin, regardless of driver configuration, can be read (subject to a resynchronisation delay that may or may not be relevant in any given application) from the Pin Data Status Register (PIO_PDSR).
You can do some low level programming. You use the high level HAL functions to configure, set and reset the pins but before you do that you would. Read the value for the pin by addressing the data value of the register. In AVR that would be done by reading PORTx. In a STM32 this can be done by reading the value of GPIOx->ODR. You would of course then need to extract the correct pin but this can be done.
You can also look inside the definition of port_pin_get_output_level and check how they did it and convert that into the way this board/vendor/HAL does its addressing.
update:
When looking inside the datasheet for the SAM G55G/J. Page 340 gives us the answer we need.
The level driven on an I/O line can be determined by writing in the Set Output Data Register (PIO_SODR) and the
Clear Output Data Register (PIO_CODR). These write operations, respectively, set and clear the Output Data
Status Register (PIO_ODSR), which represents the data driven on the I/O lines.
So we can drive the output by writing to PIO_SODR and PIO_CODR to set and reset the pins respectively. But also read from PIO_ODSR this is a register which contains the state of the pin.
A quick google search turns up two options for Atmel/AVR controllers:
read back from the same location you used to set your output value (PORTx register)
This will give you the value that you have written into the register before.
read the actual value using the PINx registers
This will give you the value that you could actually measure on your device.
The difference between the two can be important: if you set a GPIO that is pulled down below the logic voltage threshold (i.e. if connected to GND) to HIGH, PORTx will read HIGH (the value you set) while PINx will read LOW (the actual value).
https://www.avrfreaks.net/forum/reading-pin-set-output
I'd like to read a playfield of RFID token equipped chess pieces. For cost and simplicity, I'd like to use ONE reader and many antennae.
I'm planning to purchase the following:
ArduinoMega; large enough to just let me program and debug without
optimizing for space or speed
standard 8x8 chess board; size may be determined by coil diameter (see below)
standard 16 pc chess set
16 RFID tokens of a given frequency; each with a different "value" or serial number that when glued to the bottom of the chess pieces would uniquely identify each piece to the system
64 RFID coils (initially) designed for correct frequency of RFID tokens; mounted to bottom side of playfield
1 RFID reader compatible with RFID frequency selected
some sort of multiplexor (or set of multiplexors) for the Arduino to step thru connecting all 64 of the coils for the playfield
My overall system design would be to connect the reader to each coil in turn via the multiplexor(s) and read the token found at each location of the playfield, if any. The Arduino would read the output of the RFID reader and step thru the various field positions, monitoring which chess piece was at which location.
Before I just buy all the parts and go for it, I'm wondering if anyone here has any initial advice or criteria to consider.
My specific questions are:
Would one RFID freq set be better than another?
How long should the Arduino have to "wait" at (row x col) position to read a token - if a token is even there - before trying to read the next one?
Is it better to use one big multiplexor vs many small ones tied
together? Why?
Part of this question was originally asked here: https://electronics.stackexchange.com/questions/9255/rfid-antenna-array
Moderators requested that the author start a new question instead of asking a new question in the replies of an existing question. But I can't find that they ever did. So, here we are.. :^)
Your design is completely valid. Sometime ago, i play with RFID using arduino and found that RDM xxxx, using Wiegan standard, is very hard to code. The simple and working one is MFRC-522, mifare family. For easiest use on maintenance, you should uses writeable RFID card, so if one of chess your pieces is lost, you can easily replace it.
I am trying to communicate with SMC LEC6 Servo motor controller via Delphi 7-TComPort Library. I have read related questions TComPort and Modbus. My question is if I want to send a massage containing 8 bytes, how can I specify the stop-bit/start-bit values ? and Do I need to send each byte as a packet and the stop-bit separately or it will be done automatically by the library ?
The start bit cannot be selected and this bit will be added to each byte automatically by your RS485 or RS232 hardware.
The stop bit type you may select in the component properties (e.g. 1 stop bit). This bit will be added automatically too.
I'm working with some simple VGA driver code for use with the Xilinx Spartan 6 FPGA (via a Papilio Pro board). The code expects to have 4-bits of output per color, and so defines logic vectors for each color. However, my setup doesn't happen to provide the full 4 bits per color so I wanted to find a creative way to control this via the UCF.
The original UCF defined 4 pins for each color. In the case of blue, I only have two pins, so I chose to map the two I have to blues MSBs, thus:
NET Blue(0) IOSTANDARD=LVTTL; # N/C
NET Blue(1) IOSTANDARD=LVTTL; # N/C
NET Blue(2) LOC="P92" | IOSTANDARD=LVTTL; # to a pin
NET Blue(3) LOC="P87" | IOSTANDARD=LVTTL; # to a pin
(I totally omitted the first two constraints at first, and it still compiled and worked but complained about the inconsistent voltage standards (the absent ones defaulted to IOSTANDARD = LVCMOS25), thus throwing "WARNING:Place:838 - An IO Bus with more than one IO standard is found.")
The main warning is the one I'd like to know how to eliminate, preferably within the UCF:
WARNING:Place:837 - Partially locked IO Bus is found.
Following components of the bus are not locked:
Comp: Blue<1>
Comp: Blue<0>
What's the right way to map a net without a programmable pin location to a default value (logic '1' or '0', or perhaps a tri-state value) within the UCF in such a way as to eliminate this "Partially locked IO Bus" sort of warning?
My goal is that, in a setup with more or fewer bits per channel being driven by pins, only the UCF should need to change (not the source code). What I did works, despite the warnings... I'd just like to do it better and properly eliminate these warnings.
You've asked for pins within the top level of your code (on your entity). The tools therefore have to provide them. Hence you have to map them (otherwise it'll pick some random ones for you, which you usually don't want)
If those pins really have nowhere to go on the board and never will have, then remove them from the design completely (UCF and HDL).
Otherwise, you have to LOC them. You could add a PULLDOWN in the UCF to them to ensure they go to a low value.