looking for a little help.
I'm familiar with PIC Microcontrollers but have never used Atmel.
I'm required to use an ATMEGA128 for a project at work so I've been playing around in Atmel Studio 6 the last few days.
I'm having an issue however, I can't even get an LED to blink.
I'm using the STK500 and STK501 Dev boards and the JTAGICE_MKII USB debugger/programmer.
The ATMEGA128 chip is a TQFP package that's in the socket on the STK501 board.
I'm able to program/read the chip no problems, and my code builds without error (except for when I try to use the delay functions used in the delay.h library - but that's another issue).
For now I'm just concerned with getting the IO working. I have a jumper from 2 bits of PORTD connecting to 2 of the LEDs on the STK500 board.
All I'm doing in my code is setting the PORT direction with the DDRx ports and then setting all the PORTD pins to 0. The LEDs remain turned on.
When I'm in debugging mode and I have the watch window open, I can break the code and the watch windows shows me that the PORTD bits are indeed all 0's, but the LEDs remain on.
So far, I hate Atmel. :)
Any ideas?
Thanks
Have you tried setting them to logic 1? It is common for LED circuits to connect the LED to Vcc via a current-limiting resistor, which means the output port has to be 0 to turn on the LED.
If you set it to 1 and the LED goes off, then that'll tell you it's an "active low" signal and you can reverse your logic accordingly.
Have you read the STK500's doc? It is likely, that the LEDs are driven active low.
There are two steps to follow. First you set the "direction" of the pins, because they can be used as input or output. To make the D register pins output pins:
DDRD = 0xFF;
This will set all pins on the D register as output pins. Do this first. Then code like:
PORTD != 0x01;
will set the D0 pin high. And code like
PORTD ^= 0x01;
will toggle the pin.
See this tutorial for a little more info or visit in with this community. The Atmel community is vibrant and helpful.
Related
i am currently trying to use more than 1 HC-SR04 on my BeagleBone Black (Rev C.)
I tried the following script:
https://github.com/luigif/hcsr04 And it is also working, but I have no idea, how I am able to change the used PINs and also how to use them in a serial way.
May someone help me please?
best regards
Ingo
One possible solution with the current code is to add two fast enough multiplexer to the echo/trigger pins of the sensors (8:1 or 16:1 depending on how many sensors you want to connect). The first will be to switch between trigger connections and the second to switch between echo connections. To control the mux you'll have connect the select lines of the mux to any of the GPIO pins(easiest are P8_14, P8_15, P8_16 and P8_18 since P8_11 and P8_12 are being used by PRU).
You'll have to change the present code something like this
/* Execute code on PRU */
printf(">> Executing HCSR-04 code\n");
prussdrv_exec_program(0, "hcsr04.bin");
/*Add code here to set GPIO pins high/low to choose the sensor */
/* Get measurements */
mux generally have 5v inputs and outputs, make sure that you step it down to 3V else you'll blow your beaglebone!
basic cheap mux have 35ns max response time which is more that sufficient to match the requirements
https://en.wikipedia.org/wiki/Multiplexer
http://socrates.berkeley.edu/~phylabs/bsc/PDFFiles/DM74151A.pdf
Addition: Tie all the trigger pins together and mux only the echo pins so that you'll need only one mux instead of 2
I work for a semiconductor manufacturer. We are often trying to test our designs to make sure that sequences we run on our parts properly connect two points on a schematic for example signal_a and signal_b. The two signals usually have multiple pass gates that have to be turned on to connect the two signals. To check that this happens correctly we usually go through the schematic and simulation to check that all the pass gates were turned on correctly. It seems like Verilog would already have a built in command for checking this. For example something similar to:
#triggering_signal
begin
connected=check_connection(signal_a,signal_b)
end
connected would be set to 1 if they are connected and to 0 if they are not. I would appreciate it if anybody could point me in the correct direction if something like this exists. Note I thought of putting a force signal in the code to toggle signal_a and seeing if it shows up at signal_b using a counter, but this does not work for all the cases I need due to the fact that signal_a being at any other state than 1 turns the die off.
You can try to use SV assertions using sequence to test that signal_a value is always same as signal_b.
assert (signal_a == signal_b) else $error("It's gone wrong")Íž
I'm pretty much a noob when it comes to this kind of thing, so if you guys could either help me or direct me to a place to learn what I need to know, I would greatly appreciate it.
Basically my problem is that I am using the libpruio library to continuously sample analog values from the board. 2 things are going wrong here.
The first is that whenever the BB is sampling the voltages, the voltage of the wire that is hooked up to the AIN pin goes up. I've observed this through hooking up an oscilloscope to the same wire the pin is sampling. What I see is that whenever the BB starts sampling, the entire signal (just a sound wave from an amplified mic) is shifted up .8-.9 volts. This is also reflected in the values that I get from the BB, which are around 30,000 (when they should be 0). Hooking the pin up to ground gets me 0, which is correct, and hooking it up to 1.8 volts gets me something like 65520, which is also correct. So maybe it has something to do with the signal being weak?
The second issue is that even though I am receiving values at a rate of like 500khz-900khz, the actual rate seems to be around 11khz. What I mean by this is I only get a new value every 88us, and the rest of the values I get are stay the same as the new value until the next 88us passes, when I get a new value. These times correspond to the voltage shift up, which I mentioned in the previous paragraph. So actually what I see on the oscilloscope is that whenever I sample with the BB, there is a saw wave, with the frequency at the 11khz I was mentioning earlier.
In conclusion, whenever the BB samples, it first increases the voltage at the pin by .9volts, takes a sample of that voltage, and the voltage dies down for the next 88us, all the while the BB spits back the sample it took at the beginning of the period. I do not want this. I want it to not affect the voltage significantly, and take new samples every time the code runs.
As for the code I'm using, it's basically a slightly modified version of the IO_Input example in the libpruio library, with the values being stored in an array for later use instead of being printed immediately.
If you guys need any more information, I will gladly post it here, but for now I'm wondering if it is something super obvious that I'm missing.
Hooking the pin up to ground gets me 0, which is correct, and hooking
it up to 1.8 volts gets me something like 65520, which is also
correct. So maybe it has something to do with the signal being weak?
The BBB and libpruio seem to work OK. Check your wiring.
Regarding the sampling rate, the io_input example uses IO mode. If you need accurate timing for the samples use MM mode or RB mode.
Your target isn't very clear, so I cannot give detailed advices. (Some code also would help to understand what you're trying to do.)
BR
I am trying to drive down the current consumption of the contiki os running on the CC2538 development kit.
I would like to operate the device from a CR2032 with a run life of 2 years. To achieve this I would need an average current less than 100uA.
However when I run the following at 3V, I get the following results:
contiki/examples/hello-world = 0.4mA - 2mA
contiki/examples/er-rest-example/er-example-client = 27mA
contiki/examples/er-rest-example/er-example-server = 27mA
thingsquare websocket example = 4mA
I have also designed my own target platform based on the cc2538 and get similar results.
I have read the guide at https://github.com/contiki-os/contiki/blob/648d3576a081b84edd33da05a3a973e209835723/platform/cc2538dk/README.md
and have ensured that in the contiki-conf.h file:
- LPM_CONF_ENABLE 1
- LPM_CONF_MAX_PM 2
Can anyone give me some pointers as to how I can get the current down. It would be most appreciated.
Regards,
Shane
How did you measure the current?
You have to be aware that using a basic ampere meter to measure the current consumption of contiki-os wouldn't give you relevant results. The system is turning on/off the radio at a relative high rate (8Hz by default) in order to perform the CCA. This might not be very easy to catch for an ampere meter.
To have an idea of the current consumption when the device is in deep sleep (and then make calculation to determine the averaged current consumption), I'd rather put the device in the PM state before the program reach the infinite while loop. I used the following code to do that:
lpm_enter();
REG(SYS_CTRL_PMCTL) = SYS_CTRL_PMCTL_PM2;
do { asm("wfi"::); } while(0);
leds_on(LEDS_RED); // should not reach here
while(1){
...
On the CC2538, the CCA check consumes about 10-15mA and last approximately 2ms. When the radio transmit a packet, it consume 25mA. Have a look at this post: Contiki UDP packet transmission duration with CC2538.
Furthermore, to save a little more current, turn off the serial com:
#define CC2538_CONF_QUIET 1
Are you using the SmartRF board? If you want to make proper current measurement with this board, you have to remove every jumpers: P486, P487, P411 and P408. Keep only the jumpers of BTN_SEL and the RESET signals.
I have an Adafruit (Gemma) / Arduino and a Neopixel LED ring that I would like to control from World of Warcraft in-game events. This part is soldered and working.
Question:
Is there any way to send communications between World of Warcraft and some sort of listener on the PC that can then in turn send messages over USB to the Arduino/Gemma device?
My aim is to create an on-desk LED indicator e.g. if I'm a healer, then I want green/yellow/red light to represent the health of each raid/party member - so refreshes would be required at a high rate (0.5 / sec).
Thanks for your feedback in advance and welcome any future possibilities with the soon to be released Warlords of Draenor.
Is there any way to send communications between World of Warcraft and some sort of listener on the PC
Not directly via the WoW API. I came up with a way which I've never shared, because my usage broke Blizzard rules. But I haven't played in years, so here ya go. :)
I used an addon to create a one pixel frame in the top-left of the WoW window. I manipulated the color of this pixel to send data to the outside world.
The "listener" app can read this pixel with three Win32 calls:
HWND hwnd = FindWindow(NULL, "World of Warcraft"); // find WoW window
HDC hdc = GetDC(hwnd); // get the device context (graphics drawing abstraction)
COLORREF color = GetPixel(hdc, 0,0); // read the pixel at x 0, y 0
I then interpreted the bits of the color like this:
4: sequence number
7: checksum: (sequence + key code + ctrl + alt + shift + win)/6
8: key code or ASCII character
1: 1: virtual key code, 0: ASCII
1: CTRL key pressed
1: ALT key pressed
1: SHIFT key pressed
2: WINDOWS key pressed
The "sequence number" was just means of detecting that a new message had been posted to the pixel. The checksum was to prevent bogus reads when my special pixel was not active, like during loading screens. The rest was keystroke information. This allowed me to generate keystrokes from an addon. The entire watcher app is about 100 lines of C. Very simple.
I wrote an in-game script editor and used this with "pixelbot" to automate things in game. Towards the end of my WoW life I had more fun coding for Wow than playing it, which is saying a lot, because it's a fun game. :) One upon a time I knew everything there was to know about WoW addon programming, but I'm several years out of date now. I'll see if I can dig up some pixelbot Lua code for, though.
Anyway, you can adapt this scheme to send any messages you like. For instance:
4: sequence number
7: checksum (sequence + player number + LED color)/3
5: player number
2: LED color (0: green, 1: yellow, 2: red)
6: *reserved*
As for speed, I never actually measured it, but it blows away your 0.5 second requirement. At most a few milliseconds of latency between writes and reads.
that can then in turn send messages over USB to the Arduino/Gemma device?
That's just writing to the serial port in the "watcher" app and using Arduino libraries for read from the serial port inside your device.
I have source code for the "listener" app (pixel watcher) and for the WoW side stuff that writes message to the pixel. Let me know if you're interested and I'll help you out of band or dramatically increase the side of this post.
After some research, I did not found any built-in functionnality to signal/pipe/communicate with an external software. I believe it is due to the anti-bot blizzard policy. Actually you could do this with a memory watcher ( just like CheatEngine ), but there is chances you'll be banned for using this.
The only thing you could do if you can't find anything, is to ask on official forum, and hope a technic-friendly blue poster will answer =)
If you find anything, update your post, your idea is pretty interesting =)
There are only two ways to communicate with the game client without breaking the ToU:
Saving variables between sessions. Meaning that you can have an addon read and write to its storage file but this requires you to either relog or to /reload the UI for this file to be written to and read from. In short this wouldn't be so viable.
Have an addon use a tiny space on screen to write colors and use said colors to communicate with your external software by reading the pixels on screen.
There are many ways to achieve the second suggestion. You only need to be able to write this addon for the game. Then write an external program to read pixels. Sending commands back to the game would require hotkeys or sending it in the chat window.
Note that you are still limited to the API in-game that require hardware events. So for those you'd have to push a button or use the mouse to buypass.