so today i tried using my seeduino 9dof with my esp32.
When i tried using the library that seeduino has made it compiled with this error "avr/pgmspace.h no such file or directory”.
I also tried reading the raw i2c data but i only manage to read either a static 1 or 0.
When i tried using the library that seeduino has made it compiled with this error "avr/pgmspace.h no such file or directory”, this led to me changing a line that called pgmspace in the library to this:
#if defined(AVR)
#include <avr/pgmspace.h>
#else //defined(AVR)
#include <pgmspace.h>
#endif //defined(AVR)
which only caused more compiler errors.
After this i tried reading the raw i2c data but did not figure out which pins the esp32 used for i2c since the pinout on the site did not list the i2c pins ( https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/_images/ESP32-S3_DevKitC-1_pinlayout_v1.1.jpg ), butt i figured out it was 19, 20 (Or every PWM pin?). However, i do get the adress from the WireScan script, but when i try to read the data i only get either 1 or 0 and it stays static.
The wirecheck script does say error 5 at 0x6B but i dont use this adress so shouldn't be a problem?
So my 2 options is to get the library working on the esp32, or figure out the i2c communication?
Thanks for any help i can get.
Also here is the code i use to read the i2c data:
#include <Wire.h>
void setup() {
// put your setup code here, to run once:
Serial.begin(115200);
Wire.begin(21, 20);
pinMode(8, OUTPUT);
digitalWrite(8, HIGH);
}
void loop() {
// put your main code here, to run repeatedly:
Wire.requestFrom(0x69, 6);
float test = Wire.read();
Serial.println(test);
delay(100);
}
Related
ARDUINO PROBLEM
**So this is the circuit bord **
THE PROBLEM: when I try to run the code and try to press any button on the IR remote it does nothing ( it doesn't print the hexacode ! )
I have tried to change the circuit and tried to change the code. I was looking fro the arduino forums and tried every one, but still it doesn't work .
Is there a problem with tinkercad. simulation or is it with the code ?
CODE:
https://pastebin.com/1Uhn1j3a
CODE:
#include <IRremote.h>
const int RECV_PIN = A5;
IRrecv irrecv(RECV_PIN);
decode_results results;
void setup(){
Serial.begin(9600);
irrecv.enableIRIn();
irrecv.blink13(true);
}
void loop(){
if (irrecv.decode(&results)){
Serial.println(results.value, HEX);
irrecv.resume();
}
}
Two of the L293D ground pins are, according to your circuit layout, connected to the +5V rail inadvertantly. And the other two are connected to GND. According to this post the grounds are all internally connected, so in effect you would be shorting the +5V output to ground.
For an ESP32, under Mongoose OS, I’m trying to write some code to detect that a button was pushed (GPIO pin pulled to GND). I wrote the code below, but it constantly prints that the button is pushed, so it thinks the button is always pushed, except when I actually push it. When I push and hold it, the output stops. The button is wired between the GPIO pin and GND, with no pullup resistor since there is an internal pullup. I wonder if my code is wrong and would appreciate your comments, thank you.
I have pasted the relevant code below:
// GPIO 36
#define BTN_MOB 36
#ifdef BTN_MOB
mgos_gpio_set_mode(BTN_MOB, MGOS_GPIO_MODE_INPUT);
#endif
static void button_cb(int pin, void *pParam)
{
if(pin == BTN_MOB)
LOG(LL_INFO, ("***** BUTTON PRESSED\r\n"));
}
mgos_gpio_set_button_handler(BTN_MOB,
MGOS_GPIO_PULL_UP,
MGOS_GPIO_INT_EDGE_NEG,
100 /* debounce ms */,
button_cb, /* callback handler */
NULL); /* arguments to callback handler */
As it turns out, GPIO pins 34, 35, 36 and 39 are actually GPI - input only and have no internal pullup or pulldown resistors. I switched to a different GPIO with internal pullup and this solved the problem.
I have found examples of basic arduino to arduino serial communication but have been unable to get those working on ESP32 boards. I am trying to make the same thing work between two ESP32's The two are connected:
esp1 esp2
gnd to gnd
tx2 to rx2
rx2 to tx2
Simple sketches:
//transmit sketch
void setup() {
Serial.begin(9600);
}
void loop() {
Serial.println("test...");
delay(1000);
}
//receive sketch
void setup() {
Serial.begin(9600);
}
void loop() {
String received = "";
while (Serial.available())
{
received = Serial.read();
Serial.println(received);
}
}
What else is required to make this work?
I think your code comes from a simpler world in which pins were always fixed and one UART was all you had available. With the ESP32 you should probably look for a solution more along these lines:
#include <HardwareSerial.h>
HardwareSerial Serial2(2); // use uart2
Serial2.begin(19200, SERIAL_8N1, 16, 17); // pins 16 rx2, 17 tx2, 19200 bps, 8 bits no parity 1 stop bit
I hope this helps. If you still have problems after this, they're likely to be either a) the board you're using doesn't use 16 & 17 for rx2 & tx2, or b) you need 10k pull-up (not series) resistors on both lines to stop them "floating" - however some boards take care of the pull-ups for you.
All the following criteria should be meet to make it work:
ESP32 board should not use the serial port you want to use to any embedded feature. So it should be free to use.
Make sure you are using the right pins:
U
Rx
Tx
Serial
40
41
Serial1
9
10
Serial2
16
17
Make sure lines are crossed, so Tx is bind to Rx on the other board and vice versa.
Make sure that the speed is the same on both board.
To see the result both ESP32 board should be connected to the PC via USB and a console should attached to the USB ports. You can use putty for this purpose to connect the USB ports. Two instances can be run for the two USB port. Make sure the speed setup in putty is the same as it is in the code.
Whatever you type in one console will be transferred and will appear on the other console.
Upload this code to both ESP32 board:
HardwareSerial &hSerial = Serial1; //can be Serial2 as well, just use proper pins
void setup()
{
Serial.begin(115200);//open serial via USB to PC on default port
hSerial.begin(115200);//open the other serial port
}
void loop()
{
if (Serial.available()) //check incoming on default serial (USB) from PC
{
hSerial.write(Serial.read()); // read it from UBS and send it to hSerial
}
if (hSerial.available()) //check incoming on other serial from the other board
{
Serial.write(hSerial.read()); //read it from hSerial and send it to UBS
}
}
System is basic but I have terrible problem and I can not solve it pls help me. When my system works PIC keep running but clear the registers 4-5 times in a day.
How system should work:
-I have a PIC, pneumatic cylinder and 3 sensor(works with 24V DC).
-Main sensor take the signal from another system.
-When a signal came from main sensor, if the cyclinder is backward, cylinder should go to forward until forward sensor see it and if the cylinder is forward, cyclinder should come to backward until backward sensor see it.
Program:
#include <16F628A.h>
#FUSES NOWDT //No Watch Dog Timer
#FUSES NOBROWNOUT //No brownout reset
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or
B5(PIC18) used for I/O
#use delay(crystal=4000000)
#use fast_io(a)
#use fast_io(b)
#define goForward PIN_A0
#define comeBackward PIN_A1
#define main_sensor PIN_B0
#define positionSensorForward PIN_B5
#define positionSensorBackward PIN_B4
int1 pistonPositionedForward=0, pistonPositionedBackward=1;
int1 positionForwardReg=0, positionBackwardReg=0;
int1 pistonForwarding=0, pistonBackwarding=0;
#priority rb,ext
#int_RB NOCLEAR
void B_change()
{
positionForwardReg=input(positionSensorForward);
positionBackwardReg=input(positionSensorBackward);
if(positionForwardReg&&pistonForwarding) //if forwarding and forward sensor see
{
disable_interrupts(INT_RB);
output_low(goForward);
pistonPositionedForward=1;
pistonPositionedBackward=0;
write_eeprom(0,1);
write_eeprom(1,0);
pistonForwarding=0;
pistonBackwarding=0;
clear_interrupt(int_ext);
enable_interrupts(INT_EXT);
}
else if(positionBackwardReg&&pistonBackwarding) //if backwarding and backward sensor see
{
disable_interrupts(INT_RB);
output_low(comeBackward);
pistonPositionedForward=0;
pistonPositionedBackward=1;
write_eeprom(0,0);
write_eeprom(1,1);
pistonForwarding=0;
pistonBackwarding=0;
clear_interrupt(int_ext);
enable_interrupts(INT_EXT);
}
clear_interrupt(int_rb);
}
#int_ext NOCLEAR
void ext_interrupt()
{
disable_interrupts(INT_EXT);
positionForwardReg=input(positionSensorForward);
positionBackwardReg=input(positionSensorBackward);
if(positionForwardReg^positionBackwardReg) //if one of position sensor is see then position according to sensor, else position according to memory
{
pistonPositionedForward=positionForwardReg;
pistonPositionedBackward=positionBackwardReg;
}
if(pistonPositionedForward)
{
pistonBackwarding=1;
pistonForwarding=0;
output_high(comeBackward);
clear_interrupt(int_rb);
enable_interrupts(INT_RB);
}
else if(pistonPositionedBackward)
{
pistonForwarding=1;
pistonBackwarding=0;
output_high(goForward);
clear_interrupt(int_rb);
enable_interrupts(INT_RB);
}
clear_interrupt(int_ext);
}
void main()
{
//to remember last position after power off
pistonPositionedForward=read_eeprom(0);
pistonPositionedBackward==read_eeprom(1);
set_tris_a(0x00);
set_tris_b(0xFF);
output_a(0x00);
delay_ms(1000);
ext_int_edge(L_TO_H);
clear_interrupt(int_ext);
enable_interrupts(INT_EXT);
enable_interrupts(GLOBAL);
while(TRUE)
{
}
}
And my circuit:
CIRCUIT
*j2,j3 connected selonoid valve
*J4,J5,J6 connected 3 sensors 1. pin +24VDC,2. pin GND, 3.pin sensor data
***B1 and B2 connections changed. Now B1 connected to B5,B2 connected to B4
And These are I tried:
-I have 3 PIC all of them do same thing
-I changed 24V power supply
-I cancelled 7805 and 7812 and I connected seperate 5V power supply istead of 7805.
I am debugging via LEDs. Sometimes system stop running just waiting at one of positions. Take main sensor signal but doesnot anything, And pistonPositionedForward and pistonPositionedBackward register values are 0. I cant find problem how can it clear these registers?
You have unconnected pins on RB that are configured as inputs, with no internal pull ups set. Electrical noise may well trigger unwanted interrupts on PORTB, that has been known to happen.
The use of interrupts is making the overall logic a bit hard to follow for such a simple device. Have you tried rewriting the program NOT using interrupts (except maybe for EXT)? It should not take long and I think it may greatly improve the reliability - and maintainability, without impacting performance of the physical system.
I suggest you first configure the unused PORTA and PORTB pins as outputs, and see if the problem goes away. If that fails, a rewrite not using interrupts should take no more than an hour. This would probably make sense since that is probably way shorter than the time you have already spent chasing the issue.
Reading the description, I came up with this solution.
#include <16F628A.h>
#FUSES NOWDT //No Watch Dog Timer
#FUSES NOBROWNOUT //No brownout reset
#FUSES NOLVP //No low voltage prgming, B5(PIC18) used for I/O
#use delay(crystal=4000000)
#use fast_io(a)
#use fast_io(b)
#define FWD_MOVE PIN_A0
#define BACK_MOVE PIN_A1
#define PORTA_RESET (0x00) // outputs=LO, unused pins as outputs
#define PORTA_TRISTATE (0x00)
#define EXT_SENSOR PIN_B0
#define FWD_REST PIN_B5
#define BACK_REST PIN_B4
#define PORTB_RESET (0xCE) // can't use pull ups because of HW logic...
#define PORTB_TRISTATE (0x31)
#define EEPROM_STATUS_ADDR (0x0000)
#define EEPROM_STATUS_FWD (0x01)
#define EEPROM_STATUS_BACK (0x00)
int1 extLast;
int1 extCur;
void main()
{
// setup
output_a(PORTA_RESET):
output_b(PORTB_RESET):
// setting to last known state...
// safety check.
output_low(FWD_MOVE);
output_low(BACK_MOVE);
// This will activate the outputs to make sure we have good
// positioning.
switch(eeprom_read(EEPROM_STATUS_ADDR))
{
default: // EEPROM error... I'll let you decide what to do here.
// either move forward or back.
// this implementation goes back by default.
eeprom_write(EEPROM_STATUS_ADDR, EEPROM_STATUS_BACK);
disable_interrupts(GLOBAL);
// falling through...
case EEPROM_STATUS_BACK:
output_high(BACK_MOVE);
break;
case EEPROM_STATUS_FWD:
output_high(FWD_MOVE);
break;
}
// activate outputs... watch your fingers!
set_tris_a(PORTA_TRISTATE);
set_tris_b(PORTB_TRISTATE);
extLast = input(EXT_SENSOR);
for (;;)
{
// read external sensor, take action.
extCur = input(EXT_SENSOR);
if (extCur && !extlast)
{
// safety check.
output_low(FWD_MOVE);
output_low(BACK_MOVE);
// control logic
switch(eeprom_read(EEPROM_STATUS_ADDR))
{
default: // should never happen.
// falling through...
case EEPROM_STATUS_BACK:
output_high(FWD_MOVE);
eeprom_write(EEPROM_STATUS_ADDR, EEPROM_STATUS_FWD);
disable_interrupts(GLOBAL);
break;
case EEPROM_STATUS_FWD:
output_high(BACK_MOVE);
eeprom_write(EEPROM_STATUS_ADDR, EEPROM_STATUS_BACK);
disable_interrupts(GLOBAL);
break;
}
}
extLast = extCur;
// mechanical interface:
// read the limit guards and stop movement when done.
if (input(FWD_REST))
{
output_low(FWD_MOVE);
}
if (input(BACK_REST))
{
output_low(BACK_MOVE);
}
}
}
Of course, I could not check the above code on-site :).
After reviewing the schematics, I must also advise to add 1N4001 diodes in parallel of the 2 output MOSFETS to give them better protection against reverse voltage spikes. MOSFET built-in diodes are not very sturdy. 1N4148 or 1N914 would work there as well.
The 16F628 has very limited stack space. It looks like you are experiencing stack overflow during the call to write_eeprom. Calling write_eeprom from an interrupt may not be such a good idea after all.
There was a bug in older CCS compilers, related to the use of write_eeprom. It seems write_eeprom is enabling interrupts during the call. I've added calls to disable interrupts after the writes. I don't know if that bug was fixed, since I never use CCS.
[EDIT] after checking your HW. I realized you cannot use internal pull-ups because the HW logic is positive-going. The pull-ups in the PIC are meant to work with NPN transistors in the open collector configuration (emitter to ground). I changed the code accordingly.
The way you write to EEPROM is not good. eeprom writes take time, and the second write is usually taken care of in the eeprom interrupt. The CCS bug that enables the global interrupt and unmask the EEIE in eeprom_write does not help. Unhandled interrupts do generate a reset.
I'm working on a board based on the iMX6 and am trying to configure a number of GPIOs that are being used as chip enable and reset lines. Based on the research I've done, the way to handle this is via the gpio-reset driver in the device tree. Following the documentation I've come up with the below code which compiles but I'm not sure how to then control these reset lines from user space.
The first device tree driver I used was the gpio-leds which created an leds folder in sys/class with nodes to control the LED. However I don't see anything similar for reset. So I have 2 questions:
1) Is GPIO-RESET the correct binding to use for controlling reset lines, enable lines, etc.
2) Is there documentation on how to handle this and other bindings from user space, similar to how I'm controlling the GPIO-LED?
Kernel: Linux buildroot 4.1.15
/dts-v1/;
#include <dt-bindings/input/input.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/pinctrl/omap.h>
#include "imx6ul.dtsi"
/ {
model = "Freescale i.MX6 UltraLite 14x14 EVK Board";
compatible = "fsl,imx6ul-14x14-evk", "fsl,imx6ul";
memory {
reg = <0x80000000 0x20000000>;
};
/* Reset Line Configuration */
gpio_resets {
compatible = "linux,gpio-reset";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_gpioreset>;
gnss {
gpios = <&gpio1 4 0>;
asserted-state = <0>;
duration-ms = <100>;
auto;
};
};
...
};
&iomuxc {
pinctrl-names = "default";
imx6ul-evk {
pinctrl_gpioreset:
gpiorstgrp {
fsl,pins = <
MX6UL_PAD_GPIO1_IO04__GPIO1_IO04 0x000010B0 /* GNSS RESET_N */
>;
};
...
};
I'm not exactly sure about the gpio-reset sysfs interface as I couldn't find any information in bindings documentation, but for the normal gpio interface you need to export the gpio before it will show up in /sys/class/gpio/gpio*. Basically you just need to write the number of the gpio you wish to use to the export file underneath /sys/class/gpio. Here is an example of someone doing that. If you're just toggling the gpio on/off that interface should be enough.
Is GPIO-RESET the correct binding to use for controlling reset lines, enable lines, etc.
I have been looking for such a driver too.
I can see that there was a proposal for exactly this:
https://lwn.net/Articles/585145/
but I cannot find it in my kernel version (tracking the 5.4.y releases).
Only in some stale imx6 kernel: https://github.com/samnazarko/linux-imx6/blob/master/Documentation/devicetree/bindings/reset/gpio-reset.txt
So I will either
create a small driver to support the "delayed" function based on the above proposal (time of asserting the reset at boot).
use gpio-led with a default-state. Maybe using the "one-shot" trigger, to provide a single-write API to my apps. (Write once to the sysfs shot file results in a single toggle of the pin for a configurable time.)
Totally handle it from the userspace via libgpio or sysfs. (Maybe combined with gpio-led, to have at least a clearly defined state of the line during boot.)