you are not logged in, login. new entry
text: sort by
tags: modified
type: chronology
hide / edit[1] / print
ref: -0 tags: US employment top 100 bar chart date: 11-12-2018 00:02 gmt revision:1 [0] [head]

After briefly searching the web, I could not find a chart of the top 100 occupations in the US. After downloading the data from the US Bureau of Labor Statistics, made this chart:

Click for full-size.

Surprising how very service heavy our economy is.

hide / edit[0] / print
ref: -0 tags: NC state tap drill chart date: 08-02-2016 18:38 gmt revision:0 [head]


by way of: https://m.reddit.com/r/engineering/comments/4ry07t/does_anyone_have_a_stored_copy_of_this_tap_and/

hide / edit[3] / print
ref: notes-0 tags: usbmon decode chart linux debug date: 07-12-2010 03:29 gmt revision:3 [2] [1] [0] [head]

From this and the USB 2.0 spec, I made this quick (totally incomprehensible?) key for understanding the output of commands like

# mount -t debugfs none_debugs /sys/kernel/debug
# modprobe usbmon
# cat /sys/kernel/debug/usbmon/2u

To be used with the tables from the (free) USB 2.0 spec:

hide / edit[7] / print
ref: notes-0 tags: nordic nrf24L01 state diagram flowchart SPI blackfin date: 06-25-2008 02:44 gmt revision:7 [6] [5] [4] [3] [2] [1] [head]


The goal is to use a nRF24L01 to make an asymmetrical, bidirectional link. The outgoing bandwidth should be maximized, ~1.5mbps, and the incoming bandwidth can be much smaller, ~17kbps, though on both channels we want guaranteed latency, < 4ms for the outgoing data, and < 10ms for the incoming data. Furthermore, the processor that is being used to run this, a blackfin BF532, does not seem to play well when both SPI DMA is enabled and most CPU time is being spent in SPORT ISR reading samples & processing them. Fortunately, the SPI port and SPORT can be run synchronously (provided the SPI port is clocked fast enough), allowing the processor to run one 'thread' e.g. no interrupts. It seem that with high-priority interrupts, the DMA engine is not able to service the SPI perfectly, and without DMA, data comes out of the SPI in drips and drabs, and cannot keep the radio's fifo full. Hence, must program a synchronous radio controller, where states are stored in variables and not in the program counter (PC register, saved upon interrupt, etc).

As in other postings on the nRF24L01, the plan is to keep the transmit fifo full for most of the 4ms allowed by the free-running pll, then transition back into either standby-I mode, or send a status packet. The status packet is always acknowledged by the primary receiver with a command packet, and this allows both synchronization and incoming bandwidth. Therefore, there are 4 classes of transfers:

  1. just a status packet. After uploading, wait for TX_DS IRQ, transition to RX mode, wait for RX_DR irq, clear ce, read in the packet, and set back to TX mode.
  2. one data packet + status packet. There are timeouts on both the transmission of data packets and status packets; in this case, both have been exceeded. Here TX data state is entered, the packet is uploaded, CE is asserted, send the status packet, wait for IRQ from both packets. This requires a transition from tx data CE high state to tx status CSN low state.
  3. many data packets and one status packet. This is the same as above, only the data transmission was triggered by a full threshold in the outgoing packet queue (in processor ram). In this case, two packets are uploaded to the radio before waiting for a TX_DS IRQ, and, at the end of the process, we have to wait for two TX_DS IRQs after uploading the data packet.
  4. many data packets. This is straightforward - upload 2 packets, wait for 1 TX_DS IRQ, {upload another, wait for IRQ}(until packets are gone), wait for final IRQ, set CE low.

screenshot of the derived code working (yea, my USB logic analyzer only runs on windows..yeck):

old versions: