Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.raspberry-pi > #25372 > unrolled thread
| Started by | bob prohaska <bp@www.zefox.net> |
|---|---|
| First post | 2021-01-01 20:53 +0000 |
| Last post | 2021-01-02 20:45 +0000 |
| Articles | 20 on this page of 61 — 22 participants |
Back to article view | Back to comp.sys.raspberry-pi
USB card adapters crash Pi4 bob prohaska <bp@www.zefox.net> - 2021-01-01 20:53 +0000
Re: USB card adapters crash Pi4 Nikolaj Lazic <nlazicBEZ_OVOGA@mudrac.ffzg.hr> - 2021-01-01 23:32 +0000
Re: USB card adapters crash Pi4 Martin Gregorie <martin@mydomain.invalid> - 2021-01-02 00:52 +0000
Re: USB card adapters crash Pi4 bob prohaska <bp@www.zefox.net> - 2021-01-02 02:13 +0000
Re: USB card adapters crash Pi4 "Dave Liquorice" <allsortsnotthisbit@howhill.com> - 2021-01-02 09:49 +0000
Re: USB card adapters crash Pi4 Martin Gregorie <martin@mydomain.invalid> - 2021-01-02 12:34 +0000
Re: USB card adapters crash Pi4 Martin Gregorie <martin@mydomain.invalid> - 2021-01-02 12:51 +0000
Re: USB card adapters crash Pi4 Jan Panteltje <pNaOnStPeAlMtje@yahoo.com> - 2021-01-02 13:23 +0000
Re: USB card adapters crash Pi4 Martin Gregorie <martin@mydomain.invalid> - 2021-01-02 14:52 +0000
Re: USB card adapters crash Pi4 Jan Panteltje <pNaOnStPeAlMtje@yahoo.com> - 2021-01-02 17:27 +0000
Re: USB card adapters crash Pi4 Martin Gregorie <martin@mydomain.invalid> - 2021-01-02 18:05 +0000
Re: USB card adapters crash Pi4 Jan Panteltje <pNaOnStPeAlMtje@yahoo.com> - 2021-01-02 19:45 +0000
Re: USB card adapters crash Pi4 Martin Gregorie <martin@mydomain.invalid> - 2021-01-02 20:41 +0000
Re: USB card adapters crash Pi4 Jan Panteltje <pNaOnStPeAlMtje@yahoo.com> - 2021-01-03 05:53 +0000
Re: USB card adapters crash Pi4 Martin Gregorie <martin@mydomain.invalid> - 2021-01-03 14:39 +0000
Re: USB card adapters crash Pi4 Jan Panteltje <pNaOnStPeAlMtje@yahoo.com> - 2021-01-03 15:41 +0000
Re: USB card adapters crash Pi4 Joe <joe@jretrading.com> - 2021-01-03 18:38 +0000
Re: USB card adapters crash Pi4 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-01-03 19:15 +0000
Re: USB card adapters crash Pi4 The Natural Philosopher <tnp@invalid.invalid> - 2021-01-04 03:17 +0000
Re: USB card adapters crash Pi4 Martin Gregorie <martin@mydomain.invalid> - 2021-01-04 11:33 +0000
Re: USB card adapters crash Pi4 Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-04 12:24 +0000
Re: USB card adapters crash Pi4 Martin Gregorie <martin@mydomain.invalid> - 2021-01-04 13:58 +0000
Re: USB card adapters crash Pi4 Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2021-01-04 10:21 -0500
Re: USB card adapters crash Pi4 Martin Gregorie <martin@mydomain.invalid> - 2021-01-04 15:33 +0000
Re: USB card adapters crash Pi4 Björn Lundin <b.f.lundin@gmail.com> - 2021-01-23 23:03 +0100
Re: USB card adapters crash Pi4 Martin Gregorie <martin@mydomain.invalid> - 2021-01-23 22:54 +0000
Re: USB card adapters crash Pi4 Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2021-01-23 18:30 -0500
Re: USB card adapters crash Pi4 Martin Gregorie <martin@mydomain.invalid> - 2021-01-24 14:42 +0000
Re: USB card adapters crash Pi4 Pancho <Pancho.Dontmaileme@outlook.com> - 2021-01-23 23:31 +0000
Re: USB card adapters crash Pi4 Scott Alfter <scott@alfter.diespammersdie.us> - 2021-01-25 17:23 +0000
Re: USB card adapters crash Pi4 Martin Gregorie <martin@mydomain.invalid> - 2021-01-25 18:31 +0000
Re: USB card adapters crash Pi4 Jim H <invalid@invalid.invalid> - 2021-01-25 18:47 +0000
Re: USB card adapters crash Pi4 Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2021-01-26 10:59 -0500
Re: USB card adapters crash Pi4 Scott Alfter <scott@alfter.diespammersdie.us> - 2021-01-26 17:13 +0000
Re: USB card adapters crash Pi4 mjb@signal11.invalid (Mike) - 2021-01-26 23:11 +0000
Re: USB card adapters crash Pi4 Richard Kettlewell <invalid@invalid.invalid> - 2021-01-25 18:55 +0000
Re: USB card adapters crash Pi4 Dennis <dennis@none.none> - 2021-01-25 15:21 -0600
Re: USB card adapters crash Pi4 The Natural Philosopher <tnp@invalid.invalid> - 2021-01-24 09:36 +0000
Re: USB card adapters crash Pi4 Martin Gregorie <martin@mydomain.invalid> - 2021-01-03 19:36 +0000
Re: USB card adapters crash Pi4 Joe <joe@jretrading.com> - 2021-01-03 21:16 +0000
Re: USB card adapters crash Pi4 Martin Gregorie <martin@mydomain.invalid> - 2021-01-03 22:40 +0000
Re: USB card adapters crash Pi4 Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2021-01-03 20:44 -0500
Re: USB card adapters crash Pi4 Martin Gregorie <martin@mydomain.invalid> - 2021-01-04 11:46 +0000
Re: USB card adapters crash Pi4 Joe <joe@jretrading.com> - 2021-01-04 09:38 +0000
Re: USB card adapters crash Pi4 Martin Gregorie <martin@mydomain.invalid> - 2021-01-04 12:03 +0000
Re: USB card adapters crash Pi4 Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2021-01-04 11:01 -0500
Re: USB card adapters crash Pi4 Martin Gregorie <martin@mydomain.invalid> - 2021-01-04 17:15 +0000
Re: USB card adapters crash Pi4 Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2021-01-04 14:03 -0500
Re: USB card adapters crash Pi4 Jan Panteltje <pNaOnStPeAlMtje@yahoo.com> - 2021-01-05 06:17 +0000
Re: USB card adapters crash Pi4 Deloptes <deloptes@gmail.com> - 2021-01-02 16:06 +0100
Re: USB card adapters crash Pi4 A. Dumas <alexandre@dumas.fr.invalid> - 2021-01-02 16:36 +0000
Re: USB card adapters crash Pi4 The Natural Philosopher <tnp@invalid.invalid> - 2021-01-02 16:38 +0000
Re: USB card adapters crash Pi4 Jan Panteltje <pNaOnStPeAlMtje@yahoo.com> - 2021-01-02 17:29 +0000
Re: USB card adapters crash Pi4 Jan Panteltje <pNaOnStPeAlMtje@yahoo.com> - 2021-01-02 17:18 +0000
Re: USB card adapters crash Pi4 David Higton <dave@davehigton.me.uk> - 2021-01-02 20:21 +0000
Re: USB card adapters crash Pi4 Theo <theom+news@chiark.greenend.org.uk> - 2021-01-03 10:07 +0000
Re: USB card adapters crash Pi4 Theo <theom+news@chiark.greenend.org.uk> - 2021-01-03 18:39 +0000
Re: USB card adapters crash Pi4 "Dave Liquorice" <allsortsnotthisbit@howhill.com> - 2021-01-02 13:08 +0000
Re: USB card adapters crash Pi4 Jan Panteltje <pNaOnStPeAlMtje@yahoo.com> - 2021-01-02 09:10 +0000
Re: USB card adapters crash Pi4 druck <news@druck.org.uk> - 2021-01-02 12:36 +0000
Re: USB card adapters crash Pi4 bob prohaska <bp@www.zefox.net> - 2021-01-02 20:45 +0000
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | Martin Gregorie <martin@mydomain.invalid> |
|---|---|
| Date | 2021-01-03 22:40 +0000 |
| Message-ID | <rsth51$6g6$2@dont-email.me> |
| In reply to | #25417 |
On Sun, 03 Jan 2021 21:16:36 +0000, Joe wrote: > On Sun, 3 Jan 2021 19:36:54 -0000 (UTC) > Martin Gregorie <martin@mydomain.invalid> wrote: > >> A fairly rapid web search failed to discover whether unsigned >> arithmetic is a feature of the BASIC > > There is no feature list of BASIC. > I know that all so-called BASICs differ, some radically from the original Dartmouth BASIC. I thought that the context would make it plain that I was talking about PICAXE BASIC, which differs enough from traditional BASICs to be given another name (labels not numbers for branch destinations and subroutines, long names for variables, named constants, unsigned arithmetic and comparisons, conditional statement inclusion). > No. All the arithmetic operators are signed, > Not according to the current PICAXE BASIC manual, which gives numeric ranges for 8 and 16 bit variables capable of containing byte values in the range 0-255 and explicitly says that byte values are unsigned. It alao says that 16 bit variable can hold 0-65535, which implies, though it doesn't state, that these are unsigned. See https://picaxe.com/docs/picaxe_manual2.pdf If this is a mistake, they get a down vote for not correcting their manual, despite having three years to have made the correction - I bought the PICAXE and downloaded to manual 2.5 years ago and then got distracted from that project, but the online manual's wording (section 2, page 13) remains the same - I just checked. BTW I'm using the PICAXE-14M because I need at least 3 PWM outputs. and, to put this on topic for the RPi group, am running the BASIC compiler/ uploader on a headless Pi 2B. This setup successfully uploads compiled code to the PICAXE and displays messages from it on the RPi's console. -- -- Martin | martin at Gregorie | gregorie dot org
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2021-01-03 20:44 -0500 |
| Message-ID | <ekr4vf1on2vmjc0iad238vb8o739geb826@4ax.com> |
| In reply to | #25419 |
On Sun, 3 Jan 2021 22:40:33 -0000 (UTC), Martin Gregorie <martin@mydomain.invalid> declaimed the following: >I know that all so-called BASICs differ, some radically from the original >Dartmouth BASIC. I thought that the context would make it plain that I >was talking about PICAXE BASIC, which differs enough from traditional >BASICs to be given another name (labels not numbers for branch >destinations and subroutines, long names for variables, named constants, >unsigned arithmetic and comparisons, conditional statement inclusion). > PICAXE BASIC and BASIC-Stamp BASICs were optimized for microcontrollers with GPIO. Unsigned arithmetic maps to an 8-bit GPIO control register quite well (especially for bit masking). The processor chips have most of their flash memory filled with a simplified BASIC byte-code interpreter -- one's application gets downloaded (as byte-code) to a small EEPROM (or worse -- a large RAM) and is treated as data by the interpreter. A BS2 has only 32-bytes of RAM, and 6 of those are dedicated to GPIO input, output, and direction control. That leaves just 13 16-bit variables or 26 8-bit variables. The BS2 does allow defining variables and bit, nybble, byte, or word -- and the compiler does its best to optimize the RAM allocation. The manual does imply that the BS2 supports signed 16-bit values -- but when outputting them (debug print) one needs to specify the SDEC formatter, otherwise one gets an unsigned representation. -- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@mydomain.invalid> |
|---|---|
| Date | 2021-01-04 11:46 +0000 |
| Message-ID | <rsuv7b$epp$2@dont-email.me> |
| In reply to | #25420 |
On Sun, 03 Jan 2021 20:44:03 -0500, Dennis Lee Bieber wrote: > On Sun, 3 Jan 2021 22:40:33 -0000 (UTC), Martin Gregorie > <martin@mydomain.invalid> declaimed the following: > >>I know that all so-called BASICs differ, some radically from the >>original Dartmouth BASIC. I thought that the context would make it plain >>that I was talking about PICAXE BASIC, which differs enough from >>traditional BASICs to be given another name (labels not numbers for >>branch destinations and subroutines, long names for variables, named >>constants, unsigned arithmetic and comparisons, conditional statement >>inclusion). >> >> > PICAXE BASIC and BASIC-Stamp BASICs were optimized for microcontrollers > with GPIO. Unsigned arithmetic maps to an 8-bit GPIO control register > quite well (especially for bit masking). The processor chips have most > of their flash memory filled with a simplified BASIC byte-code > interpreter -- one's application gets downloaded (as byte-code) to a > small EEPROM (or worse -- a large RAM) and is treated as data by the > interpreter. > > A BS2 has only 32-bytes of RAM, and 6 of those are dedicated to GPIO > input, output, and direction control. That leaves just 13 16-bit > variables or 26 8-bit variables. The BS2 does allow defining variables > and bit, nybble, byte, or word -- and the compiler does its best to > optimize the RAM allocation. The manual does imply that the BS2 supports > signed 16-bit values -- but when outputting them (debug print) one needs > to specify the SDEC formatter, otherwise one gets an unsigned > representation. Agreed - I've done rather more with BS2 STAMPS than I have with PICAXE - even had a flight timer for an F1A glider running on a breadboard. This read timer settings, which are all positive values, from a control box, but didn't need to output them. The logic did use signed values, though, to terminate count-down sequences. However, I barely got past noddy experiments to get familiarised with PICAXE BASIC before putting that project to one side, but its likely to be woken up again quite soon. So, I'm aware that the BS2 BASIC uses signed integer variables and consequently was quite surprised that PICAXE BASIC doesn't. -- -- Martin | martin at Gregorie | gregorie dot org
[toc] | [prev] | [next] | [standalone]
| From | Joe <joe@jretrading.com> |
|---|---|
| Date | 2021-01-04 09:38 +0000 |
| Message-ID | <20210104093819.0f4062cb@jresid.jretrading.com> |
| In reply to | #25419 |
On Sun, 3 Jan 2021 22:40:33 -0000 (UTC) Martin Gregorie <martin@mydomain.invalid> wrote: > On Sun, 03 Jan 2021 21:16:36 +0000, Joe wrote: > > > On Sun, 3 Jan 2021 19:36:54 -0000 (UTC) > > Martin Gregorie <martin@mydomain.invalid> wrote: > > > >> A fairly rapid web search failed to discover whether unsigned > >> arithmetic is a feature of the BASIC > > > > There is no feature list of BASIC. > > > I know that all so-called BASICs differ, some radically from the > original Dartmouth BASIC. I thought that the context would make it > plain that I was talking about PICAXE BASIC, which differs enough > from traditional BASICs to be given another name (labels not numbers > for branch destinations and subroutines, long names for variables, > named constants, unsigned arithmetic and comparisons, conditional > statement inclusion). > > > No. All the arithmetic operators are signed, > > > Not according to the current PICAXE BASIC manual, which gives numeric > ranges for 8 and 16 bit variables capable of containing byte values > in the range 0-255 and explicitly says that byte values are unsigned. > It alao says that 16 bit variable can hold 0-65535, which implies, > though it doesn't state, that these are unsigned. Sorry, misunderstanding. I thought you were asking if PICAXE couldn't do signed because the underlying PIC processor couldn't handle signed. -- Joe
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@mydomain.invalid> |
|---|---|
| Date | 2021-01-04 12:03 +0000 |
| Message-ID | <rsv06f$epp$3@dont-email.me> |
| In reply to | #25424 |
On Mon, 04 Jan 2021 09:38:19 +0000, Joe wrote: > On Sun, 3 Jan 2021 22:40:33 -0000 (UTC) > Martin Gregorie <martin@mydomain.invalid> wrote: > >> On Sun, 03 Jan 2021 21:16:36 +0000, Joe wrote: >> >> > On Sun, 3 Jan 2021 19:36:54 -0000 (UTC) >> > Martin Gregorie <martin@mydomain.invalid> wrote: >> > >> >> A fairly rapid web search failed to discover whether unsigned >> >> arithmetic is a feature of the BASIC >> > >> > There is no feature list of BASIC. >> > >> I know that all so-called BASICs differ, some radically from the >> original Dartmouth BASIC. I thought that the context would make it >> plain that I was talking about PICAXE BASIC, which differs enough from >> traditional BASICs to be given another name (labels not numbers for >> branch destinations and subroutines, long names for variables, named >> constants, unsigned arithmetic and comparisons, conditional statement >> inclusion). >> >> > No. All the arithmetic operators are signed, >> > >> Not according to the current PICAXE BASIC manual, which gives numeric >> ranges for 8 and 16 bit variables capable of containing byte values in >> the range 0-255 and explicitly says that byte values are unsigned. >> It alao says that 16 bit variable can hold 0-65535, which implies, >> though it doesn't state, that these are unsigned. > > Sorry, misunderstanding. I thought you were asking if PICAXE couldn't do > signed because the underlying PIC processor couldn't handle signed. No problem. At least this made me look at the PIC architecture and discover that it doesn't handle signed integers - I think its the only system I've know of at that doesn't, so I didn't realise at first that this limitation is in the hardware rather than a feature of the BASIC compiler. -- -- Martin | martin at Gregorie | gregorie dot org
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2021-01-04 11:01 -0500 |
| Message-ID | <4rc6vftnqp4eukkse2015fm21jueu8r97h@4ax.com> |
| In reply to | #25429 |
On Mon, 4 Jan 2021 12:03:27 -0000 (UTC), Martin Gregorie <martin@mydomain.invalid> declaimed the following: >No problem. At least this made me look at the PIC architecture and >discover that it doesn't handle signed integers - I think its the only >system I've know of at that doesn't, so I didn't realise at first that >this limitation is in the hardware rather than a feature of the BASIC >compiler. The base BS2 uses a PIC16C57c (the BS2e, sx, p24/p40, pe, and px all used variants of Ubicom chips -- given the lack of information online, I suspect they were custom designed for Parallax alone -- ha! "The SX line of microprocessors are produced by Ubicom, Parallax is the only authorized distributor of the chips.") From the manual """ All BS2 models can interpret twos complement negative numbers correctly in DEBUG and SEROUT instructions using formatters like SDEC (for signed decimal). In calculations, however, it assumes that all values are positive. This yields correct results with two’s complement negative numbers for addition, subtraction, and multiplication, but not for division """ Hmmm, Parallax finally released a Propeller 2 chip. https://www.parallax.com/propeller-multicore-concept/ and appear to have discontinued all BASIC Stamps (not a surprise -- last time I checked a BS2p was around $70 while a Propeller Quickstart is only $40. Propellers are interesting chips... 8 simple cores running in lockstep; each core has some internal RAM for programs (so it can be different code in each core) written in assembler. The default mode is that the core is loaded with a byte-code interpreter, and SPIN programs are read from external memory. The P1 allowed one core at a time to access external memory (in sequence); the new P2 apparently allows all 8 cores to do memory I/O on each cycle. -- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@mydomain.invalid> |
|---|---|
| Date | 2021-01-04 17:15 +0000 |
| Message-ID | <rsvig0$epp$8@dont-email.me> |
| In reply to | #25435 |
On Mon, 04 Jan 2021 11:01:53 -0500, Dennis Lee Bieber wrote: > Propellers are interesting chips... 8 simple cores running in lockstep; > each core has some internal RAM for programs (so it can be different > code in each core) written in assembler. The default mode is that the > core is loaded with a byte-code interpreter, and SPIN programs are read > from external memory. The P1 allowed one core at a time to access > external memory (in sequence); the new P2 apparently allows all 8 cores > to do memory I/O on each cycle. They sound interesting. I heard of them soon after they were released, but you've just increased my knowledge about them by about 500%. Out of pure curiosity: have you any idea how much work it would be to convert a fully debugged BS2 BASIC program into a running SPIN program? -- -- Martin | martin at Gregorie | gregorie dot org
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2021-01-04 14:03 -0500 |
| Message-ID | <02o6vf5rke2l2seqn49iehasqblkenvhv7@4ax.com> |
| In reply to | #25438 |
On Mon, 4 Jan 2021 17:15:45 -0000 (UTC), Martin Gregorie
<martin@mydomain.invalid> declaimed the following:
>
>Out of pure curiosity: have you any idea how much work it would be to
>convert a fully debugged BS2 BASIC program into a running SPIN program?
Probably a lot. One concept with the Propeller is that one assigns
cores to do what would have been an interrupt in other chips (instead of
having an interrupt, that core is in a polling loop). Also using cores for
dedicated I/O protocols. The GPIOs are shared by all cogs.
Manual for the P1 is at
https://www.parallax.com/package/propeller-manual/ Besides SPIN and
Propeller ASM, there is a third-party "SimpleIDE" which provides "Propeller
C" (https://www.parallax.com/downloads/propeller-c-software/)
An old demo program:
-=-=-
{{
Welcome.spin
Welcome to the OpenSource PropellerIDE.
To run this program:
* Make sure the FTDI Chip USB driver is installed.
* Connect the USB Propeller board.
* Debug (F8)
The program should pause a moment, print Hello, and
then toggle Propeller IO P27 repeatedly.
}}
CON
_clkmode = XTAL1 + PLL16X
_clkfreq = 80_000_000
OBJ
ser : "Parallax Serial Terminal"
PUB start
ser.start(115200)
waitcnt(CLKFREQ/2+CNT) '' Wait for start up
ser.str(string($d,"Hello.",$d))
blink
''
'' Blink ActivityBoard LED
''
PUB blink '' The start method
DIRA[27] |= 1 '' Set P27 to output
repeat '' Repeat forever
OUTA[27] ^= 1 '' Toggle LED pin
waitcnt(CLKFREQ/2+CNT) '' Wait
-=-=-
And the source code for the main file from DefCon22 badge (the badge uses
all cogs, one file per cog)
-=-=-
''
=================================================================================================
''
'' File....... dc22_badge_master.spin
'' -- for internal use only!
'' -- no changes unless approved/reviewed by JonnyMac/Ryan
''
'' Authors.... Jon "JonnyMac" McPhalen and Ryan "1o57" Clarke
'' MIT License
'' -- see below for terms of use
''
'' E-mail..... jon@jonmcphalen.com
'' 1o57@10000100001.org
''
'' Modified for Propeller Quickstart Board (touch pads and LEDs) with
Human Interface
'' Device board (I/R emitter/receiver, LEDs). Also modified to read
pads to set "Goon"
'' mode on start-up
'' Dennis L Bieber
''
''
=================================================================================================
{{
Welcome to Defcon 22. This year we would like to invite you to experiment
more fully with your
badge -- feel free to play around with code.
You can load directly to RAM [F10] if you don't want to blast your
firmware, but even if you do,
we are giving you the source from the start. The source provides a nice
badge template with extra
objects so that you can experiment with LEDs, buttons, IR (in and out),
timing, speed changes, etc.
Completing the challenge will at some point require you to 'update' your
badge -- but for now, how
about changing your LED pattern? It's easier than you think! If you need
help, feel free to stop
by the Hardware Hacking Village, or simply ask someone who has a
different pattern than yours.
Create a new pattern -- have fun!
}}
con { timing }
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000 ' use 5MHz
crystal
CLK_FREQ = ((_clkmode - xtal1) >> 6) * _xinfreq ' system
freq as a constant
MS_001 = CLK_FREQ / 1_000 ' ticks in
1ms
US_001 = CLK_FREQ / 1_000_000 ' ticks in
1us
' speed settings for power control/reduction
' -- use with clkset() instruction
XT1_P16 = %0_1_1_01_111 ' 16x
crystal (5MHz) = 80MHz
XT1_PL8 = %0_1_1_01_110
XT1_PL4 = %0_1_1_01_101
XT1_PL2 = %0_1_1_01_100
XT1_PL1 = %0_1_1_01_011
RC_SLOW = %0_0_0_00_001 ' 20kHz
' program speed and terminal baud
B_SPEED = 20 { MHz }
T_BAUD = 57_600 { for terminal io }
IR_FREQ = 36_000 { matches receiver on DC22 badge }
IR_BAUD = 2400 { max supported using IR connection }
IR_BLAST = $DC22
'con
'
#0, HUMAN, ARTIST, PRESS, SPEAKER, VENDOR, CONTEST, GOON, UBER, LO57
'
' BADGE_TYPE = HUMAN
con { io pins }
RX1 = 31 '
programming / terminal
TX1 = 30
SDA = 29 ' eeprom /
i2c
SCL = 28
PAD3 = 4 '27 ' touch
pads
PAD2 = 5 '26 ' HID SD
slot uses 0-3, sems to conflict
PAD1 = 6 '25
PAD0 = 7 '24
LED7 = 23 ' leds
LED6 = 22
LED5 = 21
LED4 = 20
LED3 = 19
LED2 = 18
LED1 = 17
LED0 = 16
IR_IN = 9 '15 ' ir
input
IR_OUT = 8 '14 ' ir
output
con { io configuration }
IS_OFF = 0 ' all bits
off
IS_ON = -1 ' all bits
on
IS_LOW = 0
IS_HIGH = -1
IS_INPUT = 0
IS_OUTPUT = -1
con { pst formatting }
#1, HOME, GOTOXY, #8, BKSP, TAB, LF, CLREOL, CLRDN, CR
#14, GOTOX, GOTOY, CLS
obj
term : "cryptofullduplexserial64" ' serial io
for terminal
irtx : "jm_sircs_tx" ' SIRCS
output
irrx : "jm_sircs_rx" ' SIRCS
input
prng : "jm_prng" ' random #s
tmr1 : "jm_eztimer" '
asynchronous timer
ee : "jm_24xx512" ' eeprom
access
pwm : "jm_pwm8" ' pwm for
LEDs
btn : "touch buttons" ' QuickStart buttons are
more sensitive?
var
long ms001 ' system
ticks per millisecond
long us001 ' system
ticks per microsecond
byte BADGE_TYPE 'TBD --
change type on boot
pub main | idx, last, button
setup ' setup
badge io and objects
term.tx(CLS) ' clear the
terminal
if (BADGE_TYPE => GOON) ' check
badge type
alien_badge
' non-Goon badge code here
repeat until (read_pads <> %0000) ' wait for
a pad press
idx := (prng.random >> 1) // 13
repeat (idx << 1)
term.tx(" ")
idx := (prng.random >> 1) // 13
term.caesar(@@Commands[idx])
if (check_ir)
quit
pause(250)
term.tx(CLS)
term.caesar(@Greets)
term.tx(CR)
term.otp(@Test3, @Test4)
term.tx(CR)
last := -1 ' any
button to start
repeat
repeat
check_ir ' check ir
process
button := read_pads ' wait for
input
until ((button <> %0000) and (button <> last)) ' must be
new
last := button ' save for
next check
case button
%0001:
start_animation(@Cylon, 0) ' start
animation
term.caesar(@Detective) ' display
crypto string
pause(250) ' allow
clean button release
%0101:
start_animation(@Chaser, 0)
term.otp(@Scientist, @Driver)
pause(250)
%0111:
start_animation(@Police, 0)
term.caesar(@Diver)
pause(250)
%1000:
start_animation(@InOut, 0)
term.otp(@Politician, @Football)
pause(250)
%1001:
stop_animation
term.otp(@RayNelson, @Mystery)
pause(250)
pub check_ir | code
code := irrx.rxcheck ' check ir
input
if (code < 0) ' abort if
waiting
return
if (code == IR_BLAST)
start_animation(@Blasted, 3) term.caesar(string($0A, "DROI VSFO GO
CVOOZ", CR)) ' THEY LIVE WE SLEEP
repeat while (anicog) ' let
animation finish
irrx.enable
if (code == IR_BLAST)
return TRUE
pub alien_badge | btns, delay
'' Badge code for >= Goon
delay := -1 ' force
immediate broadcast
repeat
btns := read_pads
if ((read_pads) or (tmr1.seconds => delay)) ' pad input
or delay expired?
irtx.tx(IR_BLAST, 16, 3) ' blast the
humans!
'term.caesar(string($0C, "IQ XUHQ FTQK EXQQB", CR)) ' WE LIVE
THEY SLEEP
start_animation(@Blasted, 3) ' play
blaster animation
tmr1.start ' restart
timer
delay := ||(prng.random) // 11 + 10 ' new delay
pub setup
'' Setup badge IO and objects
'' -- set speed before starting other objects
set_speed(B_SPEED) ' set badge
speed (MHz)
set_leds(%00000000) ' LEDs off
term.start(RX1, TX1, %0000, T_BAUD) ' start
terminal
prng.seed(cnt << 2, cnt, $1057, -cnt, cnt ~> 2) ' seed prng
(random #s)
btn.Start(CLK_FREQ / 100) ' start button
reading process
BADGE_TYPE := HUMAN 'read_pads ' somehow need to
set up on pads
if (BADGE_TYPE < GOON)
irrx.start(IR_IN) ' start ir
input
irrx.enable ' accept ir
input now
else
irtx.start(IR_OUT, IR_FREQ) ' start ir
output
tmr1.start ' start
timer
con
{ ----------------------------- }
{ B A D G E F E A T U R E S }
{ ----------------------------- }
pub set_speed(mhz)
'' Sets badge clock speed
'' -- sets timing variables ms001 and us001
'' -- note: objects may require restart after speed change
case mhz
0: clkset(RC_SLOW, 20_000) ' super low
power -- sleep mode only!
5: clkset(XT1_PL1, 5_000_000)
10: clkset(XT1_PL2, 10_000_000)
20: clkset(XT1_PL4, 20_000_000)
40: clkset(XT1_PL8, 40_000_000)
80: clkset(XT1_P16, 80_000_000)
waitcnt(cnt + (clkfreq / 100)) ' wait
~10ms
ms001 := clkfreq / 1_000 ' set ticks
per millisecond for waitcnt
us001 := clkfreq / 1_000_000 ' set ticks
per microsecond for waitcnt
pub set_leds(pattern)
'' Sets LED pins to output and writes pattern to them
'' -- swaps LSB/MSB for correct binary output
outa[LED0..LED7] := pattern ' write
pattern to LEDs
dira[LED0..LED7] := IS_HIGH ' make LED
pins outputs
pub read_pads | btns, lwr, upr, wid
lwr := PAD3 <# PAD0 'determine lowest
pad in set
upr := PAD3 #> PAD0 'determine highest
pad in set
wid := upr - lwr + 1 'determine width of
used pads
btns := btn.state >> lwr ' shift buttons by lower of
PAD specification
btns := btns & !($FFFF << wid) ' generate bitmask for only
the desired set
return btns
' outa[PAD0..PAD3] := IS_HIGH ' charge
pads (all output high)
' dira[PAD0..PAD3] := IS_OUTPUT
' dira[PAD0..PAD3] := IS_INPUT ' float
pads
' pause(50) ' -- allow
touch to discharge
' return (!ina[PAD0..PAD3] & $0F)' >< 4 ' return
"1" for touched pads
con
{ --------------- }
{ L E D F U N }
{ --------------- }
var
long anicog ' cog
running animation
long anistack[32] ' stack
space for Spin cog
pri start_animation(p_table, cycles)
'' Start animation in background cog
'' -- allows LED animation while doing other processes
'' -- p_table is pointer (address of) animation table
'' -- set cycles to 0 to run without stopping
stop_animation
anicog := cognew(run_animation(p_table, cycles), @anistack) + 1
return anicog ' return
cog used
pri stop_animation
'' Stop animation if currently running
if (anicog) ' if
running
cogstop(anicog - 1) ' stop the
cog
anicog := 0 ' mark
stopped
pri run_animation(p_table, cycles) | p_leds
'' Run animation
'' -- p_table is pointer (address of) animation table
'' -- cycles is number of iterations to run
'' * 0 cycles runs "forever"
'' -- usually called with start_animation()
if (cycles =< 0)
cycles := POSX ' run
"forever"
repeat cycles
p_leds := p_table ' point to
table
repeat byte[p_leds++] ' repeat
for steps in table
set_leds(byte[p_leds++]) ' update
leds
pause(byte[p_leds++]) ' hold
anicog := 0 ' mark
stopped
cogstop(cogid) ' stop this
cog
dat
' Animation tables for LEDs
' -- 1st byte is number of steps in animation sequence
' -- each step holds pattern and hold time (ms)
' -- for delays > 255, duplicate pattern + delay
Cylon byte (@Cylon_X - @Cylon) / 2 + 1
byte %10000000, 125
byte %01000000, 125
byte %00100000, 125
byte %00010000, 125
byte %00001000, 125
byte %00000100, 125
byte %00000010, 125
byte %00000001, 125
byte %00000010, 125
byte %00000100, 125
byte %00001000, 125
byte %00010000, 125
byte %00100000, 125
Cylon_X byte %01000000, 125
Chaser byte (@Chaser_X - @Chaser) / 2 + 1
byte %10010010, 75
byte %00100100, 75
Chaser_X byte %01001001, 75
InOut byte (@InOut_X - @InOut) / 2 + 1
byte %10000001, 100
byte %01000010, 100
byte %00100100, 100
byte %00011000, 100
byte %00100100, 100
InOut_X byte %01000010, 100
Police byte (@Police_X - @Police) / 2 + 1
byte %11001100, 75
byte %11110000, 75
byte %11001100, 75
byte %11110000, 75
byte %00001111, 75
byte %00110011, 75
byte %00001111, 75
Police_X byte %00110011, 75
Blasted byte (@Blasted_X - @Blasted) / 2 + 1
byte %00000000, 50
byte %00011000, 50
byte %00111100, 50
byte %01111110, 50
byte %11111111, 50
byte %00000000, 50
byte %00011000, 50
byte %00111100, 50
byte %01111110, 50
byte %11111111, 50
byte %00000000, 50
byte %00011000, 50
byte %00111100, 50
byte %01111110, 50
byte %11111111, 50
byte %00000000, 50
byte %11111111, 50
byte %00000000, 50
byte %11111111, 50
byte %00000000, 50
byte %11111111, 50
byte %00000000, 50
byte %11111111, 50
byte %00000000, 50
byte %11111111, 50
Blasted_X byte %00000000, 50
con
{ ------------- }
{ B A S I C S }
{ ------------- }
pub pause(ms) | t
'' Delay program in milliseconds
'' -- ensure set_speed() used before calling
t := cnt ' sync to
system counter
repeat (ms #>= 0) ' delay > 0
waitcnt(t += ms001) ' hold 1ms
pub high(pin)
'' Makes pin output and high
outa[pin] := IS_HIGH
dira[pin] := IS_OUTPUT
pub low(pin)
'' Makes pin output and low
outa[pin] := IS_LOW
dira[pin] := IS_OUTPUT
pub toggle(pin)
'' Toggles pin state
!outa[pin]
dira[pin] := IS_OUTPUT
pub input(pin)
'' Makes pin input and returns current state
dira[pin] := IS_INPUT
return ina[pin]
pub pulse_out(pin, us) | state
'' Generate pulse on pin for us microseconds
'' -- ensure set_speed() used before calling
'' -- makes pin output
'' -- pulse out is opposite of pin's input state
'' -- blocks until pulse is finished (to clear counter)
us *= us001 ' convert
us to system ticks
state := ina[pin] ' read
incoming state of pin
if (ctra == 0) ' ctra
available?
if (state == 0) '
low-high-low
low(pin) ' set to
output
frqa := 1
phsa := -us ' set
timing
ctra := (%00100 << 26) | pin ' start the
pulse
repeat
until (phsa => 0) ' let pulse
finish
else '
high-low-high
high(pin)
frqa := -1
phsa := us
ctra := (%00100 << 26) | pin
repeat
until (phsa < 0)
ctra := IS_OFF ' release
counter
return true
elseif (ctrb == 0)
if (state == 0)
low(pin)
frqb := 1
phsb := -us
ctrb := (%00100 << 26) | pin
repeat
until (phsb => 0)
else
high(pin)
frqb := -1
phsb := us
ctrb := (%00100 << 26) | pin
repeat
until (phsb < 0)
ctrb := IS_OFF
return true
else
return false ' alert
user of error
pub set_freq(ctrx, px, fx)
'' Sets ctrx to frequency fx on pin px (NCO/SE mode)
'' -- fx in hz
'' -- use fx of 0 to stop counter that is running
if (fx > 0)
fx := ($8000_0000 / (clkfreq / fx)) << 1 ' convert
freq for NCO mode
case ctrx
"a", "A":
ctra := ((%00100) << 26) | px ' configure
ctra for NCO on pin
frqa := fx ' set
frequency
dira[px] := IS_OUTPUT
"b", "B":
ctrb := ((%00100) << 26) | px
frqb := fx
dira[px] := IS_OUTPUT
else
case ctrx
"a", "A":
ctra := IS_OFF ' disable
counter
outa[px] := IS_OFF ' clear
pin/driver
dira[px] := IS_INPUT
"b", "B":
ctrb := IS_OFF
outa[px] := IS_OFF
dira[px] := IS_INPUT
dat
RayNelson byte "IAIHG TPJNU QU CZR GALWXK DC MHR LANK FOTLA OTN
LOYOC HPMPB PX HKICW",0
Test4 byte "DID YOU REALLY THINK THAT IT WOULD BE SO EASY?
Really? Just running strings?",0
Greets byte
16,77,85,66,83,69,67,85,32,74,69,32,84,85,86,83,69,68,32,74,77,85,68,74,79,32,74,77,69,13,0
Detective byte
13,74,85,82,69,82,32,71,66,32,79,82,84,86,65,32,86,32,88,65,66,74,32,83,86,65,81,32,85,78,69,66,89,81,13,0
Scientist byte
76,81,84,89,86,70,32,82,75,66,32,83,78,90,32,83,81,87,83,85,32,87,82,65,32,73,77,82,66,32,67,70,72,82,32,90,65,65,65,65,32,73,89,77,87,90,32,80,32,69,65,74,81,86,68,32,89,79,84,80,32,76,71,65,87,32,89,75,90,76,13,0
Diver byte 10,"DBI DRO PSBCD RKVP YP RSC ZRYXO XEWLOB PYVVYGON
LI RSC VKCD XKWO DROX DRO COMYXN RKVP YP RSC XEWLOB",CR,0
Driver byte "SOMETIMES WE HAVE ANSWERS AND DONT EVEN KNOW IT SO
ENJOY THE VIEW JUST BE HAPPY",0
Politician byte
83,83,80,87,76,77,32,84,72,67,65,80,32,81,80,32,74,84,32,73,87,69,32,87,68,88,70,90,32,89,85,90,88,32,85,77,86,72,88,72,32,90,65,32,67,66,32,80,65,69,32,88,82,79,76,32,70,65,89,32,73,80,89,75,13,0
Test3 byte "ZGJG MTM LLPN C NTER MPMH TW",CR,0
Football byte "IT MIGHT BE HELPFUL LATER IF YOU KNOW HOW TO GET
TO EDEN OR AT LEAST THE WAY",0
Mystery byte "OH A MYSTERY STRING I SHOULD HANG ON TO THIS FOR
LATER I WONDER WHAT ITS FOR OR WHAT IT DECODES TO?",0
dat
Cmd00 byte $05, $42, $54, $57, $50, $20, $4A, $4E, $4C, $4D,
$59, $20, $4D, $54
byte $5A, $57, $58, $0D, $00, $4C, $4F, $56, $45, $00
Cmd01 byte $04, $41, $45, $58, $47, $4C, $20, $58, $5A, $0D,
$00
Cmd02 byte $0E, $47, $49, $50, $41, $57, $48, $0D, $00, $4C,
$49, $46, $45, $00
Cmd03 byte $0C, $45, $46, $4D, $4B, $20, $4D, $45, $58, $51,
$51, $42, $0D, $00
Cmd04 byte $04, $53, $46, $49, $43, $0D, $00, $47, $69, $47,
$21, $00
Cmd05 byte $14, $48, $49, $20, $43, $48, $58, $59, $4A, $59,
$48, $58, $59, $48
byte $4E, $20, $4E, $42, $49, $4F, $41, $42, $4E, $0D,
$00
Cmd06 byte $02, $50, $51, $20, $4B, $4F, $43, $49, $4B, $50,
$43, $56, $4B, $51
byte $50, $0D, $00, $4A, $6F, $6E, $6E, $79, $4D, $61,
$63, $00
Cmd07 byte $0C, $59, $4D, $44, $44, $4B, $20, $4D, $5A, $50,
$20, $44, $51, $42
byte $44, $41, $50, $47, $4F, $51, $0D, $00, $48, $41,
$50, $50, $59, $00
Cmd08 byte $05, $4A, $46, $59, $0D, $00, $48, $45, $41, $4C,
$54, $48, $00
Cmd09 byte $09, $4D, $58, $20, $57, $58, $43, $20, $5A, $44,
$4E, $42, $43, $52
byte $58, $57, $20, $4A, $44, $43, $51, $58, $41, $52,
$43, $48, $0D, $00
Cmd10 byte $0F, $52, $44, $43, $48, $4A, $42, $54, $0D, $00
Cmd11 byte $02, $45, $51, $50, $48, $51, $54, $4F, $0D, $00
Cmd12 byte $19, $41, $54, $58, $0D, $00, $57, $45, $41, $4C,
$54, $48, $00
byte $31, $6F, $35, $37, $00
Commands word @Cmd00, @Cmd01, @Cmd02, @Cmd03, @Cmd04, @Cmd05
word @Cmd06, @Cmd07, @Cmd08, @Cmd09, @Cmd10, @Cmd11
word @Cmd12
dat
{{
Terms of Use: MIT License
Permission is hereby granted, free of charge, to any person obtaining a
copy of this
software and associated documentation files (the "Software"), to deal in
the Software
without restriction, including without limitation the rights to use,
copy, modify,
merge, publish, distribute, sublicense, and/or sell copies of the
Software, and to
permit persons to whom the Software is furnished to do so, subject to the
following
conditions:
The above copyright notice and this permission notice shall be included
in all copies
or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR IMPLIED,
INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
FOR A
PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
COPYRIGHT
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
AN ACTION OF
CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH
THE SOFTWARE
OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
}}
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
[toc] | [prev] | [next] | [standalone]
| From | Jan Panteltje <pNaOnStPeAlMtje@yahoo.com> |
|---|---|
| Date | 2021-01-05 06:17 +0000 |
| Message-ID | <rt10cp$18bm$1@gioia.aioe.org> |
| In reply to | #25442 |
On a sunny day (Mon, 04 Jan 2021 14:03:31 -0500) it happened Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote in <02o6vf5rke2l2seqn49iehasqblkenvhv7@4ax.com>: >On Mon, 4 Jan 2021 17:15:45 -0000 (UTC), Martin Gregorie ><martin@mydomain.invalid> declaimed the following: > > >> >>Out of pure curiosity: have you any idea how much work it would be to >>convert a fully debugged BS2 BASIC program into a running SPIN program? > > Probably a lot. One concept with the Propeller is that one assigns >cores to do what would have been an interrupt in other chips (instead of >having an interrupt, that core is in a polling loop). Also using cores for >dedicated I/O protocols. The GPIOs are shared by all cogs. >.... If I read this it makes me wonder why not go FPGA, learn Verilog for example. Then you can basically create your own processor, cores, and it is widely used and proven technology, also with a wide experimental open source user base: https://opencores.org/projects make your own processor, elect one!: https://opencores.org/projects?expanded=Processor FPGA boards are cheap on ebay these days. It also enhances your value on the IT market. It helps to have hardware design experience. IIRC there also is an FPGA HAT for Raspberry. Design your own processor, with your own instruction set... Sky is the limit, as is speed it seems.
[toc] | [prev] | [next] | [standalone]
| From | Deloptes <deloptes@gmail.com> |
|---|---|
| Date | 2021-01-02 16:06 +0100 |
| Message-ID | <rsq266$8jh$1@dont-email.me> |
| In reply to | #25392 |
Jan Panteltje wrote: > It is a useful universal thing that you can use for anything like for > example measuring stuff in your car or whatever, without disconnecting or > cutting wires etc. I would not buy something specialized for just USB. USB-C and a device using such connector is not like a car electronics (I know the topic here is power supply) and besides you can not measure A or mAs without breaking the circuit. If I am wrong let me know. In case of data flow you need an oscilloscope as suggested by Martin Gregorie.
[toc] | [prev] | [next] | [standalone]
| From | A. Dumas <alexandre@dumas.fr.invalid> |
|---|---|
| Date | 2021-01-02 16:36 +0000 |
| Message-ID | <5ff0a11c$0$299$e4fe514c@news.xs4all.nl> |
| In reply to | #25394 |
Deloptes <deloptes@gmail.com> wrote: > you can not measure A or > mAs without breaking the circuit. If I am wrong let me know. Hall-effect ring. (But how would you get the wire through the loop without disconnecting it..? Ok you got me.)
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2021-01-02 16:38 +0000 |
| Message-ID | <rsq7hp$hmp$1@dont-email.me> |
| In reply to | #25395 |
On 02/01/2021 16:36, A. Dumas wrote: > Deloptes <deloptes@gmail.com> wrote: >> you can not measure A or >> mAs without breaking the circuit. If I am wrong let me know. > > Hall-effect ring. (But how would you get the wire through the loop without > disconnecting it..? Ok you got me.) > clamp on meters -- If you tell a lie big enough and keep repeating it, people will eventually come to believe it. The lie can be maintained only for such time as the State can shield the people from the political, economic and/or military consequences of the lie. It thus becomes vitally important for the State to use all of its powers to repress dissent, for the truth is the mortal enemy of the lie, and thus by extension, the truth is the greatest enemy of the State. Joseph Goebbels
[toc] | [prev] | [next] | [standalone]
| From | Jan Panteltje <pNaOnStPeAlMtje@yahoo.com> |
|---|---|
| Date | 2021-01-02 17:29 +0000 |
| Message-ID | <rsqaip$10sh$1@gioia.aioe.org> |
| In reply to | #25395 |
On a sunny day (02 Jan 2021 16:36:44 GMT) it happened A. Dumas <alexandre@dumas.fr.invalid> wrote in <5ff0a11c$0$299$e4fe514c@news.xs4all.nl>: >Deloptes <deloptes@gmail.com> wrote: >> you can not measure A or >> mAs without breaking the circuit. If I am wrong let me know. > >Hall-effect ring. (But how would you get the wire through the loop without >disconnecting it..? Ok you got me.) It is 2 halves that can open FYI ;-)
[toc] | [prev] | [next] | [standalone]
| From | Jan Panteltje <pNaOnStPeAlMtje@yahoo.com> |
|---|---|
| Date | 2021-01-02 17:18 +0000 |
| Message-ID | <rsq9vr$nr8$1@gioia.aioe.org> |
| In reply to | #25394 |
On a sunny day (Sat, 02 Jan 2021 16:06:45 +0100) it happened Deloptes <deloptes@gmail.com> wrote in <rsq266$8jh$1@dont-email.me>: >Jan Panteltje wrote: > >> It is a useful universal thing that you can use for anything like for >> example measuring stuff in your car or whatever, without disconnecting or >> cutting wires etc. I would not buy something specialized for just USB. > >USB-C and a device using such connector is not like a car electronics (I >know the topic here is power supply) and besides you can not measure A or >mAs without breaking the circuit. If I am wrong let me know. No, that clamp on meter measures to a few mA, without breaking any connections. Use the zero button before you measure. >In case of data flow you need an oscilloscope as suggested by Martin >Gregorie. That is an other thing, I have a scope, never used it for USB data flow there are plenty of utiities to check that. >
[toc] | [prev] | [next] | [standalone]
| From | David Higton <dave@davehigton.me.uk> |
|---|---|
| Date | 2021-01-02 20:21 +0000 |
| Message-ID | <4cf3ace858.DaveMeUK@BeagleBoard-xM> |
| In reply to | #25397 |
In message <rsq9vr$nr8$1@gioia.aioe.org>
Jan Panteltje <pNaOnStPeAlMtje@yahoo.com> wrote:
> That is an other thing, I have a scope, never used it for USB data flow
I bought a Picoscope about a year ago. It decodes various serial
data streams on screen. I used it to decode OpenTherm (Manchester
code).
David
[toc] | [prev] | [next] | [standalone]
| From | Theo <theom+news@chiark.greenend.org.uk> |
|---|---|
| Date | 2021-01-03 10:07 +0000 |
| Message-ID | <Zjr*Cxg-x@news.chiark.greenend.org.uk> |
| In reply to | #25390 |
Martin Gregorie <martin@mydomain.invalid> wrote: > Belated thought: I wonder how many of these nice toys, many of which > which seem to have just one short production run, are actually final year > projects for electronic design graduates at Chinese technical > universities. Seems unlikely. There's a whole 'shanzhai' ecosystem of product development in Shenzhen, churning out rapid iterations of products all riffing off/stealing from each other: https://www.wired.co.uk/article/shanzai https://www.theatlantic.com/technology/archive/2014/05/chinas-mass-production-system/370898/ (separately, the fact that this listing is out of stock is just an Amazon artifact. You can likely find the same product elsewhere under a different brand. Amazon encourages sellers to have multiple bogus brands, but you'll probably find it unbranded on ebay and Aliexpress too) Theo
[toc] | [prev] | [next] | [standalone]
| From | Theo <theom+news@chiark.greenend.org.uk> |
|---|---|
| Date | 2021-01-03 18:39 +0000 |
| Message-ID | <Zjr*rpi-x@news.chiark.greenend.org.uk> |
| In reply to | #25409 |
Theo <theom+news@chiark.greenend.org.uk> wrote: > (separately, the fact that this listing is out of stock is just an Amazon > artifact. You can likely find the same product elsewhere under a different > brand. Amazon encourages sellers to have multiple bogus brands, but you'll > probably find it unbranded on ebay and Aliexpress too) Dozens of them: https://www.aliexpress.com/wholesale?catId=0&origin=y&SearchText=KCX-017 Theo
[toc] | [prev] | [next] | [standalone]
| From | "Dave Liquorice" <allsortsnotthisbit@howhill.com> |
|---|---|
| Date | 2021-01-02 13:08 +0000 |
| Message-ID | <nyyfbegfubjuvyypbz.qmbjpk2.pminews@news.individual.net> |
| In reply to | #25388 |
On Sat, 2 Jan 2021 12:34:29 -0000 (UTC), Martin Gregorie wrote: >> Or get one of the in line USB voltage and current meters. > > That makes sense - I didn't know these are available, but should have > guessed. The only disadvantage would seem to be that you'll end up with > a collection on different adapter cables since almost all of them seem > to have just USB-C connections. > > > I've a KEX KCX-017 > > > Like so many Chinese things, Amazon currently has that one marked as > 'unavailable', don't know when we'll have more. A very quick look appears that there are plenty eBay. From <£3 delivered from China/HK in a few weeks or >£6 delivered in around a week (probably quicker) from UK sellers. That unit is quite old and wouldn't be any good for the higher voltage/current that USB-C can support (up to 20 V @ 5 A?). There appears to be more recent units that can cope with that though. > Dunno why their manufacturers persist in doing that: in makes them look > like fly-by-night chancers, but maybe that's exactly what they are. I get the impression that once anything is listed on Amazon it stays there forever. -- Cheers Dave.
[toc] | [prev] | [next] | [standalone]
| From | Jan Panteltje <pNaOnStPeAlMtje@yahoo.com> |
|---|---|
| Date | 2021-01-02 09:10 +0000 |
| Message-ID | <rspdb9$24l$1@gioia.aioe.org> |
| In reply to | #25372 |
On a sunny day (Fri, 1 Jan 2021 20:53:25 -0000 (UTC)) it happened bob prohaska <bp@www.zefox.net> wrote in <rso244$fck$1@dont-email.me>: >Just tried using a couple of USB card adapters with my 8GB Pi4. >Both cause immediate loss of USB hard disk access. Unplugging >the offending adapter does not restore normal operation. Power >cycling puts matters right without apparent ill effect. > >Doesn't seem to matter if there's a card in the adapter or not. > >The USB3-Sata adapter is a Sabrent EC-UASP. It uses the UAS >driver and hasn't caused any obvious problems on its own. > >Anybody seen this, or have any idea what's going on? The card >adapters are fairly generic. Both are USB3, both have been used >before, but only in USB2 ports on Pi3's. One is no-name large- >and micro-SD only, the other is a UGreen card reader supporting TF, >SD, CF and MS cards. The slot labeled TF is the one I used with >microSD cards, didn't notice the "TF" marking till just now. > >Thanks for reading! > >bob prohaska I only have an old Sweex USB2 card adaptor, connecting it to my new Pi4 via USB via a Sitecom powered hub keeps /dev/sda2 3.4 TB Toshiba drive running normally: from dmesg: [163901.835425] usb 1-1.2.2: new high-speed USB device number 7 using xhci_hcd [163901.967321] usb 1-1.2.2: New USB device found, idVendor=058f, idProduct=6362, bcdDevice= 1.00 [163901.967343] usb 1-1.2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [163901.967359] usb 1-1.2.2: Product: Mass Storage Device [163901.967375] usb 1-1.2.2: Manufacturer: Generic [163901.967390] usb 1-1.2.2: SerialNumber: 058F312D81B [163901.970217] usb-storage 1-1.2.2:1.0: USB Mass Storage device detected [163901.970771] scsi host1: usb-storage 1-1.2.2:1.0 [163903.036487] scsi 1:0:0:0: Direct-Access Generic USB SD Reader 1.00 PQ: 0 ANSI: 0 [163903.037241] sd 1:0:0:0: Attached scsi generic sg1 type 0 [163903.038712] scsi 1:0:0:1: Direct-Access Generic USB CF Reader 1.01 PQ: 0 ANSI: 0 [163903.039297] sd 1:0:0:1: Attached scsi generic sg2 type 0 [163903.040713] scsi 1:0:0:2: Direct-Access Generic USB SM Reader 1.02 PQ: 0 ANSI: 0 [163903.041273] scsi 1:0:0:2: Attached scsi generic sg3 type 0 [163903.043009] scsi 1:0:0:3: Direct-Access Generic USB MS Reader 1.03 PQ: 0 ANSI: 0 [163903.043570] scsi 1:0:0:3: Attached scsi generic sg4 type 0 [163903.097573] sd 1:0:0:1: [sdc] Attached SCSI removable disk [163903.100928] sd 1:0:0:0: [sdb] Attached SCSI removable disk [163903.108183] sd 1:0:0:3: [sde] Attached SCSI removable disk [163903.109878] sd 1:0:0:2: [sdd] Attached SCSI removable disk from mount: ... dev/sda2 on /mnt/sda2 type ext4 (rw,relatime) tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=806492k,mode=700) from df: ... tmpfs 806492 0 806492 0% /run/user/1000 /dev/sda2 3844510712 90144 3649059904 1% /mnt/sda2 In case you have a power problem, everything here on both Pi4s runs via a Sitecom USB hub, it is even powering an older Raspi1 via some USB output (no you cannot connect via that). no extra mains adaptor needed! I like the thing. But this is running my modified old PI4 image on the new 8GB Pi4B, no idea if the recent raspios does the same. In My View Linux should have stayed with OSS audio, I had multi channel audio working 20 year ago on that, alsa broke everything and is counter Unix, now raspi changed audio again and the apt-upgrade f*cked up audio, on my old Pi4 image (I know, they call that 'improvement') so ffplay audio for example I needed a fix like this to play with ffplay via the audio jack: raspi99: ~ # cat /usr/local/sbin/ffplay2 #!/bin/bash SDL_AUDIODRIVER='alsa' AUDIODEV='hw:1,0' ffplay $1 so to play via the audio jack I use 'ffplay2 filename' Lots of work to get every script and thing going again. But I am glad with the Sitecom USB3 hub, have 2 now, one for each Pi4. Same for the Toshiba 3.4 TB USB3 harddisks connected to it, other one running 24/7 now for a year or so. hdparm shows amazing speed on those raspi99: ~ # hdparm -t /dev/sda2 /dev/sda2: Timing buffered disk reads: 408 MB in 3.00 seconds = 135.86 MB/sec raspi99: ~ # hdparm -T /dev/sda2 /dev/sda2: Timing cached reads: 1498 MB in 2.00 seconds = 749.07 MB/sec not bad!
[toc] | [prev] | [next] | [standalone]
| From | druck <news@druck.org.uk> |
|---|---|
| Date | 2021-01-02 12:36 +0000 |
| Message-ID | <rsppbk$cri$1@dont-email.me> |
| In reply to | #25372 |
On 01/01/2021 20:53, bob prohaska wrote: > Just tried using a couple of USB card adapters with my 8GB Pi4. > Both cause immediate loss of USB hard disk access. Unplugging > the offending adapter does not restore normal operation. Power > cycling puts matters right without apparent ill effect. Do you have your USB hard disk mounted using the device name (/dev/sdaX) or a disk UUID (UUID=blahblahblahblah) ? That should only make a difference when powering on with the adaptor present, not when plugging it in when running, but using UUIDs eliminates the issue of the device names ever changing. ---druck
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.sys.raspberry-pi
csiph-web