How to use the ADC on StartKit?

All technical discussions and projects around startKIT
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm

Re: How to use the ADC on StartKit?

Postby Folknology » Sat Jan 11, 2014 12:46 am

MatCat I managed to get the same problem when I changed my makefile, I narrowed it down to having '-fxscope' in my XCC_FLAGS (I had been playing with xscope), so try adding this to your XCC_FLAGS to see if it starts working.

As to why this fixes it, it could be down to channel configs being used by xscope or maybe it's a timing thing, not sure, but if I don't include '-fxscope' in my XCC_FLAGS I get your issue!

Sethu/Xmatt any ideas or insight into why this is happening?

regards
Al
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm

Postby Folknology » Sat Jan 11, 2014 1:44 am

I have created the module_startkit_adc as mentioned above and enclosed it.

here is sethu's example adapted to use the module instead:

Code: Select all

#include <xs1.h>
#include <stdio.h>
#include <platform.h>
#include <xscope.h>
#include <adc.h>

/* This the port where the leds reside */
port p32 = XS1_PORT_32A;
port trigger_port = PORT_ADC_TRIGGER;

#define MODES 10

int leds[MODES] = { 0xE1F80, 0xE1F00, 0xE1E00,
                   0xE1C00, 0xE1800, 0xE1000,
                   0xE0000, 0xC0000, 0x80000,
                   0x00000 };

void adc_example(chanend c) {
	unsigned samples[4];
	int count = 0;
	
	adc_config_t adc_conf = {{1,1,0,0},ADC_16_BPS,2,0}; // ADC channels 1 & 2, 16 bit sample, 2 samples per packet, calibration mode 0

	sk_init_adc_network();
	sk_adc_enable(adc_tile,c,trigger_port,adc_conf);
	printf("Ready \n");

	while(1) {
		sk_adc_trigger_packet(trigger_port,adc_conf);
		sk_adc_read_packet(c,adc_conf,samples);
		unsigned samps = samples[0] * 10 >> 16;
		p32 <: leds[samps];	
	}
}

int main(void) {
	chan c;
	par
	{
		startkit_adc(c);
		on tile[0] : adc_example( c);
	}
	return 0;
}

module_startkit_adc.zip
Let me know if you find any issues.

P.S. this also suffers from the same bug as sethu's code with the -fxscope gcc flag, prob something with that init_adc_network setup IMHO

regards
Al
You do not have the required permissions to view the files attached to this post.
User avatar
segher
XCore Expert
Posts: 843
Joined: Sun Jul 11, 2010 1:31 am

Postby segher » Sat Jan 11, 2014 2:01 am

Folknology wrote:I think I got it, these are the calibration samples, it needs 6?
Right; see the datasheet, peripheral 2 reg 0x20.
User avatar
MatCat
Active Member
Posts: 40
Joined: Wed Dec 18, 2013 11:51 am

Postby MatCat » Sat Jan 11, 2014 3:47 am

Folknology wrote:MatCat I managed to get the same problem when I changed my makefile, I narrowed it down to having '-fxscope' in my XCC_FLAGS (I had been playing with xscope), so try adding this to your XCC_FLAGS to see if it starts working.

As to why this fixes it, it could be down to channel configs being used by xscope or maybe it's a timing thing, not sure, but if I don't include '-fxscope' in my XCC_FLAGS I get your issue!

Sethu/Xmatt any ideas or insight into why this is happening?

regards
Al
I tried but didn't make a difference, I will try your module and see what happens.
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm

Postby Folknology » Sat Jan 11, 2014 1:14 pm

What I am unsure about (due to lack of switch setup experience) is how the links between the ADC on its tile and the user tile are setup, it looks like it may be a non-routed link but don't quote me on that, perhaps segher (or anyone familiar with setting up inter-tile/peripheral links) has some better insight, here is the setup sethu used (minus the LED status outputs) below for convenience:

Code: Select all

void sk_init_adc_network(void) {
	unsigned data;
	read_node_config_reg(tile[0], 0x87, data);
	if (data == 0) { 
		write_node_config_reg(tile[0], 0x85, 0xC0002004); // open
		write_node_config_reg(tile[0], 0x85, 0xC1002004); // and say hello
		write_sswitch_reg_no_ack(0x8000, 0x86, 0xC1002004); // say hello
		write_sswitch_reg_no_ack(0x8000, 0xC, 0x11111111); // open and say hello

		read_sswitch_reg(0x8001, 5, data);
		read_sswitch_reg(0x8000, 5, data);
		read_sswitch_reg(0x0, 5, data);
     }
}
If anyone can shed some light on this please do..

