Show Posts
Pages: 1 ... 404 405 [406] 407 408 ... 593
6076  Development / Other Hardware Development / Re: Logic sniffer shield on: September 05, 2011, 02:13:09 am
Like all these logic analyser style projects when you start adding real useful stuff like triggers, start on trigger, stop on trigger, trigger in center of data etc it gets much harder.

One problem with SPI is getting synced with the data, one bit out and it's all garbage.

6077  Development / Other Hardware Development / Re: Logic sniffer shield on: September 05, 2011, 01:56:38 am
With the FIFO you will have to start reading at the same rate as writing once the chip is full if you want to have a "stop on trigger" mode.

6078  Development / Other Hardware Development / Re: Logic sniffer shield on: September 05, 2011, 01:55:16 am
I just gave the data sheet for the 23A256 a quick look over.

It seems that you can send a control byte or two to set the address etc. and put it into sequential mode. Thereafter every 8 clock pulses stores a byte until you stop.

You're right about the FIFO though, it's probably a better choice. At 50MHz you don't need all that shift reg stuff in the design on the other thread I would think, just use it as a 9-ch analyser.

I just had a look at the price for an IDT7208, $30-40, yikes! Still you only need one. The 23A256 is $2 and for the same bit width you need 9 of them, OTOH 4 bits is probably enough.

6079  Using Arduino / Networking, Protocols, and Devices / Re: Arduino as SPI slave? on: September 05, 2011, 01:04:35 am
I started a thread here,

Just a thought. Mind you the FIFOs would do a similar thing.

6080  Development / Other Hardware Development / Logic sniffer shield on: September 05, 2011, 01:02:42 am
Further to some discussions on another thread re sniffing data on an SPI line I got the brilliant idea to use SPI serial RAM chips to do the actual data collection.

As many (all?) these chips have a "sequential" mode whereby bytes are sequentially written to consecutive locations the idea is to let them do the work then read and upload the results using the host Arduino.

Now for $30 you can buy a Bus Pirate so I'm not sure it's worth the effort, OTOH this could also be a 20MHz logic analyser as well and the number of threads I see here with issues that would be solved in 2 minutes if the data could be seen is huge. 

Block diagram below.

Any thoughts from the collective?
6081  Using Arduino / Networking, Protocols, and Devices / Re: Arduino as SPI slave? on: September 04, 2011, 11:00:11 pm
Crossroads, did you do any more work on that FIFO design?

I just had a brilliant (I think) idea to do a cheap analyser, I might start another thread to write it up.

6082  Using Arduino / Project Guidance / Re: RS-232 and Ethernet shield on 1 UART? on: September 04, 2011, 07:39:39 pm
AFAIK Ethernet shields use SPI.

6083  Community / Bar Sport / Re: Equivilant of loop() in Objective-C? on: September 04, 2011, 07:38:10 pm
I'm not familiar with Objective C but with "normal" C

