Title: Firmware v5.7
Post by: ian on August 13, 2010, 01:33:06 pm
Post by: ian on August 13, 2010, 01:33:06 pm
This release:
-Any requested changes and extension to servo and PWM
-unify the two PWM functions
???
-Any requested changes and extension to servo and PWM
-unify the two PWM functions
???
Title: Re: Firmware v5.7
Post by: Sjaak on August 13, 2010, 10:54:14 pm
Post by: Sjaak on August 13, 2010, 10:54:14 pm
I guess I have to work on 16 bits read/write :) ( http://dangerousprototypes.com/forum/in ... opic=833.0 (http://dangerousprototypes.com/forum/index.php?topic=833.0) )
(perhaps more :P)
(perhaps more :P)
Title: Re: Firmware v5.7
Post by: Randy on August 14, 2010, 02:01:29 am
Post by: Randy on August 14, 2010, 02:01:29 am
There's really no reason why the PWM functions and servo mode couldn't be unified.
On another note, since the Easter egg has been depreciated is it OK to publish this?
Randy ;-)
On another note, since the Easter egg has been depreciated is it OK to publish this?
Code: [Select]
HiZ> m 4
Set speed:
1. ~5KHz
2. ~50KHz
3. ~100KHz
4. ~400KHz
(1)>
Ready
I2C> WP
Power supplies ON
Pull-up resistors ON
I2C> go n
You are at the heart of the buspirate: the PIC24FJ64GA002!!
CFG1:0xF9DF CFG2:0x3F7F DEVID:0x0447 REVID:0x3043
Exits: North East south
I2C> go n
You are near the current limiting resistors
Exits: North West East south
I2C> go n
You are standing next to an interesting chip
It is a I2C EEPROM!
you read carefully the contents:
__ .________
-= 7H3 BU5P1R47E W1ll =- |__| _
___.___ _____ .________ .___ __.____________ /
/ | / _ \_ ___ | |/__| __ ___/ /
/ + / /_ / | | | | |____/
/ | __|_ | | | | | ____
___|_ ____|__ ______ /___|__ __| |____|| |
/ : / / : / CvD:2010 |___/
Exits:
I2C>
Randy ;-)
Title: Re: Firmware v5.7
Post by: Sjaak on August 14, 2010, 09:28:13 am
Post by: Sjaak on August 14, 2010, 09:28:13 am
It is ok, it is also on the blog. So it is not an secret anymore.
I hope you enjoyed it and took a nice walk in the buspirate. We included it to make people aware they should use pullups on I2C.
I hope you enjoyed it and took a nice walk in the buspirate. We included it to make people aware they should use pullups on I2C.
Title: Re: Firmware v5.7
Post by: ian on August 14, 2010, 09:49:19 am
Post by: ian on August 14, 2010, 09:49:19 am
Is the new feature for 9bit+ read/writes, or is it specifically 16bits?
Title: Re: Firmware v5.7
Post by: Sjaak on August 14, 2010, 09:53:46 am
Post by: Sjaak on August 14, 2010, 09:53:46 am
everything in between :D so 1-16 bits read/write should be possible.
You can use it for PIC programming? :P
You can use it for PIC programming? :P
Title: Re: Firmware v5.7
Post by: tiersten on August 14, 2010, 06:36:15 pm
Post by: tiersten on August 14, 2010, 06:36:15 pm
Two cosmetic bugs/issues which are still present in v5.6.
1. If you do frequency measurement (f) and then hold down a key it overflows some buffer somewhere and the Bus Pirate gets stuck and thinks every input key is that character.
e.g. On a just started Bus Pirate in HiZ mode with nothing connected, press f and then hold down the enter key until the HiZ> prompt reappears. At this point the Bus Pirate will think every character input is enter and the only way to fix it is to unplug it and plug it back in.
Its not a particularly high priority bug as the workaround is just not to do this since there is no reason to do this particular sequence.
2. The read/write commands give odd looking error output.
1. If you do frequency measurement (f) and then hold down a key it overflows some buffer somewhere and the Bus Pirate gets stuck and thinks every input key is that character.
e.g. On a just started Bus Pirate in HiZ mode with nothing connected, press f and then hold down the enter key until the HiZ> prompt reappears. At this point the Bus Pirate will think every character input is enter and the only way to fix it is to unplug it and plug it back in.
Its not a particularly high priority bug as the workaround is just not to do this since there is no reason to do this particular sequence.
2. The read/write commands give odd looking error output.
Code: [Select]
HiZ> 4The WRITE: 0x04 and write command error come out on the same line. It also complains about a syntax error.
WRITE: 0x04ERROR: command has no effect here
Syntax error at char 1
Code: [Select]
HiZ> rPrints out 0x00 and that syntax error again.
READ: ERROR: command has no effect here
0x00
Syntax error at char 1
Title: Re: Firmware v5.7
Post by: Sjaak on August 14, 2010, 06:58:57 pm
Post by: Sjaak on August 14, 2010, 06:58:57 pm
the behaviour in HiZ is as expected. since we did a rework of the userinput parsing this is not avoidable (without a lots of if-statements which takes valuable space). Every command that doesn't work will give errors like this (try r in the lcd protocol)
I agree it is a bit odd but you get the idea that that command is wrong and not active.
Will look into the first. Holding it down during the measurement I assume?
I agree it is a bit odd but you get the idea that that command is wrong and not active.
Will look into the first. Holding it down during the measurement I assume?
Title: Re: Firmware v5.7
Post by: tiersten on August 14, 2010, 07:13:39 pm
Post by: tiersten on August 14, 2010, 07:13:39 pm
[quote author="Sjaak"]
the behaviour in HiZ is as expected. since we did a rework of the userinput parsing this is not avoidable (without a lots of if-statements which takes valuable space).[/quote]
Ahh. I see. Is the WRITE one which is missing a CR or space fixable at least? :)
[quote author="Sjaak"]Will look into the first. Holding it down during the measurement I assume?
[/quote]
Yup
the behaviour in HiZ is as expected. since we did a rework of the userinput parsing this is not avoidable (without a lots of if-statements which takes valuable space).[/quote]
Ahh. I see. Is the WRITE one which is missing a CR or space fixable at least? :)
[quote author="Sjaak"]Will look into the first. Holding it down during the measurement I assume?
[/quote]
Yup
Title: Re: Firmware v5.7
Post by: ian on August 14, 2010, 07:24:05 pm
Post by: ian on August 14, 2010, 07:24:05 pm
Hi tiersten - thanks for the reports.
The overflow is actually in the UART hardware buffer. We don't read or clear it while in the frequency measurement loop, so it overflows and then only reads the last successful character. This is the expected behavior, but you are the first to report observing it :) The way to fix it is to check the overflow flags in the terminal RX/TX routines (see the UART bridge code for an example), but that will take up a cycle or two for every character we send up the UART. Maybe check and clear can be added to the main loop because the Bus Pirate only runs it when idle.
The overflow is actually in the UART hardware buffer. We don't read or clear it while in the frequency measurement loop, so it overflows and then only reads the last successful character. This is the expected behavior, but you are the first to report observing it :) The way to fix it is to check the overflow flags in the terminal RX/TX routines (see the UART bridge code for an example), but that will take up a cycle or two for every character we send up the UART. Maybe check and clear can be added to the main loop because the Bus Pirate only runs it when idle.
Title: Re: Firmware v5.7
Post by: tiersten on August 14, 2010, 07:31:32 pm
Post by: tiersten on August 14, 2010, 07:31:32 pm
[quote author="ian"]The overflow is actually in the UART hardware buffer. We don't read or clear it while in the frequency measurement loop, so it overflows and then only reads the last successful character. This is the expected behavior, but you are the first to report observing it :) The way to fix it is to check the overflow flags in the terminal RX/TX routines (see the UART bridge code for an example), but that will take up a cycle or two for every character we send up the UART. Maybe check and clear can be added to the main loop because the Bus Pirate only runs it when idle.[/quote]
Ahh okay. As I said originally, it isn't a particularly big issue anyway since you're not really supposed to do that anyway and the fix will use more valuable space.
Ahh okay. As I said originally, it isn't a particularly big issue anyway since you're not really supposed to do that anyway and the fix will use more valuable space.
Title: Re: Firmware v5.7
Post by: Sjaak on August 14, 2010, 08:11:09 pm
Post by: Sjaak on August 14, 2010, 08:11:09 pm
Hmmm boner. After soldering the HVP adapter Ian send me, I wanted to add some support for low-end pics. After quiet some time i realized there is no support in the buspirate ;(
I guess I'm going to implant a pic614 into binwire.c :D
I guess I'm going to implant a pic614 into binwire.c :D
Title: Re: Firmware v5.7
Post by: ian on August 16, 2010, 09:26:35 am
Post by: ian on August 16, 2010, 09:26:35 am
Hoi Sjaakje - een cadeautje :) Something James, our new programmer, worked up this weekend :) (also in SVN)
Title: Re: Firmware v5.7
Post by: Sjaak on August 16, 2010, 09:42:51 am
Post by: Sjaak on August 16, 2010, 09:42:51 am
ZZZZmak!! :$
I have the lowend pic subs ready I think, but my hvp doesn't work anymore. I think I blew a transistor or something. The /MCLR is always Ov :(
Too bad I found out late in the evening after hours of debugging and altering code ;)
I have the lowend pic subs ready I think, but my hvp doesn't work anymore. I think I blew a transistor or something. The /MCLR is always Ov :(
Too bad I found out late in the evening after hours of debugging and altering code ;)
Title: Re: Firmware v5.7
Post by: ian on August 16, 2010, 10:01:15 am
Post by: ian on August 16, 2010, 10:01:15 am
Let me know if you need another or some parts.
Title: Re: Firmware v5.7
Post by: Sjaak on August 16, 2010, 10:31:35 am
Post by: Sjaak on August 16, 2010, 10:31:35 am
I think I can fix it, I have lots of transistors or scrapp boards for parts. :D
Those transistors aren't very critical, are they?
Those transistors aren't very critical, are they?
Title: Re: Firmware v5.7
Post by: octal on August 16, 2010, 10:36:20 am
Post by: octal on August 16, 2010, 10:36:20 am
Just out of curiosity, where do you buy your SMT components (in small qtt) ?
Title: Re: Firmware v5.7
Post by: ian on August 16, 2010, 10:48:09 am
Post by: ian on August 16, 2010, 10:48:09 am
I buy from mouser or digikey (usually mouser because they have free fedex to my location for orders over $100). Most people seem to have a preference for one search engine or the other, I've never had a problem with either.
Title: Re: Firmware v5.7
Post by: ian on August 16, 2010, 10:48:49 am
Post by: ian on August 16, 2010, 10:48:49 am
Values are not critical, but one is PNP :)
Title: Re: Firmware v5.7
Post by: Sjaak on August 16, 2010, 11:14:01 am
Post by: Sjaak on August 16, 2010, 11:14:01 am
[quote author="ian"]
Values are not critical, but one is PNP :)
[/quote]
It did work (I checked it with a DVM) sometime before I found out that Vpp wasn't applied anymore.
You need to have a business account with mousser/digikey?
I mostly use conrad for components, they are more focussed on private persons then a farnell.
Values are not critical, but one is PNP :)
[/quote]
It did work (I checked it with a DVM) sometime before I found out that Vpp wasn't applied anymore.
You need to have a business account with mousser/digikey?
I mostly use conrad for components, they are more focussed on private persons then a farnell.
Title: Re: Firmware v5.7
Post by: ian on August 16, 2010, 11:42:38 am
Post by: ian on August 16, 2010, 11:42:38 am
I find farnell impossible. I did order from conrad once I think (?). Nope, I just use a regular mouser/digikey account.
Title: Re: Firmware v5.7
Post by: telfohw on August 16, 2010, 12:34:04 pm
Post by: telfohw on August 16, 2010, 12:34:04 pm
Hi friend,
First of all, thanks for your fantastic work with this impressive tool.
Well, I would like to suggest if for version 5.7+ it would be interesting to add <=8 bits parallel mode like a raw5 mode (5 bit free mode with MOSI,MISO,CS,AUX,CLOCK) or also raw7(taking also as outputs PGC y PGD in the other connector). Also if we could re-use ADC input (configured as output) we could reach until a raw8 mode.
It would allow to directly interface LCD screens like HD44780 (4bit mode) without the lcd adapter. I think it would cover almost every device we think about.
Hope my idea helps for firmware 5.7+.
Thanks again friends.
First of all, thanks for your fantastic work with this impressive tool.
Well, I would like to suggest if for version 5.7+ it would be interesting to add <=8 bits parallel mode like a raw5 mode (5 bit free mode with MOSI,MISO,CS,AUX,CLOCK) or also raw7(taking also as outputs PGC y PGD in the other connector). Also if we could re-use ADC input (configured as output) we could reach until a raw8 mode.
It would allow to directly interface LCD screens like HD44780 (4bit mode) without the lcd adapter. I think it would cover almost every device we think about.
Hope my idea helps for firmware 5.7+.
Thanks again friends.
Title: Re: Firmware v5.7
Post by: ian on August 16, 2010, 12:44:18 pm
Post by: ian on August 16, 2010, 12:44:18 pm
Hi telfohw - thanks for the suggestions.
There is a binary bitbang mode that gives access to all five pins like this. I'm not sure how to integrate it into user terminal mode because there isn't currently syntax to control 5 different pins.
Unfortunately the ADC has a voltage divider attached so it can measure >3.3volts. It is not possible to use it as an output. Some people have used the PGC and PGD pins for outputs in the past though.
Quote
raw5 mode (5 bit free mode with MOSI,MISO,CS,AUX,CLOCK)
There is a binary bitbang mode that gives access to all five pins like this. I'm not sure how to integrate it into user terminal mode because there isn't currently syntax to control 5 different pins.
Quote
Also if we could re-use ADC input
Unfortunately the ADC has a voltage divider attached so it can measure >3.3volts. It is not possible to use it as an output. Some people have used the PGC and PGD pins for outputs in the past though.
Title: Re: Firmware v5.7
Post by: Sjaak on August 16, 2010, 01:01:13 pm
Post by: Sjaak on August 16, 2010, 01:01:13 pm
AUX is only 3v3 output (5v tolerant input), and not HiZ. The other in/outputs can be anything (depending on the Vpu).
If you want additional in/ouputs a i2c/spi expander chip is the easiest way. They provide mixed in and outputs.
[quote author="ian"]
Hi telfohw - thanks for the suggestions.
There is a binary bitbang mode that gives access to all five pins like this. I'm not sure how to integrate it into user terminal mode because there isn't currently syntax to control 5 different pins.
[/quote]
Just a read/write, and a macro that can set the direction of the pin? lets call it raw4wire :)
If you want additional in/ouputs a i2c/spi expander chip is the easiest way. They provide mixed in and outputs.
[quote author="ian"]
Hi telfohw - thanks for the suggestions.
Quote
raw5 mode (5 bit free mode with MOSI,MISO,CS,AUX,CLOCK)
There is a binary bitbang mode that gives access to all five pins like this. I'm not sure how to integrate it into user terminal mode because there isn't currently syntax to control 5 different pins.
[/quote]
Just a read/write, and a macro that can set the direction of the pin? lets call it raw4wire :)
Title: Re: Firmware v5.7
Post by: ian on August 16, 2010, 04:17:02 pm
Post by: ian on August 16, 2010, 04:17:02 pm
AUX can be hiz by making it an input (@)...
Sure, I guess that mode doesn't take up much space (other than the program struct). Something for the bonus/BP2 firmware?
Sure, I guess that mode doesn't take up much space (other than the program struct). Something for the bonus/BP2 firmware?
Title: Re: Firmware v5.7
Post by: Sjaak on August 16, 2010, 04:27:31 pm
Post by: Sjaak on August 16, 2010, 04:27:31 pm
You are right about @ :D Except it doesn't have 'internal' pullups..
bonus/bp2 firmware??
bonus/bp2 firmware??
Title: Re: Firmware v5.7
Post by: ian on August 16, 2010, 05:06:30 pm
Post by: ian on August 16, 2010, 05:06:30 pm
The secondary part with less-used modes
Title: Re: Firmware v5.7
Post by: tayken on August 18, 2010, 08:28:44 pm
Post by: tayken on August 18, 2010, 08:28:44 pm
I recently purchased a Wii NUnchuck and I was using BP to communicate with it. I realized that if I write something worn with hex values (like writing o instead of 0) and clear it with backspace I get some strange errors. Doesn't backspace clear the values from the buffer? I'll try to recreate the problem tomorrow and post the logfile here if I am successful.
Title: Re: Firmware v5.7
Post by: ian on August 18, 2010, 08:39:03 pm
Post by: ian on August 18, 2010, 08:39:03 pm
Please post the log if you can, I'll take a look.
Title: Re: Firmware v5.7
Post by: tayken on August 18, 2010, 09:09:14 pm
Post by: tayken on August 18, 2010, 09:09:14 pm
I couldn't create the exact condition but I'll try tomorrow. Here is the result of a quick trial:
Code: [Select]
HiZ> m
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. 2WIRE
7. 3WIRE
8. KEYB
9. LCD
x. exit(without change)
(1)> 4
Set speed:
1. ~5KHz
2. ~50KHz
3. ~100KHz
4. ~400KHz
(1)> 1
Ready
I2C> W
Power supplies ON
I2C> [0xa4 0x40 0x00]
I2C START BIT
WRITE: 0xA4 ACK
WRITE: 0x40 ACK
WRITE: 0x00 ACK
I2C STOP BIT
I2C> [0xa4 0x00][0xa5 r:6]
I2C START BIT
WRITE: 0xA4 ACK
WRITE: 0x00 ACK
I2C STOP BIT
I2C START BIT
WRITE: 0xA5 ACK
READ: 0x70 ACK 0x7B ACK 0x80 ACK 0x7F ACK 0x6E ACK 0xC3
NACK
I2C STOP BIT
I2C> [0xa4 0x00][0xa5 r:6]
I2C START BIT
WRITE: 0xA4 ACK
WRITE: 0x00 ACK
I2C STOP BIT
I2C START BIT
WRITE: 0xA5 ACK
READ: 0x70 ACK 0x7B ACK 0x80 ACK 0x7F ACK 0x6E ACK 0xC7
NACK
I2C STOP BIT
I2C> [0xa4 0x00] << For the second number I wrote 0xo then backspace to correct and 00
I2C START BIT
WRITE: 0xA4 ACK
WRITE: 0x00 ACK
1. HEX
2. DEC
3. BIN
4. RAW
(1)> 1
Display format set
WRITE: 0x00 ACK
I2C STOP BIT
I2C> [0xa5 r:6]
I2C START BIT
WRITE: 0xA5 ACK
READ: 0x70 ACK 0x7B ACK 0x80 ACK 0x7F ACK 0x6D ACK 0x3B
NACK
I2C STOP BIT
I2C> [0xa4 0x00] << For the first number I wrote o then backspace to correct and 0xa4
I2C START BIT
1. HEX
2. DEC
3. BIN
4. RAW
(1)> 1
Display format set
WRITE: 0xA4 ACK
WRITE: 0x00 ACK
I2C STOP BIT
I2C> [0xa5 r:6]
I2C START BIT
WRITE: 0xA5 ACK
READ: 0x70 ACK 0x7B ACK 0x81 ACK 0x7F ACK 0x6E ACK 0x9F
NACK
I2C STOP BIT
I2C>
Title: Re: Firmware v5.7
Post by: octal on August 18, 2010, 10:11:21 pm
Post by: octal on August 18, 2010, 10:11:21 pm
[quote author="tayken"]
Doesn't backspace clear the values from the buffer?
[/quote]
Answer is "NO, NOT ALWAYS" !!!
All depends on the terminal emulation you are using in your PC side software. What software are you using? what emulation are you using (none, VT100, ...) ?
Regards
Doesn't backspace clear the values from the buffer?
[/quote]
Answer is "NO, NOT ALWAYS" !!!
All depends on the terminal emulation you are using in your PC side software. What software are you using? what emulation are you using (none, VT100, ...) ?
Regards
Title: Re: Firmware v5.7
Post by: tayken on August 18, 2010, 10:21:40 pm
Post by: tayken on August 18, 2010, 10:21:40 pm
[quote author="octal"]
All depends on the terminal emulation you are using in your PC side software. What software are you using? what emulation are you using (none, VT100, ...) ?
[/quote]
I'm using PuTTY om my Windows machine. The emulation it uses is xterm. I'll also check out with my Linux machine and see if there is a difference.
All depends on the terminal emulation you are using in your PC side software. What software are you using? what emulation are you using (none, VT100, ...) ?
[/quote]
I'm using PuTTY om my Windows machine. The emulation it uses is xterm. I'll also check out with my Linux machine and see if there is a difference.
Title: Re: Firmware v5.7
Post by: octal on August 19, 2010, 05:33:59 am
Post by: octal on August 19, 2010, 05:33:59 am
Hi Tayken,
what happens if you use Ctrl+H to delete last char (instead of Backspace)? does it work?
what happens if you use Ctrl+H to delete last char (instead of Backspace)? does it work?
Title: Re: Firmware v5.7
Post by: tayken on August 19, 2010, 07:16:57 am
Post by: tayken on August 19, 2010, 07:16:57 am
Here is the log file of what you suggested octal:
As you can see it works! :) Wonder why it is...
Code: [Select]
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2010.08.19 14:12:29 =~=~=~=~=~=~=~=~=~=~=~=
HiZ> m
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. 2WIRE
7. 3WIRE
8. KEYB
9. LCD
x. exit(without change)
(1)> 4
Set speed:
1. ~5KHz
2. ~50KHz
3. ~100KHz
4. ~400KHz
(1)> 1
Ready
I2C> W
Power supplies ON
I2C> [0xa4 0x40 0x00]
I2C START BIT
WRITE: 0xA4 ACK
WRITE: 0x40 ACK
WRITE: 0x00 ACK
I2C STOP BIT
I2C> [0xa4 0x00][0xa5 r:6]
I2C START BIT
WRITE: 0xA4 ACK
WRITE: 0x00 ACK
I2C STOP BIT
I2C START BIT
WRITE: 0xA5 ACK
READ: 0x70 ACK 0x7B ACK 0x83 ACK 0x7D ACK 0x6A ACK 0xAF
NACK
I2C STOP BIT
I2C> [0xa4 0xo 00] << used Ctrl+H
I2C START BIT
WRITE: 0xA4 ACK
WRITE: 0x00 ACK
I2C STOP BIT
I2C> [0xa5 r:6]
I2C START BIT
WRITE: 0xA5 ACK
READ: 0x70 ACK 0x7B ACK 0x82 ACK 0x7D ACK 0x69 ACK 0xE7
NACK
I2C STOP BIT
I2C>
As you can see it works! :) Wonder why it is...
Title: Re: Firmware v5.7
Post by: Sjaak on August 19, 2010, 08:22:11 am
Post by: Sjaak on August 19, 2010, 08:22:11 am
some terminals swap backspace and delete. this is selectable (mostly) in the settings. Basicly only a-z are the same across terminals ;)
Title: Re: Firmware v5.7
Post by: tayken on August 19, 2010, 08:36:20 am
Post by: tayken on August 19, 2010, 08:36:20 am
Changing the backspace key setting to set it to Ctrl+H worked! Thanks guys! So the problem was not about the firmware but about my terminal.
Title: Re: Firmware v5.7
Post by: ian on August 19, 2010, 09:08:29 am
Post by: ian on August 19, 2010, 09:08:29 am
Thanks for the update, glad you got it working.
I have a v5.7 release on my todo list for today, but so far I think the only changes are the SPI sniffer updates I made yesterday (and have not checked in). I'll probably bump that to tomorrow until I hear more about the sniffer update.
I have a v5.7 release on my todo list for today, but so far I think the only changes are the SPI sniffer updates I made yesterday (and have not checked in). I'll probably bump that to tomorrow until I hear more about the sniffer update.
Title: Re: Firmware v5.7
Post by: octal on August 19, 2010, 11:27:47 am
Post by: octal on August 19, 2010, 11:27:47 am
Glad it worked for you tayken.
I know this kind of problems mainly because I started working with Linux since 1995 ... I was using Slackware Linux, and we had a lot of problems with terminal emulation and its config. The time being, Slackware install software on PC was in text mode, and there were no native PC key handling for most extended keyboards (at least for those we had with our PC AT 486XT ;) ) , so we had to deal with such problems using Ctrl+H and other techniques ... :)
Maybe it can help ... you can find more details here http://www.ibb.net/~anne/keyboard.html (http://www.ibb.net/~anne/keyboard.html)
Regards
I know this kind of problems mainly because I started working with Linux since 1995 ... I was using Slackware Linux, and we had a lot of problems with terminal emulation and its config. The time being, Slackware install software on PC was in text mode, and there were no native PC key handling for most extended keyboards (at least for those we had with our PC AT 486XT ;) ) , so we had to deal with such problems using Ctrl+H and other techniques ... :)
Maybe it can help ... you can find more details here http://www.ibb.net/~anne/keyboard.html (http://www.ibb.net/~anne/keyboard.html)
Regards
Title: Re: Firmware v5.7
Post by: ian on August 20, 2010, 08:20:05 am
Post by: ian on August 20, 2010, 08:20:05 am
I'm going to package the 5.7 release now:
*SPI sniffer updates
*check and clear UART overflow flags in the main loop
These are the only minor updates for this version. I'm also going to upload a source code snapshot of v4 and v5, since the last is still a v3 for the old bootloader.
*SPI sniffer updates
*check and clear UART overflow flags in the main loop
These are the only minor updates for this version. I'm also going to upload a source code snapshot of v4 and v5, since the last is still a v3 for the old bootloader.