P.S. I am also wondering if there needs to be any delays between the switch writes/reads

regards
Al
User avatar
segher
XCore Expert
Posts: 843
Joined: Sun Jul 11, 2010 1:31 am

Postby segher » Sat Jan 11, 2014 2:07 pm

Folknology wrote:What I am unsure about (due to lack of switch setup experience) is how the links between the ADC on its tile and the user tile are setup, it looks like it may be a non-routed link but don't quote me on that,
I'll call the two processors the "application node" and the
"debugger node". The app node is node # 0, the debug
node is # 0x8000, and the analogue node is # 0x8001.

The two switches are connected by their links G,H,E,F
(to F,E,H,G in that order). Link C on the debug node's
switch is connected to the analogue tile (which has no
switch, it does no routing, it ignores its node # even).

The OTP code on the debug node sets up link C (to the
analogue) and its link E (to the app node). Link C gets
direction 0, link E gets direction 1. Routing is not set up,
so everything is sent to direction 0.

Thanks for pasting the code, zips are hard to read in a
web browser :-)

read_node_config_reg(tile[0], 0x87, data);
if (data == 0) {
Read the config of the app node's link F; run the rest
only if it is disabled so far.

write_node_config_reg(tile[0], 0x85, 0xC0002004); // open
write_node_config_reg(tile[0], 0x85, 0xC1002004); // and say hello
Open link H from the app node (to link E on the debug node).

write_sswitch_reg_no_ack(0x8000, 0x86, 0xC1002004); // say hello
write_sswitch_reg_no_ack(0x8000, 0xC, 0x11111111); // open and say hello
Say hello in the other direction (did that before but the link
on the app side was still disabled); set up routing on the
debug node to route directions 8..15 (i.e., anything with
the top eight bits zero) to the app node.

read_sswitch_reg(0x8001, 5, data);
read_sswitch_reg(0x8000, 5, data);
Read the node # from the analogue node and the debug
node, to test if it all is set up right. This hangs if not.

Does that help?

Cheers,


Segher
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm

Postby Folknology » Sat Jan 11, 2014 2:25 pm

Thanks segher that really helps, couple more questions if you don't mind:

1) Does the read_sswitch_reg return anything (modifies 'data') to test if all ok or does it literally hang/trap or whatever
2) Do we need to insert any form of delay between the write_sswitch and read_sswitch

3) Is there a document that identifies the hex codes/links etc..

4) Is there anything obvious you can see in this setup that assumes -fxscope on the xcc flags, i.e. some reliance on links setup by xscope

P.S. I have the xConnect architecture doc and the U16A data sheet but still seem to be missing information

regards
Al
User avatar
segher
XCore Expert
Posts: 843
Joined: Sun Jul 11, 2010 1:31 am

Postby segher » Sat Jan 11, 2014 3:05 pm

Folknology wrote:Thanks segher that really helps, couple more questions if you don't mind:
Sure!
1) Does the read_sswitch_reg return anything (modifies 'data') to test if all ok or does it literally hang/trap or whatever
If there is no reply it hangs waiting for it (in the INCT
instruction). If the reply is a NAK it returns 0 and doesn't
modify data; if the reply is an ACK it writes the reply to
data, and returns 1.
2) Do we need to insert any form of delay between the write_sswitch and read_sswitch
After saying HELLO from the app node, you should wait until
you have credit before sending on that link. Same for the
HELLO back -- you check if your switch has sent credit
(checking on the remote switch will hang if things went bad).
All messages stay in order, that gives some useful sequencing,
saving your sanity (somewhat).
3) Is there a document that identifies the hex codes/links etc..
For the registers, use the datasheet. For protocol description
etc. use the L1 system spec.
4) Is there anything obvious you can see in this setup that assumes -fxscope on the xcc flags, i.e. some reliance on links setup by xscope
Nothing that stands out; where exactly does it hang? Dumping
the sswitch regs will also be useful, if you can do that.
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm

Postby Folknology » Sat Jan 11, 2014 3:19 pm

Thanks Segher

I have to do some chores now but you have given me some avenues to explore, I will take another look at this later and see if I can resolve this armed with your helpful explanations.

regards
Al
User avatar
segher
XCore Expert
Posts: 843
Joined: Sun Jul 11, 2010 1:31 am

Postby segher » Sat Jan 11, 2014 3:48 pm

A correction: the debug node does _not_ send an HELLO
on its link E in its startup code.

Btw, that check for link F active, at the very start -- that
seems to be there so that this code also runs on the usual
configuration of U chips.

Who is online

Users browsing this forum: No registered users and 1 guest