main () {

  while (1) {
    // do stuff here forever


6084  Topics / Device Hacking / Re: Reprogramming the AAG RS485 Weather Station on: September 04, 2011, 06:58:48 pm
crystal controlled at 3.686MHz. I'll need some guidance about how to handle the initial reprogramming based on this clock speed.
I'd replace the Xtal with a 16Mhz version as I doubt there's a bootloader set for 3.686. Maybe you can recompile one of the existing loaders though.

5-pin programming header already on the PCB
Curious, the standard ISP header is 6 pins.

6085  Using Arduino / General Electronics / Re: Drawback of using Resistors wires as Jumpers!!! on: September 04, 2011, 09:42:27 am
That's just fine, don't even cut them off, just bend to the place they have to be if they'll reach.

6086  Development / Other Software Development / Re: QUUBmon - yet another monitor program on: September 04, 2011, 04:47:28 am
the SET command
I guess the documentation is not up to scratch yet smiley

SET will write a value into the IPC, so backing up, what's the IPC?

The IPC (Inter Processor Communications) area is a few bytes in the target (server/DUT) RAM that both server and client know about. Therefore the client (monitor) can write into this memory and the server application can take action based on that data.

There is a simple example in the server code

  // use "SET 3 0" to start the LED flashing
  // use "SET 4 n" to set the flash rate
  if (QM_ipc_scratch[3] == 0) {
    digitalWrite(13, HIGH);   // set the LED on
    digitalWrite(13, LOW);    // set the LED off

Entering "SET 3 0" (write 0 into offset 3) into the monitor should cause the server to start flashing the LED while "SET 4 n" will change the flash rate. Silly example but this should be usable - for example - to play with values for an algorithm without having to recompile.

Conversely if you mirror a server variable into the IPC (or just use the area directly) you can read it from the monitor.

Obviously you can read RAM anywhere but in the absence of symbolic information (a good project BTW, to read the MAP/ELF/whatever file and use symbols) this is a reasonable alternative.

As I didn't know how to force the address of the IPC (another thing to look into) there's the "IPC ?" command to find it.

INFO seams to return the same result as IPC
They both dump the IPC memory but INFO first writes some DUT info into the memory. Here's one after the other

AVR> ipc
 0131:  49 50 43 20 73 63 72 61 74 63 68 20 52 41 4D 00    IPC scratch RAM.
AVR> info
 0131:  42 03 04 05 0C 0B 0D 61 03 28 01 01 52 41 4D 00    B......a.(..RAM.
AVR> ipc
 0131:  42 03 04 05 0C 0B 0D 61 03 28 01 01 52 41 4D 00    B......a.(..RAM.

Note that the first IPC shows the default data in the RAM, the string "IPC scratch RAM". INFO shows the same RAM but the string has been overwritten. And the next IPC shows the same as the INFO for that reason.

It's a bit cryptic but

42 "B", the port used by the server for bit banged SPI
03 IO port MOSI pin
04 IO port MISO pin
05 IO port SCK pin
0C Arduino D pin # for MISO
0B Arduino D pin # for MOSI
0D Arduino D pin # for SCK
61 not used
03 server processor hi byte
28 server processor lo byte   (0328 = mega328, you should see 2560 I think)
01 server code version hi byte
01 server code version lo byte (server code version 01.01)

Of course you probably know most of the above or you wouldn't be seeing the data in the first place, so I don't know how useful it is. Seemed like a good idea at the time smiley

AN works for me but my server is a 328 that only has 6 analogue ports anyway, maybe the structure is not properly defined for a 2560.

Thanks a ton for sharing it Rob,
No problems, good to see it being used. There wasn't much interest at the time and I had no immediate use for it myself as I was designing hardware (still am), so I didn't clean it up and add stuff I would have liked to.

6087  Development / Other Software Development / Re: QUUBmon - yet another monitor program on: September 04, 2011, 04:06:08 am
Thank goodness. I'll spend some time tidying things up and maybe reinstating some of the commands.

I know 99% of people don't need such a tool but just to have a second opinion on the values in - for example - the timer regs is valuable I think. It's one thing to "know" you wrote 55 into a reg, quite another to have that verified by an independent tool and maybe see the value 37 and realize that you should have typed 0x55.

As you may have seen the "peripherals" are just lists of data structures and addresses and as such they are arbitrary and configurable. For example all the timers have their own regs but also share the GTCCR reg. So all the tmr0/1/2/3 etc commands show the GTCCR reg as well as those regs unique to the separate timers.

Thus "peripherals" are logical, not literal. Another example of a logical peripheral is the "mcu" peripheral, this shows all sorts of regs like the status reg, stack pointers, OSCALL etc.

In the above screen dump by Chris, UPPERCASE bit names is a set bit, lowercase is a cleared bit.

As all this was hand entered there are bound to be some mistakes, hopefully they will get sorted over time.

Some other points re the UI.

TAB - repeat the last command
UP ARROW - recall the last command to the screen

The address used by a command is remembered, so if you do "P 100" to dump the page at address 100 you can follow that with just "P" (or "L" for that matter) and get a dump from the same location.

handy if you want to reference the struct inside the struct.
Like with a linked list.

Thanks s_reg, I'l mod the code.
6088  Development / Other Software Development / Re: QUUBmon - yet another monitor program on: September 04, 2011, 02:23:30 am
The reason I have the master/slave relationship with the DUT as master is to allow the monitor to be as less intrusive as possible. Granted there is an interrupt every 16mS (maybe an on/off facility would be good) but this is only ~5% of the CPU time (my original assembler version was better) and with bit banging any pins can be used. You can't debug an SPI port if you are using it for debugging as well.

I currently use the SPI pins but that's just for convenience with the cable between ISP headers. Any other pins can be used.

Anyway that's the general idea.

Also I just read you breakpoint idea, I was thinking of proper software breakpoints that need flash to be written, but yes you could toggle a pin to cause an interrupt which in turn could say enable the monitor. The monitor could also run with full control or in the background as it does now. I think having both is good because a lot of programs will break if you stop in a monitor. 
Any thoughts are welcome.

6089  Development / Other Software Development / Re: QUUBmon - yet another monitor program on: September 04, 2011, 01:58:31 am
Yay it's working.

I have the client working on a 2560 and server on a 328. What a bloody drama and to be honest i still don't exactly know what the trouble was. I just rewrote half the code smiley

Latest code

Chris, if you could give it a try that would be good.

As for break points, that will be difficult because you have to write into flash. Doable I guess but not easy.

Here's a list of commands
RD - Read a single byte from the target RAM.
WR - Write a byte to target RAM.
L - Do a HEX dump of 16 bytes (a “line”) from the target RAM.
P - Do a HEX dump of 128 bytes (a “page”) from the target RAM.
REGS - Display the target processors registers (only with an assembly language server)
IO - Display the target processor’s IO registers.
F - Fill target RAM with a value.
SP - Display the target processors stack pointer and the values on the stack.
PER - Display detail about the target processor’s “peripherals”.
WATCH - Periodically sample a memory or IO location on the target processor.
RST - Reset the target processor.
IPC ? - Find the IPC (Inter Processor Comms) area of RAM on the target system.
IPC - Dump the IPC (Inter Processor Comms) area of RAM on the target system.
SET - Set a variable in the IPC.
DIG - Display all Arduino digital pin values on the target system.
AN - Display all Arduino analogue pin values on the target system.
PIN - Display and control Arduino digital pins.
PC - Display the target processor’s program counter.
INFO - Get information about the target system.

Note that a lot of them are disabled and there's still plenty of debug code hanging around.

6090  Community / Exhibition / Gallery / Re: AAG Weather Station - RS485 version on: September 03, 2011, 11:18:31 pm
I would also go with the ISP programming, it'll give you a couple of k extra flash as well.

Pages: 1 ... 404 405 [406] 407 408 ... 593