I am following this tutorial, but I am doing a very basic version where I just want to print something out.
All the pins and hardware specification are followed as per that tutorial.
Below is my app.js code:
var five = require('johnny-five');
var board = new five.Board();
var lcd;
board.on('ready', function() {
lcd = new five.LCD({
// LCD pin name RS EN DB4 DB5 DB6 DB7
// Arduino pin # 12, 11, 5, 4, 3, 2
pins: [12, 11, 5, 4, 3, 2],
rows: 2,
cols: 16
});
lcd.clear().print("Hello NJ");
this.repl.inject({
lcd: lcd
});
});
The problem is, when I connect my arduino to my laptop the lcd screen lits up, however when I run the code it does not show anything on the screen. I also followed this tutorial and the result is same.
Even if I remove the print command and do something like
lcd.noBacklight();
it does not work.
Even if I write the lcd.print("hello world") command in the console, it does not get printed on the lcd (however it does not show me any error on the console).
I have uploaded the Standard Firmata using my Arduino IDE. The johnny-five module works cause I tried their led examples and it was working.
Is my lcd device messed up or is it my code or is it my hardware connections?
I am confused.
Related
Is there a way to view exported coloured logs as in console (with colour)?
My program uses colour coding for errors, warnings, etc. If I redirect output of my program to file.log, I get records like:
[32m[1m(INF)[0m /environment/converter: State map: [ 2, 3, 4, 5, 6, 7, 8, 11, 12, 13, 14, 15, 16, 17, 18 ][0m
[32m[1m(INF)[0m /environment/converter: Action map: [ -1, -1, -1, 0, 1, 2, 3, 4, 5 ][0m
[32m[1m(INF)[0m PyEnv: Observation dims: 15[0m
[32m[1m(INF)[0m PyEnv: Action dims: 6[0m
Random seed None
[32m[1m(INF)[0m GRL seed 1428[0m
Now I want to see file.log, but without colour codes or even better with colours preserved.
I have tried nano, vi and gedit but they all do not do what I want.
Here are some ideas if you're still wondering for a good way to do this.
A text editor won't be able to read the color codes, as those are Bash specific. However, cat works because it can interpret the color codes. However, the way you're storing the colors isn't formatted correctly in the first place.
I'm not sure how you are writing into your log file, but I echoed your example and redirected the output into a file. I didn't see colors either. The reason is that you have to escape every square bracket for the codes to be interpreted by Bash.
So the way that I escaped the brackets is by manually adding \e before every square bracket and using echo -e to evaluate the escape characters:
`echo -e "\e[32m\e[1m(INF)\e[0m /environment/converter: State map: [ 2, 3, 4, 5, 6, 7, 8, 11, 12, 13, 14, 15, 16, 17, 18 ]\e[0m`
`\e[32m\e[1m(INF)\e[0m /environment/converter: Action map: [ -1, -1, -1, 0, 1, 2, 3, 4, 5 ]\e[0m`
`\e[32m\e[1m(INF)\e[0m PyEnv: Observation dims: 15\e[0m`
`\e[32m\e[1m(INF)\e[0m PyEnv: Action dims: 6\e[0m`
`Random seed None`
`\e[32m\e[1m(INF)\e[0m GRL seed 1428\e[0m " > example.txt`
Now when I open the file with cat I see correctly colored text:
The color codes are now stored and escaped correctly in the .txt file:
^[[32m[1m(INF)[0m GRL seed 1428^[[0m
vs
[32m[1m(INF)[0m GRL seed 1428[0m
An alternative solution is to use a package like Ansi Html Adapter (Aha).
It will produce HTML instead of plain text. Then you can open the output in your browser, and it would have the right color coding.
However, you would meet with the same problem. If the color codes aren't escaped correctly, the output is not going to be colored.
I ran the following command to convert the correctly formatted text to HTML:
aha -f example.txt > example.html
Here's the result in the browser:
You can find more info on how to use colors in bash in this Bash Tips article.
I have compiled adv7180 driver available here.
I am unloading the ov5642 cameradriver(which in my case is built-in) and loading the adv7180_tvin module and after I am loading mxcv4l2_capture module which creates video0 in /dev/.
(dmesg command says: "mxc camera on IPU2_CSI1 registered as video0")
But when I try to access video0 with v4l2-ctl I got a message "resource temporarily unavailable" or when I am using gstreamer I got message "Can not open /dev/video0" (but the device is really created).
Is that a problem in device tree settings or it can be caused by something else? Which tools should I use to find out what causes this issue?
My device tree settings look like below:
&i2c3{
adv7180: adv7180#20{
compatible = "adv,adv7180";
reg = <0x20>;
clocks = <&clks IMX6QDL_CLK_CKO2>;
clock-names = "csi_mclk";
pwn-gpios = <&gpio3 10 GPIO_ACTIVE_LOW>;
ipu_id = <1>;
csi_id = <1>;
mclk = <24000000>;
mclk_source = <0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hummingboard2_parallel>;
cvbs = <1>;
};
};
I need to add that before adv7180 I was using above settings for ov5642 camera (excluding cvbs setting) and everything worked properly.
EDIT:
Ok I got one clue.
When I load modules in dmesg message "mxc_v4l2_master_attach: ipu(0:1)/csi(1:1)/mipi(0:0) doesn't match" shows.
But it only happens when ipu_id=<1> in v4l2_cap device tree settings and in adv7180 settings. When i change ipu_id to ipu_id=<0> in v4l2 settings and adv7180 dmesg now shows "parallel attach to IPU1 CSI1 and I can access the /dev/video0 succesfully with v4l2-ctl tool.
But In my case there is only one possibility to use IPU2_CSI1.
Why can't I set IPU2 to adv7180 when I was using it successfully to ov5642 ?
As per my knowledge i.MX6 having two IPUs. I think by default IPU1 parallel interface is not enabled in the board file. So you need to check the IOMUXC_GPR1 register setting (bit 19 and 20) for IPU/CSI1 and pass the csi_id in your camera driver.
As you are using the parallel interface so check your pin muxing setting as well in your device tree. (which is not required for serial interface.)
Edit:
There are two ways which you can follow to update the register setting from the kernel space (boardfile or camera driver) itself:
1. From the board file:
struct regmap *gpr
gpr = syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
regmap_update_bits(gpr, IOMUXC_GPR1, 1 << 20, 1 << 20);
2. From the boardfile or camera driver
void __iomem *va_ipu2_address;
u32 reg_val;
va_ipu2_address = ioremap(0x20e0004,0xe0004);
reg_val = readl(va_ipu2_address);
/* Enable parallel interface to IPU2 CSI1. */
writel(reg_val | 1 << 20, va_ipu2_address);
Thanks for Your answer.
My pinmuxing looks like this:
&iomuxc{
hummingboard2{
pinctrl_hummingboard2_parallel: hummingboard2_parallel{
fsl,pins = <
MX6QDL_PAD_EIM_A24__IPU2_CSI1_DATA19 0x0b0b1
MX6QDL_PAD_EIM_A23__IPU2_CSI1_DATA18 0x0b0b1
MX6QDL_PAD_EIM_A22__IPU2_CSI1_DATA17 0x0b0b1
MX6QDL_PAD_EIM_A21__IPU2_CSI1_DATA16 0x0b0b1
MX6QDL_PAD_EIM_A20__IPU2_CSI1_DATA15 0x0b0b1
MX6QDL_PAD_EIM_A19__IPU2_CSI1_DATA14 0x0b0b1
MX6QDL_PAD_EIM_A18__IPU2_CSI1_DATA13 0x0b0b1
MX6QDL_PAD_EIM_A17__IPU2_CSI1_DATA12 0x0b0b1
MX6QDL_PAD_EIM_DA11__IPU2_CSI1_HSYNC 0x0b0b1
MX6QDL_PAD_EIM_DA12__IPU2_CSI1_VSYNC 0x0b0b1
MX6QDL_PAD_EIM_A16__IPU2_CSI1_PIXCLK 0x0b0b1
MX6QDL_PAD_EIM_DA10__GPIO3_IO10 0x400130b1
>;
};
};
};
and it's been working succesively with ov5642 camera.
No I see that the adv7180 driver does not take an ipu_id as an argument from device tree so I think it is using the default ipu which is (I think) IPU1.
I've been playing arround how to change settings in IOMUXC_GPR1. Bit 20 needs to be set ("enable parallel interface to IPU2 CSI1). But have got no more ideas how to do it in device tree.
Ok. I found it !
I couldn't set bit 20 in IOMUXC_GPR1 register using mach-imx6q.c file so I did it this way:
in console:
sudo devmem2 0x20e0004
and read the existing value (which was in my case 0x48643005). Then I set bit 20 to one ("1") so I got 0x48743005 and I put this value into the register:
sudo devmem2 0x20e0004 w 0x48743005
next I loaded adv7180_tvin and mxc_v4l2_capture modules and captured frames using gsreamer:
gst-launch-1.0 imxv4l2videosrc device=/dev/video0 ! imxipuvideotransform ! autovideosink deinterlace=true
Everything works great ! Thanks for help !
I'm using an "adafruitts" touchscreen with a raspi to control a usb peripheral.
The full raspbian kernel takes forever to boot (50 seconds), and part of that is due to the touchscreen driver loading (by modprobe/udev) and initializing.
During the first 20-30 seconds of boot, the display is not loaded, so it is blank. I need this to be a user-friendly item that cannot be blank for 30 seconds each time it is turned on, so I've used buildroot to build a small kernel with the touchscreen driver built-in. (I am on a steep learning curve with buildroot and kernel building in general).
The display driver is fbtft_device.c patched to include the adafruitts display. This patch defines the "touch" half:
/* Touch device spi-half of adafruit touchscreen */
.name = "adafruitts",
.spi = &(struct spi_board_info) {
.modalias = "stmpe610",
.max_speed_hz = 500000,
.mode = SPI_MODE_0,
.chip_select = 1,
.platform_data = &(struct stmpe_platform_data) {
.blocks = STMPE_BLOCK_TOUCHSCREEN | STMPE_BLOCK_GPIO,
.irq_over_gpio = 1,
.irq_gpio = 24,
.irq_trigger = IRQF_TRIGGER_FALLING,
.irq_base = GPIO_IRQ_START + GPIO_IRQS,
.ts = &(struct stmpe_ts_platform_data) {
.sample_time = 4,
.mod_12b = 1,
.ref_sel = 0,
.adc_freq = 2,
.ave_ctrl = 3,
.touch_det_delay = 4,
.settling = 2,
.fraction_z = 7,
.i_drive = 0,
},
}
},
.is_support = 1,
.gpio_settings = (struct gpio_setting []) {
{
.gpio = 24,
.pull = pull_up,
}
},
.gpio_num_settings = 1,
},
and the LCD half:
}, {
/* LCD component of adafruit touchscreen */
.name = "adafruitts",
.spi = &(struct spi_board_info) {
.modalias = "fb_ili9340",
.max_speed_hz = 16000000,
.mode = SPI_MODE_0,
.chip_select = 0,
.platform_data = &(struct fbtft_platform_data) {
.display = {
.buswidth = 8,
.backlight = 1,
},
.bgr = true,
.gpios = (const struct fbtft_gpio []) {
{ "dc", 25 },
{},
},
}
}
}, {
by including:
fbtft_device.name=adafruitts
in the cmdline.txt for the boot loader, I've gotten the display half of the system to work (it boots in ~ 5 seconds :) ) with tinyX/matchbox desktop showing the desktop, but I cannot get the touchscreen part to work (the cursor does not move when I touch the screeen).
Somehow I have to bind the touch part of the touchscreen to tinyX, but I have not been able to figure out how to do this.
I have tried to specify the keyboard (and mouse) when launching tinyX:
X -keybd smpte610 (for example)
but X reports it cannot find the driver.
How can I verify the touch screen input device was successfully loaded?
The boot log has these messages about fbtft_device:
fbtft_device: SPI devices registered:
fbtft_device: spidev spi0.0 500kHz 8 bits mode=0x00
fbtft_device: spidev spi0.1 500kHz 8 bits mode=0x00
fbtft_device: 'fb' Platform devices registered:
fbtft_device: bcm2708_fb id=-1 pdata? no
fbtft_device: Deleting spi0.1 (spi0.1)
fbtft_device: Looking at item 0
fbtft_device: Setting pin 24 to 2
stmpe-spi: probe of spi0.1 failed with error -22
fbtft_device: Deleting spi0.0 (spi0.0)
Console: switching to colour frame buffer device 40x30
graphics fb0: fb_ili9340 frame buffer, 320x240, 150 KiB video memory, 16 KiB buffer memory, fps=20, spi0.0 at 16 MHz
fbtft_device: GPIOS used by 'adafruitts':
fbtft_device: 'dc' = GPIO25
fbtft_device: SPI devices registered:
fbtft_device: stmpe610 spi0.1 48000kHz 8 bits mode=0x00
fbtft_device: fb_ili9340 spi0.0 16000kHz 8 bits mode=0x00
kgdb: Registered I/O driver kgdboc.
Is the kgdb message associated with fbtft_device or something else?
If I look in /dev/input I see: event0, event1, and mice. event0 and event1 are associated with an attached keyboard (according to the boot log) and I have no mouse attached. Should there be some other items in input?
If the touch screen input device IS loaded, how to I specify the correct driver for tinyX?
Thanks
What I learned:
By comparing the boot messages in my modprobe/udev/module loading kernel with the fast built-in kernel, it shows:
stmpe-spi: probe of spi0.1 failed with error -22
is a "bad" thing.
A successful driver load will say (something like):
bcm2708_spi.0: registered child spi0.0
and then later:
input: stmpe-ts as /devices/virtual/input/input0
I fixed the "probe" failure by making these changes to my kernel configuration file. (Sorry, I don't want to include the whole thing, so these are the changes from when I had the issue to when the driver successfully loaded according to the syslog):
< Touch Did Not respond > Touch Did respond
> CONFIG_INPUT_FF_MEMLESS=y
< CONFIG_INPUT_POLLDEV=m > CONFIG_INPUT_POLLDEV=y
< CONFIG_INPUT_EVDEV=m > CONFIG_INPUT_EVDEV=y
< CONFIG_TOUCHSCREEN_STMPE=m > CONFIG_TOUCHSCREEN_STMPE=y
> CONFIG_KEYBOARD_STMPE=y
< CONFIG_SERIO=m > CONFIG_SERIO_SERPORT=m
> CONFIG_SPI_DEBUG=y
< CONFIG_SPI_SPIDEV=y
> CONFIG_SPI_GPIO=y
My main objective with these changes was to try to make sure that the dependent drivers were also built-in, and I enabled the debug. (Some of these were magically set by menuconfig, and this is diff from the "non-default" values from buildroot, so the diff is - different)
With this config, I now have event0, event1, event2, mice, and mouse0. The syslog says event1 and event2 are associated with the usb keyboard I have attached. I have no extra mouse attached.
I could use "evtest" to see events from /dev/input/event0 whenever I touched the display. evtest'ing /dev/input/mouse0 threw "Inappropriate ioctl for device"
I restarted X (tinyX) using:
X -mouse mouse,,/dev/input/mouse0
and touches worked, but the touch axis is rotated from the display axis.
I could not figure out a way to fix this in tinyX, so I'm going with a full blown Xorg implementation.
Make sure you have enabled the evdev input support in tinyx (BR2_PACKAGE_XSERVER_XORG_SERVER_KDRIVE_EVDEV) and use the syntax specified in hw/kdrive/src/kinput.c:
/*
* You can call your kdriver server with something like:
* $ ./hw/kdrive/yourserver/X :1 -mouse evdev,,device=/dev/input/event4 -keybd
* evdev,,device=/dev/input/event1,xkbmodel=abnt2,xkblayout=br
*/
I tried to interface a RaspBerry pi with a LM335 temperature sensor this week-end. I'm using a MCP 3208 micro controller (channel 0) to interface the sensor. My goal is to collect samples data in SPI mode with python 3 scripts (classes).
I've checked the wiring and everything seems OK for me, I'but I'am a beginner, not really aware of Electronic concepts.
On the software side , I've installed quick2wire that claims to be python 3 compatible. In fact I want to lead the micro-controller with Python 3 API's (not thru shell calls)
Components
Raspberry pi REV2 model B with Rasbian-wheezy / Quick2wire installed. /dev/spix.y devices are listed.
MCP3208 ADC : 12 bits ADC / SPI. I'm using CS0 from the GPIO. The sensor is connected to channel 0 (B). see datasheet.
LM335 : temperature sensor. Outputs 10mV / °K. Min 5muA / Max 5 mA. It's connected to the MCP3208 channel #0 (A). see datasheet
220 ohms resistor (C). set up regarding LM335 outputs and desired temperature range coverage with my own calculations : May be a problem ...
Schematics extract
The LM335 (zener diode like) is connected as :
Wiring
Components are wired as shown bellow. Note that the yellow link is connected behind the cobbler kit on the CS0 SPI channel.
Quick2wire
I use the bellow script to query the CS0/Channel 0 GPIO interface. Unfortunately, I've not found usefull informations on the quick2wire-python-api API's. I've just copy/paste an example found as it was written in the same goal. I'm not sure if it really works :
#!/usr/bin/env python3
from quick2wire.spi import *
import sys, time
try:
channel = int(sys.argv[1])
except:
channel = 0
MCP3208 = SPIDevice(channel, 0)
while True:
try:
response = MCP3208.transaction(writing_bytes(0x41, 0x13), reading(1))
print ("output = %i" % ord(response[0]))
time.sleep(1)
except KeyboardInterrupt:
break
The script outputs :
output = 0
output = 0
output = 0
output = 0
output = 0
....
The result is the same with the channel 1 ( with argv = 1)
As the MCP3208 Din (probe output) receives voltage (see bellow) quick2wire should read at 18°C (rawghly my home inside temperature today)
3,3 V / 2^12 = 805 muA as I understand as "digital step"
18°C + 273°C = 291 => 2,91 V on the micro controller Din pin
and then return 2 910 / 0.805 = 3 615
Am I wrong ?
Controls
I've no oscilloscope, the only measures I can read are :
Voltage is 2.529 V at B checkpoint and 0,5 V (+/-5%) on the other MCP3208 channels
Note : the adjust pin is not used on the LM335 so results way not be accurate but voltage is here !
Seems to be a problem on the quick2wire side I think. But which ?
Code
The quick2wire.spi.SPIDevice class lakes of détails on the transfers parameter in terms of structure, content and output response format.
def transaction(self, *transfers):
"""
Perform an SPI I/O transaction.
Arguments:
*transfers -- SPI transfer requests created by one of the reading,
writing, writing_bytes, duplex or duplex_bytes
functions.
Returns: a list of byte sequences, one for each read or duplex
operation performed.
"""
transfer_count = len(transfers)
ioctl_arg = (spi_ioc_transfer*transfer_count)()
# populate array from transfers
for i, transfer in enumerate(transfers):
ioctl_arg[i] = transfers[i].to_spi_ioc_transfer()
ioctl(self.fd, SPI_IOC_MESSAGE(transfer_count), addressof(ioctl_arg))
return [transfer.to_read_bytes() for t in transfers if t.has_read_buf]
Another question :
how to set SPI configuration values like mode, clock speed, bits per word, LSB ... and so on.
Thanks in advance for your help.
I know you probably intend to learn how to use the ADC, an so this isn't really an answer to your question (I will use your very rich post for sure - thanks), but I'm aware of temperature sensors that already pack data in GPIO serial line, that are best suited for the raspberry.
You really have to read this awesome tutorial, if you haven't already.
Can you please provide some examples of serial communication with scilab in Linux. When I gave the command:
h=openserial(1,"9600,n,8,1");
I am getting the following error:
-->h=openserial(1,"9600,n,8,1");
!--error 999
TCL_EvalStr, at line 1
bad option "-mode": should be one of -blocking, -buffering, -buffersize, -encoding, -eofchar, or -translation
while executing
"fconfigure file114 -mode 9600,n,8,1"
at line 27 of function openserial called by :
h=openserial(1,"9600,n,8,1");
A simple serial communication with for example an Arduino device needs only the baudrate specified as the second argument in openserial. Seems like your other variables in the string argument (n?) are messing up.
Scilab 5.4 example, with Serial Toolbox, for com port 3 and baudrate 9600. 5s delay before trying to read serial.
h = openserial(3,"9600");
xpause(5000000);
data = readserial(h);
closeserial(h);
Together with some serial spamming code on your arduino device you should receive a string of data at each run in Scilab.
Example code for serial on Arduino device:
int cc=0;
void setup(){
Serial.begin(9600);
}
void loop(){
Serial.println(cc);
if (cc<10){
cc++;
}
else{
cc=0;
}
delay(100);
}